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;
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):
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:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden
