Re: Debugging a Kernel Panic
Re: Debugging a Kernel Panic
- Subject: Re: Debugging a Kernel Panic
- From: Terry Lambert <email@hidden>
- Date: Wed, 28 Feb 2007 11:07:41 -0800
On Feb 27, 2007, at 10:15 PM, Jones Curtis wrote:
Thankfully (??) the customer experienced another panic, and ran the
gdb commands that I sent him. So, here is where I show my ignorance.
While I have the information that you indicated, I don't know enough
to interpret it. Any insight you might have as to what any of this
might indicate, would be appreciated.
[ ... ]
The exception value is in R3, and the saved context is in R4. So
the output of "info regs" could be helpful.
(gdb) info registers
r0 0x8000000a 2147483658
r1 0x4483feb0 1149501104 <- Stack top at
time of panic
r2 0x0 0
r3 0x1 1 <- Exception 1
r4 0x60bff780 1623193472 <- & Last saved context
(may not be useful)
r5 0x53691000 1399394304
[ ... ]
pc 0xab7f8 702456 <- PC when exception thrown
ps 0x1030 4144
cr 0x22462094 575021204
lr 0xab6cc 702156
[ ... ]
Cannot access memory at address 0x4483feb0
System Failure: cpu=0; code=00000001 (Corrupt stack)
Latest crash info for cpu 0:
Exception state (sv=0x60BFF780)
PC=0x000AB7F8; MSR=0x00001030; DAR=0x4483FFD0;
DSISR=0x42000000; LR=0x000AB6CC; R1=0x4483FEB0; XCP=0x00000098
(System Failure)
Backtrace:
backtrace terminated - frame not mapped or invalid:
0x4483FEB0
Proceeding back via exception chain:
Exception state (sv=0x60BFF780)
PC=0x000AB724; MSR=0x00001030; DAR=0x4483FFD0;
DSISR=0x42000000; LR=0x000AB6CC; R1=0x4483FFD0; XCP=0x0000000C
(0x300 - Data access)
Backtrace:
backtrace terminated - frame not mapped or invalid:
0x4483FFD0
Exception state (sv=0x600D3280)
PC=0x00068A38; MSR=0x00009030; DAR=0x4483FFC0;
DSISR=0x42000000; LR=0x00069BBC; R1=0x448400F0; XCP=0x0000000C
(0x300 - Data access)
Backtrace:
0x00069BBC 0x000650F4 0x0002BBA4 0x0002C350 0x5D6112E0 0x5D610120
0x5D647AF0 0x5D647AA0 0x5D647AA0 0x5D647AA0 0x5D647AA0
0x5D647AA0 0x5D647AA0 0x5D647AA0
0x5D647AA0 0x5D647AA0 0x5D647AA0 0x5D647AA0 0x5D647AA0
0x5D647AA0 0x5D647AA0 0x5D647AA0
0x5D647AA0 0x5D647AA0 0x5D647AA0 0x5D647AA0 0x5D647AA0
0x5D647AA0 0x5D647AA0 0x5D647AA0
0x5D647AA0 0x5D647AA0
backtrace continues...
Kernel loadable modules in backtrace (with dependencies):
symphonic.kext.GlowWorm(1.5.3b2)@0x5d60c000
Exception state (sv=0x5CC45A00)
PC=0x00000000; MSR=0x0000D030; DAR=0x00000000;
DSISR=0x00000000; LR=0x00000000; R1=0x00000000; XCP=0x00000000
(Unknown)
Whatever function is @ 0x5D647AA0 in the KEXT GlowWorm, which was
loaded at 0x5D647AA0 called itself over and over until you ran out of
stack.
This is the only one that is obviously related to my kext:
activation thread pri state wait_queue wait_event
0x050f7f40 0x050f7f40 94 UW 0x003df5a0 0x44733d68
reserved_stack=0x445a8000
kernel_stack=0x44730000
stacktop=0x44733b40
Normal stack: stacktop > kernel_stack
the last one in the list, which I assume is the last one because it
intentionally stops after it, is more concerning:
activation thread pri state wait_queue wait_event
0x04d9c400 0x04d9c400 81 R
reserved_stack=0x44630000
kernel_stack=0x44840000
stacktop=0x4483ffd0
0x4483ffd0 Cannot access memory at address 0x4483ffd8
Overflowed stack: stacktop < kernel_stack.
So:
(1) "kextload -s /tmp -N GlowWorm.kext'" (whatever the path is to
where it lives) to generate symbols; it will as you for a hex address
where the KEXT is loaded; tell it "0x5D647AA0"
(2) load up a debuggable kernel matching the kernel version in gdb:
"gdb mach_kernel.sys"
(3) load kgmacros: "source kgmacros"
(4) load up your KEXT symbols: "add-symbolfile /tmp/
symphonic.kext.GlowWorm
(5) See the bug: "list *0x5D647AA0"
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden