Bug 80166 - [panic] Debugger SMP race panic
Summary: [panic] Debugger SMP race panic
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 5.3-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-20 20:00 UTC by Steve Sears
Modified: 2018-01-08 23:22 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Sears 2005-04-20 20:00:39 UTC
      panic: mi_switch: did not reenter debugger

This panic happens often when setting a breakpoint and then hitting
it a few times.  I think I see the problem.

The bsd code in kern/subr_kdb.c does this:


#ifdef SMP
        if (did_stop_cpus)
                restart_cpus(stopped_cpus);
#endif

        kdb_active--;


The panic is this (mi_switch):

        /*
         * Don't perform context switches from the debugger.
         */
        if (kdb_active) {
                mtx_unlock_spin(&sched_lock);
                kdb_backtrace();
                kdb_reenter();
                panic("%s: did not reenter debugger", __func__);
        }


It's an mp-race.  It restarts the other CPU's before decrementing
kdb_active.   If the other CPU races into mi_switch first, a
panic is guaranteed.

Fix: 

Decrement kdb_active before restarting cpus.
How-To-Repeat:       Hit the same breakpoint several times on an SMP box.
Comment 1 ups freebsd_committer freebsd_triage 2005-04-22 22:12:42 UTC
Responsible Changed
From-To: freebsd-bugs->ups

I am currently working on some kdb changes to make  
SMP debugging easier that will include a fix for the  
problem. 
This does NOT imply that I adopted KDB ;-)
Comment 2 K. Macy freebsd_committer freebsd_triage 2007-11-16 09:06:36 UTC
State Changed
From-To: open->feedback


Your last comments implied that you were going to fix this, did that happen? 
Thanks.
Comment 3 Mark Linimon freebsd_committer freebsd_triage 2008-03-02 02:27:07 UTC
State Changed
From-To: feedback->suspended

Feedback wasn't received, but it sounds like the problem might still 
exist.
Comment 4 Eitan Adler freebsd_committer freebsd_triage 2018-01-08 04:14:28 UTC
For the following conditions
Product: Base System, Documentation Status: New, Open, In Progress, UNCONFIRMED 
Assignee: Former FreeBSD committer 

Reset to default assignee. Reset status to "Open".
Comment 5 Andriy Gapon freebsd_committer freebsd_triage 2018-01-08 23:22:28 UTC
The code is quite different now.