Hi -
Looks like there's a race condition when we destroy a condition variable.
My understanding of the expected behavior is that once all the threads have
been signaled (i.e, pthread_cond_broadcast is called), the condition
variable can be safely destroyed with pthread_cond_destroy.
The problem is in glibc's libpthread/sysdeps/generic/pt-cond-timedwait.c.
After __pthread_block() returns, we spinlock on cond->__lock. The problem
is that our __pthread_block() is just a mach_msg receive, and our
__pthread_wakeup() (called by pthread_cond_broadcast) is just a mach_msg
send.
So we can do a pthread_cond_broadcast, which will send messages to all
waiting threads, but there's no guarantee that the threads have received
the message; the message could be queued. Then we destroy the condition
variable, then the thread receives the message and tries on spinlock on a
free'd region of memory.
It looks like the whole reason for that spinlock is to figure out if
somebody else removed us from the wait queue, and to remove ourselves from
the wait queue if they did not (i.e, we timed out).
I'm puzzling about how to fix it, other than by reorganizing my libpager
code so that condition variables don't get destroyed very often.
Also, I'm a bit confused by the management of the source code. Is the
authoritative copy at git://git.savannah.gnu.org:/hurd/libpthread.git?
agape
brent
