From owner-freebsd-threads@FreeBSD.ORG Thu Oct 28 23:40:34 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 7B72216A4CE; Thu, 28 Oct 2004 23:40:34 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66DF543D2D; Thu, 28 Oct 2004 23:40:34 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) i9SNeWwQ030648; Thu, 28 Oct 2004 23:40:33 GMT (envelope-from davidxu@freebsd.org) Message-ID: <41818397.8090303@freebsd.org> Date: Fri, 29 Oct 2004 07:41:11 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.2) Gecko/20041004 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Birrell References: <200410281554.07222.jhb@FreeBSD.org> <20041028203900.GF47792@freebsd3.cimlogic.com.au> In-Reply-To: <20041028203900.GF47792@freebsd3.cimlogic.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Daniel Eischen 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 List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2004 23:40:34 -0000 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. David Xu