Re: mach in signal handler
Re: mach in signal handler
- Subject: Re: mach in signal handler
- From: Dave Zarzycki <email@hidden>
- Date: Fri, 26 Jan 2007 06:29:33 -0800
On Jan 25, 2007, at 7:25 PM, Steve Checkoway wrote:
Dave Zarzycki wrote:
I don't remember if Mach based APIs are interruptible by signals,
but if they are, then the answer is definitely no. Why? The reply
port can get out of synchronization do to the unexpected reentrancy
on the same thread stack.
If it matters, I would only be calling it from within the signal
handler which I don't allow to be reentrant. (If another signal
happens while I'm in the handler, I give up and just die.)
Well, one of our library calls might be in the middle of a Mach based
API. :-(
Personally speaking, I try and handle as many signals as I can via
the kqueue API. The only signals that can't be handled in a kqueue
are instruction stream or memory access related faults (SIGBUS,
SIGSEGV, SIGILL, and SIGFPE). If the aforementioned signals are
what you are trying to handle, I'd suggest setting up a dedicated
thread to handle signals (man sigsuspend). All other threads should
have their signal mask setup to block delivery.
What I'm actually doing is attempting to get a back trace on x86
under crash conditions. It's fairly easy on ppc. For x86, I'd like
to walk along the stack looking for what might be return addresses,
presumably they'd be in executable, readable, but not writable
memory and would be proceeded by one of the call instructions. If
the code hasn't been compiled with -fomit-frame-pointer, then I'd
also like to be able to find valid stack frames by checking that the
stored %esp actually points up the stack.
I was hoping that vm_region would let me both check what the valid
range of memory for a thread's stack and also check if values on the
stack point to potential call sites (well, right after the call
site) including the protection.
I have zero preferences on which api to use to get the job done, so
if you can suggest a more suitable one, I'd be more than happy to
use it.
Why write code at all then? What's wrong with Apple's CrashReporter
facility? :-)
davez
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden