From owner-freebsd-threads@FreeBSD.ORG Mon Oct 13 04:54:38 2003 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 119E816A4B3 for ; Mon, 13 Oct 2003 04:54:38 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3C9543FBF for ; Mon, 13 Oct 2003 04:54:36 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id h9DBsZrq004495; Mon, 13 Oct 2003 07:54:36 -0400 (EDT) Date: Mon, 13 Oct 2003 07:54:35 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Doug Rabson In-Reply-To: <1066041497.14360.9.camel@builder02.qubesoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: GDB and libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2003 11:54:38 -0000 On 13 Oct 2003, Doug Rabson wrote: > I just upgraded one of my systems to the latest current and I came > across some problems with libthr. A program which I was working on > suddenly found itself linked against libthr (presumably because of a new > version of libmap.conf or similar) and I found myself completely unable > to debug it. This was not a threaded application, merely one which had > linked against libthr. > > The symtoms are that when running the application under gdb, it quickly > hangs and starts consuming as much CPU time as it can. I looked into > things carefully and at the bottom of things, I discovered that when a > libthr mutex is held, the process blocks out SIGTRAP (among other > things). If the application hits a breakpoint while the mutex is held, > everything quickly goes pear shaped since the application doesn't get > the SIGTRAP. Basically it gets into a tight loop of hitting the > breakpoint, getting a signal, ignoring it and then trying to execute the > breakpoint instruction again. > > Since this also happens when dlopen is called (there is always a > breakpoint inside the dynamic linker to keep GDB's list of shared > libraries up to date) and since comon apis such as getpwuid end up in > dlopen via nsdispatch, it becomes impossible to run many applications > even without setting breakpoints. > > The simplest change which fixed things for me was to remove SIGTRAP from > the list of signals blocked on mutex entry: I don't maintain libthr, but this looks OK to me. > > Index: thr_kern.c > =================================================================== > RCS file: /home/ncvs/src/lib/libthr/thread/thr_kern.c,v > retrieving revision 1.13 > diff -u -r1.13 thr_kern.c > --- thr_kern.c 8 Jul 2003 09:58:23 -0000 1.13 > +++ thr_kern.c 12 Oct 2003 12:05:39 -0000 > @@ -80,6 +80,7 @@ > #ifdef _PTHREADS_INVARIANTS > SIGDELSET(set, SIGABRT); > #endif > + SIGDELSET(set, SIGTRAP); > > /* If we have already blocked signals, just up the refcount */ > if (++curthread->signest > 1) > > > -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Oct 13 05:22:14 2003 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 ED57016A4BF; Mon, 13 Oct 2003 05:22:14 -0700 (PDT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id A013643FCB; Mon, 13 Oct 2003 05:22:13 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id h9DCMDFH038131; Mon, 13 Oct 2003 13:22:14 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) h9DCM9bx036591; Mon, 13 Oct 2003 13:22:12 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1066047729.14360.15.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 13 Oct 2003 13:22:09 +0100 Content-Transfer-Encoding: 7bit cc: threads@FreeBSD.org Subject: Re: GDB and libthr 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, 13 Oct 2003 12:22:15 -0000 On Mon, 2003-10-13 at 12:54, Daniel Eischen wrote: > On 13 Oct 2003, Doug Rabson wrote: > > > I just upgraded one of my systems to the latest current and I came > > across some problems with libthr. A program which I was working on > > suddenly found itself linked against libthr (presumably because of a new > > version of libmap.conf or similar) and I found myself completely unable > > to debug it. This was not a threaded application, merely one which had > > linked against libthr. > > > > The symtoms are that when running the application under gdb, it quickly > > hangs and starts consuming as much CPU time as it can. I looked into > > things carefully and at the bottom of things, I discovered that when a > > libthr mutex is held, the process blocks out SIGTRAP (among other > > things). If the application hits a breakpoint while the mutex is held, > > everything quickly goes pear shaped since the application doesn't get > > the SIGTRAP. Basically it gets into a tight loop of hitting the > > breakpoint, getting a signal, ignoring it and then trying to execute the > > breakpoint instruction again. > > > > Since this also happens when dlopen is called (there is always a > > breakpoint inside the dynamic linker to keep GDB's list of shared > > libraries up to date) and since comon apis such as getpwuid end up in > > dlopen via nsdispatch, it becomes impossible to run many applications > > even without setting breakpoints. > > > > The simplest change which fixed things for me was to remove SIGTRAP from > > the list of signals blocked on mutex entry: > > I don't maintain libthr, but this looks OK to me. Sorry - I saw you comment on a similar message when I did a google search for gdb+libthr. Who would be a better person to send this to? It occurred to me that similar severe problems would occur with libthr if an application took a SIGSEGV, SIGBUS, SIGABORT or any other fatal unrecoverable signal while holding a mutex. From owner-freebsd-threads@FreeBSD.ORG Mon Oct 13 05:43:35 2003 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 6671116A4B3 for ; Mon, 13 Oct 2003 05:43:35 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C86843FBD for ; Mon, 13 Oct 2003 05:43:34 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id h9DChXrq014202; Mon, 13 Oct 2003 08:43:34 -0400 (EDT) Date: Mon, 13 Oct 2003 08:43:33 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Doug Rabson In-Reply-To: <1066047729.14360.15.camel@builder02.qubesoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@FreeBSD.org Subject: Re: GDB and libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@FreeBSD.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2003 12:43:35 -0000 On 13 Oct 2003, Doug Rabson wrote: > On Mon, 2003-10-13 at 12:54, Daniel Eischen wrote: > > > > I don't maintain libthr, but this looks OK to me. > > Sorry - I saw you comment on a similar message when I did a google > search for gdb+libthr. Who would be a better person to send this to? It > occurred to me that similar severe problems would occur with libthr if > an application took a SIGSEGV, SIGBUS, SIGABORT or any other fatal > unrecoverable signal while holding a mutex. Mike Makonnen (mtm) is the maintainer, but in theory posting to threads@ with libthr problems (as well as libkse problems) should also be sufficient. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Oct 13 05:54:47 2003 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 1F7DF16A4B3; Mon, 13 Oct 2003 05:54:47 -0700 (PDT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 162C843FBF; Mon, 13 Oct 2003 05:54:46 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id h9DCskFH038782; Mon, 13 Oct 2003 13:54:46 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) h9DCsgbx037190; Mon, 13 Oct 2003 13:54:44 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1066049682.14360.17.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 13 Oct 2003 13:54:42 +0100 Content-Transfer-Encoding: 7bit cc: threads@FreeBSD.org Subject: Re: GDB and libthr 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, 13 Oct 2003 12:54:47 -0000 On Mon, 2003-10-13 at 13:43, Daniel Eischen wrote: > On 13 Oct 2003, Doug Rabson wrote: > > > On Mon, 2003-10-13 at 12:54, Daniel Eischen wrote: > > > > > > I don't maintain libthr, but this looks OK to me. > > > > Sorry - I saw you comment on a similar message when I did a google > > search for gdb+libthr. Who would be a better person to send this to? It > > occurred to me that similar severe problems would occur with libthr if > > an application took a SIGSEGV, SIGBUS, SIGABORT or any other fatal > > unrecoverable signal while holding a mutex. > > Mike Makonnen (mtm) is the maintainer, but in theory posting to > threads@ with libthr problems (as well as libkse problems) should > also be sufficient. Thanks - I'll repost there. From owner-freebsd-threads@FreeBSD.ORG Mon Oct 13 06:44:43 2003 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 1424516A4B3 for ; Mon, 13 Oct 2003 06:44:43 -0700 (PDT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3669843F93 for ; Mon, 13 Oct 2003 06:44:40 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id h9DDidFH039906 for ; Mon, 13 Oct 2003 14:44:40 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) h9DDibbx038207 for ; Mon, 13 Oct 2003 14:44:38 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: threads@freebsd.org Content-Type: text/plain Message-Id: <1066052677.14360.29.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 13 Oct 2003 14:44:37 +0100 Content-Transfer-Encoding: 7bit Subject: GDB and libthr 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, 13 Oct 2003 13:44:43 -0000 I just upgraded one of my systems to the latest current and I came across some problems with libthr. A program which I was working on suddenly found itself linked against libthr (presumably because of a new version of libmap.conf or similar) and I found myself completely unable to debug it. This was not a threaded application, merely one which had linked against libthr. The symtoms are that when running the application under gdb, it quickly hangs and starts consuming as much CPU time as it can. I looked into things carefully and at the bottom of things, I discovered that when a libthr mutex is held, the process blocks out SIGTRAP (among other things). If the application hits a breakpoint while the mutex is held, everything quickly goes pear shaped since the application doesn't get the SIGTRAP. Basically it gets into a tight loop of hitting the breakpoint, getting a signal, ignoring it and then trying to execute the breakpoint instruction again. Since this also happens when dlopen is called (there is always a breakpoint inside the dynamic linker to keep GDB's list of shared libraries up to date) and since comon apis such as getpwuid end up in dlopen via nsdispatch, it becomes impossible to run many applications even without setting breakpoints. Also, if an application happens to take a non-recoverable fatal signal such as SIGSEGV, SIGBUS, SIGSYS or similar while holding a mutex, it will wedge itself in a tight loop in a similar way, whether or not it is running under GDB. The simplest change which fixed things for me was to remove SIGTRAP from the list of signals blocked on mutex entry. This does not fix the similar problems with SIGSEGV etc. Index: thr_kern.c =================================================================== RCS file: /home/ncvs/src/lib/libthr/thread/thr_kern.c,v retrieving revision 1.13 diff -u -r1.13 thr_kern.c --- thr_kern.c 8 Jul 2003 09:58:23 -0000 1.13 +++ thr_kern.c 12 Oct 2003 12:05:39 -0000 @@ -80,6 +80,7 @@ #ifdef _PTHREADS_INVARIANTS SIGDELSET(set, SIGABRT); #endif + SIGDELSET(set, SIGTRAP); /* If we have already blocked signals, just up the refcount */ if (++curthread->signest > 1) From owner-freebsd-threads@FreeBSD.ORG Mon Oct 13 11:01:45 2003 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 B966016A4DE for ; Mon, 13 Oct 2003 11:01:45 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73A1143FDF for ; Mon, 13 Oct 2003 11:01:41 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h9DI1fFY044443 for ; Mon, 13 Oct 2003 11:01:41 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h9DI1eLi044437 for freebsd-threads@freebsd.org; Mon, 13 Oct 2003 11:01:40 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 13 Oct 2003 11:01:40 -0700 (PDT) Message-Id: <200310131801.h9DI1eLi044437@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, 13 Oct 2003 18:01:45 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything o [2002/01/16] kern/33951 threads pthread_cancel is ignored 2 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/07/18] kern/20016 threads pthreads: Cannot set scheduling timer/Can o [2000/08/26] misc/20861 threads libc_r does not honor socket timeouts o [2001/01/19] bin/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVT o [2001/01/25] bin/24632 threads libc_r delicate deviation from libc in ha o [2001/01/25] misc/24641 threads pthread_rwlock_rdlock can deadlock o [2001/04/02] bin/26307 threads libc_r aborts when using the KDE media pl o [2001/10/31] bin/31661 threads pthread_kill signal handler doesn't get s o [2001/11/26] bin/32295 threads pthread dont dequeue signals o [2002/02/01] i386/34536 threads accept() blocks other threads o [2002/03/07] bin/35622 threads sigaltstack is missing in libc_r o [2002/05/25] kern/38549 threads the procces compiled whith pthread stoppe o [2002/06/27] bin/39922 threads [PATCH?] Threaded applications executed w o [2002/08/04] misc/41331 threads Pthread library open sets O_NONBLOCK flag o [2002/10/10] kern/43887 threads abnormal CPU useage when use pthread_mute o [2003/03/02] bin/48856 threads Setting SIGCHLD to SIG_IGN still leaves z o [2003/03/10] bin/49087 threads Signals lost in programs linked with libc a [2003/04/08] bin/50733 threads buildworld won't build, because of linkin o [2003/05/07] bin/51949 threads thread in accept cannot be cancelled o [2003/05/30] kern/52817 threads top(1) shows garbage for threaded process 19 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/05/25] misc/18824 threads gethostbyname is not thread safe o [2000/10/21] misc/22190 threads A threaded read(2) from a socketpair(2) f o [2001/09/09] bin/30464 threads pthread mutex attributes -- pshared o [2002/05/02] bin/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwri o [2002/07/16] misc/40671 threads pthread_cancel doesn't remove thread from 5 problems total. From owner-freebsd-threads@FreeBSD.ORG Mon Oct 13 13:36:22 2003 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 B724816A4B3 for ; Mon, 13 Oct 2003 13:36:22 -0700 (PDT) Received: from qwerty.maxwell.syr.edu (qwerty.maxwell.syr.edu [128.230.129.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id C564C43F93 for ; Mon, 13 Oct 2003 13:36:21 -0700 (PDT) (envelope-from cmsedore@maxwell.syr.edu) Received: from qwerty.maxwell.syr.edu (qwerty.maxwell.syr.edu [128.230.129.248])h9DKaK5e063960; Mon, 13 Oct 2003 16:36:20 -0400 (EDT) (envelope-from cmsedore@maxwell.syr.edu) Date: Mon, 13 Oct 2003 16:36:20 -0400 (EDT) From: Christopher Sedore To: Daniel Eischen In-Reply-To: Message-ID: <20031013162204.H63667-100000@qwerty.maxwell.syr.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: odd problem(s) with libthr and libkse 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, 13 Oct 2003 20:36:22 -0000 On Sat, 11 Oct 2003, Daniel Eischen wrote: > On Sat, 11 Oct 2003, Christopher M. Sedore wrote: > > > I have a multithreaded program that I've built to run under libc_r, libthr, > > and libkse. I use the libc_r build for debugging and the others for actual > > work (the program is disk/network io intensive and I want the disk io > > concurrency from thr or kse). > > Anyway, here is the issue I'm seeing. It may be the same or a related > > problem for both, or may not be. > > When running under libthr, everything works fine for an indeterminate > > period, usually between 10 seconds and 30 minutes. Eventually, all program > > function stops. If I watch in top, threads get stuck in "sigwai". First > > one, then a couple, then all. > > When running under kse, the program pauses periodically. I have one thread > > that prints out a heartbeat once per second, and prints debug info. I get > > pauses of up to 5 seconds between my heartbeat: > > sigwait() may not be behaving as you'd expect in libkse. > It is slightly different than in libc_r, but should be > POSIX compliant nonetheless. The strange thing is that I don't call sigwait(). > I use the following to test libkse for I/O intensive applications: > > http://people.freebsd.org/~deischen/kse/crew.c > http://people.freebsd.org/~deischen/kse/sched_bug.c > > The latter test may be similar to what you are describing. > It spawns a bunch of threads to perform disk I/O and one thread > that just sleeps and prints an incrementing number once a > second. > > Use the first test as "crew node /usr/src" and it will spawn > worker threads to search for the string "node" in all files > in /usr/src. It is one of Butenhof's tests. Thanks, I'll try these and see if I get similar behaviour. > Other than that, you'll need to give more info. SCHED_4BSD > or SCHED_ULE? SMP or UP? scope system threads or scope > process threads? Sample program to demonstrate the problem? 4BSD, SMP. I'm running with default parameters, which I assume is scope process threads (I'd like to take advantage of M:N threading...). I've peaked out around 15 threads, so I don't think I should be bumping any limits. I can try to boil the program down to a sample. At this point it is too large (~6600 lines :-). -Chris From owner-freebsd-threads@FreeBSD.ORG Tue Oct 14 11:59:16 2003 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 922A716A4B3 for ; Tue, 14 Oct 2003 11:59:16 -0700 (PDT) Received: from omnivergent.com (mailex01.readyhosting.com [63.99.209.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id C816143FBF for ; Tue, 14 Oct 2003 11:59:05 -0700 (PDT) (envelope-from Dan@omnivergent.com) Received: from dang [198.123.44.81] by omnivergent.com with ESMTP (SMTPD32-7.07) id A7B841BC0104; Tue, 14 Oct 2003 14:00:08 -0500 From: To: Date: Tue, 14 Oct 2003 11:59:30 -0700 Message-ID: <000701c39285$4d5aae40$c90a0a0a@omni> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Thread func parameter address problem (BSD 4.8) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dgrammas@omnivergent.com List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2003 18:59:16 -0000 Hello, I have a threading runtime problem, and I was hoping you all could give me a little direction. I am writing a little divert sockets app on FreeBSD 4.8 release. I recompiled the kernel with the following options: options MROUTING # Multicast routing options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_FORWARD #enable transparent proxy support options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default options IPV6FIREWALL #firewall for IPv6 options IPV6FIREWALL_VERBOSE options IPV6FIREWALL_VERBOSE_LIMIT=100 options IPV6FIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT #divert sockets options IPSTEALTH #support for stealth forwarding options TCPDEBUG # Because I have a dual Pentium pro options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O options HTT # HyperThreading Technology Things worked fine until I tried to add a thread to my code. Here is my init code: void initialize_threads(sendqueuehead *sq, dc_info *pinfo) { pthread_t pth; pthread_attr_t pth_atr = NULL; int retval = 0; if (pthread_mutex_init(&pth_mutex, NULL)) { syslog(LOGERR, "cannot create mutext)"); perror("[initialize_threads] cannot create mutext"); exit(EXIT_FAILURE); } if (pthread_mutex_init(&pth_mutex_sendq, NULL)) { syslog(LOGERR, "cannot create mutext)"); perror("[initialize_threads] cannot create mutext"); exit(EXIT_FAILURE); } pthread_attr_init(&pth_atr); pthread_attr_setdetachstate(&pth_atr, PTHREAD_CREATE_DETACHED); retval =pthread_create(&pth, &pth_atr, hacpackets, (char *)pinfo); pthread_create(&pth, &pth_atr, heartbeat_timeout, sq); return; } When the function hacpackets() is started, its parameter address is off by 1 byte. In gdb, pinfo is fine in the initialize_threads functions, but in the hacpackets() function (since the address is off by one) I get a segmentation fault. Do threads work OK on 4.8? Is this an SMP problem? Any ideas? Thanks for the help. Regards Dan P.S. My dmesg at boot... Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-RELEASE #2: Sun Aug 17 17:55:54 PDT 2003 root@itchie.omni.com:/usr/obj/usr/src/sys/SMP Timecounter "i8254" frequency 1193182 Hz CPU: Pentium Pro (198.67-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x617 Stepping = 7 Features=0xfbff real memory = 134217728 (131072K bytes) avail memory = 125902848 (122952K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfec08000 cpu1 (AP): apic id: 4, version: 0x00040011, at 0xfec08000 io0 (APIC): apic id: 13, version: 0x00170011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc049a000. Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 isab0: at device 18.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 18.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pcib1: at device 20.0 on pci0 pci1: on pcib1 ahc0: port 0xec00-0xecff mem 0xfaeff000-0xfaefffff irq 11 at device 5.0 on pci1 ahc0: Using left over BIOS settings aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs fxp0: port 0xe800-0xe81f mem 0xfad00000-0xfadfffff,0xf78ff000-0xf78fffff irq 11 at device 10.0 on pci1 fxp0: Ethernet address 00:a0:c9:06:69:f7 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci1: at 15.0 orm0: