Date: Thu, 28 Oct 2004 16:57:34 -0400 (EDT) From: Daniel Eischen <deischen@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: <Pine.GSO.4.43.0410281654571.5783-100000@sea.ntplx.net> In-Reply-To: <20041028203900.GF47792@freebsd3.cimlogic.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0410281654571.5783-100000>