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.
On Feb 27, 2007, at 20.22.10, Terry Lambert wrote:
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
r2 0x0 0
r3 0x1 1
r4 0x60bff780 1623193472
r5 0x53691000 1399394304
r6 0x0 0
r7 0xfffffff8 4294967288
r8 0x600d3280 1611477632
r9 0x0 0
r10 0x100 256
r11 0xc 12
r12 0xfc088891 4228417681
r13 0x4d9c400 81380352
r14 0x310 784
r15 0x10 16
r16 0x50c7f40 84705088
r17 0x0 0
r18 0x100 256
r19 0x0 0
r20 0xab6a0 702112
r21 0x1030 4144
r22 0x0 0
r23 0x4483ffd0 1149501392
r24 0x1 1
r25 0x364000 3555328
r26 0x4483ffd0 1149501392
r27 0x42000000 1107296256
r28 0x366000 3563520
r29 0x364000 3555328
r30 0x0 0
r31 0x1030 4144
pc 0xab7f8 702456
ps 0x1030 4144
cr 0x22462094 575021204
lr 0xab6cc 702156
ctr 0x9f7e0 653280
xer 0x0 0
mq 0x0 0
fpscr 0x0 0
vscr 0x0 0
vrsave 0x0 0
Also, the panic information, particularly the DAR and PC at the time of the panic; this can be obtained by using the "paniclog" command from "kgmacros".
(gdb) paniclog
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)
Kernel version:
Darwin Kernel Version 8.8.0: Fri Sep 8 17:18:57 PDT 2006; root:xnu-792.12.6.obj~1/RELEASE_PPC
If you are writing assembly code functions,
No assembly. All C.
If you are using the "kgmacros" that ship with the "kernel debug kits" on <
http://developer.apple.com/sdk/>, and are set up for two machine debugging, as described there, then you can do a "showallstacks".
This will get you a list of all the stacks that there are, and for each thread not currently in a continuation, you'll see values for reserved_stack, kernel_stack, stacktop, and stackbottom, which will, with a little math, let you know what at least part of the callstack looks like for the problem process.
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
0x44733b40 0x34c24 <stack_alloc_try+192>
0x44733b90 0x32808 <thread_invoke+784>
0x44733c00 0x32d00 <thread_block_reason+252>
0x44733c60 0x274c94 <_sleep+704>
0x44733cd0 0x274f3c <msleep+176>
0x44733d30 0x5d61e888 <symphonic.kext.GlowWorm + 0x12888>
0x44733d90 0x5d64866c <symphonic.kext.GlowWorm + 0x3c66c>
0x44733e10 0x3c884 <_call_thread_continue+284>
0x44733e90 0xa9314 <Call_continuation+20>
stackbottom=0x44733e90
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