Date: Thu, 21 Jan 2016 09:18:54 -0800 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: <1668788.bFLpJ6aV8e@ralph.baldwin.cx> In-Reply-To: <56A0CA17.7030204@FreeBSD.org> References: <554E41EE.2010202@ignoranthack.me> <16207260.7oBjvc4tcM@ralph.baldwin.cx> <56A0CA17.7030204@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, January 21, 2016 02:07:51 PM Andriy Gapon wrote: > On 08/01/2016 22:05, John Baldwin wrote: > > So I figured out why newer kgdb wasn't unwinding through NULL function pointer > > traps yesterday. I'm not sure if the fix will help with your case as well, > > but it might be worth trying. The changes are in > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206044 > > Thank you very much! > It does help in my case: > > (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=<optimized out>, ap=<optimized out>) at > /usr/src/sys/kern/kern_shutdown.c:635 > #3 0xffffffff806348a3 in panic (fmt=<unavailable>) at > /usr/src/sys/kern/kern_shutdown.c:568 > #4 0xffffffff8041bba7 in db_panic (addr=<optimized out>, > have_addr=<unavailable>, count=<unavailable>, modif=<unavailable>) at > /usr/src/sys/ddb/db_command.c:473 > #5 0xffffffff8041b67b in db_command (last_cmdp=<optimized out>, cmd_table=0x0, > dopager=<optimized out>) 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=<optimized out>, code=<unavailable>) at > /usr/src/sys/ddb/db_main.c:251 > #8 0xffffffff80669de8 in kdb_trap (type=19, code=0, tf=0xffffffff80f976d0 > <nmi0_stack+3888>) at /usr/src/sys/kern/subr_kdb.c:653 > #9 0xffffffff80820d26 in trap (frame=0xffffffff80f976d0 <nmi0_stack+3888>) at > /usr/src/sys/amd64/amd64/trap.c:381 > #10 <signal handler called> > #11 0xffffffff80619e1f in __mtx_assert (c=<optimized out>, what=<optimized out>, > file=<optimized out>, line=<optimized out>) at /usr/src/sys/kern/kern_mutex.c:842 > #12 0xffffffff807fef86 in vm_reserv_free_page (m=0xfffff80229e07cc0) at > /usr/src/sys/vm/vm_reserv.c:832 > #13 0xffffffff807f2b96 in vm_page_free_toq (m=0xfffff80229e07cc0) at > /usr/src/sys/vm/vm_page.c:2432 > #14 0xffffffff807f2e4d in vm_page_free (m=0xffffffff81129198 > <vm_page_queue_free_mtx+24>) at /usr/src/sys/vm/vm_page.c:962 > #15 0xffffffff821c28e2 in ttm_bo_vm_fault (vm_obj=0xfffff8021fcdeb00, > offset=5304320, prot=<optimized out>, mres=0xfffffe02b8357050) at > /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/ttm/ttm_bo_vm.c:269 > #16 0xffffffff807d4fd3 in dev_pager_getpages (object=0xfffff8021fcdeb00, > ma=0xfffffe02b8357050, count=1, reqpage=0) at /usr/src/sys/vm/device_pager.c:321 > #17 0xffffffff807f9d67 in vm_pager_get_pages (object=0xfffff8021fcdeb00, > m=0xfffffe02b8357050, count=1, reqpage=0) at /usr/src/sys/vm/vm_pager.c:291 > #18 0xffffffff807e0d84 in vm_fault_hold (map=0xfffff8001dd57000, > vaddr=34729947136, fault_type=2 '\002', fault_flags=0, m_hold=0x0) at > /usr/src/sys/vm/vm_fault.c:672 > #19 0xffffffff807e05ee in vm_fault (map=0xfffff8001dd57000, vaddr=<optimized > out>, fault_type=2 '\002', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:277 > #20 0xffffffff80821342 in trap_pfault (frame=0xfffffe02b8357c00, usermode=1) at > /usr/src/sys/amd64/amd64/trap.c:734 > #21 0xffffffff80820bda in trap (frame=0xfffffe02b8357c00) at > /usr/src/sys/amd64/amd64/trap.c:326 > #22 0xffffffff8082154a in trap_check (frame=0xfffffe02b8357c00) at > /usr/src/sys/amd64/amd64/trap.c:628 > #23 <signal handler called> > #24 0x00000008022b4046 in ?? () > Backtrace stopped: Cannot access memory at address 0x7fffffffe7c8 > > See http://article.gmane.org/gmane.os.freebsd.devel.hackers/56410 for comparison. > One small regression is that previously there was nmi_calltrap in the trace, now > it's just "<signal handler called>". Yeah, listing trapframes as that is fallout from the fix. I've thought about adding a custom frame type so I can install a custom frame printer and output things like the trap number the way ddb does, but that would be a far more invasive change that might be harder to maintain going forward. Glad that this helped though! -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1668788.bFLpJ6aV8e>