pthread weirdness
[ 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/
Reply to: