debug: slow/unpredictable variable display behavior when remote debugging

[stamblerre]

Both microsoft/vscode-go#2865 and microsoft/vscode-go#3051 mention an issue of slow behavior when debugging remote targets.

@cpoole writes:

I feel like this issue is related to: go-delve/delve#1741
feels like vscode is possibly timing out waiting for delve responses and delve is very slow.

@tsarni provides a repro case in microsoft/vscode-go#3051 (comment).

The issues experienced by these users may be different, but the repro case would be a good starting point.

@hhrutter, @vishal-wadhwa, and @cpoole: If you could also provide repro cases, that would really help in our investigation and help clarify if these are instances of the same issue or not.

/cc @quoctruong

[polinasok]

It's impossible to diagnose this without repro cases (e.g. with local attach or connecting to "remote" server running on the same machine) or at least full logs for both vscode and delve with:

"showLog": true, // equivalent to --log if dlv is launched externally 
"logOutput": "rpc,debug", // equivalent to --log-output=rpc,debug if dlv is launched externally
"trace": "verbose"

Vscode writes the log to a file that you can attach to issues (see top of the Debug Console output). There is an option in delve to print logs to a file as well (--log-to-file).

Some comments based on some of the thoughts expressed in the discussion.

I feel like this issue is related to: go-delve/delve#1741
feels like vscode is possibly timing out waiting for delve responses and delve is very slow.

A known source of vscode+delve slowness is having to load too many goroutines (#129). This slows things down before stack, scopes and variables requests are issued.

I see all of the variables in the json VariablesResponse

If you see VariablesResponse in the logs, that means the extension did everything it was supposed to do. This is logged after the response is sent to the editor.

Sometimes local and global vars are displayed, sometimes neither local nor global vars
are displayed

Be careful to make sure you have the right goroutine highlighted. As you stop at different breakpoints, the view switches to the last selected goroutine, which could "wipe out" the variables that you were viewing at the last breakpoint relative to a different goroutine. And globals are displayed per package, so the view might also change depending on the goroutine and its location.

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)