Re: panic.log on Intel?
Re: panic.log on Intel?
- Subject: Re: panic.log on Intel?
- From: Derek Kumar <email@hidden>
- Date: Fri, 13 Oct 2006 14:21:38 -0400
In this case, it's because none of the saved return addresses (as
determined by a framepointer chain walk to generate the stack trace)
are from a kernel module:
(gdb) x/i 0x35fb08 (the EIP)
0x35fb08 <soreceive+1051>: mov 280(ëx),êx
A load from MEM[EBX+280] in soreceive triggered a page fault that
couldn't be resolved. This looks like the so->so_usecount dereference
1636 if (so->so_usecount < 1)
1637 panic("soreceive: after 2nd sblock so=
%x ref=%d on socket\n", so, so->so_usecount);
(gdb) p/d &((struct socket *)0)->so_usecount
$3 = 280 (offsetof)
(assuming so is maintained in EBX which I haven't verified, also EBX
matches the first parameter dump as expected)
As to why the backtrace doesn't show any more, it's because the
framepointer linkage was terminated prematurely (zeroed)...could be
stack corruption. If you can connect to the machine or examine a
crashdump, you can try trawling the stack for traces. I'd also
suggest verifying that you were, in fact, on the appropriate thread
stack at the time of the panic.
Derek
On Oct 13, 2006, at 1:11 PM, Andrew Gallatin wrote:
I've been getting panic.log files from customers running on Intel
Macs, and they do not seem to have nearly as much information as ppc
panic.log files. Specifically, they are missing the helpful
"Kernel loadable modules in backtrace (with dependencies):"
Here is an example that I got today:
Fri Oct 13 17:58:33 2006
panic(cpu 0 caller 0x001A3135): Unresolved kernel trap (CPU 0, Type
14=page fault), registers:
CR0: 0x8001003b, CR2: 0x30071518, CR3: 0x00ff7000, CR4: 0x000006e0
EAX: 0x00000000, EBX: 0x30071400, ECX: 0x068a01cc, EDX: 0x00000000
CR2: 0x30071518, EBP: 0x4797b998, ESI: 0x00000000, EDI: 0x00000000
EFL: 0x00010246, EIP: 0x0035fb08, CS: 0x00000008, DS: 0x06980010
Backtrace, Format - Frame : Return Address (4 potential args on stack)
0x4797b6e8 : 0x128d1f (0x3c9540 0x4797b70c 0x131df4 0x0)
0x4797b728 : 0x1a3135 (0x3cf1f4 0x0 0xe 0x3cea24)
0x4797b838 : 0x19a8d4 (0x4797b850 0x4797b8b8 0x4797b888 0x344fcc)
0x4797b998 : 0x0 (0x30071400 0x10000000 0x6a13280 0x0) Backtrace
terminated-invalid frame pointer 0x0
Kernel version:
Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006;
root:xnu-792.13.8.obj~1/RELEASE_I386
***********
Whithout a clue as to where our module was loaded, it makes it
challenging to figure out what happened. Is this to be expected for
Intel, or is there something else going on?
Drew
_______________________________________________
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
_______________________________________________
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