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