Date: Tue, 4 Mar 2008 03:48:18 GMT From: Josh Carroll <josh.carroll@gmail.com> To: freebsd-gnats-submit@FreeBSD.org Subject: threads/121343: pthread_cond_wait hanging in libthr Message-ID: <200803040348.m243mI8e013298@www.freebsd.org> Resent-Message-ID: <200803040400.m24401go009374@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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@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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200803040348.m243mI8e013298>