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