svn commit: r243980 - in head/sys: kern sys
Alfred Perlstein
bright at mu.org
Fri Dec 7 18:31:10 UTC 2012
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
More information about the freebsd-arch
mailing list