[ Please CC replies to me, thanks! ] Hello glibc maintainers,
I wanted to zip a quick email off to you to ask and see if you might have time to give a quick think to a problem I've uncovered. It manifests itself in Tcl, but what has me suspicious is this: pthread_cond_wait: thread 1076375680 mutex 804c7d0 pthread_cond_broadcast: thread 1085057968 condptr 806bb00 cond_wait returned pthread_cond_wait: thread 1076375680 mutex 804c7d0 pthread_cond_broadcast: thread 1085057968 condptr 806bb00 cond_wait returned pthread_cond_timedwait: thread 1076375680 mutex 804c7d0 pthread_cond_broadcast: thread 1085057968 condptr 806bb00 timedwait returned pthread_cond_timedwait: thread 1076375680 mutex 804c7d0 pthread_cond_broadcast: thread 1085057968 condptr 806bb00 timedwait returned pthread_cond_wait: thread 1076375680 mutex 804c7d0 pthread_cond_broadcast: thread 1085057968 condptr 806bb00 *HANGS* Where *HANGS* means the calling thread is stuck here: 14:03:46.088569 futex(0x804a880, FUTEX_WAKE, 1) = 1 14:03:46.089297 futex(0x80f7228, FUTEX_WAKE, 1) = 1 14:03:46.089604 futex(0x80f7238, FUTEX_WAIT, 10191, NULL <unfinished ...> Which equates to here: Thread 1 (Thread 1076207744 (LWP 19681)): #0 0x400fb295 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 So, my thinking was starting to move towards "how is this Tcl's fault, or if it is, what's it doing wrong?". What could cause it to receive a wakeup, but not actually do so? Platform is i386, Debian sarge. We're still digging on the Tcl side... Thanks for any insights you might be able to provide. -- David N. Welton - http://www.dedasys.com/davidw/ Apache, Linux, Tcl Consulting - http://www.dedasys.com/
