Print/Whatis command creats runtime error on the first run of delve

[CylusFaranIdo]

trafficstars

1. What version of Delve are you using (dlv version)? Version 1.0.0
2. What version of Go are you using? (go version)? go1.8.3
3. What operating system and processor architecture are you using? linux/amd64
4. What did you do?

• Executed delve for the first time on the machine.
• Debugged a process using delve exec <path> command.
• Printed a variable using 'print' or 'whatis' command - for example print 5

5. What did you expect to see? I expected to see the value 5 printed.
6. What did you see instead? I received the following runtime error:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x73dcf9]

goroutine 1 [running]:
github.com/derekparker/delve/pkg/terminal.printVar(0xc420633b00, 0x0, 0xffffffffffffffff, 0x0, 0x0, 0xc4202f40b2, 0x1, 0x2, 0x0)
        /go/src/github.com/derekparker/delve/pkg/terminal/command.go:1014 +0x1e9
github.com/derekparker/delve/pkg/terminal.(*Commands).CallWithContext(0xc420300c30, 0xc4202f40b0, 0x3, 0xc420633b00, 0x0, 0xffffffffffffffff, 0x0, 0x0, 0x3, 0xc4202f40b0)
        /go/src/github.com/derekparker/delve/pkg/terminal/command.go:348 +0x134
github.com/derekparker/delve/pkg/terminal.(*Commands).Call(0xc420300c30, 0xc4202f40b0, 0x3, 0xc420633b00, 0x0, 0x0)
        /go/src/github.com/derekparker/delve/pkg/terminal/command.go:353 +0x71
github.com/derekparker/delve/pkg/terminal.(*Term).Run(0xc420633b00, 0x0, 0x0, 0x0)
        /go/src/github.com/derekparker/delve/pkg/terminal/terminal.go:132 +0x38f
github.com/derekparker/delve/cmd/dlv/cmds.execute(0x0, 0xc420138590, 0x1, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0)
        /go/src/github.com/derekparker/delve/cmd/dlv/cmds/commands.go:537 +0x94f
github.com/derekparker/delve/cmd/dlv/cmds.New.func4(0xc420154900, 0xc420138590, 0x1, 0x1)
        /go/src/github.com/derekparker/delve/cmd/dlv/cmds/commands.go:169 +0x6f
github.com/derekparker/delve/vendor/github.com/spf13/cobra.(*Command).execute(0xc420154900, 0xc420138540, 0x1, 0x1, 0xc420154900, 0xc420138540)
        /go/src/github.com/derekparker/delve/vendor/github.com/spf13/cobra/command.go:647 +0x234
github.com/derekparker/delve/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc420154000, 0xc420154900, 0xc4201546c0, 0xc420154480)
        /go/src/github.com/derekparker/delve/vendor/github.com/spf13/cobra/command.go:733 +0x339
github.com/derekparker/delve/vendor/github.com/spf13/cobra.(*Command).Execute(0xc420154000, 0xc420154000, 0xa13c7e)
        /go/src/github.com/derekparker/delve/vendor/github.com/spf13/cobra/command.go:692 +0x2b
main.main()
        /go/src/github.com/derekparker/delve/cmd/dlv/main.go:18 +0x91

I managed to find the source of the bug:

• In the file delve/pkg/config/config.go in line 63 - After failing to open configuration file, it creates a new one using the function createDefaultConfig.
• However afterward, the code returns nil instead of trying to open it again.
• That is why this problem exists only during the first execution of delve. I noticed that because I also used delve on a Docker container, so almost every run of delve is the first run on the machine.

[CylusFaranIdo]

This does prevent the runtime error that caused by missing configuration file (=first execution of delve). However - other problems may exist in loading the configuration - for example, missing read permissions. The real cause of the runtime error is the assumption that terminal.config is not nil in the terminal commands code (for example delve/pkg/terminal/command.go line 1040). This may result in such unclear runtime errors. In order to prevent such errors, one solution can be stopping the execution of delve in case of failure in loading the configuration (in addition to printing the configuration error to the user). The relevant code is located in delve/cmd/dlv/cmds/commands.go line 70 - check if the return value of LoadConfig equals to nil. @derekparker

[derekparker]

I'll reopen this, we can definitely be more defensive here.

[aarzilli]

This was fixed a long time ago in 6cf7a7149d35fe8c349a03caa57627860bf48ddd