Debugging goes into proc.go at every step

[mmcmm]

I'm using go modules, and every debug step into or step over goes into a proc.go file gopark function and then goes back. You can see it in this gif. https://gyazo.com/adb4a54cc467ce372a4b5595b72d150f

Steps to Reproduce:

Have some test and try to debug them.

launch.json

{ "name": "Test", "type": "go", "mode": "test", "request": "launch", "remotePath": "", "port": 2346, "host": "127.0.0.1", "program": "${workspaceRoot}/test", "env": { "GOPATH": "/Users/user/golang" }, "args": ["-test.short"], "showLog": false }

[ramya-rao-a]

Can you try running dlv from the command line, debug the same test and see if the step into/over in that case does something similar?

[stffabi]

We are seeing the same behaviour on different machines in our company. I'll try to test dlv from the command line later this day.

[virtuald]

I'm seeing the same issue, on go version go1.10.4 darwin/amd64

Delve Debugger
Version: 1.1.0
Build: $Id: 1990ba12450cab9425a2ae62e6ab988725023d5c $

[virtuald]

Is there a way to easily obtain the commandline that vscode is providing to dlv? That seems like it would be useful.

[ramya-rao-a]

Dustin Spicuzza (@virtuald) Of course. I just added a note on it at https://github.com/Microsoft/vscode-go/wiki/Debugging-Go-code-using-VS-Code#try-using-dlv-from-the-terminalcommand-line

[stffabi]

Ramya Rao (@ramya-rao-a) I've tried running dlv from the command line. An attach from vscode to the running dlv leads to the same behaviour. Stepping into/out goes into proc.go gopark. Furthermore I've now even seen some assembler files popup during the debugging.

[ramya-rao-a]

stffabi I didn't mean attaching vscode to a running dlv instance. I meant using the dlv client directly. Run dlv debug on the folder that has your file. That will open an interactive session where you can add break points, step into/over code using commands

[anphung]

Same here, and it's very slow for it to Step into/over, or showing Variables in the debug tab.
I try with using dlv debug, and use interactive session b, c, n, it's quite fast there.

$ go version
go version go1.11 darwin/amd64
$ dlv version
Delve Debugger
Version: 1.1.0
Build: $Id: 1990ba12450cab9425a2ae62e6ab988725023d5c
$ code --version
1.29.1
bc24f98b5f70467bc689abf41cc5550ca637088e
x64

[anphung]

Inspecting the vscode-go-debug.txt from the debug, global vars request is huge for me, I guess thats the reason. Is there anyway to disable global vars?

[ramya-rao-a]

namocode (@anphung) Is your problem also about every step in going into the proc.go file or is it just about slowness?

[anphung]

It's both. Actually, it jumps into proc.go for around several seconds (the time varies). If just wait for several seconds then it'll jump back to the next line that it supposed to jump in the first place.
I guess it jumps like that because of the slowness, and the slowness is because of loading all global vars.

[ramya-rao-a]

Inspecting the vscode-go-debug.txt from the debug, global vars request is huge for me, I guess thats the reason. Is there anyway to disable global vars?

Thats an interesting find. There is no official way to disable global vars, but can you try the below

• Open the file ~/.vscode/extensions/ms-vscode.go-0.7.0/out/src/debugAdapter/goDebug.js. If you are using Insiders then use .vscode-insiders. If you are not on the latest version of VS Code (0.7.0), then use the appropriate version
• Find the function getPackageInfo, and add return Promise.resolve(null); to the first line inside the function. This will return null for package and consequently the global vars call will not be made.
• Reload VS Code

Check if this solves the problem of slowness

[anphung]

That's faster. It still jumps into proc.go sometime, but jumps out immediately (not several seconds anymore).