Re: Darwin-kernel Digest, Vol 1, Issue 38
Re: Darwin-kernel Digest, Vol 1, Issue 38
- Subject: Re: Darwin-kernel Digest, Vol 1, Issue 38
- From: David Gatwood <email@hidden>
- Date: Mon, 1 Nov 2004 13:01:24 -0800
On Nov 1, 2004, at 12:04 PM, email@hidden wrote:
Anyway... I've read the kernel programming docs and kbase articles
on panic analysis, but I've had a hard time getting started because
the only intro-level doc I've seen assumes the a two-machine
setup. Unfortunately, my wife has only allowed me one Mac (so
far)...
That makes things harder. Do you have any other machines that aren't
Macs? Because I -think- gdb can be compiled for cross-architecture
debugging without too much pain, as long as you use the Darwin
sources.
I'd like to try to my hand at doing some panic analysis if I can get
past the single-machine limitation. In the past, I've worked on
Solaris boxes and was able to use adb from a terminal on a system
core dump in the /var/crash directory. Can I configure OS X to
savecore in a filesystem directory and use gdb on it? Maybe this
is described somewhere and I just missed it?
Not to my knowledge, though another poster mentioned a mechanism for
saving it across the network. I've never tried that, but then again, you
said you don't have a second machine, which makes that not so useful....
Aside from the Apple developer and kbase docs, does anyone
have any reference material they recommend on the panic analysis?
I think I have a copy of Chris Drake's "Panic!" lying around somewhere.
Any other references, online or otherwise, would be helpful.
Get a copy of the kernel debug kit for your OS release. It contains a
symboled copy of the kernel (non-bootable) that you can look at in gdb. Once
you have that, you just do
x/i 0xfeedbeef
or whatever the address is and it will tell you the function in which the panic
occurred, and an offset into that function. If you have a copy of the source code,
you should be able to compile a copy yourself, point gdb at your copy, and
get the addresses of line numbers. With that, by subtracting the address of
the function, you can figure out approximately which line of code was running
at the time.
For the curious and benificent, there's a sourceforge thread that
describes the issue at the URL below. I'm wondering if there's anything
in the panic.log outputs that jumps out. From what I've gleaned, it
looks
like Azureus or the JVM is accessing a memory address in kernel
land that is out of bounds...
http://sourceforge.net/forum/forum.php?thread_id=1146956&forum_id=291997
The address accessed was 0x14. It's a null pointer dereference (or, more
accurately, a dereference to some field in a pointer to a struct where the struct
pointer itself was NULL, thus the field was at some very small value).
Backtrace explained here:
<x-tad-bigger>
0x00000006 junk
0x0020B1F4 <kevent+476>: lwz r1,0(r1)
0x002452B40 <unix_syscall+580>: lwz r0,164(r30)
0x00094200 <.L_call_server_syscall_exception>
0xFF8BB9DF junk
</x-tad-bigger>
The link register (which tells where the current stack frame should return) contains:
<x-tad-bigger> 0x0020B83C <kqueue_scan+784>: cmpwi cr7,r3,0</x-tad-bigger>
The program counter contains;
<x-tad-bigger>0x0020B7B8 <kqueue_scan+652>: lwz r9,20(r31)</x-tad-bigger>
So if these (or similar) results are reproducible on more than one machine, that
suggests a bug somewhere in the kqueues part of the xnu kernel itself. Please
file a bug. :-)
David
_______________________________________________
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