From owner-freebsd-threads@FreeBSD.ORG Sun Nov 21 00:15:43 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 B776916A4CE for ; Sun, 21 Nov 2004 00:15:43 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 633B143D1F for ; Sun, 21 Nov 2004 00:15:43 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) iAL0FfvV000600; Sat, 20 Nov 2004 19:15:41 -0500 (EST) Date: Sat, 20 Nov 2004 19:15:41 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Steve Kargl In-Reply-To: <20041120163733.GA72479@troutmask.apl.washington.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: freebsd-threads@freebsd.org Subject: Re: firefox stuck in kserel X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 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: Sun, 21 Nov 2004 00:15:43 -0000 On Sat, 20 Nov 2004, Steve Kargl wrote: > Fired up firefox and went to espn.com. Firefox becomes > unresponse. gdb -p shows > > (gdb) where > #0 0x48a7774b in pthread_testcancel () from /usr/lib/libpthread.so.1 > #1 0x48a6f97c in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 > #2 0x48a73c74 in pthread_setconcurrency () from /usr/lib/libpthread.so.1 > #3 0x48a78371 in pthread_exit () from /usr/lib/libpthread.so.1 > #4 0x48a63013 in pthread_create () from /usr/lib/libpthread.so.1 > #5 0x48b2a06f in _ctx_start () from /lib/libc.so.6 > (gdb) list Make sure you don't have any libm.so.2/libm.so.3 problems (use libmap.conf or rebuild firefox and its dependencies). You can try the patch at: http://people.freebsd.org/~deischen/kse/libpthread.diffs -- DE From owner-freebsd-threads@FreeBSD.ORG Sun Nov 21 00:36:05 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 99AB516A4CE; Sun, 21 Nov 2004 00:36:05 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DA7E43D58; Sun, 21 Nov 2004 00:36:05 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) iAL0a56N075153; Sat, 20 Nov 2004 16:36:05 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)iAL0a5x1075152; Sat, 20 Nov 2004 16:36:05 -0800 (PST) (envelope-from sgk) Date: Sat, 20 Nov 2004 16:36:05 -0800 From: Steve Kargl To: Daniel Eischen Message-ID: <20041121003605.GA75111@troutmask.apl.washington.edu> References: <20041120163733.GA72479@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: freebsd-threads@freebsd.org Subject: Re: firefox stuck in kserel 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, 21 Nov 2004 00:36:05 -0000 On Sat, Nov 20, 2004 at 07:15:41PM -0500, Daniel Eischen wrote: > On Sat, 20 Nov 2004, Steve Kargl wrote: > > > Fired up firefox and went to espn.com. Firefox becomes > > unresponse. gdb -p shows > > > > (gdb) where > > #0 0x48a7774b in pthread_testcancel () from /usr/lib/libpthread.so.1 > > #1 0x48a6f97c in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 > > #2 0x48a73c74 in pthread_setconcurrency () from /usr/lib/libpthread.so.1 > > #3 0x48a78371 in pthread_exit () from /usr/lib/libpthread.so.1 > > #4 0x48a63013 in pthread_create () from /usr/lib/libpthread.so.1 > > #5 0x48b2a06f in _ctx_start () from /lib/libc.so.6 > > (gdb) list > > Make sure you don't have any libm.so.2/libm.so.3 problems > (use libmap.conf or rebuild firefox and its dependencies). > > You can try the patch at: > > http://people.freebsd.org/~deischen/kse/libpthread.diffs > I rebuilt firefox 2 hours ago, but did not map libm.so.2 to libm.so.3. Perhaps, one of the plugins needs libmap.conf. Just tried libmap.conf. No change. I'll rebuild all dependencies and try your diff. Thanks. BTW, both 4BSD and ULE show this problem. -- Steve From owner-freebsd-threads@FreeBSD.ORG Sun Nov 21 01:10:28 2004 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE04516A4CE for ; Sun, 21 Nov 2004 01:10:27 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2DDB43D46 for ; Sun, 21 Nov 2004 01:10:27 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) iAL1ARL5009835 for ; Sun, 21 Nov 2004 01:10:27 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id iAL1ARwD009834; Sun, 21 Nov 2004 01:10:27 GMT (envelope-from gnats) Resent-Date: Sun, 21 Nov 2004 01:10:27 GMT Resent-Message-Id: <200411210110.iAL1ARwD009834@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-threads@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Pavel Kraynyukhov Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2EB116A4CE for ; Sun, 21 Nov 2004 01:00:55 +0000 (GMT) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id A33CE43D1D for ; Sun, 21 Nov 2004 01:00:55 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id iAL10tUr055343 for ; Sun, 21 Nov 2004 01:00:55 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id iAL10tPh055342; Sun, 21 Nov 2004 01:00:55 GMT (envelope-from nobody) Message-Id: <200411210100.iAL10tPh055342@www.freebsd.org> Date: Sun, 21 Nov 2004 01:00:55 GMT From: Pavel Kraynyukhov To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Subject: threads/74180: KSE problem. Applications those riched maximum possible threads at a time, would hang on threads join. look at detailed description ! 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, 21 Nov 2004 01:10:28 -0000 >Number: 74180 >Category: threads >Synopsis: KSE problem. Applications those riched maximum possible threads at a time, would hang on threads join. look at detailed description ! >Confidential: no >Severity: non-critical >Priority: high >Responsible: freebsd-threads >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Nov 21 01:10:26 GMT 2004 >Closed-Date: >Last-Modified: >Originator: Pavel Kraynyukhov >Release: 5.3 >Organization: private >Environment: FreeBSD ChainOfWorlds.InstantHQ.COM 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Nov 12 15:21:33 CET 2004 root@ChainOfWorlds.InstantHQ.COM:/usr/src/sys/i386/compile/ROMUL i386 >Description: Doing some measuring tests i found that application that creates a maximum possible threads in process, and then joins those threads after condition broadcasted, impossible to run more then once per boot. On second run the test hangs on threads joining. So you must reboot a PC to successfully pass this test again. >How-To-Repeat: compile following C++ test and run it twice or more times sequentually. first test will pass sucessfuly. second one (and all following) will hang on threads joining. #include #include #include #include #include #include pthread_cond_t WakeThemUp; pthread_mutex_t lock; void* thread(void* args) { pthread_mutex_lock(&lock); pthread_cond_wait(&WakeThemUp,&lock); pthread_mutex_unlock(&lock); /* for(size_t i=1; i< 1000;i++) { float m=i; m=log(sqrt(m*3.14/0.3876543234*234.765438/2.666666)); m+=i; }*/ } int main() { std::vector threads; size_t thrcount=0; pthread_cond_init(&WakeThemUp,NULL); pthread_mutex_init(&lock,NULL); clock_t start=clock(); clock_t end=0; try{ while(1) { pthread_t *threadP=new pthread_t; if(pthread_create(threadP,NULL,thread,NULL)==0) { threads.push_back(threadP); thrcount++; } else throw 1; } } catch( ... ) { end=clock(); std::cout << "threads created: " << thrcount << " ,\ creation time: " << end-start << " \ ticks" <<" CLOCKS_PER_SEC(" <Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-threads@FreeBSD.ORG Sun Nov 21 14:20:49 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 14EE716A4CE for ; Sun, 21 Nov 2004 14:20:49 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B346743D49 for ; Sun, 21 Nov 2004 14:20:48 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) iALEKlTu004120; Sun, 21 Nov 2004 09:20:47 -0500 (EST) Date: Sun, 21 Nov 2004 09:20:47 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Steve Kargl In-Reply-To: <20041121003605.GA75111@troutmask.apl.washington.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: freebsd-threads@freebsd.org Subject: Re: firefox stuck in kserel X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 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: Sun, 21 Nov 2004 14:20:49 -0000 On Sat, 20 Nov 2004, Steve Kargl wrote: > On Sat, Nov 20, 2004 at 07:15:41PM -0500, Daniel Eischen wrote: > > > > Make sure you don't have any libm.so.2/libm.so.3 problems > > (use libmap.conf or rebuild firefox and its dependencies). > > > > You can try the patch at: > > > > http://people.freebsd.org/~deischen/kse/libpthread.diffs > > > > I rebuilt firefox 2 hours ago, but did not map libm.so.2 > to libm.so.3. Perhaps, one of the plugins needs libmap.conf. > Just tried libmap.conf. No change. I'll rebuild all > dependencies and try your diff. Thanks. I've had a lot of problems with mozilla crashing until I added: libm.so.2 libm.so.3 libreadline.so.4 libreadline.so.5 libhistory.so.4 libhistory.so.5 libopie.so.2 libopie.so.3 libpcap.so.2 libpcap.so.3 to libmap.conf. I haven't rebuilt mozilla or any of the flash plugins/other dependencies, so that was expected I guess. I've got a fresh build of firefox, mozilla, and other ports at work. I'll try espn.com tomorrow or later this week. -- DE From owner-freebsd-threads@FreeBSD.ORG Sun Nov 21 19:55: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 C045316A4CE; Sun, 21 Nov 2004 19:55:15 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6944043D1F; Sun, 21 Nov 2004 19:55:15 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) iALJtFZf079568; Sun, 21 Nov 2004 11:55:15 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)iALJtF62079567; Sun, 21 Nov 2004 11:55:15 -0800 (PST) (envelope-from sgk) Date: Sun, 21 Nov 2004 11:55:15 -0800 From: Steve Kargl To: Daniel Eischen Message-ID: <20041121195514.GA79507@troutmask.apl.washington.edu> References: <20041121003605.GA75111@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: freebsd-threads@freebsd.org Subject: Re: firefox stuck in kserel 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, 21 Nov 2004 19:55:15 -0000 On Sun, Nov 21, 2004 at 09:20:47AM -0500, Daniel Eischen wrote: > On Sat, 20 Nov 2004, Steve Kargl wrote: > > > On Sat, Nov 20, 2004 at 07:15:41PM -0500, Daniel Eischen wrote: > > > > > > Make sure you don't have any libm.so.2/libm.so.3 problems > > > (use libmap.conf or rebuild firefox and its dependencies). > > > > > > You can try the patch at: > > > > > > http://people.freebsd.org/~deischen/kse/libpthread.diffs > > > > > > > I rebuilt firefox 2 hours ago, but did not map libm.so.2 > > to libm.so.3. Perhaps, one of the plugins needs libmap.conf. > > Just tried libmap.conf. No change. I'll rebuild all > > dependencies and try your diff. Thanks. > > I've had a lot of problems with mozilla crashing until I added: > > libm.so.2 libm.so.3 > libreadline.so.4 libreadline.so.5 > libhistory.so.4 libhistory.so.5 > libopie.so.2 libopie.so.3 > libpcap.so.2 libpcap.so.3 > > to libmap.conf. I haven't rebuilt mozilla or any of the flash > plugins/other dependencies, so that was expected I guess. > I've got a fresh build of firefox, mozilla, and other ports > at work. I'll try espn.com tomorrow or later this week. > Well, I've narrowed the problem down. I deleted /lib/libm.so.2 and removed *all* installed ports. Then, I started re-installing the ports I use regularly. firefox works with espn.com if I do not install linuxpluginwrapper and linux-flashplugin6. Once I install these two ports, firefox will hang in kserel. Note, www.zappa.com, which uses flash-6, works. I'll try your patch in a few minutes. -- Steve From owner-freebsd-threads@FreeBSD.ORG Sun Nov 21 20:04:03 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 165AA16A4CE; Sun, 21 Nov 2004 20:04:03 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFFCB43D39; Sun, 21 Nov 2004 20:04:02 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) iALK42Ki079652; Sun, 21 Nov 2004 12:04:02 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)iALK42KC079651; Sun, 21 Nov 2004 12:04:02 -0800 (PST) (envelope-from sgk) Date: Sun, 21 Nov 2004 12:04:02 -0800 From: Steve Kargl To: Daniel Eischen Message-ID: <20041121200402.GA79639@troutmask.apl.washington.edu> References: <20041121003605.GA75111@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: freebsd-threads@freebsd.org Subject: Re: firefox stuck in kserel 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, 21 Nov 2004 20:04:03 -0000 On Sun, Nov 21, 2004 at 09:20:47AM -0500, Daniel Eischen wrote: > On Sat, 20 Nov 2004, Steve Kargl wrote: > > > On Sat, Nov 20, 2004 at 07:15:41PM -0500, Daniel Eischen wrote: > > > > > > Make sure you don't have any libm.so.2/libm.so.3 problems > > > (use libmap.conf or rebuild firefox and its dependencies). > > > > > > You can try the patch at: > > > > > > http://people.freebsd.org/~deischen/kse/libpthread.diffs > > > kargl[281] firefox Fatal error 'Recurse on a private mutex.' at line 988 in file /usr/src/lib/libpthread/thread/thr_mutex.c (errno = 0) Abort trap (core dumped) -- Steve From owner-freebsd-threads@FreeBSD.ORG Sun Nov 21 23:37:02 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 2FBDD16A4CE for ; Sun, 21 Nov 2004 23:37:02 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD59A43D45 for ; Sun, 21 Nov 2004 23:37:01 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) iALNb0RT002773; Sun, 21 Nov 2004 18:37:00 -0500 (EST) Date: Sun, 21 Nov 2004 18:37:00 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Steve Kargl In-Reply-To: <20041121200402.GA79639@troutmask.apl.washington.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: freebsd-threads@freebsd.org Subject: Re: firefox stuck in kserel X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 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: Sun, 21 Nov 2004 23:37:02 -0000 On Sun, 21 Nov 2004, Steve Kargl wrote: > On Sun, Nov 21, 2004 at 09:20:47AM -0500, Daniel Eischen wrote: > > On Sat, 20 Nov 2004, Steve Kargl wrote: > > > > > On Sat, Nov 20, 2004 at 07:15:41PM -0500, Daniel Eischen wrote: > > > > > > > > Make sure you don't have any libm.so.2/libm.so.3 problems > > > > (use libmap.conf or rebuild firefox and its dependencies). > > > > > > > > You can try the patch at: > > > > > > > > http://people.freebsd.org/~deischen/kse/libpthread.diffs > > > > > > kargl[281] firefox > Fatal error 'Recurse on a private mutex.' at line 988 in file /usr/src/lib/libpthread/thread/thr_mutex.c (errno = 0) > Abort trap (core dumped) What page? I was running at firefox at work with this patch. The recurse shouldn't happen. Are you still using plugins? -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Nov 22 00:02:04 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 9081916A4CE; Mon, 22 Nov 2004 00:02:04 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 567BF43D2F; Mon, 22 Nov 2004 00:02:04 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) iAM024sS080563; Sun, 21 Nov 2004 16:02:04 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)iAM024BY080562; Sun, 21 Nov 2004 16:02:04 -0800 (PST) (envelope-from sgk) Date: Sun, 21 Nov 2004 16:02:03 -0800 From: Steve Kargl To: Daniel Eischen Message-ID: <20041122000203.GA80504@troutmask.apl.washington.edu> References: <20041121200402.GA79639@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: freebsd-threads@freebsd.org Subject: Re: firefox stuck in kserel 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, 22 Nov 2004 00:02:04 -0000 On Sun, Nov 21, 2004 at 06:37:00PM -0500, Daniel Eischen wrote: > On Sun, 21 Nov 2004, Steve Kargl wrote: > > > > > > You can try the patch at: > > > > > > > > > > http://people.freebsd.org/~deischen/kse/libpthread.diffs > > > > > > > > > kargl[281] firefox > > Fatal error 'Recurse on a private mutex.' at line 988 in file /usr/src/lib/libpthread/thread/thr_mutex.c (errno = 0) > > Abort trap (core dumped) > > What page? I was running at firefox at work with this patch. > The recurse shouldn't happen. Are you still using plugins? > It happens with both espn.com and www.zappa.com. Yes, this is using the linuxpluginwrapper and linux-flashplugin6 ports. My libmap.conf contains libreadline.so.4 libreadline.so.5 libhistory.so.4 libhistory.so.5 libopie.so.2 libopie.so.3 libpcap.so.2 libpcap.so.3 [/usr/local/Acrobat5/Browsers/intellinux/nppdf.so] libc.so.6 pluginwrapper/acrobat.so [/usr/local/lib/linux-flashplugin6/libflashplayer.so] libpthread.so.0 pluginwrapper/flash6.so libdl.so.2 pluginwrapper/flash6.so libz.so.1 libz.so.2 libstdc++-libc6.2-2.so.3 libstdc++.so.4 libm.so.6 libm.so.3 libc.so.6 pluginwrapper/flash6.so Note, I no longer have a libm.so.2, and all ports were rebuilt after deleting it and running ldconfig. You'll probably need to build firefox, linuxpluginwrapper, and linux-flashplugin6 with the patched libpthread. One other item. My last cvsup/build/install was on 20 Nov 04. I also use CFLAGS=-O -pipe and CPUTYPE=athlon in make.conf. -- Steve From owner-freebsd-threads@FreeBSD.ORG Mon Nov 22 00:32:45 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 5B93016A4CE; Mon, 22 Nov 2004 00:32:45 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3AEB43D5C; Mon, 22 Nov 2004 00:32:44 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) iAM0WiZY080654; Sun, 21 Nov 2004 16:32:44 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)iAM0Wiuc080653; Sun, 21 Nov 2004 16:32:44 -0800 (PST) (envelope-from sgk) Date: Sun, 21 Nov 2004 16:32:44 -0800 From: Steve Kargl To: Daniel Eischen Message-ID: <20041122003244.GA80638@troutmask.apl.washington.edu> References: <20041121200402.GA79639@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: freebsd-threads@freebsd.org Subject: Re: firefox stuck in kserel 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, 22 Nov 2004 00:32:45 -0000 On Sun, Nov 21, 2004 at 06:37:00PM -0500, Daniel Eischen wrote: > > > > > > > > > > You can try the patch at: > > > > > > > > > > http://people.freebsd.org/~deischen/kse/libpthread.diffs > > > > > > > > > kargl[281] firefox > > Fatal error 'Recurse on a private mutex.' at line 988 in file /usr/src/lib/libpthread/thread/thr_mutex.c (errno = 0) > > Abort trap (core dumped) > > What page? I was running at firefox at work with this patch. > The recurse shouldn't happen. Are you still using plugins? > One more tidbit. I re-installed your patch and deleted linuxpluginwrapper and linux-flashplugin6. The above patch works fine. Of course, any web page that use flash 6 becomes somewhat useless. I also rebuilt libpthread with debugging option -g. The trace shows (gdb) bt #0 0x48a77a2b in kse_thr_interrupt () at kse_thr_interrupt.S:2 #1 0x48a65d1e in sig_daemon (arg=0x0) at /usr/src/lib/libpthread/thread/thr_sig.c:214 #2 0x48a6fae7 in kse_sched_single (kmbx=0x17f) at /usr/src/lib/libpthread/thread/thr_kern.c:880 #3 0x00000000 in ?? () Current language: auto; currently asm (gdb) quit This doesn't make any sense to me, so maybe gdb is having trouble tracing the core dump. -- Steve From owner-freebsd-threads@FreeBSD.ORG Mon Nov 22 05:48:29 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 CC53716A4CE; Mon, 22 Nov 2004 05:48:29 +0000 (GMT) Received: from smtp1.jp.viruscheck.net (smtp1.jp.viruscheck.net [154.33.69.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71C6643D5D; Mon, 22 Nov 2004 05:48:29 +0000 (GMT) (envelope-from bland@FreeBSD.org) Received: from scan3.jp.viruscheck.net ([154.33.69.38] helo=mail4.jp.viruscheck.net) by smtp1.jp.viruscheck.net with esmtp (Exim 3.36 #1) id 1CW73k-000640-00; Mon, 22 Nov 2004 14:48:20 +0900 Received: from [220.108.149.115] (helo=noc.orchid) by mail4.jp.viruscheck.net with esmtp (Exim 3.36 #3) id 1CW73j-0004PK-00; Mon, 22 Nov 2004 14:48:19 +0900 Received: from [89.60.10.11] (horse.orchid [89.60.10.11]) by noc.orchid (8.12.11/8.12.11) with ESMTP id iAM5mIsg001646; Mon, 22 Nov 2004 14:48:19 +0900 (JST) (envelope-from bland@FreeBSD.org) Message-ID: <41A17D9D.4050502@FreeBSD.org> Date: Mon, 22 Nov 2004 14:48:13 +0900 From: Alexander Nedotsukov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040927 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Joe Marcus Clarke cc: Joe Marcus Clarke cc: freebsd-threads@FreeBSD.org Subject: Re: Question about our default pthread stack size 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, 22 Nov 2004 05:48:30 -0000 Daniel Eischen wrote: >On Fri, 19 Nov 2004, Joe Marcus Clarke wrote: > > > >>Daniel Eischen wrote: >>| The thing I worry about is these piggy applications being the >>| driving force behind our stack size. If they really are designed >>| to need a huge stack size, they should be the ones that change >>| to support it, not the other way around. Do they know their own >>| stack space requirements or do they just ignore it because it >>| isn't a problem so far (on Linux)? >> >>The bottom line is that they don't know their stack requirements, but >>the OS is accommodating, so they never have to really find out until we >>submit a bug to them. However, some applications (e.g. gstreamer, >>libgnomecups, etc.) cannot be fixed without massive architectural >>changes. Just to be clear, these applications _are_ overrunning the >>default stack. >> >> > >FYI, I don't suggest they change their stack usage, just that >they create threads with thread attributes specifying a larger >stack size. If they recognize they have large stack space >requirements, it should be easily solved without an architectural >overhaul. I assume your patches do exactly this; are the GNOME >developers reluctant to incorporate your patches? > >I'm not going to argue very strongly against changing the >default stack size. I just think the onus should be on >the larger applications to recognize that they need larger >stacks and to explicitly set it. There may also be other >applications that create a lot of threads which may need >to lower the stack size if the default were changed. > > > I want to explain my personal opinion about blaming heavy stack usage. This probably explains how other userland programmers think about his problem: Heavy stack usage is not so evil like it may look like. That "pig" will have to allocate big memory chunk anyway and the usual options here are to grab phys memory page on the heap through the malloc() or do it on the stack. In both of the cases this memory will not be immediately allocated. But malloc() way will be slower and this is why multimedia processing code may prefer on stack allocation. Another malloc/free() disadvantage for C program is potential memory leakage. People may feel safer when they don't have to check all return paths but get automatic memory disposal. One more thing about "Do they know their own stack space requirements". No they don't. And the whole idea here I believe was to let them don't care at all. I doubt very much if such research for something like OpenOffice will worth the efforts. So it is more practical to follow Bill's like "no one can beat xxx barrier". Where xxx is 1MB in our 32bit case :-) So finally. If we going to keep stack limit lower than it is on other OSes we have to provide programmers with good arguments why the above I said is not correct and/or why we think our numbers are better. Otherwise we trouble people because of reason we don't honestly know. Hey, and now let's do something. Do not keep this suspicious silence! ;-) All the best, Alexander. ps. btw no one commented the idea of making this $limits -s tunable (default limit will be inherited from the main thread) thus making both of the worlds happy. From owner-freebsd-threads@FreeBSD.ORG Mon Nov 22 05:55:48 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 DB0D616A4CE for ; Mon, 22 Nov 2004 05:55:48 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D42243D49 for ; Mon, 22 Nov 2004 05:55:48 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) iAM5tlOM008574; Mon, 22 Nov 2004 00:55:47 -0500 (EST) Date: Mon, 22 Nov 2004 00:55:47 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Steve Kargl In-Reply-To: <20041122003244.GA80638@troutmask.apl.washington.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: freebsd-threads@freebsd.org Subject: Re: firefox stuck in kserel X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 22 Nov 2004 05:55:49 -0000 On Sun, 21 Nov 2004, Steve Kargl wrote: > On Sun, Nov 21, 2004 at 06:37:00PM -0500, Daniel Eischen wrote: > > > > > > > > > > > > You can try the patch at: > > > > > > > > > > > > http://people.freebsd.org/~deischen/kse/libpthread.diffs > > > > > > > > > > > > kargl[281] firefox > > > Fatal error 'Recurse on a private mutex.' at line 988 in file /usr/src/lib/libpthread/thread/thr_mutex.c (errno = 0) > > > Abort trap (core dumped) > > > > What page? I was running at firefox at work with this patch. > > The recurse shouldn't happen. Are you still using plugins? > > > > One more tidbit. I re-installed your patch and deleted > linuxpluginwrapper and linux-flashplugin6. The above > patch works fine. Of course, any web page that use flash 6 > becomes somewhat useless. I don't think it's anything libpthread is doing. > I also rebuilt libpthread with debugging option -g. The > trace shows > > (gdb) bt > #0 0x48a77a2b in kse_thr_interrupt () at kse_thr_interrupt.S:2 > #1 0x48a65d1e in sig_daemon (arg=0x0) > at /usr/src/lib/libpthread/thread/thr_sig.c:214 > #2 0x48a6fae7 in kse_sched_single (kmbx=0x17f) > at /usr/src/lib/libpthread/thread/thr_kern.c:880 Something is hosed because the mailbox in kse_sched_single() is garbage. > #3 0x00000000 in ?? () > Current language: auto; currently asm > (gdb) quit > > This doesn't make any sense to me, so maybe gdb is having > trouble tracing the core dump. I don't know. The backtrace looks OK 'cause kse_sched_single() is the upcall entry point, but the KSE mailbox (kmbx) is not correct -- it should be a pointer and looks more like what %gs would be. -- DE From owner-freebsd-threads@FreeBSD.ORG Mon Nov 22 06:15:10 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 1CD4816A4CE; Mon, 22 Nov 2004 06:15:10 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B64BF43D54; Mon, 22 Nov 2004 06:15:09 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) iAM6F8L3002964; Mon, 22 Nov 2004 01:15:08 -0500 (EST) Date: Mon, 22 Nov 2004 01:15:08 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Alexander Nedotsukov In-Reply-To: <41A17D9D.4050502@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: Joe Marcus Clarke cc: Joe Marcus Clarke cc: freebsd-threads@freebsd.org Subject: Re: Question about our default pthread stack size X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 22 Nov 2004 06:15:10 -0000 On Mon, 22 Nov 2004, Alexander Nedotsukov wrote: > Daniel Eischen wrote: > > Heavy stack usage is not so evil like it may look like. That "pig" > will have to allocate big memory chunk anyway and the usual options here > are to grab phys memory page on the heap through the malloc() or do it > on the stack. In both of the cases this memory will not be immediately > allocated. But malloc() way will be slower and this is why multimedia > processing code may prefer on stack allocation. Another malloc/free() > disadvantage for C program is potential memory leakage. People may feel > safer when they don't have to check all return paths but get automatic > memory disposal. > One more thing about "Do they know their own stack space requirements". > No they don't. And the whole idea here I believe was to let them don't > care at all. I doubt very much if such research for something like > OpenOffice will worth the efforts. So it is more practical to follow > Bill's like "no one can beat xxx barrier". Where xxx is 1MB in our 32bit > case :-) You're missing my point. There is a perfectly good POSIX standard for setting thread stack size -- you don't even need to allocate it yourself. Using pthread_attr_setstacksize() is more portable than relying on the OS to guess at what an application's stack size requirements are. We may increase it to 1MB now, but what happens when that is not enough? And you _know_ one day, perhaps sooner than you realize, that it won't be enough. I've searched the GTK archives and can see that the stack size was removed from the thread pool api, but not from creating other threads. The reason for removing it seems silly, but such is life... -- DE From owner-freebsd-threads@FreeBSD.ORG Mon Nov 22 06:28:41 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 3C29A16A4CE; Mon, 22 Nov 2004 06:28:41 +0000 (GMT) Received: from creme-brulee.marcuscom.com (creme-brulee.marcuscom.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 965C043D55; Mon, 22 Nov 2004 06:28:40 +0000 (GMT) (envelope-from marcus@marcuscom.com) Received: from gyros (gyros.marcuscom.com [192.168.1.9]) iAM6SfML005395; Mon, 22 Nov 2004 01:28:41 -0500 (EST) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Daniel Eischen In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-r771LLZlfWLy4bhx52aU" Organization: MarcusCom, Inc. Date: Mon, 22 Nov 2004 01:28:39 -0500 Message-Id: <1101104919.95599.4.camel@gyros> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port cc: Alexander Nedotsukov cc: freebsd-threads@freebsd.org Subject: Re: Question about our default pthread stack size 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, 22 Nov 2004 06:28:41 -0000 --=-r771LLZlfWLy4bhx52aU Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2004-11-22 at 01:15 -0500, Daniel Eischen wrote: > On Mon, 22 Nov 2004, Alexander Nedotsukov wrote: >=20 > > Daniel Eischen wrote: > > > > Heavy stack usage is not so evil like it may look like. That "pig" > > will have to allocate big memory chunk anyway and the usual options her= e > > are to grab phys memory page on the heap through the malloc() or do it > > on the stack. In both of the cases this memory will not be immediately > > allocated. But malloc() way will be slower and this is why multimedia > > processing code may prefer on stack allocation. Another malloc/free() > > disadvantage for C program is potential memory leakage. People may feel > > safer when they don't have to check all return paths but get automatic > > memory disposal. > > One more thing about "Do they know their own stack space requirements". > > No they don't. And the whole idea here I believe was to let them don't > > care at all. I doubt very much if such research for something like > > OpenOffice will worth the efforts. So it is more practical to follow > > Bill's like "no one can beat xxx barrier". Where xxx is 1MB in our 32bi= t > > case :-) >=20 > You're missing my point. There is a perfectly good POSIX standard for > setting thread stack size -- you don't even need to allocate it yourself. > Using pthread_attr_setstacksize() is more portable than relying on > the OS to guess at what an application's stack size requirements are. > We may increase it to 1MB now, but what happens when that is not enough? > And you _know_ one day, perhaps sooner than you realize, that it won't > be enough. Okay, but I still don't see the reason for not increasing the stack size now to be more inline with Solaris and Linux. We seem to be adopting other Solaris-like threading attributes (based on some of your previous emails), and this would help other popular software packages "just work" on FreeBSD. >=20 > I've searched the GTK archives and can see that the stack size was > removed from the thread pool api, but not from creating other threads. > The reason for removing it seems silly, but such is life... Right. You can still create individual threads, and specify a per-thread stack size. However, this cannot be done with GThreadPools. Joe >=20 --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-r771LLZlfWLy4bhx52aU Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBoYcXb2iPiv4Uz4cRAh+EAJwKUFkPnKxoogX1GT5jTDUQqUW5bACfSNj1 WIMPoc3I++J6Qlq44xgj2iA= =fvhD -----END PGP SIGNATURE----- --=-r771LLZlfWLy4bhx52aU-- From owner-freebsd-threads@FreeBSD.ORG Mon Nov 22 08:30:39 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 2164F16A4CE; Mon, 22 Nov 2004 08:30:39 +0000 (GMT) Received: from smtp4.jp.viruscheck.net (smtp4.jp.viruscheck.net [154.33.69.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id B225643D60; Mon, 22 Nov 2004 08:30:38 +0000 (GMT) (envelope-from bland@FreeBSD.org) Received: from scan4.jp.viruscheck.net ([154.33.69.39] helo=mail1.jp.viruscheck.net) by smtp4.jp.viruscheck.net with esmtp (Exim 3.36 #1) id 1CW9am-0001WQ-00; Mon, 22 Nov 2004 17:30:36 +0900 Received: from [220.108.149.115] (helo=noc.orchid) by mail1.jp.viruscheck.net with esmtp (Exim 3.36 #3) id 1CW9am-0002IO-00; Mon, 22 Nov 2004 17:30:36 +0900 Received: from [89.60.10.11] (horse.orchid [89.60.10.11]) by noc.orchid (8.12.11/8.12.11) with ESMTP id iAM8UZS5002335; Mon, 22 Nov 2004 17:30:35 +0900 (JST) (envelope-from bland@FreeBSD.org) Message-ID: <41A1A3A5.20601@FreeBSD.org> Date: Mon, 22 Nov 2004 17:30:29 +0900 From: Alexander Nedotsukov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040927 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Joe Marcus Clarke cc: Joe Marcus Clarke cc: freebsd-threads@FreeBSD.org Subject: Re: Question about our default pthread stack size 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, 22 Nov 2004 08:30:39 -0000 Daniel Eischen wrote: >On Mon, 22 Nov 2004, Alexander Nedotsukov wrote: > > > >>Daniel Eischen wrote: >> >> Heavy stack usage is not so evil like it may look like. That "pig" >>will have to allocate big memory chunk anyway and the usual options here >>are to grab phys memory page on the heap through the malloc() or do it >>on the stack. In both of the cases this memory will not be immediately >>allocated. But malloc() way will be slower and this is why multimedia >>processing code may prefer on stack allocation. Another malloc/free() >>disadvantage for C program is potential memory leakage. People may feel >>safer when they don't have to check all return paths but get automatic >>memory disposal. >>One more thing about "Do they know their own stack space requirements". >>No they don't. And the whole idea here I believe was to let them don't >>care at all. I doubt very much if such research for something like >>OpenOffice will worth the efforts. So it is more practical to follow >>Bill's like "no one can beat xxx barrier". Where xxx is 1MB in our 32bit >>case :-) >> >> > >You're missing my point. There is a perfectly good POSIX standard for >setting thread stack size -- you don't even need to allocate it yourself. >Using pthread_attr_setstacksize() is more portable than relying on >the OS to guess at what an application's stack size requirements are. > > Daniel, this is what I said in my very first letter under the topic. I know how portable code must look like. API is good and complete. Let's clear thing up yet more to understand each other completely. My points are: - there is an omision in standard (or better to say something that is hard to standardize) Therefore there is a term like default stack size which can be understood as the amount enough for regular code. Otherwise it will be more logical to make thread stack size argument mandatory for pthread_create(). - main stream follows the stack usage rules I described above and chosen 1MB/2MB for their default stacks size. - we have limit which most likely triggers SIGSEGV. At this point I believe we both agreed that there is a sence to break 64K limit. Right? Than the only open question how much we will grow it up. My point is that if we going to use lower numbers we must give a good reason for that. Some technical issues I guess like performance penalty whatever... My main question I'd like to hear the answer is: If we can not prove being as safe as main stream and do not win anything in technical aspect than why we must do extra work? I can understand if there is some true technical issue which prevents us form be inline with others. But I do not if we just pushing people to use APIs speculating on standard omisions. >We may increase it to 1MB now, but what happens when that is not enough? >And you _know_ one day, perhaps sooner than you realize, that it won't >be enough. > > This will be a problem for everyone not just for FreeBSD users. Perhaps that day will be a good time to prove Solaris/Linux/Windows OS engineers who was right. But now I think we lost the race. All the best, Alexander. From owner-freebsd-threads@FreeBSD.ORG Mon Nov 22 11:02:06 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 221E016A4CF for ; Mon, 22 Nov 2004 11:02:06 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED9DA43D6D for ; Mon, 22 Nov 2004 11:02:05 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id iAMB25p2076068 for ; Mon, 22 Nov 2004 11:02:05 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id iAMB25kW076062 for freebsd-threads@freebsd.org; Mon, 22 Nov 2004 11:02:05 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 22 Nov 2004 11:02:05 GMT Message-Id: <200411221102.iAMB25kW076062@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, 22 Nov 2004 11:02:06 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/04/22] threads/65883threads libkse's sigwait does not work after fork 1 problem 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] kern/20861 threads libc_r does not honor socket timeouts o [2001/01/20] threads/24472threads libc_r does not honor SO_SNDTIMEO/SO_RCVT o [2001/01/25] threads/24632threads libc_r delicate deviation from libc in ha o [2001/01/25] kern/24641 threads pthread_rwlock_rdlock can deadlock o [2001/11/26] bin/32295 threads pthread dont dequeue signals o [2002/02/01] threads/34536threads 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] kern/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 s [2004/03/15] kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/un o [2004/08/26] threads/70975threads unexpected and unreliable behaviour when o [2004/09/14] threads/71725threads Mysql Crashes frequently giving Sock Erro o [2004/10/05] threads/72353threads Assertion fails in /usr/src/lib/libpthrea o [2004/10/07] threads/72429threads threads blocked in stdio (fgets, etc) are o [2004/10/21] threads/72953threads fork() unblocks blocked signals w/o PTHRE 19 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/05/26] kern/18824 threads gethostbyname is not thread safe o [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything o [2000/10/21] kern/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 o [2004/09/21] threads/71966threads Mlnet Core Dumped : Fatal error '_pq_inse o [2004/11/21] threads/74180threads KSE problem. Applications those riched ma 9 problems total. From owner-freebsd-threads@FreeBSD.ORG Wed Nov 24 07:02:48 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 7455616A4CE; Wed, 24 Nov 2004 07:02:48 +0000 (GMT) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2645043D3F; Wed, 24 Nov 2004 07:02:48 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: from aldaris.auir.gank.org (arbiter.gank.org [64.81.113.221]) by ion.gank.org (mail) with ESMTP id 8D1CA2AA50; Wed, 24 Nov 2004 01:02:47 -0600 (CST) From: Craig Boston To: freebsd-hackers@freebsd.org Date: Wed, 24 Nov 2004 01:02:41 -0600 User-Agent: KMail/1.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200411240102.42269.craig@tobuj.gank.org> cc: freebsd-threads@freebsd.org Subject: SSE vs. stack alignment vs. pthread 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: Wed, 24 Nov 2004 07:02:48 -0000 First of all, I'd like to apologize for cross-posting to -hackers and -threads. I'm not sure yet if this is an application bug, a gcc bug, or a pthreads bug, so here goes... I'm currently working on the audacity port. It's up to 1.2.3, but I want to get a problem I've observed with 1.2.2 resolved to make sure that it doesn't crop up later or affect other software... Long story short, audacity is a threaded program. A straight compile of 1.2.2 results in a 100% reproducible bus error that happens on multiple Pentium-4 machines (5.3-STABLE). It always happens at this instruction: 0x081807c4: movaps %xmm0,0xffffff68(%ebp) Now, at that time ebp is 0xbfadc6c0, so ebp+0xffffff68 (-0x152) is 0xbfadc56e. Oops, that's not 16-byte aligned like SSE wants. The offsets vary sligthly depending on the compile flags, etc., but the result is always the same -- SIGBUS. My first suspicion was compiler bug. Audacity doesn't inline any SSE code itself -- the movaps is being generated by gcc as part of the pentium4 optimizations. There are two factors that are a little suspicious, though. 1) When I switch out libpthread for libc_r, the crash goes away. Unfortunately, the gdb in 5.3 seems to have forgotten how to debug libc_r based programs so I can't really tell what is different in that case. I just get "Cannot find thread 2: Thread ID=1, generic error". 2) Some searching turned up several similar problems on Linux and NetBSD. The NetBSD post here [http://mail-index.netbsd.org/port-amd64/2004/02/27/0001.html] indicates that it may be related to stack alignment in the thread library. I'm not sure if the ABI requirement discussed there is NetBSD and/or amd64 specific though. HOWEVER -- I inserted some debugging printfs into libpthread to test this theory. The stack it allocates for that thread is located at 0xbfaad000, which is not only 16-byte aligned but page aligned... So I'm reluctant to blame libpthread as it seems to be doing everything right and even going the extra mile. I honestly don't know whether gcc is expecting the alignment to compensate for the return address push or the function prolog, or if it's just losing track of where the stack should be somewhere. I may be over-analyzing the problem at that point :) Another factor to consider is that nobody has reported similar problems in other software... I've been trying to create a simple test case, however it's proving quite difficult to coax gcc into generating SSE code on its own where I want it. It's of course possible that Audacity itself is doing something weird to cause it, but I haven't been able to find anything suspicious or low-level enough to affect the stack alignment. It could just be a heisenbug, and libc_r is different enough to mask the problem. Any and all suggestions from threads/compiler gurus would be very much appreciated. I'm about ready to throw in the towel and just force "-mno-sse -mno-sse2" compiler flags in the makefile... Thanks, Craig From owner-freebsd-threads@FreeBSD.ORG Wed Nov 24 07:36:58 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 8810A16A4CE; Wed, 24 Nov 2004 07:36:58 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7EFF43D69; Wed, 24 Nov 2004 07:36:57 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) iAO7auZE009146; Wed, 24 Nov 2004 02:36:56 -0500 (EST) Date: Wed, 24 Nov 2004 02:36:55 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Craig Boston In-Reply-To: <200411240102.42269.craig@tobuj.gank.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: freebsd-hackers@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: SSE vs. stack alignment vs. pthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Nov 2004 07:36:58 -0000 On Wed, 24 Nov 2004, Craig Boston wrote: > First of all, I'd like to apologize for cross-posting to -hackers and > -threads. I'm not sure yet if this is an application bug, a gcc > bug, or a pthreads bug, so here goes... > > I'm currently working on the audacity port. It's up to 1.2.3, but I > want to get a problem I've observed with 1.2.2 resolved to make sure > that it doesn't crop up later or affect other software... > > Long story short, audacity is a threaded program. A straight compile of > 1.2.2 results in a 100% reproducible bus error that happens on multiple > Pentium-4 machines (5.3-STABLE). It always happens at this instruction: > > 0x081807c4: movaps %xmm0,0xffffff68(%ebp) > > Now, at that time ebp is 0xbfadc6c0, so ebp+0xffffff68 (-0x152) is 0xbfadc56e. > Oops, that's not 16-byte aligned like SSE wants. The offsets vary sligthly > depending on the compile flags, etc., but the result is always the same -- > SIGBUS. Tor Egge reported similar problem to me yesterday. I haven't had a chance to test his patch, but this supposedly fixes it. Index: lib/libc/i386/gen/makecontext.c =================================================================== RCS file: /home/ncvs/src/lib/libc/i386/gen/makecontext.c,v retrieving revision 1.4 diff -u -r1.4 makecontext.c --- lib/libc/i386/gen/makecontext.c 2 Jul 2004 14:19:44 -0000 1.4 +++ lib/libc/i386/gen/makecontext.c 22 Nov 2004 22:51:49 -0000 @@ -118,7 +118,9 @@ * address, _ctx_start, and ucp) and argc arguments. * We allow the arguments to be pointers also. */ - stack_top = stack_top - (sizeof(intptr_t) * (3 + argc)); + stack_top = stack_top - (sizeof(intptr_t) * (1 + argc)); + stack_top -= ((long) stack_top & 15); /* 16 bytes alignment */ + stack_top -= sizeof(intptr_t) * 2; argp = (intptr_t *)stack_top; /* From owner-freebsd-threads@FreeBSD.ORG Wed Nov 24 07:45:39 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 3D44916A4D0; Wed, 24 Nov 2004 07:45:39 +0000 (GMT) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 010A543D2D; Wed, 24 Nov 2004 07:45:39 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: by ion.gank.org (mail, from userid 1001) id DB5F02AA77; Wed, 24 Nov 2004 01:45:38 -0600 (CST) Date: Wed, 24 Nov 2004 01:45:38 -0600 From: Craig Boston To: Daniel Eischen Message-ID: <20041124074538.GB67289@nowhere> References: <200411240102.42269.craig@tobuj.gank.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: freebsd-hackers@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: SSE vs. stack alignment vs. pthread 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: Wed, 24 Nov 2004 07:45:39 -0000 On Wed, Nov 24, 2004 at 02:36:55AM -0500, Daniel Eischen wrote: > Tor Egge reported similar problem to me yesterday. I haven't had a chance > to test his patch, but this supposedly fixes it. He just sent me the patch via private mail a few minutes ago. With his patch applied, the stack (after the frame is set up by the thread function) is now 16-byte aligned and everything works just fine ... no bus error anymore. Craig From owner-freebsd-threads@FreeBSD.ORG Wed Nov 24 16:33:49 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 E539916A4EE; Wed, 24 Nov 2004 16:33:48 +0000 (GMT) Received: from r1a.corp.servercentral.net (exchange.corp.servercentral.net [66.225.247.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4592843D5D; Wed, 24 Nov 2004 16:33:48 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail pickup service by r1a.corp.servercentral.net with Microsoft SMTPSVC; Wed, 24 Nov 2004 10:33:40 -0600 Received: from demandindustries.net ([161.58.224.124]) by r1a.corp.servercentral.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Nov 2004 01:37:33 -0600 Received: from scanner.servercentral.net (scanner.servercentral.net [66.225.196.47]) by demandindustries.net (8.12.11/8.12.9) with ESMTP id iAO7bW7r012785 for ; Wed, 24 Nov 2004 01:37:32 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by scanner.servercentral.net (Postfix) with ESMTP id 077208700C3 for ; Wed, 24 Nov 2004 01:37:23 -0600 (CST) Received: from scanner.servercentral.net ([127.0.0.1]) by localhost (mb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01241-09 for ; Wed, 24 Nov 2004 01:37:21 -0600 (CST) Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by scanner.servercentral.net (Postfix) with ESMTP id 56DE68700BF for ; Wed, 24 Nov 2004 01:37:21 -0600 (CST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 7D19457BAF; Wed, 24 Nov 2004 07:37:08 +0000 (GMT) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 09E3F16A507; Wed, 24 Nov 2004 07:37:04 +0000 (GMT) Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8810A16A4CE; Wed, 24 Nov 2004 07:36:58 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7EFF43D69; Wed, 24 Nov 2004 07:36:57 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) iAO7auZE009146; Wed, 24 Nov 2004 02:36:56 -0500 (EST) Date: Wed, 24 Nov 2004 02:36:55 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Craig Boston In-Reply-To: <200411240102.42269.craig@tobuj.gank.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-hackers@freebsd.org Errors-To: owner-freebsd-hackers@freebsd.org X-Virus-Scanned: by amavis for cervercentral.net X-OriginalArrivalTime: 24 Nov 2004 07:37:33.0866 (UTC) FILETIME=[763780A0:01C4D1F8] cc: freebsd-hackers@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: SSE vs. stack alignment vs. pthread X-BeenThere: freebsd-threads@freebsd.org Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 16:33:49 -0000 On Wed, 24 Nov 2004, Craig Boston wrote: > First of all, I'd like to apologize for cross-posting to -hackers and > -threads. I'm not sure yet if this is an application bug, a gcc > bug, or a pthreads bug, so here goes... > > I'm currently working on the audacity port. It's up to 1.2.3, but I > want to get a problem I've observed with 1.2.2 resolved to make sure > that it doesn't crop up later or affect other software... > > Long story short, audacity is a threaded program. A straight compile of > 1.2.2 results in a 100% reproducible bus error that happens on multiple > Pentium-4 machines (5.3-STABLE). It always happens at this instruction: > > 0x081807c4: movaps %xmm0,0xffffff68(%ebp) > > Now, at that time ebp is 0xbfadc6c0, so ebp+0xffffff68 (-0x152) is 0xbfadc56e. > Oops, that's not 16-byte aligned like SSE wants. The offsets vary sligthly > depending on the compile flags, etc., but the result is always the same -- > SIGBUS. Tor Egge reported similar problem to me yesterday. I haven't had a chance to test his patch, but this supposedly fixes it. Index: lib/libc/i386/gen/makecontext.c =================================================================== RCS file: /home/ncvs/src/lib/libc/i386/gen/makecontext.c,v retrieving revision 1.4 diff -u -r1.4 makecontext.c --- lib/libc/i386/gen/makecontext.c 2 Jul 2004 14:19:44 -0000 1.4 +++ lib/libc/i386/gen/makecontext.c 22 Nov 2004 22:51:49 -0000 @@ -118,7 +118,9 @@ * address, _ctx_start, and ucp) and argc arguments. * We allow the arguments to be pointers also. */ - stack_top = stack_top - (sizeof(intptr_t) * (3 + argc)); + stack_top = stack_top - (sizeof(intptr_t) * (1 + argc)); + stack_top -= ((long) stack_top & 15); /* 16 bytes alignment */ + stack_top -= sizeof(intptr_t) * 2; argp = (intptr_t *)stack_top; /* _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-threads@FreeBSD.ORG Wed Nov 24 16:34:03 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 D985A16A4E2; Wed, 24 Nov 2004 16:34:02 +0000 (GMT) Received: from r1a.corp.servercentral.net (exchange.corp.servercentral.net [66.225.247.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 309FD43D5E; Wed, 24 Nov 2004 16:34:02 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: from mail pickup service by r1a.corp.servercentral.net with Microsoft SMTPSVC; Wed, 24 Nov 2004 10:33:55 -0600 Received: from demandindustries.net ([161.58.224.124]) by r1a.corp.servercentral.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Nov 2004 01:02:58 -0600 Received: from scanner.servercentral.net (scanner.servercentral.net [66.225.196.47]) by demandindustries.net (8.12.11/8.12.9) with ESMTP id iAO7309V006100 for ; Wed, 24 Nov 2004 01:03:00 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by scanner.servercentral.net (Postfix) with ESMTP id 5B4568700C3 for ; Wed, 24 Nov 2004 01:02:51 -0600 (CST) Received: from scanner.servercentral.net ([127.0.0.1]) by localhost (mb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01103-05 for ; Wed, 24 Nov 2004 01:02:50 -0600 (CST) Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by scanner.servercentral.net (Postfix) with ESMTP id 335688700BF for ; Wed, 24 Nov 2004 01:02:50 -0600 (CST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 295A056E40; Wed, 24 Nov 2004 07:02:58 +0000 (GMT) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 879B116A508; Wed, 24 Nov 2004 07:02:52 +0000 (GMT) Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7455616A4CE; Wed, 24 Nov 2004 07:02:48 +0000 (GMT) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2645043D3F; Wed, 24 Nov 2004 07:02:48 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: from aldaris.auir.gank.org (arbiter.gank.org [64.81.113.221]) by ion.gank.org (mail) with ESMTP id 8D1CA2AA50; Wed, 24 Nov 2004 01:02:47 -0600 (CST) From: Craig Boston To: freebsd-hackers@freebsd.org Date: Wed, 24 Nov 2004 01:02:41 -0600 User-Agent: KMail/1.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200411240102.42269.craig@tobuj.gank.org> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-hackers@freebsd.org Errors-To: owner-freebsd-hackers@freebsd.org X-Virus-Scanned: by amavis for cervercentral.net X-OriginalArrivalTime: 24 Nov 2004 07:03:00.0829 (UTC) FILETIME=[A29728D0:01C4D1F3] cc: freebsd-threads@freebsd.org Subject: SSE vs. stack alignment vs. pthread X-BeenThere: freebsd-threads@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 16:34:03 -0000 First of all, I'd like to apologize for cross-posting to -hackers and -threads. I'm not sure yet if this is an application bug, a gcc bug, or a pthreads bug, so here goes... I'm currently working on the audacity port. It's up to 1.2.3, but I want to get a problem I've observed with 1.2.2 resolved to make sure that it doesn't crop up later or affect other software... Long story short, audacity is a threaded program. A straight compile of 1.2.2 results in a 100% reproducible bus error that happens on multiple Pentium-4 machines (5.3-STABLE). It always happens at this instruction: 0x081807c4: movaps %xmm0,0xffffff68(%ebp) Now, at that time ebp is 0xbfadc6c0, so ebp+0xffffff68 (-0x152) is 0xbfadc56e. Oops, that's not 16-byte aligned like SSE wants. The offsets vary sligthly depending on the compile flags, etc., but the result is always the same -- SIGBUS. My first suspicion was compiler bug. Audacity doesn't inline any SSE code itself -- the movaps is being generated by gcc as part of the pentium4 optimizations. There are two factors that are a little suspicious, though. 1) When I switch out libpthread for libc_r, the crash goes away. Unfortunately, the gdb in 5.3 seems to have forgotten how to debug libc_r based programs so I can't really tell what is different in that case. I just get "Cannot find thread 2: Thread ID=1, generic error". 2) Some searching turned up several similar problems on Linux and NetBSD. The NetBSD post here [http://mail-index.netbsd.org/port-amd64/2004/02/27/0001.html] indicates that it may be related to stack alignment in the thread library. I'm not sure if the ABI requirement discussed there is NetBSD and/or amd64 specific though. HOWEVER -- I inserted some debugging printfs into libpthread to test this theory. The stack it allocates for that thread is located at 0xbfaad000, which is not only 16-byte aligned but page aligned... So I'm reluctant to blame libpthread as it seems to be doing everything right and even going the extra mile. I honestly don't know whether gcc is expecting the alignment to compensate for the return address push or the function prolog, or if it's just losing track of where the stack should be somewhere. I may be over-analyzing the problem at that point :) Another factor to consider is that nobody has reported similar problems in other software... I've been trying to create a simple test case, however it's proving quite difficult to coax gcc into generating SSE code on its own where I want it. It's of course possible that Audacity itself is doing something weird to cause it, but I haven't been able to find anything suspicious or low-level enough to affect the stack alignment. It could just be a heisenbug, and libc_r is different enough to mask the problem. Any and all suggestions from threads/compiler gurus would be very much appreciated. I'm about ready to throw in the towel and just force "-mno-sse -mno-sse2" compiler flags in the makefile... Thanks, Craig _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-threads@FreeBSD.ORG Wed Nov 24 16:34:13 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 1DA5B16A524; Wed, 24 Nov 2004 16:34:13 +0000 (GMT) Received: from r1a.corp.servercentral.net (exchange.corp.servercentral.net [66.225.247.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id C33E943D3F; Wed, 24 Nov 2004 16:34:12 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: from mail pickup service by r1a.corp.servercentral.net with Microsoft SMTPSVC; Wed, 24 Nov 2004 10:34:03 -0600 Received: from demandindustries.net ([161.58.224.124]) by r1a.corp.servercentral.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Nov 2004 01:46:37 -0600 Received: from scanner.servercentral.net (scanner.servercentral.net [66.225.196.47]) by demandindustries.net (8.12.11/8.12.9) with ESMTP id iAO7kZVe014372 for ; Wed, 24 Nov 2004 01:46:36 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by scanner.servercentral.net (Postfix) with ESMTP id 5BE5E8700C3 for ; Wed, 24 Nov 2004 01:46:26 -0600 (CST) Received: from scanner.servercentral.net ([127.0.0.1]) by localhost (mb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01412-03 for ; Wed, 24 Nov 2004 01:46:25 -0600 (CST) Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by scanner.servercentral.net (Postfix) with ESMTP id 7384F8700BF for ; Wed, 24 Nov 2004 01:46:25 -0600 (CST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id BA86C5751A; Wed, 24 Nov 2004 07:45:44 +0000 (GMT) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9551716A4DC; Wed, 24 Nov 2004 07:45:43 +0000 (GMT) Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D44916A4D0; Wed, 24 Nov 2004 07:45:39 +0000 (GMT) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 010A543D2D; Wed, 24 Nov 2004 07:45:39 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: by ion.gank.org (mail, from userid 1001) id DB5F02AA77; Wed, 24 Nov 2004 01:45:38 -0600 (CST) Date: Wed, 24 Nov 2004 01:45:38 -0600 From: Craig Boston To: Daniel Eischen Message-ID: <20041124074538.GB67289@nowhere> References: <200411240102.42269.craig@tobuj.gank.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-hackers@freebsd.org Errors-To: owner-freebsd-hackers@freebsd.org X-Virus-Scanned: by amavis for cervercentral.net X-OriginalArrivalTime: 24 Nov 2004 07:46:37.0549 (UTC) FILETIME=[BA46F1D0:01C4D1F9] cc: freebsd-hackers@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: SSE vs. stack alignment vs. pthread X-BeenThere: freebsd-threads@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 16:34:13 -0000 On Wed, Nov 24, 2004 at 02:36:55AM -0500, Daniel Eischen wrote: > Tor Egge reported similar problem to me yesterday. I haven't had a chance > to test his patch, but this supposedly fixes it. He just sent me the patch via private mail a few minutes ago. With his patch applied, the stack (after the frame is set up by the thread function) is now 16-byte aligned and everything works just fine ... no bus error anymore. Craig _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-threads@FreeBSD.ORG Thu Nov 25 13:10:28 2004 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB8E416A4CE for ; Thu, 25 Nov 2004 13:10:28 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B8F143D45 for ; Thu, 25 Nov 2004 13:10:28 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id iAPDASCY086043 for ; Thu, 25 Nov 2004 13:10:28 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id iAPDASwV086042; Thu, 25 Nov 2004 13:10:28 GMT (envelope-from gnats) Resent-Date: Thu, 25 Nov 2004 13:10:28 GMT Resent-Message-Id: <200411251310.iAPDASwV086042@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-threads@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Alexander Nedotsukov Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 169B816A4CE for ; Thu, 25 Nov 2004 13:08:19 +0000 (GMT) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09B3343D2F for ; Thu, 25 Nov 2004 13:08:19 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id iAPD8IaZ013949 for ; Thu, 25 Nov 2004 13:08:18 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id iAPD8Iri013948; Thu, 25 Nov 2004 13:08:18 GMT (envelope-from nobody) Message-Id: <200411251308.iAPD8Iri013948@www.freebsd.org> Date: Thu, 25 Nov 2004 13:08:18 GMT From: Alexander Nedotsukov To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Subject: threads/74370: Cannot get lwp 0 registers in gdb 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: Thu, 25 Nov 2004 13:10:28 -0000 >Number: 74370 >Category: threads >Synopsis: Cannot get lwp 0 registers in gdb >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-threads >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Nov 25 13:10:28 GMT 2004 >Closed-Date: >Last-Modified: >Originator: Alexander Nedotsukov >Release: 5.3-STABLE, 6-CURRENT >Organization: >Environment: FreeBSD nest.bbnest.net 6.0-CURRENT FreeBSD 6.0-CURRENT #1: Fri Nov 19 23:03:42 JST 2004 bland@nest.bbnest.net:/usr/obj/usr/src/sys/NEST i386 >Description: For any program linked against libpthread gdb unable to continue execution after stop-on-solib-event. >How-To-Repeat: $gdb ./a.out (gdb) set stop-on-solib-events 1 (gdb) r Starting program: /usr/home/bland/a.out [Switching to LWP 100092] Stopped due to shared library event (gdb) c Continuing. Cannot get lwp 0 registers: Operation not permitted >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-threads@FreeBSD.ORG Thu Nov 25 14:48:18 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 DEBC716A4CE; Thu, 25 Nov 2004 14:48:18 +0000 (GMT) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 638C443D4C; Thu, 25 Nov 2004 14:48:18 +0000 (GMT) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (mi@localhost [127.0.0.1]) by aldan.algebra.com (8.13.1/8.13.1) with ESMTP id iAPEmHaS098215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Nov 2004 09:48:17 -0500 (EST) (envelope-from mi+kde@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by aldan.algebra.com (8.13.1/8.13.1/Submit) id iAPEmGoE098214; Thu, 25 Nov 2004 09:48:16 -0500 (EST) (envelope-from mi+kde@aldan.algebra.com) From: Mikhail Teterin To: Brian Fundakowski Feldman Date: Thu, 25 Nov 2004 09:48:15 -0500 User-Agent: KMail/1.7 References: <200411250844.iAP8i1R8002966@repoman.freebsd.org> <20041125115638.GC1473@green.homeunix.org> In-Reply-To: <20041125115638.GC1473@green.homeunix.org> X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7whJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" cc: freebsd-threads@freebsd.org Subject: Re: cvs commit: ports/devel/icu Makefile 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: Thu, 25 Nov 2004 14:48:19 -0000 On Thursday 25 November 2004 06:56 am, Brian Fundakowski Feldman wrote: = > So this was not a fluke on my machine. intltest does hang more = > often, than it does not and a thread-guru should take a closer = > look. = > = > Modify the port to make `intltest' part optional, while running = > through other vendor's tests. Vendor is notified -- = I'll bet it hangs with libpthread, and seems to work okay with libc_r. Try it. The port obeys PTHREAD_LIBS and PTHREAD_CFLAGS settings (or should). Once it builds, do `make intltest' no need to even install the thing. ICU documents some issues threading and on Solaris -- due, supposedly, to unsafe sleep/usleep there: http://oss.software.ibm.com/cvs/icu/~checkout~/icu/readme.html?tag=release-3-2#ImportantNotesSolaris It would be great to resolve this -- FreeBSD's threading or ICU or both will benefit. Thanks! -mi From owner-freebsd-threads@FreeBSD.ORG Fri Nov 26 12:38:24 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 42C3C16A4D6 for ; Fri, 26 Nov 2004 12:38:24 +0000 (GMT) Received: from smtp.rol.ru (smtp.rol.ru [194.67.21.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBF9543D46 for ; Fri, 26 Nov 2004 12:38:23 +0000 (GMT) (envelope-from ab_fatal@mail.ru) Received: from ts3-b139.NNovgorod.dial.rol.ru ([212.92.166.139]:53002 "EHLO mail.ru" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by gnome04.net.rol.ru with ESMTP id S17310413AbUKZMiW (ORCPT ); Fri, 26 Nov 2004 15:38:22 +0300 Message-ID: <41A72410.9080500@mail.ru> Date: Fri, 26 Nov 2004 15:39:44 +0300 From: Alexander Bubnov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-threads@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: deadlock 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, 26 Nov 2004 12:38:24 -0000 /* Hello! Could you tell me why this exemple is deadlocked under FreeBSD, not Linux? (FreeBSD 4.10 and 5.2 , I have not tried under other versions) a string that includes this problem marked, see below the main function */ #include #include #include #include #include #include #include int Exit=0;/* uses in hand(), changes in main() */ int ReStart,Start;/* semaphores ID which returns semget() */ /* Start semphore controls starting threads, EXETHREADS - how many threads can start in one time ReStart semaphore for wait when the starting threads display a string */ struct sembuf dec={0},inc={0},op={0};/* they initilize in the main function*/ void*hand(void*p){ do{ semop(Start,&dec,1); if(Exit)break; puts(p); semop(ReStart,&inc,1); }while(1); fprintf(stderr,"bye, %s!\n",p); return NULL; } #define MAXTHREADS 5 #define EXETHREADS 2 /* number of threads which is executed in one time*/ #define ITERAT 2 /* number of iterations, see the main function */ int main(void){ char*s[MAXTHREADS]={"Mike","Leo","Don","Raph","Splinter"}; int i; pthread_t thread[MAXTHREADS]; /* to initlize semaphores operations */ dec.sem_op=-1,inc.sem_op=1,op.sem_op=EXETHREADS; if( -1==(Start=semget('A',1,0666|IPC_CREAT)) || -1==(ReStart=semget('B',1,0666|IPC_CREAT)) ){perror("semget");return EXIT_FAILURE;} /* to initilize semaphores value */ semctl(Start,0,SETVAL,0); semctl(ReStart,0,SETVAL,0); #ifndef linux /* may be this string is not needed, I do not know*/ if(pthread_setconcurrency(MAXTHREADS+1))perror("concurrency"); #endif /* to create the threads */ for(i=0;i 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 2C51516A4CE; Fri, 26 Nov 2004 18:57:01 +0000 (GMT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80C9F43D41; Fri, 26 Nov 2004 18:57:00 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from h00609772adf0.ne.client2.attbi.com ([66.30.114.143]) by comcast.net (sccrmhc12) with ESMTP id <2004112618565901200imjese>; Fri, 26 Nov 2004 18:56:59 +0000 Received: from h00609772adf0.ne.client2.attbi.com (localhost [127.0.0.1]) iAQIuxfo004252; Fri, 26 Nov 2004 13:56:59 -0500 (EST) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost)iAQIuxh9004251; Fri, 26 Nov 2004 13:56:59 -0500 (EST) (envelope-from rodrigc) Date: Fri, 26 Nov 2004 13:56:58 -0500 From: Craig Rodrigues To: Alexander Nedotsukov Message-ID: <20041126185658.GA4213@crodrigues.org> References: <41A1A3A5.20601@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41A1A3A5.20601@FreeBSD.org> User-Agent: Mutt/1.4.1i cc: freebsd-threads@freebsd.org Subject: Re: Question about our default pthread stack size 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, 26 Nov 2004 18:57:01 -0000 On Mon, Nov 22, 2004 at 05:30:29PM +0900, Alexander Nedotsukov wrote: > - main stream follows the stack usage rules I described above and chosen > 1MB/2MB for their default stacks size. > - we have limit which most likely triggers SIGSEGV. Alexander, what was the original application which you were working with where you encountered this thread stack problem? It would be good if multithreaded code that was written on Linux or Solaris worked as much as possible "out of the box", especially large applications like GNOME. Like it or not, these are dominant platforms, and we might have to adjust a bit to accomodate their quirks of large default thread stack size (a developer can always decrease the stack size with pthread_attr_setstacksize() if his application requires a smaller stack). What is the patch that would be required to increase the default stacksize in libpthread, so that mainstream applicatons like GNOME, or the application you were working with, would "just work"? Is it something like: --- /tmp/thr_private.h.orig Fri Nov 26 13:50:16 2004 +++ /tmp/thr_private.h Fri Nov 26 13:50:55 2004 @@ -450,14 +450,14 @@ /* * Miscellaneous definitions. */ -#define THR_STACK_DEFAULT 65536 +#define THR_STACK_DEFAULT 0x100000 /* * Maximum size of initial thread's stack. This perhaps deserves to be larger * than the stacks of other threads, since many applications are likely to run * almost entirely on this stack. */ -#define THR_STACK_INITIAL 0x100000 +#define THR_STACK_INITIAL 0x200000 /* * Define the different priority ranges. All applications have thread -- Craig Rodrigues http://crodrigues.org rodrigc@crodrigues.org From owner-freebsd-threads@FreeBSD.ORG Fri Nov 26 22:42:41 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 728ED16A4CE for ; Fri, 26 Nov 2004 22:42:41 +0000 (GMT) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD20743D58 for ; Fri, 26 Nov 2004 22:42:40 +0000 (GMT) (envelope-from mbsd@pacbell.net) Received: from sotec.home (adsl-64-168-25-248.dsl.snfc21.pacbell.net [64.168.25.248])iAQMgTvR002479; Fri, 26 Nov 2004 17:42:30 -0500 Date: Fri, 26 Nov 2004 14:42:39 -0800 (PST) From: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= X-X-Sender: mikko@sotec.home To: Alexander Bubnov In-Reply-To: <41A72410.9080500@mail.ru> Message-ID: <20041126143048.U9837@sotec.home> References: <41A72410.9080500@mail.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-threads@freebsd.org Subject: Re: deadlock 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, 26 Nov 2004 22:42:41 -0000 Hi Alexander, On Fri, 26 Nov 2004, Alexander Bubnov wrote: > /* > Hello! > Could you tell me why this exemple is deadlocked under FreeBSD, not Linux? > (FreeBSD 4.10 and 5.2 , I have not tried under other versions) > > a string that includes this problem marked, see below the main function > > */ > #include > #include > #include > #include > #include > #include > #include > > int Exit=0;/* uses in hand(), changes in main() */ > int ReStart,Start;/* semaphores ID which returns semget() */ > /* > Start semphore controls starting threads, > EXETHREADS - how many threads can start in one time > ReStart semaphore for wait when the starting threads display a string > */ > struct sembuf dec={0},inc={0},op={0};/* they initilize in the main function*/ > void*hand(void*p){ > do{ > semop(Start,&dec,1); > if(Exit)break; > puts(p); > semop(ReStart,&inc,1); > }while(1); > fprintf(stderr,"bye, %s!\n",p); > return NULL; > } > > #define MAXTHREADS 5 > #define EXETHREADS 2 /* number of threads which is executed in one time*/ > #define ITERAT 2 /* number of iterations, see the main function */ > > int main(void){ > char*s[MAXTHREADS]={"Mike","Leo","Don","Raph","Splinter"}; > int i; > pthread_t thread[MAXTHREADS]; > /* to initlize semaphores operations */ > dec.sem_op=-1,inc.sem_op=1,op.sem_op=EXETHREADS; > if( -1==(Start=semget('A',1,0666|IPC_CREAT)) || > -1==(ReStart=semget('B',1,0666|IPC_CREAT)) > ){perror("semget");return EXIT_FAILURE;} > /* to initilize semaphores value */ > semctl(Start,0,SETVAL,0); > semctl(ReStart,0,SETVAL,0); > #ifndef linux /* may be this string is not needed, I do not know*/ > if(pthread_setconcurrency(MAXTHREADS+1))perror("concurrency"); > #endif Not needed. Also, it does not set errno, it returns the error value. Use strerror(). > > /* to create the threads */ > for(i=0;i pthread_create(thread+i,NULL,hand,s[i]); > for(i=0;i puts("____START____"); > semop(Start,&op,1); > /* to wait EXETHREADS threads */ > op.sem_op*=-1; > /* > !!! this problem is here !!! > if I insert 'pause()' or 'while(1)' instend of > 'semop(ReStart,&op,1)' > that only one thread is executed two time, why? > this code does not help too (but I can see names that > is printed by hand()) > op.sem_flg=IPC_NOWAIT > while(-1==semop(ReStart,&op,1) && EAGAIN); > */ > semop(ReStart,&op,1); > op.sem_op*=-1; > puts("____FINISH____"); > } > /* to wait the threads to exit*/ > semctl(Start,0,SETVAL,MAXTHREADS); > Exit=1; > for(i=0;i pthread_join(thread[i],NULL); > > if( -1==semctl(ReStart,0,IPC_RMID) || > -1==semctl(Start,0,IPC_RMID) > ) perror("semdel"); > return EXIT_SUCCESS; > } Silently wondering why on earth anybody would want to use SYSV semaphores to synchronize threads in the same program, I compiled and ran your code on some different boxes: FreeBSD 5.3, i386 - runs ok (?) FreeBSD 5.3, sparc64 - hangs after first line of output Linux 2.6/Debian 3.1, i386 - hangs after last line of output Solaris 9, sparc64 - dumps core in semctl I believe your program perhaps is not 100% correct... :-) $.02, /Mikko From owner-freebsd-threads@FreeBSD.ORG Sat Nov 27 00:30:02 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 92B7716A4CE for ; Sat, 27 Nov 2004 00:30:02 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7828143D46; Sat, 27 Nov 2004 00:30:02 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id iAR0U0pk072793; Sat, 27 Nov 2004 00:30:01 GMT (envelope-from davidxu@freebsd.org) Message-ID: <41A7CA88.60505@freebsd.org> Date: Sat, 27 Nov 2004 08:30:00 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040921 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexander Bubnov References: <41A72410.9080500@mail.ru> In-Reply-To: <41A72410.9080500@mail.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: deadlock 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, 27 Nov 2004 00:30:02 -0000 Your program has obvious race condition: main: create thread A: LOOP: A: wait on Start main: signal Start main: wait on Restart A: resumed from Start A: Signal Restart main: resumed from Restart main: Create thread B goto loop This demo shows FreeBSD has better throughput then others. David Xu Alexander Bubnov wrote: > /* > Hello! > Could you tell me why this exemple is deadlocked under FreeBSD, not > Linux? > (FreeBSD 4.10 and 5.2 , I have not tried under other versions) > > a string that includes this problem marked, see below the main function > > */ > #include > #include > #include > #include > #include > #include > #include > > int Exit=0;/* uses in hand(), changes in main() */ > int ReStart,Start;/* semaphores ID which returns semget() */ > /* > Start semphore controls starting threads, > EXETHREADS - how many threads can start in one time > ReStart semaphore for wait when the starting threads display a > string > */ > struct sembuf dec={0},inc={0},op={0};/* they initilize in the main > function*/ > void*hand(void*p){ > do{ > semop(Start,&dec,1); > if(Exit)break; > puts(p); > semop(ReStart,&inc,1); > }while(1); > fprintf(stderr,"bye, %s!\n",p); > return NULL; > } > > #define MAXTHREADS 5 > #define EXETHREADS 2 /* number of threads which is executed in one time*/ > #define ITERAT 2 /* number of iterations, see the main function */ > > int main(void){ > char*s[MAXTHREADS]={"Mike","Leo","Don","Raph","Splinter"}; > int i; > pthread_t thread[MAXTHREADS]; > /* to initlize semaphores operations */ > dec.sem_op=-1,inc.sem_op=1,op.sem_op=EXETHREADS; > if( -1==(Start=semget('A',1,0666|IPC_CREAT)) || > -1==(ReStart=semget('B',1,0666|IPC_CREAT)) > ){perror("semget");return EXIT_FAILURE;} > /* to initilize semaphores value */ > semctl(Start,0,SETVAL,0); > semctl(ReStart,0,SETVAL,0); > #ifndef linux /* may be this string is not needed, I do not know*/ > if(pthread_setconcurrency(MAXTHREADS+1))perror("concurrency"); > #endif > > /* to create the threads */ > for(i=0;i pthread_create(thread+i,NULL,hand,s[i]); > for(i=0;i puts("____START____"); > semop(Start,&op,1); > /* to wait EXETHREADS threads */ > op.sem_op*=-1; > /* > !!! this problem is here !!! > if I insert 'pause()' or 'while(1)' instend of > 'semop(ReStart,&op,1)' > that only one thread is executed two time, why? > this code does not help too (but I can see names > that is printed by hand()) > op.sem_flg=IPC_NOWAIT > while(-1==semop(ReStart,&op,1) && EAGAIN); > */ > semop(ReStart,&op,1); > op.sem_op*=-1; > puts("____FINISH____"); > } > /* to wait the threads to exit*/ > semctl(Start,0,SETVAL,MAXTHREADS); > Exit=1; > for(i=0;i pthread_join(thread[i],NULL); > > if( -1==semctl(ReStart,0,IPC_RMID) || > -1==semctl(Start,0,IPC_RMID) > ) perror("semdel"); > return EXIT_SUCCESS; > } > > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to > "freebsd-threads-unsubscribe@freebsd.org" > > From owner-freebsd-threads@FreeBSD.ORG Sat Nov 27 09:07:20 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 7B74F16A4CE; Sat, 27 Nov 2004 09:07:20 +0000 (GMT) Received: from smtp.rol.ru (smtp.rol.ru [194.67.21.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9F9A43D1D; Sat, 27 Nov 2004 09:07:19 +0000 (GMT) (envelope-from alek@mts-nn.ru) Received: from ts3-a127.NNovgorod.dial.rol.ru ([212.92.142.127]:45327 "EHLO mts-nn.ru" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by gnome10.net.rol.ru with ESMTP id S24062AbUK0JHS (ORCPT + 1 other); Sat, 27 Nov 2004 12:07:18 +0300 Message-ID: <41A84422.6090001@mts-nn.ru> Date: Sat, 27 Nov 2004 12:08:50 +0300 From: Alexander Bubnov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Xu References: <41A72410.9080500@mail.ru> <41A7CA88.60505@freebsd.org> In-Reply-To: <41A7CA88.60505@freebsd.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: deadlock again 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, 27 Nov 2004 09:07:20 -0000 Many thanks! I see, nevertheless why is my program deadlocked? You wanted to said this problem from race condition? But why does it work correctly under some UNIX, UNIX-like OS? David Xu wrote: > Your program has obvious race condition: > main: create thread A: > > LOOP: > > A: wait on Start > main: signal Start > main: wait on Restart > A: resumed from Start > A: Signal Restart > main: resumed from Restart > main: Create thread B > goto loop > > This demo shows FreeBSD has better throughput then others. > > David Xu > > Alexander Bubnov wrote: > >> /* >> Hello! >> Could you tell me why this exemple is deadlocked under FreeBSD, not >> Linux? >> (FreeBSD 4.10 and 5.2 , I have not tried under other versions) >> >> a string that includes this problem marked, see below the main function >> >> */ >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> >> int Exit=0;/* uses in hand(), changes in main() */ >> int ReStart,Start;/* semaphores ID which returns semget() */ >> /* >> Start semphore controls starting threads, >> EXETHREADS - how many threads can start in one time >> ReStart semaphore for wait when the starting threads display a >> string >> */ >> struct sembuf dec={0},inc={0},op={0};/* they initilize in the main >> function*/ >> void*hand(void*p){ >> do{ >> semop(Start,&dec,1); >> if(Exit)break; >> puts(p); >> semop(ReStart,&inc,1); >> }while(1); >> fprintf(stderr,"bye, %s!\n",p); >> return NULL; >> } >> >> #define MAXTHREADS 5 >> #define EXETHREADS 2 /* number of threads which is executed in one >> time*/ >> #define ITERAT 2 /* number of iterations, see the main function */ >> >> int main(void){ >> char*s[MAXTHREADS]={"Mike","Leo","Don","Raph","Splinter"}; >> int i; >> pthread_t thread[MAXTHREADS]; >> /* to initlize semaphores operations */ >> dec.sem_op=-1,inc.sem_op=1,op.sem_op=EXETHREADS; >> if( -1==(Start=semget('A',1,0666|IPC_CREAT)) || >> -1==(ReStart=semget('B',1,0666|IPC_CREAT)) >> ){perror("semget");return EXIT_FAILURE;} >> /* to initilize semaphores value */ >> semctl(Start,0,SETVAL,0); >> semctl(ReStart,0,SETVAL,0); >> #ifndef linux /* may be this string is not needed, I do not know*/ >> if(pthread_setconcurrency(MAXTHREADS+1))perror("concurrency"); >> #endif >> >> /* to create the threads */ >> for(i=0;i> pthread_create(thread+i,NULL,hand,s[i]); >> for(i=0;i> puts("____START____"); >> semop(Start,&op,1); >> /* to wait EXETHREADS threads */ >> op.sem_op*=-1; >> /* >> !!! this problem is here !!! >> if I insert 'pause()' or 'while(1)' instend of >> 'semop(ReStart,&op,1)' >> that only one thread is executed two time, why? >> this code does not help too (but I can see >> names that is printed by hand()) >> op.sem_flg=IPC_NOWAIT >> while(-1==semop(ReStart,&op,1) && EAGAIN); >> */ >> semop(ReStart,&op,1); >> op.sem_op*=-1; >> puts("____FINISH____"); >> } >> /* to wait the threads to exit*/ >> semctl(Start,0,SETVAL,MAXTHREADS); >> Exit=1; >> for(i=0;i> pthread_join(thread[i],NULL); >> if( -1==semctl(ReStart,0,IPC_RMID) || >> -1==semctl(Start,0,IPC_RMID) >> ) perror("semdel"); >> return EXIT_SUCCESS; >> } >> >> _______________________________________________ >> freebsd-threads@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-threads >> To unsubscribe, send any mail to >> "freebsd-threads-unsubscribe@freebsd.org" >> >> > > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to > "freebsd-threads-unsubscribe@freebsd.org" > > From owner-freebsd-threads@FreeBSD.ORG Sat Nov 27 09:07: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 2820A16A4CE for ; Sat, 27 Nov 2004 09:07:27 +0000 (GMT) Received: from smtp.rol.ru (smtp.rol.ru [194.67.21.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id A234843D62 for ; Sat, 27 Nov 2004 09:07:26 +0000 (GMT) (envelope-from alek@mts-nn.ru) Received: from ts3-a127.NNovgorod.dial.rol.ru ([212.92.142.127]:38405 "EHLO mts-nn.ru" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by gnome10.net.rol.ru with ESMTP id S25006AbUK0JHZ (ORCPT ); Sat, 27 Nov 2004 12:07:25 +0300 Message-ID: <41A84429.8010805@mts-nn.ru> Date: Sat, 27 Nov 2004 12:08:57 +0300 From: Alexander Bubnov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= References: <41A72410.9080500@mail.ru> <20041126143048.U9837@sotec.home> In-Reply-To: <20041126143048.U9837@sotec.home> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: deadlock 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, 27 Nov 2004 09:07:27 -0000 Many thanks! Mikko Tyo"la"ja"rvi wrote: > > Hi Alexander, > > On Fri, 26 Nov 2004, Alexander Bubnov wrote: > >> /* >> Hello! >> Could you tell me why this exemple is deadlocked under FreeBSD, not >> Linux? >> (FreeBSD 4.10 and 5.2 , I have not tried under other versions) >> >> a string that includes this problem marked, see below the main function >> >> */ >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> >> int Exit=0;/* uses in hand(), changes in main() */ >> int ReStart,Start;/* semaphores ID which returns semget() */ >> /* >> Start semphore controls starting threads, >> EXETHREADS - how many threads can start in one time >> ReStart semaphore for wait when the starting threads display a string >> */ >> struct sembuf dec={0},inc={0},op={0};/* they initilize in the main >> function*/ >> void*hand(void*p){ >> do{ >> semop(Start,&dec,1); >> if(Exit)break; >> puts(p); >> semop(ReStart,&inc,1); >> }while(1); >> fprintf(stderr,"bye, %s!\n",p); >> return NULL; >> } >> >> #define MAXTHREADS 5 >> #define EXETHREADS 2 /* number of threads which is executed in one >> time*/ >> #define ITERAT 2 /* number of iterations, see the main function */ >> >> int main(void){ >> char*s[MAXTHREADS]={"Mike","Leo","Don","Raph","Splinter"}; >> int i; >> pthread_t thread[MAXTHREADS]; >> /* to initlize semaphores operations */ >> dec.sem_op=-1,inc.sem_op=1,op.sem_op=EXETHREADS; >> if( -1==(Start=semget('A',1,0666|IPC_CREAT)) || >> -1==(ReStart=semget('B',1,0666|IPC_CREAT)) >> ){perror("semget");return EXIT_FAILURE;} >> /* to initilize semaphores value */ >> semctl(Start,0,SETVAL,0); >> semctl(ReStart,0,SETVAL,0); >> #ifndef linux /* may be this string is not needed, I do not know*/ >> if(pthread_setconcurrency(MAXTHREADS+1))perror("concurrency"); >> #endif > > > Not needed. Also, it does not set errno, it returns the error value. > Use strerror(). > >> >> /* to create the threads */ >> for(i=0;i> pthread_create(thread+i,NULL,hand,s[i]); >> for(i=0;i> puts("____START____"); >> semop(Start,&op,1); >> /* to wait EXETHREADS threads */ >> op.sem_op*=-1; >> /* >> !!! this problem is here !!! >> if I insert 'pause()' or 'while(1)' instend of 'semop(ReStart,&op,1)' >> that only one thread is executed two time, why? >> this code does not help too (but I can see names that is printed by >> hand()) >> op.sem_flg=IPC_NOWAIT >> while(-1==semop(ReStart,&op,1) && EAGAIN); >> */ >> semop(ReStart,&op,1); >> op.sem_op*=-1; >> puts("____FINISH____"); >> } >> /* to wait the threads to exit*/ >> semctl(Start,0,SETVAL,MAXTHREADS); >> Exit=1; >> for(i=0;i> pthread_join(thread[i],NULL); >> >> if( -1==semctl(ReStart,0,IPC_RMID) || >> -1==semctl(Start,0,IPC_RMID) >> ) perror("semdel"); >> return EXIT_SUCCESS; >> } > > > Silently wondering why on earth anybody would want to use SYSV > semaphores to synchronize threads in the same program, I compiled and > ran your code on some different boxes: > > FreeBSD 5.3, i386 - runs ok (?) > FreeBSD 5.3, sparc64 - hangs after first line of output > Linux 2.6/Debian 3.1, i386 - hangs after last line of output > Solaris 9, sparc64 - dumps core in semctl > > I believe your program perhaps is not 100% correct... :-) > > $.02, > /Mikko > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to > "freebsd-threads-unsubscribe@freebsd.org" > >