null dereference

[Adam D. Ruppe]

There is a hidden module on Linux which can activate this, sort 
of:

void main() {
    // these two lines turn it on
    import etc.linux.memoryerror;
    registerMemoryErrorHandler();

    Object o = null;
    o.toString(); // trigger it here
}

etc.linux.memoryerror.NullPointerError at src/etc/linux/memoryerror.d(325):
----------------
./test56(void etc.linux.memoryerror.sigsegvDataHandler()+0xb) 
[0x805d44b]
./test56(_Dmain+0xa) [0x805c8ea]
./test56(void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).runAll().void __lambda1()+0x10) [0x805cb58]
./test56(void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate())+0x18) 
[0x805cad0]
./test56(void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).runAll()+0x27) [0x805cb1f]
./test56(void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate())+0x18) 
[0x805cad0]
./test56(_d_run_main+0x117) [0x805ca67]
./test56(main+0x14) [0x805c90c]
/lib/libc.so.6(__libc_start_main+0xe6) [0xf75f3b86]
./test56() [0x805c831]




As you can see there, the top line doesn't really help much, it 
just lists the  druntime module, but the stack trace can help: it 
shows _Dmain in there, and if you add other functions, you can 
see them too.

So still not quite a file+line number for the exact place (you 
can get that in a debugger fairly easily though) but helps find 
where it is, especially if you have fairly small functions.