null dereference

[luka8088]

On 16.3.2014. 0:22, Jonathan M Davis wrote:
> On Saturday, March 15, 2014 11:05:42 luka8088 wrote:
>> I was thinking and I am not sure about the reason for not having some
>> king of safeguard for null dereferencing in version(assert)/debug builds.
>>
>> One possible reason that comes to mind is that it somewhat affects
>> performance but should this really be an issue in version(assert)/debug
>> build? Especially given the benefit of having file/line number and stack
>> information outputted.
> 
> Essentially what it comes down to is the fact that because the OS already 
> detects null pointer dereferences for you (hence the segfault or access 
> violation that you get when it occurs), Walter considers it unnecessary. If 
> you want more details, look at the resulting core dump in a debugger or run 
> the program in a debugger to begin with. Now, that obviously doesn't always 
> work, which is part of why many folks argue in favor of adding additional 
> checks, but that's Walter's position.
> 
> I believe that there was some work done to make it so that druntime would 
> detect a segfault and print a stacktrace when that happens, but it's not 
> enabled normally, and I don't know quite what state it's in. That would 
> probably be the ideal solution though, since it gives you the stacktrace 
> without requiring additional checks.
> 
> - Jonathan M Davis
> 


That is great. At least in theory, but at the end of the day the
following code still performs invalid memory operation and ends up being
killed by the os without any change of recovery.

void main () @safe {
  Object o = null;
  o.toHash();
}


I saw multiple failed attempts to implement handlers for such operation
and throwing exceptions instead. I don't remember why, and I can't find
the post, but there where claims that it will never be turned on by default.

etc.linux.memoryerror.registerMemoryErrorHandler(); that Adam pointed
out is great but somewhat looses it's point if it not turned on by default.


Consider a simple scenario. I am writing a vibed application, and I
deploy it to a linux server. Now for testing purposes I make a
non-release build and add:

try { ... } catch (Throwable t) { logCrash(t); }

Unfortunately null deference happened and I have no info why. For
argument purposes let's say that this happens rarely and I am not able
to reproduce it on my machine. Now I go to the docs looking for a way to
get more info out of this. And there is nothing about it in the docs.