Re: Why no crash reporter if I install some signal handler on Leopard
Re: Why no crash reporter if I install some signal handler on Leopard
- Subject: Re: Why no crash reporter if I install some signal handler on Leopard
- From: Terry Lambert <email@hidden>
- Date: Tue, 27 Nov 2007 14:42:09 -0800
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.
The OP understands that.
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 <email@hidden>
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.
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;
}
=======
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):
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
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.
-- Terry
_______________________________________________
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