Re: single machine debugging?/advice for noob on OS X panic
Re: single machine debugging?/advice for noob on OS X panic
- Subject: Re: single machine debugging?/advice for noob on OS X panic
- From: David Gatwood <email@hidden>
- Date: Tue, 2 Nov 2004 12:57:22 -0800
Sometime in the recent past, Eric R Johnson wrote:
Subject: Re: single machine debugging?/advice for noob on OS X panic
analysis
To: email@hidden
Message-ID: <email@hidden>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Andrew, Rohan, Garth, Markus,
Thank you for sharing your insights, pointers, etc. I'll need some
time to
struggle up the learning curve w/OS X, but it promises to be an
interesting
challenge. Given my available free time, it'll probably be a while
before
I get back to the list with any findings or follow-up questions.
You probably missed my reply because I forgot to change the subject
line.
Whoops. Here's the relevant bit:
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:
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
The link register (which tells where the current stack frame should
return) contains:
0x0020B83C <kqueue_scan+784>: cmpwi cr7,r3,0
The program counter contains;
0x0020B7B8 <kqueue_scan+652>: lwz r9,20(r31)
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. :-)
Okay. Now that I've reiterated that....
Markus, to your point regarding the user-land Java app crashing the
kernel...
I couldn't agree more. There's been some bluster on the SF thread
about
writing a virus when they figure out the issue, but I think that's idle
talk born of
frustration. The potential is pretty ugly, though.
The potential should be pretty much zero. It's a null pointer
dereference,
not a buffer overflow problem. A buffer overflow would, more often
than not,
cause a jump to an invalid location, resulting in a 0x400 (instruction
access).
The only way I can think of that this could turn into anything more
than a
crash would be if the null pointer dereference was a fluke side-effect
of a
buffer overflow. While there's the most distant possibility that a
buffer
overflow caused the null dereference, given that the stack backtrace
doesn't
look like Swiss cheese, I'd say the odds are pretty slim....
To put it more in perspective, the odds of this being helpful to a
virus (unless
the goal of the virus were to cause a kernel panic) are probably
roughly on
the same order as the odds of Ralph Nader winning today's election by a
landslide. :-)
Just my $0.02. As always, my opinions rarely (if ever) reflect the
views of my
employer. :-)
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