site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com User-agent: Thunderbird 1.5.0.9 (X11/20061206) -- Steve Checkoway _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... 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. This email sent to site_archiver@lists.apple.com