Bug mixing old sem_wait and new pthread_cond_broadcast

[Erland Lewin]

Hello,

I think there is a bug in linuxthreads, when the same thread uses
pthread calls from both the old calls and new calls (for instance, when
one library was made with an older glibc). I'm using glibc-2.2.2.

in __old_sem_wait (in oldsemaphore.c), the following is done:

self->p_nextwaiting = (pthread_descr) oldstatus;

as far as I can tell, this self->p_nextwaiting is never set to NULL
after returning, so "junk" (non-NULL values) can be in the
self->p_nextwaiting of a running thread after __old_sem_wait.

This will cause problems when the same thread later calls
pthread_cond_wait in condvar.c (the thread will be enqueued with its
p_nextwaiting set to a junk value). Actually, the ASSERT macro in
enqueue in queue.h should trigger at this point.
  If it doesn't fail the assertion, a subsequent pthread_cond_broadcast
will crash when dequeueing the thread with p_nextwaiting set to
something which is an invalid pointer.

A fix is to, in oldsemaphore.c, line 119, insert
  
  self->p_nextwaiting = NULL;

before

  return 0;

Of course there might be better ways.


By the way, where can I find documentation of versioning and dynamic
linking? I don't understand why a program I'm compiling and linking ends
up with links to older versions of glibc (I look at the executable with
ldd -v).

  Please cc replies to me since I don't subscribe to bug-glibc.

    Best regards,

      Erland