layer=dap recovered panic: runtime error: invalid memory address or nil pointer dereference

[zhiburt]

Hi there,

I am not sure if it's a duplicate or if it's an unrelated issue at all. So sorry for that. Just felt like it may be worth to report.

2022-07-08T10:53:06+03:00 error layer=dap recovered panic: runtime error: invalid memory address or nil pointer dereference
goroutine 10 [running]:
runtime/debug.Stack(0xc001354948, 0x9ce440, 0xe024f0)
	/usr/lib/golang/src/runtime/debug/stack.go:24 +0x9f
github.com/go-delve/delve/service/dap.(*Server).recoverPanic(0xc0001b81c0, 0xb18e20, 0xc0006a0640)
	/home/mzhiburt/go/pkg/mod/github.com/go-delve/[email protected]/service/dap/server.go:364 +0x76
panic(0x9ce440, 0xe024f0)
	/usr/lib/golang/src/runtime/panic.go:965 +0x1b9
github.com/go-delve/delve/pkg/proc.(*Defer).load(0xc000a4e640)
	/home/mzhiburt/go/pkg/mod/github.com/go-delve/[email protected]/pkg/proc/stack.go:623 +0x2ca
github.com/go-delve/delve/pkg/proc.(*G).Defer(0xc0013940d0, 0x0)
	/home/mzhiburt/go/pkg/mod/github.com/go-delve/[email protected]/pkg/proc/variables.go:482 +0xb9
github.com/go-delve/delve/pkg/proc.(*G).readDefers(0xc0013940d0, 0xc0003a4280, 0x2, 0x2)
	/home/mzhiburt/go/pkg/mod/github.com/go-delve/[email protected]/pkg/proc/stack.go:571 +0x2f
github.com/go-delve/delve/pkg/proc.(*G).Stacktrace(0xc0013940d0, 0x1, 0x1, 0x0, 0x0, 0xc000b2ef90, 0x0, 0x0)
	/home/mzhiburt/go/pkg/mod/github.com/go-delve/[email protected]/pkg/proc/stack.go:166 +0xe9
