site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Feb 7, 2005, at 9:31 PM, Rick Steele wrote: Matt Watson wrote: write(1, sig_message, sizeof(sig_message)); exit(1); } Thanks everyone!!!! #define kMySigError -9999 void fatalSigHandler(int sig, siginfo_t* info, void* context) { short pErr = kMySigError; throw(pErr); _Exit(1); //Not that this will ever be reached } main(){ Ptr ptrFoo = nil; char barrrr; installSignalHandler(SIGSEGV, &fatalSigHandler); installSignalHandler(SIGBUS, &fatalSigHandler); try{ barrrr = (*ptrFoo); }catch(short err){ printf("Error %x", err); } ....continue return(noErr); } Rick _______________________________________________ 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/paulf%40aphrodite.com _______________________________________________ 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... Actually, I think you can, but I'm not sure how good an idea it really is. Derive what you throw from std::bad_exception. At your top level catch: catch (const std::bad_exception &e) { const char *what = e.what (); write (2, what, strlen (what)); // or, better yet, abort () provided you aren't catching SIGABRT for this purpose _exit (1); } It's always bothered me that C++ exceptions aren't integrated into system signals, but that's a very old issue. There's a "d" programming language in development that actually addresses this. void fatalSigHandler(int sig, siginfo_t* info, void* context) { // We are very limited in what we are allowed to do in a signal handler. // Memory should not be allocated, and most libc functions should not be used. static char sig_message[] = "Aborting: Fatal signal occurred!\n"; Never call exit() from a signal handler. You want _Exit() instead. exit() will call atexit() handlers which will are likely not signal-safe. And you probably want to use fd 2 (stderr), instead of fd 1 in the write() call. Good suggestions. That's especially important when using dlopen or NSLinkModule on libraries. They could cause further signals or even signal deadlocks when they get unloaded. That said: if you're not going to add any more info in your signal handler, or do any cleanup like unlink() files, it may just be best to let it crash and generate a crash log. I assumed that he'd replace the handler with something else. One of the handlers I have for a project calls execv() to restart the daemon in case of a crash. That is after writing errors to a log and closing open file handles/resetting signal masks (as they are both inherited by the new process), and doing some other general cleanup of the daemon's lock/state files. -Kevin- I hope no one minds if I take this one step further. Is there actually a way to have it return to the offending code with an exception triggered? For example, would the following snippet work... This email sent to paulf@aphrodite.com This email sent to site_archiver@lists.apple.com