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

next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org



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