site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com The OP understands that. The following will work, but it's not ideal: ======= #include <signal.h> #include <stdio.h> void sig_abort(int sig) { printf("Application has been abort\n"); abort(); } int main(int argc, char* argv[]) { struct sigaction sa; sa.sa_handler = sig_abort; sigemptyset(&sa.sa_mask); sa.sa_flags = SA_RESETHAND; if (sigaction(SIGABRT, &sa, NULL) == -1) { perror("sigaction"); exit(0); } while (1) {} return 0; } ======= Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Crashed Thread: 0 Thread 0 Crashed: 0 libSystem.B.dylib 0x916fd1f8 __kill + 12 1 libSystem.B.dylib 0x9179e820 abort + 84 2 foo 0x00001e8c sig_abort + 44 3 libSystem.B.dylib 0x916fb100 _sigtramp + 64 -- Terry _______________________________________________ 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... On Nov 27, 2007, at 9:28 AM, Steve Sisak wrote: At 1:19 PM -0800 11/26/07, Terry Lambert wrote: A consequence of this is that caught signals that would otherwise be fatal no longer trigger crash reports. He asks what to do if he wants to do something in response to the signal (and therefore needs to install an handler), but still wants a crash report generated: On Nov 26, 2007, at 1:23 AM, zhanglin <zhanglin.zhou@gmail.com> wrote: If I want to install the signal handler and make the crash reporter dialog to be shown too, what should I do? Pass the exception in signal hander? How? Is there a best practice for generating a crash report for a signal that one partially handles? Off the top of my head, I'm not sure. CrashReporter tends to be launched by launchd when something causes abnormal_exit_notify() to be called in the kernel, thus raising the exception EXC_CRASH. THis is handled in osfmk/kern/exception.c. This is normally called in proc_prepareexit() from either exit1() (via the exit() system call) or from proc_exit(), but doesn't happen if the system is in the process of being shutdown, or the signal is not indicated to normally result in a core file. proc_exit() in turn is called when your process is exiting, and the last thread exits uninterruptible state and would otherwise run up and return to user space, but instead ends up calling thread_terminate_self() because it's been killed/terminated/aborted/whatever. It's not ideal because you can't really rethrow the abort with the same stack, you will always show as being in the trap handler (the stack for a crash report looks something like this (on a PPC): Thread 0 crashed with PPC Thread State 32: srr0: 0x916fd1f8 srr1: 0x0000d030 dar: 0xa0265520 dsisr: 0x0a000000 r0: 0x00000025 r1: 0x00026900 r2: 0x00000008 r3: 0x00000000 r4: 0x00000000 r5: 0x00000001 r6: 0x0000000a r7: 0x0000001b r8: 0x00000889 r9: 0x00000889 r10: 0x916c5d7c r11: 0xa0267448 r12: 0x916fd1e4 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000 r20: 0x00000000 r21: 0x00000000 r22: 0x00000000 r23: 0x00000000 r24: 0x00000000 r25: 0x00000000 r26: 0xbffff8e4 r27: 0x00026a88 r28: 0x00026a68 r29: 0x00000014 r30: 0x00026960 r31: 0x9179e7d8 cr: 0x22000002 xer: 0x00000000 lr: 0x9179e824 ctr: 0x916fd1e4 vrsave: 0x00000000 It might be cleaner to dump the mcontext information himself, which will be hard, since we intentionally make these values opaque to avoid people other than debugger writers, CrashReporter, etc. messing with them and tying us to an ABI that we might need to change to add features or resolve issues at some point. The people who write those types of tools understand that they may be broken by system updates. On the other hand, if he is handling the stack traceback on his own, he should be OK. This email sent to site_archiver@lists.apple.com