From owner-freebsd-stable@FreeBSD.ORG Wed Feb 27 07:56:48 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A81291065671 for ; Wed, 27 Feb 2008 07:56:48 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by mx1.freebsd.org (Postfix) with ESMTP id 7E8BA13C458 for ; Wed, 27 Feb 2008 07:56:48 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by wf-out-1314.google.com with SMTP id 25so2092133wfa.7 for ; Tue, 26 Feb 2008 23:56:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=NtcLQhB7ARJ97JrB7ss72QdsA/FwTp3CUuDLLAN+pzY=; b=mpMCvf6/bHbjMGSPP5OyI9Y+HJqGycc4BtBofAItmZo1PU3bJVLvHZdE2WASxDL/G7IahvLqYpZ16r+ewfkMPAM9A9i3Wt/U+mbExcTO/zUjXEC68FWYjrDRpwbIFF+2iF6a6P13Ew63mLdKJT0fkDX7LZCwP217F2vnwaeFMjE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=rMnSJp47CBAPr7ZP8EYCIlx1xMKVmtZIHwTQg2RtPF/CBJqH2NHUOU9Lrr/2Uj9phqtoIOobp7fDFvEIchUhDWNc0fc7V2LREbviz2kxEdyyIi1ttL9Y0qH37dIVPp8RRu5PMKxC2Aoq/EtZtFprc0MoYqyx8ULk4Hdd/AtCjH4= Received: by 10.142.216.9 with SMTP id o9mr4873078wfg.42.1204099007825; Tue, 26 Feb 2008 23:56:47 -0800 (PST) Received: by 10.143.195.2 with HTTP; Tue, 26 Feb 2008 23:56:47 -0800 (PST) Message-ID: <8cb6106e0802262356w497d9d29r417b09710a90f820@mail.gmail.com> Date: Wed, 27 Feb 2008 02:56:47 -0500 From: "Josh Carroll" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: pthread_cond_wait hanging in libthr X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 07:56:48 -0000 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