From owner-freebsd-threads@FreeBSD.ORG Sun Aug 15 17:04:07 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D55A616A4D1 for ; Sun, 15 Aug 2004 17:04:07 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F26943D1F for ; Sun, 15 Aug 2004 17:04:07 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7FH2KOl061958 for ; Sun, 15 Aug 2004 13:02:20 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7FH2KGr061955 for ; Sun, 15 Aug 2004 13:02:20 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 15 Aug 2004 13:02:20 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: threads@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: thread-unsafe syslog code in libc? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2004 17:04:08 -0000 I recently resolved a kernel race reported by Martin Blapp in which a file descriptor had connect() called on it by one thread, and was simultaenously close()'d by another. The bug resulted in a kernel crash, which is certainly not the right response, and I'm working on a number of aspects of that problem. However, this also speaks to a race in user space. The socket in question was being connected to /var/run/log, so I believe it was made from the libc syslog code. A glance at src/lib/libc/gen/syslog.c suggests that things are indeed a bit un-threadsafe, especially in vsyslog(), where things get connected and disconnected a fair amount. I'm guessing we need some sort of synchronization around use of that file descriptor to prevent this sort of race from happening in the future, as potentially it might lose log records, etc. It's also doing a lot of work by reconnecting so frequently, and I have to wonder if we can't improve the performance of applications using syslog by doing a better job at using a single connection... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-threads@FreeBSD.ORG Sun Aug 15 19:58:07 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CD3A16AF51; Sun, 15 Aug 2004 19:58:07 +0000 (GMT) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A44E43D4C; Sun, 15 Aug 2004 19:58:07 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (dsl081-189-067.sea1.dsl.speakeasy.net [64.81.189.67]) by blake.polstra.com (8.12.11/8.12.11) with ESMTP id i7FJw6O2068088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Aug 2004 12:58:06 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.11/8.12.11/Submit) id i7FJw6nQ013644; Sun, 15 Aug 2004 12:58:06 -0700 (PDT) (envelope-from jdp) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sun, 15 Aug 2004 12:58:06 -0700 (PDT) From: John Polstra To: Robert Watson X-Bogosity: No, tests=bogofilter, spamicity=0.016632, version=0.14.5 cc: threads@freebsd.org Subject: RE: thread-unsafe syslog code in libc? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2004 19:58:07 -0000 On 15-Aug-2004 Robert Watson wrote: > > I recently resolved a kernel race reported by Martin Blapp in which a file > descriptor had connect() called on it by one thread, and was > simultaenously close()'d by another. The bug resulted in a kernel crash, > which is certainly not the right response, and I'm working on a number of > aspects of that problem. However, this also speaks to a race in user > space. The socket in question was being connected to /var/run/log, so I > believe it was made from the libc syslog code. A glance at > src/lib/libc/gen/syslog.c suggests that things are indeed a bit > un-threadsafe, especially in vsyslog(), where things get connected and > disconnected a fair amount. I don't see any repeated connecting and disconnecting in vsyslog except under error conditions. Here's the relevant code, with my commentary non-indented: /* Get connected, output the message to the local logger. */ if (!opened) openlog(LogTag, LogStat | LOG_NDELAY, 0); connectlog(); Note that connectlog() is a no-op if we are already connected (the expected case after the first call). if (send(LogFile, tbuf, cnt, 0) >= 0) return; If the send succeeds (the normal case) we return here and don't disconnect. /* * If the send() failed, the odds are syslogd was restarted. * Make one (only) attempt to reconnect to /dev/log. */ disconnectlog(); connectlog(); if (send(LogFile, tbuf, cnt, 0) >= 0) return; The above is only to handle an unusual error case. There is some thread-unsafeness here, but it doesn't look like it would matter under normal conditions. John From owner-freebsd-threads@FreeBSD.ORG Sun Aug 15 20:37:33 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E444A16A4F5; Sun, 15 Aug 2004 20:37:33 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D9D043F54; Sun, 15 Aug 2004 20:13:52 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7FKC4XO064557; Sun, 15 Aug 2004 16:12:04 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7FKC4JC064554; Sun, 15 Aug 2004 16:12:04 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 15 Aug 2004 16:12:04 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: John Polstra In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: mbr@freebsd.org Subject: RE: thread-unsafe syslog code in libc? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2004 20:37:36 -0000 On Sun, 15 Aug 2004, John Polstra wrote: > The above is only to handle an unusual error case. > > There is some thread-unsafeness here, but it doesn't look like it would > matter under normal conditions. So maybe we're dealing with a user space race where multiple threads attempt to do a first syslog in parallel? Martin -- do we know exactly what that application does threadwise to generate this problem? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-threads@FreeBSD.ORG Sun Aug 15 21:12:27 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CE8C16A4CE; Sun, 15 Aug 2004 21:12:27 +0000 (GMT) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id A189F43D1D; Sun, 15 Aug 2004 21:12:26 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (dsl081-189-067.sea1.dsl.speakeasy.net [64.81.189.67]) by blake.polstra.com (8.12.11/8.12.11) with ESMTP id i7FLCQZp068615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Aug 2004 14:12:26 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.11/8.12.11/Submit) id i7FLCQwg013721; Sun, 15 Aug 2004 14:12:26 -0700 (PDT) (envelope-from jdp) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sun, 15 Aug 2004 14:12:25 -0700 (PDT) From: John Polstra To: Robert Watson X-Bogosity: No, tests=bogofilter, spamicity=0.047737, version=0.14.5 cc: threads@freebsd.org cc: mbr@freebsd.org Subject: RE: thread-unsafe syslog code in libc? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2004 21:12:27 -0000 On 15-Aug-2004 Robert Watson wrote: > On Sun, 15 Aug 2004, John Polstra wrote: > >> The above is only to handle an unusual error case. >> >> There is some thread-unsafeness here, but it doesn't look like it would >> matter under normal conditions. > > So maybe we're dealing with a user space race where multiple threads > attempt to do a first syslog in parallel? Probably not that. You said it was a simultaneous connect() and close(), right? The close is only done in disconnectlog() and closelog(). The former is only called in unusual error cases, and the latter is called by applications. So I guess one culprit could be a first syslog call in one thread and a closelog call in another thread. Or, maybe the system ran out of mbufs and the send() did fail, causing disconnectlog to be used and exercising the race. An out of mbufs condition might also contribute to the kernel panic you mentioned. John From owner-freebsd-threads@FreeBSD.ORG Sun Aug 15 21:21:23 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D27B016A4CE; Sun, 15 Aug 2004 21:21:23 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8849C43D2F; Sun, 15 Aug 2004 21:21:23 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7FLJZCJ065508; Sun, 15 Aug 2004 17:19:35 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7FLJZSD065505; Sun, 15 Aug 2004 17:19:35 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 15 Aug 2004 17:19:35 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: John Polstra In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: mbr@freebsd.org Subject: RE: thread-unsafe syslog code in libc? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2004 21:21:24 -0000 On Sun, 15 Aug 2004, John Polstra wrote: > On 15-Aug-2004 Robert Watson wrote: > > On Sun, 15 Aug 2004, John Polstra wrote: > > > >> The above is only to handle an unusual error case. > >> > >> There is some thread-unsafeness here, but it doesn't look like it would > >> matter under normal conditions. > > > > So maybe we're dealing with a user space race where multiple threads > > attempt to do a first syslog in parallel? > > Probably not that. You said it was a simultaneous connect() and > close(), right? The close is only done in disconnectlog() and > closelog(). The former is only called in unusual error cases, and the > latter is called by applications. So I guess one culprit could be a > first syslog call in one thread and a closelog call in another thread. > > Or, maybe the system ran out of mbufs and the send() did fail, causing > disconnectlog to be used and exercising the race. An out of mbufs > condition might also contribute to the kernel panic you mentioned. The race in question was one where we failed to protect against namei() in connect() possibly sleeping during a lookup and a close() on the file descriptor during that period disconnecting the PCB from the socket. When connect() woke up again, it would try to dereference the PCB and cause a page fault. The problem is a larger issue concerning how we want to handle file descriptors, etc, but it was triggered by odd use of a file descriptor in user space that is also suggestive of a user space race. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-threads@FreeBSD.ORG Sun Aug 15 23:04:01 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF0CB16A4CE; Sun, 15 Aug 2004 23:04:01 +0000 (GMT) Received: from mx1.imp.ch (mx1.imp.ch [157.161.9.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8457643D1F; Sun, 15 Aug 2004 23:04:00 +0000 (GMT) (envelope-from mb@imp.ch) Received: from mx2.imp.ch (mx2o [157.161.9.17]) by mx1.imp.ch (8.12.11/8.12.11) with ESMTP id i7FN3r9U090572; Mon, 16 Aug 2004 01:03:54 +0200 (CEST) (envelope-from mb@imp.ch) Received: from mx2.imp.ch (localhost [127.0.0.1]) by mx2.imp.ch (8.12.11/8.12.11/Submit) with ESMTP id i7FN3pH1064833; Mon, 16 Aug 2004 01:03:51 +0200 (CEST) (envelope-from mb@imp.ch) Received: (from clamav@localhost) by mx2.imp.ch (8.12.11/8.12.11/Submit) id i7FN3o5T064829; Mon, 16 Aug 2004 01:03:50 +0200 (CEST) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by ns1.imp.ch (MIMEDefang) with ESMTP id i7FN3kZW031731; Mon, 16 Aug 2004 01:03:50 +0200 (CEST) Date: Mon, 16 Aug 2004 01:03:46 +0200 (CEST) From: Martin Blapp To: John Polstra In-Reply-To: Message-ID: <20040816010320.N20538@cvs.imp.ch> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Resent: Yes X-Spam-Checksum: a31e8437fc8cd41681b976b4fce5bd4a X-Virus-Message-Status: No X-Virus-Status: No, scantime="0.0075 seconds" X-Spam-Status: No, hits=-4.9 required=5 scantime="2.3598 seconds" tests=BAYES_00 X-Scanned-By: MIMEDefang 2.44 cc: threads@freebsd.org cc: mbr@freebsd.org cc: Robert Watson Subject: RE: thread-unsafe syslog code in libc? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2004 23:04:01 -0000 Hi, > Or, maybe the system ran out of mbufs and the send() did fail, causing > disconnectlog to be used and exercising the race. An out of mbufs > condition might also contribute to the kernel panic you mentioned. This didn't happen. Martin From owner-freebsd-threads@FreeBSD.ORG Mon Aug 16 11:03:15 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 417FF16A4DA for ; Mon, 16 Aug 2004 11:03:15 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17AE143D1D for ; Mon, 16 Aug 2004 11:03:15 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i7GB3EOn097207 for ; Mon, 16 Aug 2004 11:03:14 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i7GB3Drk097189 for freebsd-threads@freebsd.org; Mon, 16 Aug 2004 11:03:13 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 16 Aug 2004 11:03:13 GMT Message-Id: <200408161103.i7GB3Drk097189@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2004 11:03:15 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything s [2004/03/15] kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/un o [2004/04/22] threads/65883threads libkse's sigwait does not work after fork 3 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/07/18] kern/20016 threads pthreads: Cannot set scheduling timer/Can o [2000/08/26] misc/20861 threads libc_r does not honor socket timeouts o [2001/01/20] bin/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVT o [2001/01/25] bin/24632 threads libc_r delicate deviation from libc in ha o [2001/01/25] misc/24641 threads pthread_rwlock_rdlock can deadlock o [2001/11/26] bin/32295 threads pthread dont dequeue signals o [2002/02/01] i386/34536 threads accept() blocks other threads o [2002/05/25] kern/38549 threads the procces compiled whith pthread stoppe o [2002/06/27] threads/39922threads [PATCH?] Threaded applications executed w o [2002/08/04] misc/41331 threads Pthread library open sets O_NONBLOCK flag o [2003/03/02] threads/48856threads Setting SIGCHLD to SIG_IGN still leaves z o [2003/03/10] threads/49087threads Signals lost in programs linked with libc o [2003/05/08] threads/51949threads thread in accept cannot be cancelled 13 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/05/26] misc/18824 threads gethostbyname is not thread safe o [2000/10/21] misc/22190 threads A threaded read(2) from a socketpair(2) f o [2001/09/09] threads/30464threads pthread mutex attributes -- pshared o [2002/05/02] threads/37676threads libc_r: msgsnd(), msgrcv(), pread(), pwri s [2002/07/16] threads/40671threads pthread_cancel doesn't remove thread from o [2004/07/13] threads/69020threads pthreads library leaks _gc_mutex 6 problems total. From owner-freebsd-threads@FreeBSD.ORG Fri Aug 20 06:59:19 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6C8316A4CE for ; Fri, 20 Aug 2004 06:59:19 +0000 (GMT) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18BAB43D2F for ; Fri, 20 Aug 2004 06:59:19 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.102] (ddsl-66-42-172-210.fuse.net [66.42.172.210]) (authenticated bits=0)i7K6kmjr093303 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 20 Aug 2004 02:46:48 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-threads@freebsd.org Date: Fri, 20 Aug 2004 03:00:35 -0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <200408200300.43060.mistry.7@osu.edu> X-Spam-Status: No, hits=-2.4 required=5.0 tests=PGP_SIGNATURE,RCVD_IN_ORBS,USER_AGENT_KMAIL version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: Wine and CURRENT X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2004 06:59:19 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've managed to get the post May versions on wine to be able to mmap their= =20 memory properly by patching our mmap implementation (see current mailling=20 list), but I'm having the following problem that I can't figure out: =46atal error 'Uninitialized mutex in pthread_mutex_trylock_basic' at line = 474=20 in file /usr/src/lib/libpthread/thread/thr_mutex.c (errno =3D 0) Here is a backtrace if it helps. (gdb) bt #0 0x97f9c2cf in kill () from /lib/libc.so.5 #1 0x97f913c2 in raise () from /lib/libc.so.5 #2 0x98003717 in abort () from /lib/libc.so.5 #3 0x00d94550 in pthread_testcancel () from /usr/lib/libpthread.so.1 #4 0x00d87f08 in _pthread_mutex_trylock () from /usr/lib/libpthread.so.1 #5 0x00d895a3 in _pthread_mutex_lock () from /usr/lib/libpthread.so.1 #6 0x00d86cb0 in pthread_once () from /usr/lib/libpthread.so.1 #7 0x97fd5e5b in __res_randomid () from /lib/libc.so.5 #8 0x97fd5f11 in _ () from /lib/libc.so.5 #9 0x97fe1a59 in gethostbyname () from /lib/libc.so.5 #10 0x00c89f67 in _X11TransSocketINETConnect ()=20 from /usr/X11R6/lib/libX11.so.6 #11 0x00c8b17b in _X11TransConnect () from /usr/X11R6/lib/libX11.so.6 #12 0x00c53dfd in _X11TransConnectDisplay () from /usr/X11R6/lib/libX11.so.6 #13 0x00c63046 in XOpenDisplay () from /usr/X11R6/lib/libX11.so.6 #14 0x00bf8d26 in x11drv_init_thread_data () at x11drv_main.c:470 #15 0x00bd1612 in X11DRV_create_desktop (desktop_vi=3D0x77f24000,=20 geometry=3D0x77f07270 "800x600") at x11drv.h:376 #16 0x00bf9ce0 in DllMain (hinst=3D0xbc0000, reason=3D1, reserved=3D0x0) at x11drv_main.c:391 #17 0x00bc86cc in __wine_dll_main () from /usr/local/lib/wine/x11drv.dll.so #18 0x0003a4ee in call_dll_entry_point () at loader.c:53 #19 0x0003d0a1 in MODULE_InitDLL (wm=3D0x1b2188, reason=3D1, lpReserved=3D0= x0) at loader.c:741 =2D ---Type to continue, or q to quit--- #20 0x0003d1c2 in process_attach (wm=3D0x1b2188, lpReserved=3D0x0) at loade= r.c:814 #21 0x0003dac7 in LdrLoadDll (path_name=3D0x1b2050, flags=3D0, libname=3D0x= 5bfa40,=20 hModule=3D0x5bfa3c) at loader.c:1575 #22 0x002f6915 in LoadLibraryExW (libnameW=3D0x9802ac00, hfile=3D0x0, flags= =3D0) at module.c:667 #23 0x002f6a4e in LoadLibraryExA (libname=3D0x5bfcb0 "x11drv", hfile=3D0x0,= =20 flags=3D0) at module.c:703 #24 0x002f6a78 in LoadLibraryA (libname=3D0x5bfcb0 "x11drv") at module.c:741 #25 0x00666f2e in DllMain (inst=3D0x5e0000, reason=3D1, reserved=3D0x1) at user_main.c:75 #26 0x005f12c0 in __wine_dll_main () from /usr/local/lib/wine/user32.dll.so #27 0x0003a4ee in call_dll_entry_point () at loader.c:53 #28 0x0003d0a1 in MODULE_InitDLL (wm=3D0x180868, reason=3D1, lpReserved=3D0= x1) at loader.c:741 #29 0x0003d1c2 in process_attach (wm=3D0x180868, lpReserved=3D0x1) at loade= r.c:814 #30 0x0003d224 in process_attach (wm=3D0x180730, lpReserved=3D0x1) at loade= r.c:806 #31 0x0003d5a1 in LdrInitializeThunk (main_file=3D0x18, unknown2=3D0, unkno= wn3=3D0,=20 unknown4=3D0) at loader.c:1912 #32 0x002ffde6 in start_process (arg=3D0x0) at process.c:983 #33 0x97f3c38d in wine_switch_to_stack () at port.c:38 Any suggestions? Thanks. =2D --=20 Anish Mistry =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBJaGaxqA5ziudZT0RApPsAKCZcG4KMmUO+AxbuKRXIkX3gXpyvACeIVti 1Ie9cvuBLDfkQWcWIfDFqgs=3D =3DS3wK =2D----END PGP SIGNATURE----- From owner-freebsd-threads@FreeBSD.ORG Sat Aug 21 02:52:42 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E83A16A4CE for ; Sat, 21 Aug 2004 02:52:42 +0000 (GMT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC37043D2D for ; Sat, 21 Aug 2004 02:52:41 +0000 (GMT) (envelope-from burpmaster@truffula.net) Received: from [192.168.0.2] (c-67-169-200-31.client.comcast.net[67.169.200.31]) by comcast.net (sccrmhc13) with ESMTP id <2004082102524001600jro07e> (Authid: rogers240); Sat, 21 Aug 2004 02:52:41 +0000 Message-ID: <4126B8F4.4050809@truffula.net> Date: Fri, 20 Aug 2004 19:52:36 -0700 From: Brian Rogers User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040806) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-threads@freebsd.org References: <200408200300.43060.mistry.7@osu.edu> In-Reply-To: <200408200300.43060.mistry.7@osu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Wine and CURRENT X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2004 02:52:42 -0000 Anish Mistry wrote: >I've managed to get the post May versions on wine to be able to mmap their memory properly by patching our mmap implementation (see current mailling list) > Great! >but I'm having the following problem that I can't figure out: > >Fatal error 'Uninitialized mutex in pthread_mutex_trylock_basic' at line 474 >in file /usr/src/lib/libpthread/thread/thr_mutex.c (errno = 0) > > Wine doesn't like being linked to libpthread, and that happens through winearts.drv.so and the libraries that use OpenGL. To deal with OpenGL, I mapped libpthread to libc (not libc_r, wine doesn't like that either) for libGL.so, effectively canceling it out. You can avoid winearts.drv.so by disabling sound in the wine config or switching to a different audio driver. Alternatively, you can just use wine-pthread. It actually works, and it doesn't have a problem with libpthread. You just have to "cd loader && gmake wine-pthread" to build it. From owner-freebsd-threads@FreeBSD.ORG Sat Aug 21 22:30:28 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0E8D16A4D0 for ; Sat, 21 Aug 2004 22:30:28 +0000 (GMT) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00F3743D45 for ; Sat, 21 Aug 2004 22:30:19 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.102] (ddsl-66-42-172-210.fuse.net [66.42.172.210]) (authenticated bits=0)i7LMHbjr081761 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 21 Aug 2004 18:17:37 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-threads@freebsd.org Date: Sat, 21 Aug 2004 18:31:31 -0400 User-Agent: KMail/1.6.2 References: <200408200300.43060.mistry.7@osu.edu> <4126B8F4.4050809@truffula.net> In-Reply-To: <4126B8F4.4050809@truffula.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200408211831.39430.mistry.7@osu.edu> X-Spam-Status: No, hits=-4.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,J_CHICKENPOX_52,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_KMAIL version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: Brian Rogers Subject: Re: Wine and CURRENT X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2004 22:30:29 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 20 August 2004 10:52 pm, Brian Rogers wrote: > Anish Mistry wrote: > >I've managed to get the post May versions on wine to be able to mmap the= ir > > memory properly by patching our mmap implementation (see current mailli= ng > > list) > > Great! > > >but I'm having the following problem that I can't figure out: > > > >Fatal error 'Uninitialized mutex in pthread_mutex_trylock_basic' at line > > 474 in file /usr/src/lib/libpthread/thread/thr_mutex.c (errno =3D 0) > > Wine doesn't like being linked to libpthread, and that happens through > winearts.drv.so and the libraries that use OpenGL. To deal with OpenGL, > I mapped libpthread to libc (not libc_r, wine doesn't like that either) > for libGL.so, effectively canceling it out. You can avoid > winearts.drv.so by disabling sound in the wine config or switching to a > different audio driver. > Ok, using libmap seemed to work here on CURRENT. > Alternatively, you can just use wine-pthread. It actually works, and it > doesn't have a problem with libpthread. You just have to "cd loader && > gmake wine-pthread" to build it. Wasn't able to make this work CURRENT, but works on 4-STABLE. I kept getti= ng: =46atal error 'can not create signal daemon thread! ' at line 238 in file /usr/src/lib/libpthread/thread/thr_sig.c (errno =3D 1= 2) I'm now getting this only on some apps (others work fine), which looks to b= e=20 more mmap issues or something in wine. err:virtual:map_image Image was mapped at 0x4c0000: standard load address f= or=20 a Win32 program (0x00400000) not available err:virtual:map_image Do you have exec-shield or prelink active? Thanks, I think I'll be able to make some changes to get this stuff working. =2D --=20 Anish Mistry =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBJ81KxqA5ziudZT0RAlJSAJ0akGg1417qwnV+1zC3tb0U8iq8YQCdF9cy EAGFCwjApuWDf7FCBNlcUl0=3D =3DlxAR =2D----END PGP SIGNATURE-----