threads/121343: pthread_cond_wait hanging in libthr

[Josh Carroll]

>Number:         121343
>Category:       threads
>Synopsis:       pthread_cond_wait hanging in libthr
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-threads
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Mar 04 04:00:01 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator:     Josh Carroll
>Release:        7.0-RELEASE
>Organization:
n/a
>Environment:
FreeBSD pflog.net 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Tue Feb 26 01:20:52 EST 2008     root at pflog.net:/usr/obj/usr/src/sys/PFLOG  amd64
>Description:
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.
>How-To-Repeat:
Since libupnp 1.6.0 doesn't compile on FreeBSD 7.0/amd64, I have been using 1.6.5, which includes my upstream source patch discussed here:

http://www.freebsd.org/cgi/query-pr.cgi?pr=119120

I have a tarball of a upnp 1.6.5 setup here:

http://pflog.net/new_upnp.tgz
>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted: