Re: mach in signal handler
Re: mach in signal handler
- Subject: Re: mach in signal handler
- From: Quinn <email@hidden>
- Date: Fri, 2 Feb 2007 11:31:12 +0000
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.
At 0:01 -0800 2/2/07, Terry Lambert wrote:
To get there from here, I can only tell you to look at the gdb
sources, and see what gdb does for signal management for processes
being debugged when it's compiled for Darwin/MacOS X.
That's not easy, for a bunch of reasons:
o GDB catches the standard crash exceptions (SIGSEGV, for example) as
Mach exceptions, before the BSD part of the kernel turns these
exceptions into signals.
o For software signals, GDB tells the kernel to deliver the signal as
an exception (it attaches using PT_ATTACHEXC).
o GDB's code is a complex tangled mess.
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
_______________________________________________
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