From owner-freebsd-threads@FreeBSD.ORG Thu Oct 28 20:49:11 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E49C16A4CF; Thu, 28 Oct 2004 20:49:11 +0000 (GMT) Received: from lakermmtao01.cox.net (lakermmtao01.cox.net [68.230.240.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD9B843D54; Thu, 28 Oct 2004 20:49:10 +0000 (GMT) (envelope-from mezz7@cox.net) Received: from mezz.mezzweb.com ([68.103.32.140]) by lakermmtao01.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041028204901.LGIN4770.lakermmtao01.cox.net@mezz.mezzweb.com>; Thu, 28 Oct 2004 16:49:01 -0400 To: "Daniel Eischen" References: Message-ID: Date: Thu, 28 Oct 2004 15:49:21 -0500 From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/7.54 (Linux, build 751) cc: threads@freebsd.org cc: John Baldwin Subject: Re: Infinite loop bug in libc_r on 4.x with condition variables and signals X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2004 20:49:11 -0000 On Thu, 28 Oct 2004 16:27:56 -0400 (EDT), Daniel Eischen 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 * 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