Date: Sat, 20 Aug 2005 12:31:02 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Kris Kennaway <kris@obsecurity.org> Cc: marcel@FreeBSD.org, sparc64@FreeBSD.org Subject: Re: kgdb still broken? Message-ID: <B7B4E68A-0DAF-471B-9588-7D7827AE272F@xcllnt.net> In-Reply-To: <20050820190957.GA66426@xor.obsecurity.org> References: <20050819171555.GA45748@xor.obsecurity.org> <A4D2B753-A1C2-4686-A656-4DF061AB72A8@xcllnt.net> <20050820025336.GA94049@xor.obsecurity.org> <3DBF403C-80AA-46B4-A57B-8B78F033E368@xcllnt.net> <20050820182755.GA57524@xor.obsecurity.org> <9D6502D2-02E7-4BAE-B3C1-AA6D4613C8BC@xcllnt.net> <20050820190957.GA66426@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 20, 2005, at 12:09 PM, Kris Kennaway wrote: >> What exactly is unreliable about backtraces in kgdb? >> > > Wih gdb53 I see the following: *snip* > #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 *snip* > While the kgdb output is useless: *snip* > #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?) *snip* I see. As I said, kgdb cannot yet unwind across trapframes. Other than that the backtrace seems to be reliable. Not being able to unwind across backtraces is not particular to sparc64. kgdb cannot do that on any platforms. Some platforms, i386 in particular, are lucky in that kgdb is able to get out of the woods and pick up the trail after being lost for a handful of frames. This is due to the way backtraces work on those platforms. As for the resolution: I've been working on a new import of gdb, which allows us to register frame sniffers to handle this, but gdb has changed internally in such a way that our threading support cannot be compiled-in. This requires porting, which I don't want to do because it needs to be rewritten to support all platforms and merged into gdb. I don't see a point in fixing backtraces at the cost of the partial threading support we have now. In other words: it requires too much work for me to embark on it right now. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B7B4E68A-0DAF-471B-9588-7D7827AE272F>