Skip site navigation (1)Skip section navigation (2)
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>