KDB/DDB deubgger_on_panic sysctl

From: Ed Maste <emaste_at_phaedrus.sandvine.ca>
Date: Tue, 1 Feb 2005 10:55:57 -0500
About 1/2 year ago there was a thread about the debug.debugger_on_panic
sysctl.  The report was that it no longer functioned the same way (i.e.
dropped into the debugger instead of panic, when set to zero), and the
replies suggested it still worked as designed.  We see the same
behaviour of entering the debugger.

The original thread was at
http://lists.freebsd.org/pipermail/freebsd-current/2004-July/031446.html

It appears that on RELENG_4 with DDB, the sysctl's behaviour was more
like debugger_on_panic_or_trap.  i386/i386/trap.c used to check
debugger_on_panic before calling kdb_trap (for DDB).

In RELENG_4, i386/i386/trap.c had, in trap_fatal():
http://fxr.watson.org/fxr/source/i386/i386/trap.c?v=RELENG4#L964

964 #ifdef KDB
965         if (kdb_trap(&psl))
966                 return;
967 #endif
968 #ifdef DDB
969         if ((debugger_on_panic || db_active) && kdb_trap(type, 0, frame))
970                 return;
971 #endif
972         printf("trap number             = %d\n", type);
973         if (type <= MAX_TRAP_MSG)
974                 panic("%s", trap_msg[type]);
975         else
976                 panic("unknown/reserved trap");

The following patch somewhat restores the previous functionality

$ diff -u3 trap.c.orig trap.c
--- trap.c.orig Tue Feb  1 10:21:50 2005
+++ trap.c      Tue Feb  1 10:26:01 2005
_at__at_ -753,6 +753,7 _at__at_
        return((rv == KERN_PROTECTION_FAILURE) ? SIGBUS : SIGSEGV);
 }
 
+extern int debugger_on_panic;
 static void
 trap_fatal(frame, eva)
        struct trapframe *frame;
_at__at_ -820,7 +821,7 _at__at_
        }
 
 #ifdef KDB
-       if (kdb_trap(type, 0, frame))
+       if (debugger_on_panic && kdb_trap(type, 0, frame))
                return;
 #endif
        printf("trap number             = %d\n", type);

If debugger_on_panic=0 and the debugger is entered for other reasons
(e.g. key sequence), I suppose there's an issue with something in the
debugger causing a trap and then leading to a panic.  In RELENG_4
there was a db_active global for this case, but it seems to be gone.
I'm not sure of the proper way to fix that, but my concern is mainly
that remote units don't sit at a debugger prompt.

Ed Maste
Sandvine Inc.
Received on Tue Feb 01 2005 - 14:56:01 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:27 UTC