From owner-freebsd-threads@FreeBSD.ORG Thu Oct 6 23:00:20 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 885E516A41F for ; Thu, 6 Oct 2005 23:00:20 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4584643D45 for ; Thu, 6 Oct 2005 23:00:20 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j96N0K0I042250 for ; Thu, 6 Oct 2005 23:00:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j96N0KoB042249; Thu, 6 Oct 2005 23:00:20 GMT (envelope-from gnats) Date: Thu, 6 Oct 2005 23:00:20 GMT Message-Id: <200510062300.j96N0KoB042249@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: freebsd@spatula.net Cc: Subject: Re: threads/84778: libpthread busy loop/hang with Java when handling signals and Runtime.exec X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd@spatula.net List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2005 23:00:20 -0000 The following reply was made to PR threads/84778; it has been noted by GNATS. From: freebsd@spatula.net To: Daniel Eischen Cc: bug-followup@freebsd.org Subject: Re: threads/84778: libpthread busy loop/hang with Java when handling signals and Runtime.exec Date: Thu, 6 Oct 2005 15:46:38 -0700 (PDT) select, however, does call nanosleep, and nanosleep does call _nanosleep... but you're right that everything after that looks broken... though I've never seen a stack get smashed like that before. Usually I've seen freakish addresses and "??" for function names, not addresses that look reasonable and function names with symbols that can be actually located. What happens when you gcore a running threaded process? Do the process's threads stop while the core dump is being written? If not, could the stack have changed while the core was being dumped and we're actually seeing bits of stack from multiple running threads (and therefore basically useless information)? Which thread do you see in a core dump if there are multiple threads? On Thu, 6 Oct 2005, Daniel Eischen wrote: > On Thu, 6 Oct 2005 freebsd@spatula.net wrote: > >> What about them is "not possible" exactly? > > Because [_]nanosleep() does not call pthread_setconcurrency(). And > pthread_setconcurrency() does not call pthread_mutexattr_init(). > >> What about ktrace showing a tight loop of kse_release calls followed by >> RET kse_release 0? >> >> Why is it perfectly fine with libc_r? > > Libc_r is a totally different beast. You can't necessarily compare > apples and oranges. There are much more likely to be race conditions > exposed using libpthread than with libc_r. > > -- > DE >