Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
zhiburt opened this issue Jul 8, 2022 · 12 comments
Closed

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

zhiburt opened this issue Jul 8, 2022 · 12 comments

Comments

@zhiburt
Copy link

zhiburt commented Jul 8, 2022

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 $
  1. What version of Go are you using? (go version)?
    go version go1.18.3 linux/amd64
  2. What operating system and processor architecture are you using?
    linux/amd64
  3. 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
Copy link
Member

aarzilli commented Jul 8, 2022

delve 1.6.1 is not compatible with go 1.18.

@aarzilli
Copy link
Member

aarzilli commented Jul 8, 2022

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

@zhiburt
Copy link
Author

zhiburt commented Jul 8, 2022

No I don't pass anything

Look what I've found.

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

@zhiburt
Copy link
Author

zhiburt commented Jul 8, 2022 •
edited
Loading

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

@aarzilli
Copy link
Member

aarzilli commented Jul 8, 2022

@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
Copy link
Collaborator

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
Copy link
Member

I remember the Cloud Code discussion but this was added by golang/vscode-go@ab3d3a6 fixing golang/vscode-go#1716. Does cloud code have to use the same typescript adapter as the vscode-go that end users install?

@polinasok
Copy link
Collaborator

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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Collaborator

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.

@aarzilli aarzilli mentioned this issue Dec 5, 2022
Closed
gopherbot pushed a commit to golang/vscode-go that referenced this issue Dec 5, 2022
@aarzilli @hyangah
src/goDebugFactory: re-enable version check
34c0efb 
Passing --check-go-version=false without informing the user leads to
suppressing important warnings and confusion.

Fixes go-delve/delve#3058

Change-Id: Ib5aea336f3ea8a0c6d859e5d82562da12dc54a9c
Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/455175
TryBot-Result: kokoro <[email protected]>
Run-TryBot: Hyang-Ah Hana Kim <[email protected]>
Reviewed-by: Hyang-Ah Hana Kim <[email protected]>
Reviewed-by: Michael Pratt <[email protected]>
@aarzilli
Copy link
Member

Closing since we've reenabled the version check in vscode-go.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@briandealwis @aarzilli @zhiburt @polinasok