ohh, yeah, I omitted the definition of the class because I thought it'd be obvious, here it is:
$ cat main.d
import std.stdio;
class Greetings {
void hello() {
writeln("hello");
}
}
void main()
{
Greetings g = null;
g.hello();
}
$ dmd -g main.d && ./main
Segmentation fault: 11
$ uname -a
Darwin Johan-Ride-Mac.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64
$ dmd --version
DMD64 D Compiler v2.069.0
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
I'm intentionally making it null to see how the new backtraces work.
I know it's because I'm trying to call a method on "null", but If I'm working on a huge code base, how do I debug this kind of issues if I don't have stack trace with line and error number of the error?
I'd like to get at least the stack trace and the error number with the line of the source code that caused the problem, like in golang:
$ cat main.go
package main
type Greetings struct {
}
func (g Greetings) hello() {
}
func main() {
g := &Greetings{} // heap instance
g = nil // intentionally shooting myself in the foot like I did in D
g.hello()
}
$ go run main.go
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x2025]
goroutine 1 [running]:
main.main()
/Users/ride/Documents/main.go:13 +0x15
goroutine 2 [runnable]:
runtime.forcegchelper()
/opt/boxen/homebrew/Cellar/go/1.4.2/libexec/src/runtime/proc.go:90
runtime.goexit()
/opt/boxen/homebrew/Cellar/go/1.4.2/libexec/src/runtime/asm_amd64.s:2232 +0x1
exit status 2
null deference in D doesn't throw exceptions by default on Unix so you won't see the backtrace there.
If you are working in a big codebase and have this come up, you can enable core dumps and run it in a debugger to get far more information than just a line number (and line numbers are there too at least if compiled in debug mode).
Sample code: