From owner-freebsd-threads@FreeBSD.ORG Mon Nov 29 08:12: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 0059416A4CE for ; Mon, 29 Nov 2004 08:12:06 +0000 (GMT) Received: from smtp1.jp.viruscheck.net (smtp1.jp.viruscheck.net [154.33.69.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id A753B43D6D for ; Mon, 29 Nov 2004 08:12:05 +0000 (GMT) (envelope-from bland@FreeBSD.org) Received: from scan2.jp.viruscheck.net ([154.33.69.37] helo=mail2.jp.viruscheck.net) by smtp1.jp.viruscheck.net with esmtp (Exim 3.36 #1) id 1CYgdf-0006ID-00; Mon, 29 Nov 2004 17:12:03 +0900 Received: from [220.108.149.115] (helo=noc.orchid) by mail2.jp.viruscheck.net with esmtp (Exim 3.36 #3) id 1CYgdf-00009o-00; Mon, 29 Nov 2004 17:12:03 +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 iAT8BlfQ048875; Mon, 29 Nov 2004 17:11:48 +0900 (JST) (envelope-from bland@FreeBSD.org) Message-ID: <41AAD9BE.102@FreeBSD.org> Date: Mon, 29 Nov 2004 17:11:42 +0900 From: Alexander Nedotsukov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041122 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Craig Rodrigues References: <41A1A3A5.20601@FreeBSD.org> <20041126185658.GA4213@crodrigues.org> In-Reply-To: <20041126185658.GA4213@crodrigues.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 29 Nov 2004 08:12:06 -0000 Craig Rodrigues wrote: >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? > > This time it was libburn which did on stack reservation for its data structures which just exeeds 64K. Another sample could be gstreamer which is much more stack hungry. >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: > > Yep. It is. If this going to be commited please bump __FreeBSD_version so we'll be able to conditionaly remove current hacks. Thanks, Alexander. > >--- /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 > > > > From owner-freebsd-threads@FreeBSD.ORG Mon Nov 29 11:02: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 9CC7116A4E2 for ; Mon, 29 Nov 2004 11:02:10 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B58143D48 for ; Mon, 29 Nov 2004 11:02:10 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id iATB2A8Y008165 for ; Mon, 29 Nov 2004 11:02:10 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id iATB29rh008159 for freebsd-threads@freebsd.org; Mon, 29 Nov 2004 11:02:09 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 29 Nov 2004 11:02:09 GMT Message-Id: <200411291102.iATB29rh008159@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, 29 Nov 2004 11:02:10 -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 o [2004/11/25] threads/74370threads Cannot get lwp 0 registers in gdb 20 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 Dec 1 02:52: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 3A92516A4CE for ; Wed, 1 Dec 2004 02:52:13 +0000 (GMT) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16C7443D54 for ; Wed, 1 Dec 2004 02:52:13 +0000 (GMT) (envelope-from kelly@nttmcl.com) Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.11/8.12.11) with ESMTP id iB12qCab043448 for ; Tue, 30 Nov 2004 18:52:12 -0800 (PST) (envelope-from kelly@nttmcl.com) Received: from localhost (kelly@localhost)iB12qCQ2043445 for ; Tue, 30 Nov 2004 18:52:12 -0800 (PST) (envelope-from kelly@nttmcl.com) X-Authentication-Warning: alicia.nttmcl.com: kelly owned process doing -bs Date: Tue, 30 Nov 2004 18:52:12 -0800 (PST) From: Kelly Yancey To: threads@freebsd.org Message-ID: <20041130181558.H42615@alicia.nttmcl.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Single stepping through threads 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, 01 Dec 2004 02:52:13 -0000 Is there a way to single-step (trap on the next instruction, not gdb's step) a single thread in a process without any remaining threads running concurrently *without* reimplementing gdb? My application is not a full debugger; all it needs to do is single-step through an application. However, I need to be certain that every instruction that is executed (no matter which thread it is in) traps so my tracing process can inspect the state of the application. My utility works fine for single-thread processes, but by my reading of kse_create(), new threads are created with the P_TRACED bit cleared meaning my utility has no control over them. It looks like the functionality I am after is provided by libthread_db, but it appears to require ps_global_lookup() to determine which threading library the application is using. However, to implement ps_global_lookup() I would have to add logic to parse the symbol table in the target program, assuming it even has one. Which gets me to the crux of my quandary: I'm not implementing a debugger, I don't particularly want to implement a debugger, and even if I did I cannot assume that the programs I am trying to trace have any debugging symbols. So how do I control a multithreaded application? As I see no special support for threads in truss(1), can I assume that procfs somehow avoids this issue? Thanks, Kelly