Re: mach in signal handler
Re: mach in signal handler
- Subject: Re: mach in signal handler
- From: Terry Lambert <email@hidden>
- Date: Fri, 2 Feb 2007 21:52:32 -0800
On Feb 2, 2007, at 7:40 PM, Steve Checkoway wrote:
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.
This is a non-trivial reason, and it argues well for your position;
though moving the code after vs. before the fork might not be that
involved.
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.
You get the mach port of the current process and pass rights to it
that are inherited over fork to the child process. Then you use the
port to access the parent's address space via Mach APIs.
The GNU Hurd documentation is rrelatively up to date, and is mostly
applicable to Mach interaces. You could also check out Amit Singh's
"Mac OS X Internals" book, which covers a lot of the Mach API and what
you can do with it, in pretty cory detail (the book is over 1600
pages, and is supplemented with additional material at his web site).
-- Terry
_______________________________________________
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