Re: mach in signal handler
Re: mach in signal handler
- Subject: Re: mach in signal handler
- From: Steve Checkoway <email@hidden>
- Date: Thu, 25 Jan 2007 19:25:09 -0800
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.)
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.
--
Steve Checkoway
_______________________________________________
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