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

[Jeremy Messenger]

On Thu, 28 Oct 2004 16:27:56 -0400 (EDT), Daniel Eischen  
<deischen at 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 at 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 at cox.net  -  mezz at FreeBSD.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/  -  gnome at FreeBSD.org