From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 21:40:01 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5298F16A4CE for ; Tue, 9 Dec 2003 21:40:01 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11C9F43D29 for ; Tue, 9 Dec 2003 21:40:00 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id hBA5dxml016940; Wed, 10 Dec 2003 00:39:59 -0500 (EST) Date: Wed, 10 Dec 2003 00:39:59 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Craig Boston In-Reply-To: <200312092305.27056.craig@xfoil.gank.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: nss and pthreads and wine, oh my! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2003 05:40:01 -0000 On Tue, 9 Dec 2003, Craig Boston wrote: > I've come across a problem that I believe had been plaguing me on -CURRENT for > a while but I just now was able to track down a possible cause. The symptoms > are that wine is unable to run any Win32 program that uses gethostbyname or > getaddrinfo. I'm seeing this on a recent 5.2-BETA and also an older > 5.1-RELEASE, so I can rule out the statfs ABI changes. Wine is built from > source on both and without CPUTYPE on the 5.2-BETA machine. > > After building wine (and libc) with debug symbols, I can reproduce the > following backtrace of where the crash occurs: > > #0 0x5ce20000 in ?? () > #1 0x5c0f3c98 in _nsdispatch (retval=0x5c71f054, disp_tab=0x5c131400, > database=0x5c12c920 "hosts", method_name=0x5c12c912 "gethostbyname", > defaults=0x5c1313d0) at /usr/src/lib/libc/net/nsdispatch.c:574 > #2 0x5c0f3004 in gethostbyname2 (name=0x5d031c40 "test", > type=2) at /usr/src/lib/libc/net/gethostnamadr.c:88 > #3 0x5c0f2f9e in gethostbyname (name=0x5d031c40 "test") > at /usr/src/lib/libc/net/gethostnamadr.c:72 > > line 574 of nsdispatch.c looks like this: > > 574 result = _pthread_rwlock_rdlock(&nss_lock); > > Now, I've never really delved into libc before, so everything from this point > is pure guesswork. However, it strikes me as odd that nsdispatch() is > calling pthread locking primitives in the non-reentrant C library (wine is > linked against libc.so.5). > > A quick grep of the source code shows that the only other thing similar in > libc is in the RPC code, but in that case it uses a macro that checks > __isthreaded before calling the pthread function. According to the comments, > __isthreaded is only set if a process has more than 1 thread. So, I tried > wrapping all of the pthreads stuff in nsdispatch.c with if(__isthreaded) > blocks and presto, wine is working again. > > I have no idea why wine seems to be the only program that behaves this way... > At this point I'm not sure if it's a bug in libc or a bug in wine. Has > anybody else seen similar behavior out of wine or anything else? > > Are there any threads gurus out there who know what the 'right thing' for > nsdispatch to do is? Yes, I think libc should only call locking primitives when __isthread != 0. I am a bit confused though, because I would think nsdispatch works for other cases and don't know why it isn't for wine. What thread library are you using? -- Dan Eischen