Date: Wed, 20 Nov 2002 13:29:34 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: "Joel M. Baldwin" <qumqats@outel.org> Cc: current@FreeBSD.ORG Subject: Re: panic: sleeping thread owns a mutex - with debug traceback Message-ID: <Pine.NEB.3.96L.1021120132453.44513F-100000@fledge.watson.org> In-Reply-To: <2964362.1037787636@[192.168.1.20]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 20 Nov 2002, Joel M. Baldwin wrote: > --On Wednesday, November 20, 2002 12:01 PM -0500 Robert Watson > <rwatson@FreeBSD.ORG> 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 <pid> Once you've found the process you're looking for, you can trace its stack using: trace <pid> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1021120132453.44513F-100000>