From owner-freebsd-threads@FreeBSD.ORG Thu Oct 28 20:39: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 392A416A4CF; Thu, 28 Oct 2004 20:39:03 +0000 (GMT) Received: from freebsd3.cimlogic.com.au (adsl-20-121.swiftdsl.com.au [218.214.20.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 500D743D48; Thu, 28 Oct 2004 20:39:02 +0000 (GMT) (envelope-from jb@cimlogic.com.au) Received: by freebsd3.cimlogic.com.au (Postfix, from userid 102) id 8C63A6A9BC; Fri, 29 Oct 2004 06:39:00 +1000 (EST) Date: Fri, 29 Oct 2004 06:39:00 +1000 From: John Birrell To: John Baldwin Message-ID: <20041028203900.GF47792@freebsd3.cimlogic.com.au> References: <200410281554.07222.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410281554.07222.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2.1i cc: Daniel Eischen cc: threads@FreeBSD.org 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 List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2004 20:39:03 -0000 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. -- John Birrell