pthread_cond_wait hanging in libthr
Josh Carroll
josh.carroll at gmail.com
Wed Feb 27 07:56:48 UTC 2008
I have been debugging a problem with ushare in FreeBSD 7.0,
specifically I have tracked it down to the pthread_cond_wait call
inside the libupnp library that ushare uses. UpnpInit ultimately calls
the below ithread_cond_wait, which is where I am seeing the "hang".
The code in question is on line 650 of:
/usr/ports/devel/upnp/work/libupnp-1.6.0/threadutil/src/ThreadPool.c
648 while( tp->totalThreads < currentThreads ) {
649
650 ithread_cond_wait( &tp->start_and_shutdown, &tp->mutex );
651
652 }
The call to ithread_cond_wait (#defined to pthread_cond_wait) hangs
indefinitely, causing ushare to never listen on the UPnP port. It only
does this when ushare is run with the -D option, indicating it should
daemonize. If I run it without -D, it works fine.
Here is the tail end of a truss of ushare when run with -D, at which
point it hangs and subsequently does not listen on the UPnP socket.
22539: mprotect(0x7fffff9fe000,4096,PROT_NONE) = 0 (0x0)
22539: thr_new(0x7fffffffe590,0x68,0x7fffffffe620,0x0,0xffffffffb05a9d40,0x7fffffffe538)
= 0 (0x0)
22539: _umtx_op(0x40e1c160,0x6,0x0,0x0,0x0,0x7fffffffe578) ERR#1
'Operation not permitted'
22539: _umtx_op(0x40e1e160,0x8,0x1,0x40e1e140,0x0,0x7fffffffe598)#
and here's the tail end of the ktrace for the same:
ushare CALL mmap(0x7fffff9fe000,0x201000,PROT_READ|PROT_WRITE,MAP_STACK,0xffffffff,0)
ushare RET mmap -6299648/0x7fffff9fe000
ushare CALL mprotect(0x7fffff9fe000,0x1000,PROT_NONE)
ushare RET mprotect 0
ushare CALL thr_new(0x7fffffffe9c0,0x68)
ushare RET thr_new 0
ushare RET fork 0
ushare CALL _umtx_op(0x40e1e160,0x8,0x1,0x40e1e140,0)
ushare RET _umtx_op -1 errno 1 Operation not permitted
ushare CALL _umtx_op(0x40e1e140,0x5,0,0,0)
ushare CALL _umtx_op(0x40e1c160,0x5,0,0,0)
ushare RET _umtx_op RESTART
ushare PSIG SIGTERM SIG_DFL
I pointed ushare and libupnp.so to libkse instead with libmap.conf,
and it works properly with libkse. It only exhibits this behavior with
libthr.
For now, I am using libmap.conf as a workaround, but there seems to be
a problem with libthr in this particular usage.
Please let me know if any other information is required. This is
7.0-RELEASE on amd64.
Thanks!
Josh
More information about the freebsd-stable
mailing list