kgdb still broken?
marcel at xcllnt.net
Sat Aug 20 06:28:17 GMT 2005
On Aug 19, 2005, at 7:53 PM, Kris Kennaway wrote:
> It's not making much sense of the backtrace though:
> (kgdb) bt
> #0 doadump () at /usr/src.6/sys/kern/kern_shutdown.c:233
> #1 0x00000000c006a728 in db_fncall (dummy1=0, dummy2=0, dummy3=11,
> dummy4=0x16e9a41a0 "")
> at /usr/src.6/sys/ddb/db_command.c:486
> #2 0x00000000c006a434 in db_command (last_cmdp=0xc040f940,
> cmd_table=0x0, aux_cmd_tablep=0xc03c8dc8,
> aux_cmd_tablep_end=0xc03c8de0) at /usr/src.6/sys/ddb/
> #3 0x00000000c006a558 in db_command_loop () at /usr/src.6/sys/ddb/
> #4 0x00000000c006d0b8 in db_trap (type=1855603632, code=0) at /usr/
> #5 0x00000000c018d208 in kdb_trap (type=107, code=0,
> tf=0x16e9a4630) at /usr/src.6/sys/kern/subr_kdb.c:473
> #6 0x00000000c02f6b4c in trap (tf=0x16e9a4630) at /usr/src.6/sys/
> #7 0x00000000c0048fe0 in tl1_trap ()
> #8 0x00000000c0048fe0 in tl1_trap ()
> Previous frame identical to this frame (corrupt stack?)
> Where ddb showed that the panic correctly (see my mail to -current
> entitled 'panic: uma_small_alloc: free page still has mappings!').
How can you compare this backtrace with the one in the email. This
backtrace is the result of a trap, not a panic. For a panic, KDB
is entered via kdb_enter(), not kdb_trap() as it is in this case.
It is a known issue that kgdb cannot unwind across traps right now.
> gdb53 also gets it right, but I can't examine other threads to see if
> they had also panicked.
Do you mean that 'info threads' doesn't work or that 'thread <TID>'
doesn't work in kgdb?
Marcel Moolenaar USPA: A-39004 marcel at xcllnt.net
More information about the freebsd-sparc64