Infinite loop bug in libc_r on 4.x with condition variables and signals

[Daniel Eischen]

On Fri, 29 Oct 2004, 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.

Hmm, a [sig]longjmp() out of a signal handler to the
context of a different thread?

-- 
Dan