dereferencing null

[Steven Schveighoffer]

On Mon, 05 Mar 2012 23:58:48 -0500, Chad J  
<chadjoan at __spam.is.bad__gmail.com> wrote:

> 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?

A segmentation fault indicates that a program tried to access memory that  
is not available.  Since the 0 page is never allocated, any null pointer  
dereferencing results in a seg fault.

However, there are several causes of seg faults:

1. You forgot to initialize a variable.
2. Your memory has been corrupted, and some corrupted pointer now points  
into no-mem land.
3. You are accessing memory that has been deallocated.

Only 1 is benign.  2 and 3 are fatal.  Since you cannot know which of  
these three happened, the only valid choice is to terminate.

I think the correct option is to print a stack trace, and abort the  
program.

> 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.

You cannot be sure if your program is in a sane state.

> 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?

Again, this is a simple case.  There is also this case:

Foo f = new Foo();
... // some code that corrupts f so that it is now null
f.bar = 4;

This is not a "continue execution" case, and cannot be distinguished from  
the simple case by compiler or library code.

Philosophically, any null pointer access is a program error, not a user  
error, and should not be considered for "normal" execution.  Terminating  
execution is the only right choice.

-Steve