I'm running a ~2 week old -current, and when debugging some hacks of mine, I noticed that gdb -k seems to be missing at least one frame in its stack. Eg, ddb shows: panic: page fault cpuid = 0; lapic.id = 00000000 Stack backtrace: backtrace(c0380cf2,0,c036e757,d96d4bd4,100) at backtrace+0x17 panic(c036e757,c0395a7f,c5283164,1,1) at panic+0x14a trap_fatal(d96d4c98,0,c0395c61,2cd,c5281e40) at trap_fatal+0x356 trap_pfault(d96d4c98,0,0,d0d0d0d0,0) at trap_pfault+0x1c2 trap(18,10,d96d0010,0,0) at trap+0x2ed calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc52b3c5b, esp = 0xd96d4cd8, ebp = 0xd96d4cf4 --- mi_go(0,0,c52b381f,c5283000,d96d4d34) at mi_go+0x2b freebsd_mapper_thread(0,d96d4d48,c037e742,30e,d0d0d0d0) at freebsd_mapper_thread+0x49 fork_exit(c52b381f,0,d96d4d48) at fork_exit+0xcf fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd96d4d7c, ebp = 0 --- boot() called on cpu#0 But gdb -k shows: # gdb -k /sys/i386/compile/DEBUG/kernel.debug /var/crash/vmcore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. <....> #0 doadump () at ../../../kern/kern_shutdown.c:240 #1 0xc020c3eb in boot (howto=256) at ../../../kern/kern_shutdown.c:372 #2 0xc020c7f6 in panic () at ../../../kern/kern_shutdown.c:550 #3 0xc03442e6 in trap_fatal (frame=0xd96d4c98, eva=0) at ../../../i386/i386/trap.c:821 #4 0xc0343f62 in trap_pfault (frame=0xd96d4c98, usermode=0, eva=0) at ../../../i386/i386/trap.c:735 #5 0xc0343b1d in trap (frame= {tf_fs = 24, tf_es = 16, tf_ds = -647167984, tf_edi = 0, tf_esi = 0, tf_ebp = -647148300, tf_isp = -647148348, tf_ebx = 0, tf_edx = 0, tf_ecx = -1065271296, tf_eax = -987394048, tf_trapno = 12, tf_err = 2, tf_eip = -987022245, tf_cs = 8, tf_eflags = 66118, tf_esp = -986972328, tf_ss = -986972233}) at ../../../i386/i386/trap.c:420 #6 0xc032c318 in calltrap () at {standard input}:103 #7 0xc52b3868 in freebsd_mapper_thread (arg=0x0) at /home/gallatin/mx/mx/driver/freebsd/mi.c:60 #8 0xc01f785f in fork_exit (callout=0, arg=0x0, frame=0x0) at ../../../kern/kern_fork.c:790 The interesting function (mi_go) where the null pointer deref happened is missing from the trace. I thought only alpha had these kinds of problems :( DrewReceived on Tue Sep 02 2003 - 06:16:42 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:21 UTC