Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Oct 2004 07:41:11 +0800
From:      David Xu <davidxu@freebsd.org>
To:        John Birrell <jb@cimlogic.com.au>
Cc:        John Baldwin <jhb@freebsd.org>
Subject:   Re: Infinite loop bug in libc_r on 4.x with condition variables and signals
Message-ID:  <41818397.8090303@freebsd.org>
In-Reply-To: <20041028203900.GF47792@freebsd3.cimlogic.com.au>
References:  <Pine.GSO.4.43.0410271826590.239-100000@sea.ntplx.net> <200410281554.07222.jhb@FreeBSD.org> <20041028203900.GF47792@freebsd3.cimlogic.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41818397.8090303>