[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: rbtree problems in libpthread
In article <200903311912.VAA0000110638%zel459.zel.kfa-juelich.de@localhost>,
Matthias Drochner <M.Drochner%fz-juelich.de@localhost> wrote:
>I've observed that some applications sometimes get an ESRCH error
>on pthread_join(). Added diagnostics but everything looks OK -
>just the RB_FIND() in libpthread:pthread__find() returns that error
>while the thread should be there.
>This could be a bug in the rbtree implementation, or some
>misuse or race condition in libpthread, or some memory
>Now I've added some fallback code to pthread__find() to
>look up the thread in pthread__allqueue if it wasn't found
>in pthread__alltree, and this did always succeed.
>I can't imagine a memory corruption so subtle that it
>damages the rbtree structures in a way that doesn't cause
>a crash, and still leaves the queue structures intact, and I
>also didn't find a misuse in libpthread, so I suspect
>the rbtree implementation.
>Has anyone seen that kind of problem? Is the rbtree code
>well tested or used in other subsystems?
>(btw, I think the use of rbtree in libpthread is not completely
>clean because the pointer subtraction in pthread__cmp() can
>overflow but this doesn't seem to be the problem here)
Do you have a regression test?
Main Index |
Thread Index |