Debugging kernel cores without a stack

Adrian Chadd adrian at freebsd.org
Sun Mar 24 17:44:55 UTC 2013


You need to use 'bt' to see the stack trace, then 'frame X' to go into
that frame.

Post 'bt' output and I'll show you what you're looking for.




Adrian


On 24 March 2013 10:23, Joshua Isom <jrisom at gmail.com> wrote:
> I have several core dumps that need debugged.  All are the same problem.
> The debugging problem is when I fire up kgdb, I have to backtrace even
> though the kernel message buffer contains a back trace.  If I try to set the
> frame with "frame 0xffffff8020bddb30" I get an error "Cannot access memory
> at address 0x0".  All I have to debug with are these two pieces of
> information.  How do I get more information?
>
>> jri.homeunix.com dumped core - see /var/crash/vmcore.29
>>
>> Sun Mar 24 10:49:52 CDT 2013
>>
>> FreeBSD jri.homeunix.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248680M:
>> Sun Mar 24 07:13:16 CDT 2013     r
>>
>> panic: kdb_switch: did not reenter debugger
>>
>> 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 "amd64-marcel-freebsd"...
>>
>> Unread portion of the kernel message buffer:
>> witness_warn() at witness_warn+0x4a8/frame 0xffffff8020bdd690
>> trap_pfault() at trap_pfault+0x5a/frame 0xffffff8020bdd740
>> trap() at trap+0x659/frame 0xffffff8020bdd950
>> calltrap() at calltrap+0x8/frame 0xffffff8020bdd950
>> --- trap 0xc, rip = 0xffffffff8133519e, rsp = 0xffffff8020bdda10, rbp =
>> 0xffffff8020bddb30 ---
>> ath_edma_tx_processq() at ath_edma_tx_processq+0x18e/frame
>> 0xffffff8020bddb30
>> taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame
>> 0xffffff8020bddb80
>> taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame
>> 0xffffff8020bddbb0
>> fork_exit() at fork_exit+0x84/frame 0xffffff8020bddbf0
>> fork_trampoline() at fork_trampoline+0xe/frame 0xffffff8020bddbf0
>> --- trap 0, rip = 0, rsp = 0xffffff8020bddcb0, rbp = 0 ---
>>
>>
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 0; apic id = 00
>> fault virtual address   = 0x0
>> fault code              = supervisor read data, page not present
>> instruction pointer     = 0x20:0xffffffff8133519e
>> stack pointer           = 0x28:0xffffff8020bdda10
>> frame pointer           = 0x28:0xffffff8020bddb30
>> code segment            = base 0x0, limit 0xfffff, type 0x1b
>>                         = DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags        = interrupt enabled, resume, IOPL = 0
>> current process         = 0 (ath0 taskq)
>> Uptime: 2m19s
>> Dumping 261 out of 1771
>> MB:..7%..13%..25%..31%..43%..56%..62%..74%..86%..92%
>
>
>> (kgdb) list *(0xffffffff8133519e)
>> 0xffffffff8133519e is in ath_edma_tx_processq
>> (/root/ATH/head/sys/modules/ath/../../dev/ath/if_ath_tx_edma.c:552).
>> 547                                 bf->bf_descid);
>> 548                     }
>> 549     #endif
>> 550
>> 551                     /* This removes the buffer and decrements the
>> queue depth */
>> 552                     ATH_TXQ_REMOVE(txq, bf, bf_list);
>> 553                     if (bf->bf_state.bfs_aggr)
>> 554                             txq->axq_aggr_depth--;
>> 555                     txq->axq_fifo_depth --;
>> 556                     /* XXX assert FIFO depth >= 0 */
>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"


More information about the freebsd-hackers mailing list