Re: mach in signal handler
Re: mach in signal handler
- Subject: Re: mach in signal handler
- From: Steve Checkoway <email@hidden>
- Date: Fri, 02 Feb 2007 19:40:39 -0800
Quinn wrote:
At 22:45 -0800 1/2/07, Steve Checkoway wrote:
In general, I agree. What we do in this specific case, is build a
crash log including a backtrace (being very careful not to call
forbidden functions), fork a new process, send the data to it and have
it do things like symbol lookups and throw up a dialog informing the
user of the crash, etc.
If you're going to fork a new process, why not have the new process do
the backtrace (vm_region, and so on, work just fine across processes).
This has a bunch of benefits:
o It minimises the amount of stuff that you have to do within the signal
handler, which is always a good thing.
o It makes it easier for you to write your backtrace code (you'll be
able to call malloc, for example).
o If the original process is dying, doing complex operations from within
that process is a bad idea because you can't trust its state.
I agree completely that as little as possible should be done in the
dying parent. I have two (not necessarily good) reasons for how it's
currently handled.
The better of the two is that it fits in nicely with the linux code,
minimizing the amount of architecture dependent code. There are
essentially two nontrivial pieces of arch dependent code. The first is
getting the backtrace which is done in the context of the handler and
the second is the symbol lookup done in the new process. (As I recall,
this was much harder on OS X 10.2.8 and uses code from Jorge Acereda and
Peter O'Gorman. For the intel side, it has to be 10.4 or above so we
just use dladdr.) Once those two pieces of code have been written, the
rest of the code is platform independent, more or less. The goal is for
the windows code to be merged into this "at some point." It's been a low
priority for about two years now.
The second reason is that I'm unsure how I would access the memory in
the parent process short of ptracing it. Walking the stack and grabbing
return addresses is easy (on powerpc, at least) when you have direct
access to the memory. I am unsure how one would go about doing this from
the child process. My guess is with mach, but the documentation on the
mach functions is rather...sparse. I found
<http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/index.html>
but that is geared toward programming in the kernel.
--
Steve Checkoway
_______________________________________________
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