Date: Fri, 02 Oct 2015 09:12:58 -0700 From: John Baldwin <jhb@freebsd.org> To: Andriy Gapon <avg@freebsd.org> Cc: Ryan Stone <rysto32@gmail.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: How to get anything useful out of kgdb? Message-ID: <1595419.L0rkNTMkPe@ralph.baldwin.cx> In-Reply-To: <560E238F.9050609@FreeBSD.org> References: <554E41EE.2010202@ignoranthack.me> <CAFMmRNyM6Tc7P8rLJmMSVXOFkK4Tc0OCOtc=E9dLEtzKrEtjLg@mail.gmail.com> <560E238F.9050609@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, October 02, 2015 09:26:23 AM Andriy Gapon wrote: > On 15/05/2015 20:57, Ryan Stone wrote: > > *Sigh*, kgdb isn't unwinding the trap frame properly. You can try this to > > figure out where it was running: > > I wonder, what is a reason for this? > Can that be fixed in kgdb itself? > It seems that usually kgdb handles trap frames just fine, but not always? It should be fixable. If this doesn't work under newer kgdb let me know and I'll try to fix it. I did fix a few edge cases with special frame handling in the newer kgdb though those mostly had to do with fork_trampoline and possibly Xtimerint (and aside from fork_trampoline I think the fixes were mostly for i386 where different handlers setup trapframes differently) > > That gives you the top of the callstack at the time that the core was > > taken. To get the rest of it, try: > > > > define trace_stack > > set $frame_ptr=$arg0 > > set $iters=0 > > while $frame_ptr != 0 && $iters < $arg1 > > set $ret_addr=((char*)$frame_ptr) + sizeof(void*) > > printf "frameptr=%p, ret_addr=%p\n", (void*)$frame_ptr, *(void**)$ret_addr > > printf " " > > info line **(void***)$ret_addr > > set $frame_ptr=*(void**)$frame_ptr > > set $iters=$iters+1 > > end > > end > > > > trace_stack frame->tf_rbp 20 > > Thank you for this script. > Here is an example from my practice. > > (kgdb) bt > #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:291 > #1 0xffffffff8063453f in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:359 > #2 0xffffffff80634ba4 in vpanic (fmt=<value optimized out>, ap=<value optimized > out>) at /usr/src/sys/kern/kern_shutdown.c:635 > #3 0xffffffff806348a3 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:568 > #4 0xffffffff8041bba7 in db_panic (addr=<value optimized out>, have_addr=false, > count=0, modif=0x0) at /usr/src/sys/ddb/db_command.c:473 > #5 0xffffffff8041b67b in db_command (cmd_table=0x0) at > /usr/src/sys/ddb/db_command.c:440 > #6 0xffffffff8041b524 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 > #7 0xffffffff8041de0b in db_trap (type=<value optimized out>, code=0) at > /usr/src/sys/ddb/db_main.c:251 > #8 0xffffffff80669de8 in kdb_trap (type=19, code=0, tf=0xffffffff80f976d0) at > /usr/src/sys/kern/subr_kdb.c:653 > #9 0xffffffff80820d26 in trap (frame=0xffffffff80f976d0) at > /usr/src/sys/amd64/amd64/trap.c:381 > #10 0xffffffff80809623 in nmi_calltrap () at > /usr/src/sys/libkern/explicit_bzero.c:28 This may be part of the problem. The trapframe unwinder depends on function names to know when it is crossing a trapframe. nmi_calltrap() is not the function at explicit_bzero.c:28. Usually debugging this sort of thing starts by going to frame 11 and comparing its registers with the values in the trapframe. They should match, but sometimes you will find them shifted by one or two, etc. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1595419.L0rkNTMkPe>