From owner-freebsd-current Wed Nov 20 10:29:39 2002 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 BF05D37B401 for ; Wed, 20 Nov 2002 10:29:37 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4F5143E6E for ; Wed, 20 Nov 2002 10:29:36 -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 gAKITYBF050790; Wed, 20 Nov 2002 13:29:34 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 20 Nov 2002 13:29:34 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Joel M. Baldwin" Cc: current@FreeBSD.ORG Subject: Re: panic: sleeping thread owns a mutex - with debug traceback In-Reply-To: <2964362.1037787636@[192.168.1.20]> 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 Wed, 20 Nov 2002, Joel M. Baldwin wrote: > --On Wednesday, November 20, 2002 12:01 PM -0500 Robert Watson > wrote: > > > On Wed, 20 Nov 2002, Robert Watson wrote: > > > >> Hmm. Another thread has decided to sleep while holding an inpcb > >> mutex. Any chance this can be reproduced while running WITNESS? If > >> so, you should get a panic earlier when the other thread sleeps in > >> the first place. The easiest way to do that is if you can reproduce > >> the panic with WITNESS. If you can't reproduce the panic, you may > >> be able to extract this from your system core using gdb -- you want > >> to figure out what the thread owner of the mutex is doing -- in the > >> context of the kassert() below, td is the pointer to the thread > >> that owns the mutex. I'm not sure how to extract a stack trace from > >> that information, unfortunately, perhaps someone can give us > >> pointers. (note: td from the priority_propagate() argument is > >> shadowed, which is annoying). > > > > Ack. I mis-read. You want the stack from thread td1 (the mutex > > owner), not thread td. > > The kernel that produced the core dump ALREADY HAS > WITNESS and WITNESS_SKIPSPIN! :( A great ddb command to use, if WITNESS is present, is the following: show locks That shows the locks held by the current thread. Also good: show locks Once you've found the process you're looking for, you can trace its stack using: trace This makes a little less sense in KSE land, but given that you're unlikely to have processes with more than one thread, it should work ok. If this panic recurs, we're interested in finding the process that holds the inpcb lock in question, and getting a stack trace of it. > I'll try to get more info from kgdb, but I doubt that I'll have much > luck since I've never tried using gdb before. 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