From owner-freebsd-threads@FreeBSD.ORG Mon Sep 17 04:35:34 2007 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46C2A16A419; Mon, 17 Sep 2007 04:35:34 +0000 (UTC) (envelope-from lavajoe@gentoo.org) Received: from shadow.wildlava.net (shadow.wildlava.net [67.40.138.81]) by mx1.freebsd.org (Postfix) with ESMTP id 027D013C46A; Mon, 17 Sep 2007 04:35:31 +0000 (UTC) (envelope-from lavajoe@gentoo.org) Received: from [67.40.138.82] (crater.wildlava.net [67.40.138.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shadow.wildlava.net (Postfix) with ESMTP id 1F5188F424; Sun, 16 Sep 2007 22:35:31 -0600 (MDT) Message-ID: <46EE0412.70206@gentoo.org> Date: Sun, 16 Sep 2007 22:35:30 -0600 From: Joe Peterson User-Agent: Thunderbird 2.0.0.6 (X11/20070822) MIME-Version: 1.0 To: Jason Evans References: <46E9CBC8.3060906@gentoo.org> <46E9E867.7030909@freebsd.org> <46EAEABA.20003@gentoo.org> <46EB152B.1080905@freebsd.org> In-Reply-To: <46EB152B.1080905@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: David Xu , freebsd-threads@freebsd.org Subject: Re: Segfault when mapping libpthread -> libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 04:35:34 -0000 Jason Evans wrote: > I saw something similar a while back when investigating malloc problem > reports (that turned out to be a threads problem). It looked to me like > there was a minor incompatibility in the exported symbols of libpthread > and libthr that caused rtld to pull some symbols from libpthread, > despite the libmap.conf settings. IIRC, the symbol incompatibilities > did not at first glance seem like they would cause the problem, but my > guess (unverified) was that dynamic dependency resolution was chasing a > dependency into libpthread before a legitimate dependency through libthr > managed to map the symbol. > > I'm sorry that I don't remember the nature of the library interface > incompatibilities. It seems to me though that it was pretty subtle, > having to do with weak internally exported symbols (available to other > .o's within the library, but not to external consumers of the library). This would indeed explain the issue. It is as if some symbols come from libthr and some from libpthread. Or maybe sometimes the libthr version gets called and other timed the libpthread. For now, I am symlinking libpthread.so and libc_r.so to libthr.so (and same for the .a files), and this seems to fix the issue. These are the same libs that we map in libmap.conf. If you remember more about this let me know, or if anyone else knows more about this potential issue, I'd love to hear more! Thanks, Joe From owner-freebsd-threads@FreeBSD.ORG Mon Sep 17 11:08:21 2007 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8561416A41A for ; Mon, 17 Sep 2007 11:08:21 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6A2F513C469 for ; Mon, 17 Sep 2007 11:08:21 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8HB8Lur049557 for ; Mon, 17 Sep 2007 11:08:21 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8HB8Kk2049553 for freebsd-threads@FreeBSD.org; Mon, 17 Sep 2007 11:08:20 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Sep 2007 11:08:20 GMT Message-Id: <200709171108.l8HB8Kk2049553@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 11:08:21 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s threa/76690 threads fork hang in child for -lc_r 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/20016 threads pthreads: Cannot set scheduling timer/Cannot set virtu s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s bin/32295 threads pthread dont dequeue signals s threa/34536 threads accept() blocks other threads o kern/38549 threads the procces compiled whith pthread stopped in pthread_ s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/49087 threads Signals lost in programs linked with libc_r s kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/unset O_NONBLOC o threa/70975 threads unexpected and unreliable behaviour when using SYSV se o threa/72429 threads threads blocked in stdio (fgets, etc) are not cancella o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag s threa/76694 threads fork cause hang in dup()/close() function in child (-l o threa/79683 threads svctcp_create() fails if multiple threads call at the o threa/80435 threads panic on high loads o threa/83914 threads [libc] popen() doesn't work in static threaded program s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/85160 threads [libthr] [patch] libobjc + libpthread/libthr crash pro o kern/91266 threads [threads] Trying sleep, but thread marked as sleeping s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r o threa/101323 threads fork(2) in threaded programs broken. o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/110636 threads gdb(1): using gdb with multi thread application with l o threa/113666 threads misc/shared-mime-info doesn't install, can't find thre 28 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19247 threads uthread_sigaction.c does not do anything wrt SA_NOCLDW s kern/22190 threads A threaded read(2) from a socketpair(2) fd can sometim s threa/30464 threads pthread mutex attributes -- pshared s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/69020 threads pthreads library leaks _gc_mutex o threa/79887 threads [patch] freopen() isn't thread-safe o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/81534 threads [libc_r] [patch] libc_r close() will fail on any fd ty o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/115211 threads pthread_atfork misbehaves in initial thread 11 problems total. From owner-freebsd-threads@FreeBSD.ORG Wed Sep 19 16:12:43 2007 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AAE516A418 for ; Wed, 19 Sep 2007 16:12:43 +0000 (UTC) (envelope-from sean@chittenden.org) Received: from smtp2.joyent.net (smtp2.joyent.net [8.12.32.84]) by mx1.freebsd.org (Postfix) with ESMTP id 5C3C613C442 for ; Wed, 19 Sep 2007 16:12:43 +0000 (UTC) (envelope-from sean@chittenden.org) Received: from [10.0.0.51] (bigip_float [10.12.32.12]) by smtp2.joyent.net (Postfix) with ESMTP id 0A9E9E924 for ; Wed, 19 Sep 2007 08:41:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <22249390-ABCD-4993-977C-02D7AEB0CE69@chittenden.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: threads@freebsd.org From: Sean Chittenden Date: Wed, 19 Sep 2007 08:41:46 -0700 X-Mailer: Apple Mail (2.752.3) Cc: Subject: Programatic way to determine the contents of struct pthread_*_t... X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 16:12:43 -0000 Howdy. What's the best way to programatically gain access to the contents of the various struct pthread_*_t members? In OS-X and Linux, the contents are defined in /usr/include/*/_*pthreads.h, but that doesn't appear to be the case for FreeBSD at the moment. I'm in the process of porting D's Tango runtime to FreeBSD[1] and it appears that due to FreeBSD's multi-thread model, this is a bit problematic. Is there an obvious (or not so obvious) magic woobie stick that I can shake at this problem? I'm mostly done with the port at this point, but am a bit perplexed as to how to approach the poking at internals problem since D's runtime environment is possibly tied to my kernel configuration. Less than keen on that reality. Can I safely assume that libthr is now king of the hill and isn't about to be dethroned anytime soon? Having looked at src/lib/lib(thr|pthread)/thread/thr_private.h - the sizes are different, the contents are different, etc. Given other platforms have this publicly defined in userspace and we don't... is this going to get kicked over to userland again at somepoint or are we always going to be indirectly passing around pthread_*_t structs? Thoughts/suggestions? Thanks in advance! -sc [1] D is a slick language and very much worth a hander if you haven't poked at it before. Tango is an alternate standard class library and runtime environment for D that has many performance advantages over the stock runtime environment. Tango Info: http://www.dsource.org/projects/tango D Info: http://www.digitalmars.com/d/ PS Very aware of the dangers/stupidity associated with poking at the contents of structures, but for the time being, that's how tango works for threading compatibilities. If there's a #define that specifies the version number of the pthreads structures, I'd love to make use of it as a safety belt. -- Sean Chittenden sean@chittenden.org From owner-freebsd-threads@FreeBSD.ORG Wed Sep 19 16:53:05 2007 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C69D16A419 for ; Wed, 19 Sep 2007 16:53:05 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 52EB313C48A for ; Wed, 19 Sep 2007 16:53:05 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 5DB821A4D7C; Wed, 19 Sep 2007 09:24:59 -0700 (PDT) Date: Wed, 19 Sep 2007 09:24:59 -0700 From: Alfred Perlstein To: Sean Chittenden Message-ID: <20070919162459.GD79417@elvis.mu.org> References: <22249390-ABCD-4993-977C-02D7AEB0CE69@chittenden.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22249390-ABCD-4993-977C-02D7AEB0CE69@chittenden.org> User-Agent: Mutt/1.4.2.3i Cc: threads@freebsd.org Subject: Re: Programatic way to determine the contents of struct pthread_*_t... X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 16:53:05 -0000 * Sean Chittenden [070919 09:12] wrote: > Howdy. What's the best way to programatically gain access to the > contents of the various struct pthread_*_t members? In OS-X and > Linux, the contents are defined in /usr/include/*/_*pthreads.h, but > that doesn't appear to be the case for FreeBSD at the moment. I'm in > the process of porting D's Tango runtime to FreeBSD[1] and it appears > that due to FreeBSD's multi-thread model, this is a bit problematic. > Is there an obvious (or not so obvious) magic woobie stick that I can > shake at this problem? I'm mostly done with the port at this point, > but am a bit perplexed as to how to approach the poking at internals > problem since D's runtime environment is possibly tied to my kernel > configuration. Less than keen on that reality. Can I safely assume > that libthr is now king of the hill and isn't about to be dethroned > anytime soon? Sean, one thing you might look at is providing an _np() api set for accessing the required data. If this is non-workable, what I suggest doing for the time being is adding some kind of version retrieval function for the thhreading libraries and then just duplicate the struts, at least for the time being. Can you describe what sort of internal access this program you're working on requires? -Alfred From owner-freebsd-threads@FreeBSD.ORG Wed Sep 19 19:00:37 2007 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E40FD16A417 for ; Wed, 19 Sep 2007 19:00:37 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9DE0A13C4D9 for ; Wed, 19 Sep 2007 19:00:37 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.1/8.14.1/NETPLEX) with ESMTP id l8JIa1eS002258; Wed, 19 Sep 2007 14:36:01 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.netplex.net [204.213.176.10]); Wed, 19 Sep 2007 14:36:01 -0400 (EDT) Date: Wed, 19 Sep 2007 14:36:01 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Sean Chittenden In-Reply-To: <22249390-ABCD-4993-977C-02D7AEB0CE69@chittenden.org> Message-ID: References: <22249390-ABCD-4993-977C-02D7AEB0CE69@chittenden.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: threads@freebsd.org Subject: Re: Programatic way to determine the contents of struct pthread_*_t... X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 19:00:38 -0000 On Wed, 19 Sep 2007, Sean Chittenden wrote: > Howdy. What's the best way to programatically gain access to the contents of > the various struct pthread_*_t members? In OS-X and Linux, the contents are > defined in /usr/include/*/_*pthreads.h, but that doesn't appear to be the > case for FreeBSD at the moment. I'm in the process of porting D's Tango > runtime to FreeBSD[1] and it appears that due to FreeBSD's multi-thread > model, this is a bit problematic. Is there an obvious (or not so obvious) > magic woobie stick that I can shake at this problem? I'm mostly done with > the port at this point, but am a bit perplexed as to how to approach the > poking at internals problem since D's runtime environment is possibly tied to > my kernel configuration. Less than keen on that reality. Can I safely > assume that libthr is now king of the hill and isn't about to be dethroned > anytime soon? You can't do that. The pthread_*_t things are opaque and can and will change over time. D or Tango or whatever it is is severely broken. Not even Java or Ada need this kind of access. Now I almost feel like changing the pthread_*_t layouts around every couple of months ;-) -- DE From owner-freebsd-threads@FreeBSD.ORG Thu Sep 20 23:10:08 2007 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08CC416A418 for ; Thu, 20 Sep 2007 23:10:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E711E13C45D for ; Thu, 20 Sep 2007 23:10:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8KNA75g059173 for ; Thu, 20 Sep 2007 23:10:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8KNA77r059169; Thu, 20 Sep 2007 23:10:07 GMT (envelope-from gnats) Date: Thu, 20 Sep 2007 23:10:07 GMT Message-Id: <200709202310.l8KNA77r059169@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Simon Perreault Cc: Subject: Re: threads/101323: fork(2) in threaded programs broken. X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Simon Perreault List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 23:10:08 -0000 The following reply was made to PR threads/101323; it has been noted by GNATS. From: Simon Perreault To: bug-followup@freebsd.org, phk@critter.freebsd.dk Cc: Marc Blanchet Subject: Re: threads/101323: fork(2) in threaded programs broken. Date: Thu, 20 Sep 2007 11:22:20 -0400 Hi, This email is an attemps to revive bug 101323 by stating that it prevents Asterisk (http://www.asterisk.org/) from running in daemon mode. Here's what Asterisk tries to do in a nutshell: #include #include void* dummy( void *data ) {} int main() { pthread_t t1, t2; pthread_create( &t1, NULL, dummy, NULL ); daemon(0,1); pthread_create( &t2, NULL, dummy, NULL ); return 0; } From owner-freebsd-threads@FreeBSD.ORG Thu Sep 20 23:34:01 2007 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5A7C16A418 for ; Thu, 20 Sep 2007 23:34:01 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id AE78E13C45B for ; Thu, 20 Sep 2007 23:34:01 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.1/8.14.1/NETPLEX) with ESMTP id l8KNY0K9007977; Thu, 20 Sep 2007 19:34:00 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.netplex.net [204.213.176.10]); Thu, 20 Sep 2007 19:34:00 -0400 (EDT) Date: Thu, 20 Sep 2007 19:34:00 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Simon Perreault In-Reply-To: <200709202310.l8KNA77r059169@freefall.freebsd.org> Message-ID: References: <200709202310.l8KNA77r059169@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-threads@freebsd.org Subject: Re: threads/101323: fork(2) in threaded programs broken. X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 23:34:02 -0000 On Thu, 20 Sep 2007, Simon Perreault wrote: > > This email is an attemps to revive bug 101323 by stating that it prevents > Asterisk (http://www.asterisk.org/) from running in daemon mode. Here's what > Asterisk tries to do in a nutshell: POSIX states that only async signal safe functions can be used after a fork() in the child process and before a call to one of the exec() functions. The behavior of an application is undefined otherwise. From owner-freebsd-threads@FreeBSD.ORG Thu Sep 20 23:40:54 2007 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03CD216A468 for ; Thu, 20 Sep 2007 23:40:54 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id BF42F13C469 for ; Thu, 20 Sep 2007 23:40:53 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.1/8.14.1/NETPLEX) with ESMTP id l8KNeqwY011345; Thu, 20 Sep 2007 19:40:52 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.netplex.net [204.213.176.10]); Thu, 20 Sep 2007 19:40:52 -0400 (EDT) Date: Thu, 20 Sep 2007 19:40:52 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Simon Perreault In-Reply-To: Message-ID: References: <200709202310.l8KNA77r059169@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-threads@freebsd.org Subject: Re: threads/101323: fork(2) in threaded programs broken. X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 23:40:54 -0000 On Thu, 20 Sep 2007, Daniel Eischen wrote: > On Thu, 20 Sep 2007, Simon Perreault wrote: > >> >> This email is an attemps to revive bug 101323 by stating that it prevents >> Asterisk (http://www.asterisk.org/) from running in daemon mode. Here's >> what >> Asterisk tries to do in a nutshell: > > POSIX states that only async signal safe functions can be used > after a fork() in the child process and before a call to one of > the exec() functions. The behavior of an application is undefined > otherwise. I didn't realize this was an old bug and the above was already stated in its previous history. Does the patch in the bug report fix your problem? I thought phk had already committed it. -- DE