On 03/05/2012 11:27 PM, Jonathan M Davis wrote:
On Tuesday, March 06, 2012 05:11:30 Martin Nowak wrote:
There are two independent discussions being conflated here. One about
getting more
information out of crashes even in release mode and the other about
adding runtime checks to prevent crashing merely in debug builds.
A segfault should _always_ terminate a program - as should dereferencing a
null pointer. Those are fatal errors. If we had extra checks, they would have
to result in NullPointerErrors, not NullPointerExceptions. It's horribly
broken to try and recover from dereferencing a null pointer. So, the question
then becomes whether adding the checks and getting an Error thrown is worth
doing as opposed to simply detecting it and printing out a stack trace. And
throwing an Error is arguably _worse_, because it means that you can't get a
useful core dump.
Really, I think that checking for null when dereferencing is out of the
question. What we need is to detect it and print out a stacktrace. That will
maximize the debug information without costing performance.
- Jonathan M Davis
Why is it fatal?
I'd like to be able to catch these. I tend to run into a lot of fairly
benign sources of these, and they should be try-caught so that the user
doesn't get the boot unnecessarily. Unnecessary crashing can lose user
data. Maybe a warning message is sufficient: "hey that last thing you
did didn't turn out so well; please don't do that again." followed by
some automatic emailing of admins. And the email would contain a nice
stack trace with line numbers and stack values and... I can dream huh.
I might be convinced that things like segfaults in the /general case/
are fatal. It could be writing to memory outside the bounds of an array
which is both not bounds-checked and may or may not live on the stack.
Yuck, huh. But this is not the same as a null-dereference:
Foo f = null;
f.bar = 4; // This is exception worthy, yes,
// but how does it affect unrelated parts of the program?
