Date: Thu, 28 Oct 2004 15:49:21 -0500 From: "Jeremy Messenger" <mezz7@cox.net> To: "Daniel Eischen" <deischen@freebsd.org> Cc: John Baldwin <jhb@freebsd.org> Subject: Re: Infinite loop bug in libc_r on 4.x with condition variables and signals Message-ID: <opsgllgjle9aq2h7@mezz.mezzweb.com> In-Reply-To: <Pine.GSO.4.43.0410281610570.5783-100000@sea.ntplx.net> References: <Pine.GSO.4.43.0410281610570.5783-100000@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 28 Oct 2004 16:27:56 -0400 (EDT), Daniel Eischen
<deischen@freebsd.org> wrote:
> On Thu, 28 Oct 2004, John Baldwin wrote:
>
>> On Wednesday 27 October 2004 06:30 pm, Daniel Eischen wrote:
>> > On Wed, 27 Oct 2004, John Baldwin wrote:
>> > >
>> > > FWIW, we are having (I think) the same problem on 5.3 with
>> libpthread.
>> > > The panic there is in the mutex code about an assertion failing
>> because a
>> > > thread is on a syncq when it is not supposed to be.
>> >
>> > David and I recently fixed some races in pthread_join() and
>> > pthread_exit() in -current libpthread. Don't know if those
>> > were responsible...
>> >
>> > Here's a test program that shows correct behavior with both
>> > libc_r and libpthread in -current.
>>
>> 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.
>
> You also want to make sure you're not running out of stack space
> for your threads.
>
> Is the code trying to install signal frames on threads itself?
> That could cause the problems you are seeing.
Does it has to do with those lines in Mono's threads.c? Does it looks fine?
${WRKSRC}/mono/io-layer/threads.c (264 to 292 line):
=====================================================
/* Set a 2M stack size. This is the default on Linux, but BSD
* needs it. (The original bug report from Martin Dvorak <md@9ll.cz>
* set the size to 2M-4k. I don't know why it's short by 4k, so
* I'm leaving it as 2M until I'm told differently.)
*/
thr_ret = pthread_attr_init(&attr);
g_assert (thr_ret == 0);
/* defaults of 2Mb for 32bits and 4Mb for 64bits */
if (stacksize == 0){
#if HAVE_VALGRIND_MEMCHECK_H
if (RUNNING_ON_VALGRIND)
stacksize = 1 << 20;
else
stacksize = (SIZEOF_VOID_P / 2) * 1024 * 1024;
#else
stacksize = (SIZEOF_VOID_P / 2) * 1024 * 1024;
#endif
}
#ifdef HAVE_PTHREAD_ATTR_SETSTACKSIZE
thr_ret = pthread_attr_setstacksize(&attr, stacksize);
g_assert (thr_ret == 0);
#endif
ret=_wapi_timed_thread_create(&thread_private_handle->thread, &attr,
create, start, thread_exit, param,
handle);
=====================================================
Cheers,
Mezz
--
mezz7@cox.net - mezz@FreeBSD.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?opsgllgjle9aq2h7>