dereferencing null

Adam D. Ruppe destructionator at gmail.com
Sun Mar 4 18:43:15 PST 2012


On Monday, 5 March 2012 at 02:32:12 UTC, Chad J wrote:
> I hate hate HATE vague error messages that don't help me.

In a lot of cases, getting more info is very, very easy:

$ dmd -g -debug test9
$ ./test9
Segmentation fault
$ gdb ./test9
GNU gdb (GDB) 7.1
[...]
(gdb) r
Starting program: /home/me/test9
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x08067a57 in _Dmain () at test9.d:12
12                      bar.foo = 5;
(gdb) where
#0  0x08067a57 in _Dmain () at test9.d:12
#1  0x0806eaf8 in _D2rt6dmain24mainUiPPaZi7runMainMFZv ()
#2  0x0806e605 in _D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv ()
#3  0x0806eb3f in _D2rt6dmain24mainUiPPaZi6runAllMFZv ()
#4  0x0806e605 in _D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv ()
#5  0x0806e5b4 in main ()
(gdb) print bar
$1 = (struct test9.Bar *) 0x0



My gdb is out of the box unmodified; you don't need anything
special to get basic info like this.




There's two cases where null annoys me though:

1) if it is stored somewhere where it isn't supposed to be.
Then, the location of the dereference doesn't help - the
question is how it got there in the first place.

2) Segfaults in the middle of a web app, where running it under
the same conditions again in the debugger is a massive pain in
the butt.


I've trained myself to use assert (or functions with assert
in out contracts/invariants) a lot to counter these.


More information about the Digitalmars-d mailing list