Re: rbtree problems in libpthread

[christos%astron.com@localhost (Christos Zoulas)]

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
>corruption.
>
>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)
>
>best regards
>Matthias

Do you have a regression test?

christos