On Wed, 07 Mar 2012 10:10:32 -0500, Chad J
<chadjoan@__spam.is.bad__gmail.com> wrote:
On Wednesday, 7 March 2012 at 14:23:18 UTC, Chad J wrote:
On 03/07/2012 07:57 AM, Steven Schveighoffer wrote:
On Mon, 05 Mar 2012 23:58:48 -0500, Chad J
<chadjoan@__spam.is.bad__gmail.com> wrote:
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.
Alright, I think I see where the misunderstanding is coming from.
I have only ever encountered (1). And I've encountered it a lot.
I didn't even consider (2) and (3) as possibilities. Those are far
from my mind.
I still have a nagging doubt though: since the dereference in question
is null, then there is no way for that particular dereference to
corrupt other memory. The only way this happens in (2) and (3) is that
related code tries to write to invalid memory. But if we have other
measures in place to prevent that (bounds checking, other hardware
signals, etc), then how is it still possible to corrupt memory?
[...]
-Steve
I spoke too soon!
We missed one:
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.
4. null was being used as a sentinal value, and it snuck into
a place where the value should not be a sentinal anymore.
I will now change what I said to reflect this:
I think I see where the misunderstanding is coming from.
I encounter (1) from time to time. It isn't a huge problem because
usually if I declare something the next thing on my mind is initializing
it. Even if I forget, I'll catch it in early testing. It tends to
never make it to anyone else's desk, unless it's a regression.
Regressions like this aren't terribly common though. If you make my
program crash from (1), I'll live.
I didn't even consider (2) and (3) as possibilities. Those are far from
my mind. I think I'm used to VM languages at this point (C#, Java,
Actionscript 3, Haxe, Synergy/DE|DBL, etc). In the VM, (2) and (3)
can't happen. I never worry about those. Feel free to crash these in D.
I encounter (4) a lot. I really don't want my programs crashed when (4)
happens. Such crashes would be super annoying, and they can happen at
very bad times.
You can use sentinels other than null.
-Steve
