Re: More Mac like handling of OS raised exceptions
Re: More Mac like handling of OS raised exceptions
- Subject: Re: More Mac like handling of OS raised exceptions
- From: Ryan Britton <email@hidden>
- Date: Mon, 15 May 2006 19:27:53 -0700
You cannot recover from a SIGSEGV or SIGBUS (the two memory error
termination signals). They occur when your application tries to
overstep its memory limitations and the OS terminates it. You are
not given a chance to correct it and can only clean up somewhat after
yourself before dying.
In situations where your app is going down, the best you can really
hope to get is the crash log, which will give you a stack trace and
register dump at the moment the termination signal was received. For
this, you have to either use something like Smart Crash Reports or
roll your own crash handler. For the latter, it's not overly
difficult and you can take a look at some example code in the Adium
sources. Most notably:
signal(SIGILL, CrashHandler); /* 4: illegal instruction (not
reset when caught) */
signal(SIGTRAP, CrashHandler); /* 5: trace trap (not reset when
caught) */
signal(SIGEMT, CrashHandler); /* 7: EMT instruction */
signal(SIGFPE, CrashHandler); /* 8: floating point exception */
signal(SIGBUS, CrashHandler); /* 10: bus error */
signal(SIGSEGV, CrashHandler); /* 11: segmentation violation */
signal(SIGSYS, CrashHandler); /* 12: bad argument to system call */
signal(SIGXCPU, CrashHandler); /* 24: exceeded CPU time limit */
signal(SIGXFSZ, CrashHandler); /* 25: exceeded file size limit */
When your app receives one of these signals, the passed function will
be called. You can use this chance to grab what state information
you can and pass it off to a crash reporter that is capable of
sending you back the information you want.
Ryan
On May 15, 2006, at 7:16 PM, Lon Giese wrote:
For what I am doing nothing is getting corrupted. The bad access
exception prevented that. I don't think signal handlers will help
me either, thats low level stuff, when I need high level
information about why the app tried to write to protected space. I
have users all over the world and to simply call and tell me the
app crashed is not good enough... When the app opens a certain file
it crashes, but when the app is opening thousands of files
automatically I need to know which file made it crash, and let the
app continue on, skipping over the unlucky file. I suppose I could
log to disk every file that it attempts to open but thats wacky,
were talking thousands of files. I know it's my fault the app is
crashing, but were talking an alpha release and still working out
the bugs. Even so, there are literally hundreds of different types
of files my app opens and new types being created daily by hackers.
There should/must be a way to handle this type of exception in a
more Mac like way...
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden