Replace "Failed to continue - bad access" with more informative error message and stack trace.

[jpap]

When a debug session panics, Delve will show a code listing with a cursor at the panic with a "Command failed: XXX" message. You can then issue commands to get a backtrace, etc.

In VSC, a cryptic message "Failed to continue - XXX" is shown in the Debug Console and nothing else. It would be great if instead:

• Move the editor to the relevant source line that panicked.
• Show the call stack in the debugger pane. If that's too hard, at the very least please show the panic details in the Debug Console, including stack trace.
• Instead of "Failed to continue", use a more descriptive "Debugger stopped after program failure: XXX". (The first time I encountered this I thought it was a debugger issue, rather than my code.)

[ramya-rao-a]

Can you provide a small sample code that I can use to replicate the panic scenario?

[jpap]

Please see playground, example copied below.

package main

func oops() {
	var a *int
	*a++
}

func main() {
	oops()
}

[db47h]

John Papandriopoulos (@jpap) This is the default behavior for dlv to stop at the beginning of fatalpanic when a Go program panics. While I agree that this might be confusing, panics can occur anywhere, even in the standard library (IIRC, some string to int conversion functions do), so it's not easy to guess which stack frame the user will really be interested in. In any case that specific issue should be taken to https://github.com/derekparker/delve/.

Also, in order to have vscode automatically switch to debug view on panic, you can set

"debug.openDebug": "openOnDebugBreak",

or

"debug.openDebug": "openOnSessionStart"

in your user settings.

[jpap]

Denis Bernard (@db47h) I am not concerned with the debug view opening automatically. I am more concerned with:

1. A cryptic error message is shown on the Debug Console, that isn't clearly obvious that the issue is a fault in the program being run. For example, in Debugger throws: "Failed to continue - bad access" #1853 the author probably thought it was their debugger setup, before realizing it was a defect in their code. (It has happened to me before too.)
2. When a runtime error occurs, other than an explicit call to runtime.panic, the debugger also shows a cryptic error message ("Failed to continue - XXX") on the Debug Console, and the Debug View is blank.

This is what I get in Delve with the above code sample:

$ dlv debug oops.go
Type 'help' for list of commands.
(dlv) c
     1:	package main
     2:	
     3:	func oops() {
     4:		var a *int
=>   5:		*a++
     6:	}
     7:	
     8:	func main() {
     9:		oops()
    10:	}
Command failed: bad access
(dlv) 

As you can see, Delve stops at the site of the runtime error. You can then use bt to get the stack frames,

(dlv) bt
0  0x0000000001053828 in main.oops
   at ./oops.go:5
1  0x0000000001053860 in main.main
   at ./oops.go:9
2  0x0000000001026e95 in runtime.main
   at /usr/local/Cellar/go/1.11/libexec/src/runtime/proc.go:201
3  0x000000000104dec1 in runtime.goexit
   at /usr/local/Cellar/go/1.11/libexec/src/runtime/asm_amd64.s:1333

In VSC, the debugger shows the message "Failed to continue - bad access" on the Debug Console, with the Debug View blank, and it's not clear what happened at all. To get any sense out of the situation, you have to run the code manually (under delve or not) in a terminal to see the runtime error and stack trace.

If the code sample above were to change so as to call panic in func oops() instead of the nil-pointer access, then yes, Delve and VSC breaks in runtime.fatalpanic. But this is not what this bug report is about. ;-)

[db47h]

I did test with the code sample you've provided on Linux, Go 1.11, vscode 1.26.1 and latest dlv (at the time of writing). What's strange is that I don't get any "Failed to continue ..." message in the vscode debug console and if I debug it directly from dlv on the command line, dlv halts at fatalpanic as expected.

From the backtrace I see that you're running Go 1.11, but what operating system are you on?

[jpap]

I'm running delve HEAD (or very close to it), on macOS.

[db47h]

This could be related to derekparker/delve#852. Still, since delve catches the nil pointer dereference (that's what the "bad access" means), the debug view in vscode should not be blank.

[ramya-rao-a]

I tried the above code on Windows using the latest delve.
It breaks on fatalpanic and shows the below in the debug console:

Will try on macOS soon

[vscodebot]

This issue has been closed automatically because it needs more information and has not had recent activity. Thank you for your contributions.

[vale910]

Hi! We just hit a comparable flaw in our code including triggered panic in Go on a Mac leading to the output "Failed to continue - bad access" on VS Code version 1.28.1.