From owner-freebsd-threads@FreeBSD.ORG Thu Oct 28 20:57:38 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 8D43216A4CE; Thu, 28 Oct 2004 20:57:38 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3731E43D53; Thu, 28 Oct 2004 20:57:38 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) i9SKvYZv015235; Thu, 28 Oct 2004 16:57:34 -0400 (EDT) Date: Thu, 28 Oct 2004 16:57:34 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Birrell In-Reply-To: <20041028203900.GF47792@freebsd3.cimlogic.com.au> 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: threads@freebsd.org cc: John Baldwin Subject: Re: Infinite loop bug in libc_r on 4.x with condition variables and signals 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: Thu, 28 Oct 2004 20:57:38 -0000 On Fri, 29 Oct 2004, John Birrell wrote: > On Thu, Oct 28, 2004 at 03:54:07PM -0400, John Baldwin wrote: > > We've started testing on -current and are seeing several problems with > > libpthread. Using a UP kernel (machines have single processor with HTT) > > seems to make it better, but we seem to be getting SIG 11's in > > pthread_testcancel() as well as the failed lock assertions that were > > mentioned earlier on the list in the PR. Just running monodevelop from the > > bsd-sharp stuff mentioned earlier can break in that one of the processes dies > > with the assertion failure. If you let the other processes run, then you can > > run it again and get the window to pop up, but then clicking on any of the > > controls results in the pthread_testcancel() crash. FWIW, I think the reason > > that the stack traces look weird in the PR's thread may be due to catching a > > signal. When we were looking at the problems with libc_r on 4.x we would get > > some weird looking backtraces sometimes when the assertion in uthread_sig.c > > that I added failed. Seems that gdb doesn't handle the signal frames very > > well. > > I have a server running -current as of July 23 which runs a process that often > SIG 11's in pthread_testcancel() too. I've never been able to make sense of the > back trace because it always shows the initialisation path for a module, yet > for the process to run and serve web requests, that initialisation path must > have been completed. I've assumed there is a bug in my code elsewhere in the > application and that GDB is telling me the truth. Hmm, a [sig]longjmp() out of a signal handler to the context of a different thread? -- Dan