kgdb still broken?
Kris Kennaway
kris at obsecurity.org
Sat Aug 20 19:09:59 GMT 2005
On Sat, Aug 20, 2005 at 11:58:55AM -0700, Marcel Moolenaar wrote:
> On Aug 20, 2005, at 11:27 AM, Kris Kennaway wrote:
>
> >On Fri, Aug 19, 2005 at 11:28:14PM -0700, Marcel Moolenaar wrote:
> >
> >>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/
> >>>db_command.c:401
> >>>#3 0x00000000c006a558 in db_command_loop () at /usr/src.6/sys/ddb/
> >>>db_command.c:452
> >>>#4 0x00000000c006d0b8 in db_trap (type=1855603632, code=0) at /usr/
> >>>src.6/sys/ddb/db_main.c:221
> >>>#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/
> >>>sparc64/sparc64/trap.c:307
> >>>#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.
> >>
> >
> >Regardless, this is what kgdb informed me was the backtrace for the
> >same thread that panicked and I traced with DDB and gdb53.
>
> I guess I just don't understand what's you're saying then. The
> backtrace above clearly and reliably tells me that the core was
> created by calling doadump() from within DDB. Such a backtrace
> cannot be obtained from within DDB itself. I don't know what you
> get with gdb53, but it should give you the same backtrace, unless
> it shows the backtrace of a different thread or you were working
> on a different core file altogether.
>
> >I mean that 'info threads' doesn't work in gdb53, which is the only
> >offline debugger one can use on sparc64 that obtains more or less
> >reliable traces.
>
> What exactly is unreliable about backtraces in kgdb?
Wih gdb53 I see the following:
# gdb53 -k kernel.debug vmcore.250
GNU gdb 5.3 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc64-portbld-freebsd7.0"...
panic: uma_small_alloc: free page still has mappings!
panic messages:
---
---
#0 doadump () at /usr/src.6/sys/kern/kern_shutdown.c:233
233 savectx(&dumppcb);
(kgdb) bt
#0 doadump () at /usr/src.6/sys/kern/kern_shutdown.c:233
#1 0x00000000c006a720 in db_fncall (dummy1=0, dummy2=0, dummy3=11, dummy4=0x16e9a41a0 "")
at /usr/src.6/sys/ddb/db_command.c:486
#2 0x00000000c006a42c in db_command (last_cmdp=0xc040f940, cmd_table=0x0, aux_cmd_tablep=0xc03c8dc8,
aux_cmd_tablep_end=0xc03c8de0) at /usr/src.6/sys/ddb/db_command.c:401
#3 0x00000000c006a550 in db_command_loop () at /usr/src.6/sys/ddb/db_command.c:452
#4 0x00000000c006d0b0 in db_trap (type=1855603632, code=0) at /usr/src.6/sys/ddb/db_main.c:219
#5 0x00000000c018d200 in kdb_trap (type=107, code=0, tf=0x16e9a4630) at /usr/src.6/sys/kern/subr_kdb.c:473
#6 0x00000000c02f6b44 in trap (tf=0x16e9a4630) at /usr/src.6/sys/sparc64/sparc64/trap.c:307
#7 0x00000000c018cddc in kdb_enter (msg=0x0) at /usr/src.6/sys/kern/subr_kdb.c:267
#8 0x00000000c018cdd4 in kdb_enter (msg=0xc03a2650 "panic") at /usr/src.6/sys/kern/subr_kdb.c:267
#9 0x00000000c016e144 in panic (fmt=0xc03c4130 "uma_small_alloc: free page still has mappings!")
at /usr/src.6/sys/kern/kern_shutdown.c:537
#10 0x00000000c02f83bc in uma_small_alloc (zone=0x101, bytes=8192, flags=0xfffff8013a465170 "ÿÿø\0019Ì\020p", wait=3)
at /usr/src.6/sys/sparc64/sparc64/vm_machdep.c:485
#11 0x00000000c02baf18 in slab_zalloc (zone=0xfffff8013dbfacc0, wait=3) at /usr/src.6/sys/vm/uma_core.c:819
#12 0x00000000c02bc96c in uma_zone_slab (zone=0xfffff8013dbfacc0, flags=3) at /usr/src.6/sys/vm/uma_core.c:2034
#13 0x00000000c02bcc2c in uma_zalloc_bucket (zone=0xfffff8013dbfacc0, flags=3) at /usr/src.6/sys/vm/uma_core.c:2143
#14 0x00000000c02bc7d0 in uma_zalloc_arg (zone=0xfffff8013dbfacc0, udata=0x0, flags=2) at /usr/src.6/sys/vm/uma_core.c:1951
#15 0x00000000c0162694 in malloc (size=18446735282947486976, mtp=0xc03f3368, flags=2) at uma.h:275
#16 0x00000000c01c5648 in allocbuf (bp=0xc143a920, size=2048) at /usr/src.6/sys/kern/vfs_bio.c:2654
#17 0x00000000c01c52e8 in getblk (vp=0xfffff800cf995740, blkno=0, size=2048, slpflag=0, slptimeo=0, flags=0)
at /usr/src.6/sys/kern/vfs_bio.c:2536
#18 0x00000000c0295ad0 in ffs_balloc_ufs2 (vp=0xfffff800cf995740, startoffset=0, size=512, cred=0xfffff8000ea86500,
flags=65536, bpp=0x16e9a5110) at /usr/src.6/sys/ufs/ffs/ffs_balloc.c:676
#19 0x00000000c02b519c in ufs_mkdir (ap=0x16e9a5440) at /usr/src.6/sys/ufs/ufs/ufs_vnops.c:1534
#20 0x00000000c02fa4ec in VOP_MKDIR_APV (vop=0xc0403a98, a=0x16e9a5440) at vnode_if.c:1250
#21 0x00000000c01dd870 in kern_mkdir (td=0xfffff8011e0b6980, path=---Can't read userspace from dump, or kernel process---
) at vnode_if.h:653
#22 0x00000000c01dd570 in mkdir (td=0xfffff8011e0b6980, uap=0x16e9a58c0) at /usr/src.6/sys/kern/vfs_syscalls.c:3300
#23 0x00000000c02f725c in syscall (tf=0x16e9a5880) at /usr/src.6/sys/sparc64/sparc64/trap.c:592
This corresponds to the ddb backtrace:
db> wh
Tracing pid 86114 tid 101592 td 0xfffff8011e0b6980
panic() at panic+0x164
uma_small_alloc() at uma_small_alloc+0x9c
slab_zalloc() at slab_zalloc+0x98
uma_zone_slab() at uma_zone_slab+0x12c
uma_zalloc_bucket() at uma_zalloc_bucket+0x16c
uma_zalloc_arg() at uma_zalloc_arg+0x330
malloc() at malloc+0x114
allocbuf() at allocbuf+0x208
getblk() at getblk+0x5a8
ffs_balloc_ufs2() at ffs_balloc_ufs2+0xa30
ufs_mkdir() at ufs_mkdir+0x55c
VOP_MKDIR_APV() at VOP_MKDIR_APV+0xcc
kern_mkdir() at kern_mkdir+0x2f0
mkdir() at mkdir+0x10
syscall() at syscall+0x2dc
-- syscall (136, FreeBSD ELF64, mkdir) %o7=0x105b90 --
userland() at 0x40527d08
user trace: trap %o7=0x105b90
pc 0x40527d08, sp 0x7fdffffd5d1
pc 0x105c6c, sp 0x7fdffffd711
done
While the kgdb output is useless:
(kgdb) # kgdb kernel.debug vmcore.250
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc64-marcel-freebsd".
Unread portion of the kernel message buffer:
” ‹ ¬€ ´€ Y i v ›€ ì 7 ˜ € 0 =
…€ Õ€ « ? q€ ~ ã » „€ v
#0 doadump () at /usr/src.6/sys/kern/kern_shutdown.c:233
233 savectx(&dumppcb);
(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/db_command.c:401
#3 0x00000000c006a558 in db_command_loop () at /usr/src.6/sys/ddb/db_command.c:452
#4 0x00000000c006d0b8 in db_trap (type=1855603632, code=0) at /usr/src.6/sys/ddb/db_main.c:221
#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/sparc64/sparc64/trap.c:307
#7 0x00000000c0048fe0 in tl1_trap ()
#8 0x00000000c0048fe0 in tl1_trap ()
Previous frame identical to this frame (corrupt stack?)
(kgdb)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20050820/7b6f6ce0/attachment.bin
More information about the freebsd-sparc64
mailing list