github.com/go-delve/delve/pkg/proc.topframe(0xc0013940d0, 0xb2b068, 0xc0001460e0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/home/mzhiburt/go/pkg/mod/github.com/go-delve/[email protected]/pkg/proc/threads.go:75 +0xa5
github.com/go-delve/delve/pkg/proc.next(0xc000a8d050, 0xc000150000, 0x0, 0x0)
	/home/mzhiburt/go/pkg/mod/github.com/go-delve/[email protected]/pkg/proc/target_exec.go:465 +0xe9
github.com/go-delve/delve/pkg/proc.(*Target).Next(0xc000a8d050, 0x0, 0x0)
	/home/mzhiburt/go/pkg/mod/github.com/go-delve/[email protected]/pkg/proc/target_exec.go:37 +0x94
github.com/go-delve/delve/service/debugger.(*Debugger).Command(0xc000163340, 0xc001355d28, 0xc00068f260, 0x0, 0x0, 0x0)
	/home/mzhiburt/go/pkg/mod/github.com/go-delve/[email protected]/service/debugger/debugger.go:1057 +0xf65
github.com/go-delve/delve/service/dap.(*Server).doRunCommand(0xc0001b81c0, 0xa6d08f, 0x4, 0xc00068f260)
	/home/mzhiburt/go/pkg/mod/github.com/go-delve/[email protected]/service/dap/server.go:2181 +0xe5
github.com/go-delve/delve/service/dap.(*Server).doStepCommand(0xc0001b81c0, 0xa6d08f, 0x4, 0x1, 0xc00068f260)
	/home/mzhiburt/go/pkg/mod/github.com/go-delve/[email protected]/service/dap/server.go:1270 +0x513
github.com/go-delve/delve/service/dap.(*Server).onNextRequest(0xc0001b81c0, 0xc0006a0640, 0xc00068f260)
	/home/mzhiburt/go/pkg/mod/github.com/go-delve/[email protected]/service/dap/server.go:1211 +0x171
github.com/go-delve/delve/service/dap.(*Server).handleRequest.func3(0xc0001b81c0, 0xc0006a0640, 0xc00068f260)
	/home/mzhiburt/go/pkg/mod/github.com/go-delve/[email protected]/service/dap/server.go:493 +0x7c
created by github.com/go-delve/delve/service/dap.(*Server).handleRequest
	/home/mzhiburt/go/pkg/mod/github.com/go-delve/[email protected]/service/dap/server.go:491 +0xee5

1. What version of Delve are you using (dlv version)?

Delve Debugger
Version: 1.6.1
Build: $Id: 114218c22f3791287c4bc2f4ff35a846a1416ee9 $

3. What version of Go are you using? (go version)? go version go1.18.3 linux/amd64
4. What operating system and processor architecture are you using? linux/amd64
5. What did you do?

Nothing special just, run a debug in VS Code. It feels like to happen on next step call. While breakpoints are working.

PS: yes... didn't get into gdb debug style yet (

[aarzilli]

delve 1.6.1 is not compatible with go 1.18.

[aarzilli]

Are you passing --check-go-version=false manually?

[zhiburt]

No I don't pass anything

Look what I've found.

https://github.com/golang/vscode-go/commit/ab3d3a6e3c56ebf01f77434916ea29bdfe86e7bd https://github.com/golang/vscode-go/blob/fdf5608ef092d18a51c6278409a2a0beaf896974/src/goDebugFactory.ts#L652

[zhiburt]

Shall I open an issue there to not use by default? What do you think @aarzilli?

[aarzilli]

@hyangah @polinasok IMO vscode-go shouldn't pass that option by default. I see that the motivation was that installing an old version of dlv was complicated, because of the dlv-dap rename, but IIRC that isn't an issue anymore. And the user can always pass check-go-version manually in launch.json.

[polinasok]

The check was turned off and turned it into a warning after some flagging from Cloud Code.
@briandealwis Could you remind us please what the issue was? Can you handle it by setting the flag on your end instead?

Sadly the warning goes unnoticed, especially after all the other things that get printed after :( The start-up warnings could also be captured and reprinted on recovered panics, but that won't help with any non-crashing but bogus behavior.

[aarzilli]

I remember the Cloud Code discussion but this was added by https://github.com/golang/vscode-go/commit/ab3d3a6e3c56ebf01f77434916ea29bdfe86e7bd fixing https://github.com/golang/vscode-go/issues/1716. Does cloud code have to use the same typescript adapter as the vscode-go that end users install?

[polinasok]

Cloud Code extension builds on top of vscode-go extension, so that is a factor, but not the only factor. You are right, and here it does look like the change was made in response to a user issue. Sadly I do not see an explanation in the PR/issue that explains all the context and why the decision was made. Maybe there was a plan to have more explicit prompts to sync up the outdated tools more aggressively?

I think going back to an error has merit, but I would vote for more informative error messages since there was quite a bit of confusion in the past. For example, instead of

Version of Delve is too old for Go version %%s (maximum supported version %d.%d, suppress this error with --check-go-version=false)

something like

Version of Delve is too old for Go version %%s - maximum supported version %d.%d.
Update your Delve version to %d.%d-%d.%d. or downgrade your Go version to %d.%d-%d.%d to ensure compatibility.
If you must use incompatible versions, suppress this error with --check-go-version=false, but expect undefined behavior.

Too much?

[aarzilli]

I would prefer something more concise, to be honest. It seems to me that the possibility of upgrading delve would be implicit if we say that the current version is too old.

[briandealwis]

For Cloud Code we were concerned about using Delve with older versions of Go. This sounds like a problem of using too new a version of Go. Failing seems to be the right thing to do in this case.

[polinasok]

That's a very good point. There is at least a chance that newer Delve is still compatible with old Go. There isn't much of a chance that old Delve is compatible with new Go. Checks in both directions are currently behind the same flag in Delve, so no easy way to turn off one without the other.