From owner-freebsd-threads@FreeBSD.ORG Fri Oct 29 21:09:12 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 78E8016A4CE for ; Fri, 29 Oct 2004 21:09:12 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48E8443D48 for ; Fri, 29 Oct 2004 21:09:12 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 9332 invoked from network); 29 Oct 2004 21:09:12 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 29 Oct 2004 21:09:11 -0000 Received: from [10.50.40.221] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i9TL97gj039257; Fri, 29 Oct 2004 17:09:07 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: David Xu Date: Fri, 29 Oct 2004 16:09:03 -0400 User-Agent: KMail/1.6.2 References: <20041028203900.GF47792@freebsd3.cimlogic.com.au> <41818397.8090303@freebsd.org> In-Reply-To: <41818397.8090303@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200410291609.03243.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx 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: Fri, 29 Oct 2004 21:09:12 -0000 On Thursday 28 October 2004 07:41 pm, David Xu wrote: > 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. > > It would be nice if you could provide some example code, even if the code > may contains bug, it is still good for me to see how pthread_cancel can > cause SIG 11, because pthread_cancel seems checking everything carefully. Unfortunately the only sample code I have right now is monodevelop built from the bsd-sharp stuff. I don't have any smaller samples. Note also that it's not pthread_cancel(), but pthread_testcancel(). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org