Fwd: More Mac like handling of OS raised exceptions
Fwd: More Mac like handling of OS raised exceptions
- Subject: Fwd: More Mac like handling of OS raised exceptions
- From: Lon Giese <email@hidden>
- Date: Mon, 15 May 2006 23:16:14 -0700
Begin forwarded message:
From: Lon Giese <email@hidden>
Date: May 15, 2006 11:05:40 PM PDT
To: Bill Bumgarner <email@hidden>
Subject: Re: More Mac like handling of OS raised exceptions
I just thought of something... I'm doing things the cocoa way: read
the file into NSData, get the pointer and parse the file... read too
much.. crash! NSData is supposed to simplify things.
What if I did it the old fashioned C way and just get a file pointer
from C. I don't remember: if you try to read too much with a file
pointer does the kernel crash? I think you just get an EOF error.
Thanks for all the responses thats really nice...
From what I am hearing I am summing up that the kernel (unix) sees I
tried to read/write from/to a protected space, so being the kernel and
not real smart he thinks "well if Lon tried to read from protected
space then his app is really messed up and he's probably going to do
something really bad next and I don't trust him anymore so he's outta
here..."
I know that all that happened was I tried to read more of the file
than was really there, and I appreciate being advised of that. No
damage was really done, other than my bruised ego. But still Being I'm
a human and he's only a kernel I should at least be given the chance
to surmize the situation for myself and let me decide if things are so
bad or so indeterminate we need to terminate. It is impossible to read
or write to protected space so no damage could have been done to the
system or any other apps. Only my app is possibly damaged, but hey
what app is perfect? Its not like a atomic weapon is going to be
accidentally launched. If you're launching weapons you're not going to
use OS X.
I finally got a hold of one of the files that was making the parser
crash and analyzed it. It seems that one of the pascal strings in the
file had a bad length and threw all the offsets off by one byte. These
files are created by hackers so you never know what you might find in
them...
Lots of good suggestions, I hadn't thought of spawning a child process
to parse the files...
The stack trace is good... I need to implement that.
trapping the signals should be standard for any first class app
For the short term solution I need to run an integrity test on each
file before it is parsed... This is handy because I can also inform
the user that the file is corrupt and what is wrong with it.
It all just seems to me like if the user types the wrong thing in a
text field you say he's insane and crash the app cause he cant even
type. It's just not mac like.
On May 15, 2006, at 7:35 PM, Bill Bumgarner wrote:
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...
"Bad access exception" definitely means that something bad has
already happened -- the stack is corrupted, the heap is corrupted,
the program wrote to beyond the end of a buffer (more heap
corruption), or the like.
This is not a runtime exception per se. It is lower level; it can
happen in a pure assembly language app and, as John Stiles said, the
damage has already been done and there is no real way to recover.
Even if you could validate all the data managed by your app (a very
very hard task), there is no way to validate data structures
maintained by the Foundation, AppKit or other frameworks-- their
structure is opaque.
Now, none of this is to say that solving the problems you define
above is impossible. It isn't, you just have to approach it from a
"prevent the bad access exception" frame of mind. Or, if you can't
prevent it, then log enough information somewhere such that the
situation can be avoided in future sessions.
For example, if your application is crashing because it is reading a
corrupt file, then whatever parser you are using to read the file is
not robust enough for your application's needs. This may be due to
a bug in the parser or it may be because the parser was not designed
to operate in a fail safe mode (which often requires significantly
more CPU and memory than operating in a "hope the data is OK" mode).
If you can't fix the parser (or, as is the case here, you are in
development mode and are shaking out bugs), then you can make the app
store the name of the last file parsed somewhere persistent --
~/Library/Application Support/ or /tmp/ or the user defaults
database. Once everything is successfully parsed, store the
success. Upon initiating a new parse session, check the stored
value and see if the app died without success. More likely than
not, the problematic file will be the last one.
There is the off chance that a corrupted file might cause corruption
in the heap/stack without actually crashing your app. It may be that
the last file in the parse log is actually not corrupt and that a
previous file is actually the cause of the problem.
If at all possible, make your parser robust. If not possible, move
the parser out to an external task that you can monitor from your
app. That way, if the parser crashes, you can easily offer recovery
options from the sane working conditions within your uncrashed and
isolated application's runtime.
b.bum
_______________________________________________
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