Date: Fri, 07 Dec 2012 10:31:08 -0800 From: Alfred Perlstein <bright@mu.org> To: Adrian Chadd <adrian@freebsd.org> Cc: Alfred Perlstein <alfred@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: svn commit: r243980 - in head/sys: kern sys Message-ID: <50C235EC.2050903@mu.org> In-Reply-To: <CAJ-Vmo=f5fxFzVOUWcXE6GxovH3kTB-UmEkuWc5CkK0ZU%2BQKpA@mail.gmail.com> References: <201212070825.qB78P9rY055786@svn.freebsd.org> <CAJ-Vmo=f5fxFzVOUWcXE6GxovH3kTB-UmEkuWc5CkK0ZU%2BQKpA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/7/12 6:25 AM, Adrian Chadd wrote:
> Ok, so can we now please split 'panic during debugging but we do
> handle the case' and 'panic during live runs as it really does mean
> we're hosed' assert checks, so coders can choose which is appropriate?
>
> Or does that now exist?
I'm not sure I'm understanding the requirement.
We have places in the code that explicitly call panic that I know of
that a KASSERT is not right because if the condition is caught then the
kernel will die badly.
Example (from subr_turnstile.c):
> /*
> * If the thread is asleep, then we are probably about
> * to deadlock. To make debugging this easier, just
> * panic and tell the user which thread misbehaved so
> * they can hopefully get a stack trace from the truly
> * misbehaving thread.
> */
> if (TD_IS_SLEEPING(td)) {
> printf(
> "Sleeping thread (tid %d, pid %d) owns a non-sleepable
> lock\n",
> td->td_tid, td->td_proc->p_pid);
> kdb_backtrace_thread(td);
> panic("sleeping thread");
> }
Or do you mean something else?
Propose an API! :) Let's see where this goes.
-Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50C235EC.2050903>