From owner-freebsd-current Sun Jan 5 10:50: 7 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D1FC37B401; Sun, 5 Jan 2003 10:50:05 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAA4B43EC2; Sun, 5 Jan 2003 10:50:04 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.6/8.12.5) with SMTP id h05Io41Z089607; Sun, 5 Jan 2003 13:50:04 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 5 Jan 2003 13:50:03 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Juli Mallett Cc: current@FreeBSD.org Subject: Re: pthread ^T problem on recent -CURRENT: death in libc_r mutex In-Reply-To: <20030104142844.A65065@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 4 Jan 2003, Juli Mallett wrote: > * De: Robert Watson [ Data: 2003-01-04 ] > [ Subjecte: pthread ^T problem on recent -CURRENT: death in libc_r mutex ] > > > > Juli Mallett pointed me at the following reproduceable problem on my > > -current notebook with userland/kernel dated Dec 29: > > Incidentally, this doesn't illustrate the problem I was actually trying > to point out. Try making the sleep's pthread_yield(). That will make > the threads never run again. sleep is the hack I've had to do. In my > appp, I have a 'my_yield' function which will sleep on FreeBSD, and > yield on everywhere else :( Updating to Jan 4 kernel generates the same failure mode for me: following a ^T, I get a core dump. If I run it outside of gdb and then run gdb on the core dump, I get the following: (gdb) bt #0 0x2807aa63 in _mutex_cv_lock () from /usr/lib/libc_r.so.5 #1 0x2807a749 in pthread_mutex_unlock () from /usr/lib/libc_r.so.5 #2 0x28136164 in funlockfile () from /usr/lib/libc.so.5 #3 0x2812c6ab in vfprintf () from /usr/lib/libc.so.5 #4 0x2811ab82 in printf () from /usr/lib/libc.so.5 #5 0x08048611 in thread1 (arg=0x0) at test.c:12 #6 0x280732ce in _thread_start () from /usr/lib/libc_r.so.5 There's a bit more noise if I run it under gdb, since gdb picks up the SIGINFO delivery (twice?) but the same result occurs in the end: 1load: 0.07 cmd: test 690 [running] 0.04u 0.20s 0% 816k Program received signal SIGINFO, Information request. 0x280d4c83 in poll () from /usr/lib/libc.so.5 (gdb) cont Continuing. Program received signal SIGINFO, Information request. 0x280d4c83 in poll () from /usr/lib/libc.so.5 (gdb) cont Continuing. Program received signal SIGBUS, Bus error. [Switching to Process 690, Thread 4] 0x2807aa63 in _mutex_cv_lock () from /usr/lib/libc_r.so.5 (gdb) trace trace command requires an argument (gdb) bt #0 0x2807aa63 in _mutex_cv_lock () from /usr/lib/libc_r.so.5 #1 0x2807a749 in pthread_mutex_unlock () from /usr/lib/libc_r.so.5 #2 0x28136164 in funlockfile () from /usr/lib/libc.so.5 #3 0x2812c6ab in vfprintf () from /usr/lib/libc.so.5 #4 0x2811ab82 in printf () from /usr/lib/libc.so.5 #5 0x08048611 in thread1 (arg=0x0) at test.c:12 #6 0x280732ce in _thread_start () from /usr/lib/libc_r.so.5 (gdb) Either way, still not the symptoms you have, but equally fatal. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message