Manjaro, Delve, and VScode debug is not working

[mulinbc]

Environment:
OS: Manjaro 17.10
Go: go version go1.10.3 linux/amd64
dlv: lastest

Steps to Reproduce:
1.press go on vscode debugger
Error: stuck there, can not go on.

Verbose logs are written to:
/tmp/vscode-go-debug.txt
15:33:01, 2018-6-23
InitializeRequest
InitializeResponse
Using GOPATH: /home/mulin/go
Running: /home/mulin/go/bin/dlv debug --headless=true --listen=127.0.0.1:2345 --log=true --
time="2018-06-23T15:33:01+08:00" level=info msg="launching process with args: [/home/mulin/Code/Golang/HelloWorld/debug]" layer=debugger

launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch",
            "type": "go",
            "request": "launch",
            "mode": "debug",
            "remotePath": "",
            "port": 2345,
            "host": "127.0.0.1",
            "program": "${fileDirname}",
            "env": {},
            "args": [],
            "showLog": true,
            "trace": "verbose",
            "stopOnEntry": false
        }
    ]
}

[PeterUlb]

Same issue here with Windows 10. Command line works fine

[truewt]

Have exactly same environment as OP mentioned and same problem. When I have debugging tab opened, there is indefinite (blue) loader under the configurations and debug button bar. On debug cancel there is error alert to check debug output, but nothing along existing output from OP is there.

[Sharpiro]

Windows 10 x64
Go 1.10.3
VS Code 1.24.1
vscode-go 0.6.83
Delve 1.0.0

After updating to the latest of all of the above, I also experienced "hanging" while trying to debug. I tested that this occurs on 2 of my computers after using all the latest installs.

I found that the following 2 changes were necessary to resolve my issue, at least as a workaround. For anyone looking to use this workaround, you can modify the .js versions of these files in your %userprofile%/.vscode/extensions/ms-vscode.go-0.6.83/out/src folder, though the line numbers will differ.

Also, once debugging, the "Restart" option still throws an error.

4a4cddf...Sharpiro:0.6.83

[ghost]

I'm having the same issue using macOS and Go 1.10.3.

@Sharpiro temporary fix worked on my end!

[truewt]

Confirming @Sharpiro fix also works for me (seems like all those versions have also fixed some bugs I've experienced before).

[philjonesuk]

Having the same issue here. @Sharpiro workaround works for me too.

Using:
go version go1.10.3 darwin/amd64
macOS High Sierra 10.13.5
vscode Version 1.24.1 (1.24.1)
ms-vscode.go-0.6.83

[alexaung]

Which .js version is working?

[Jacky2]

me too!!!
F5 can't run

OS is win10
VSCode version: 1.24.1
ms-vscode version: 0.6.83
go version：1.10.3
dlv version: 1.0.0

and Can debug files be deleted automatically after running?

[AmberCode]

The same thing on Ubuntu:
Ubuntu 18.04 
VSCode 1.24.1
go1.10.3 linux/amd64
go ext 0.6.83
dlv 1.0.0

Applied Sharpiro workaround in goDebug.ts and I am able to debug go again !

[fzechert]

I can confirm this bug on Arch Linux.
4.17.2-1-ARCH
VsCode 1.24.1 24f62626b222e9a8313213fb64b10d741a326288 x64
go version go1.10.3 linux/amd64
Delve Debugger
Version: 1.0.0
Build: 440b4405626d0b27b960a7d070da9b5211b7ccef

Sharpiro patch works for me too. Thank you very much @Sharpiro.

[arkanmgerges]

Hi,
I just mentioned also on debug broken: vscode breakpoint set but not hit, that I could not hit the breakpoint(s)

[yui-knk]

Delve master includes this change derekparker/delve@a208c89#diff-85f7e39a17e446f5b7c743ad1f0ed3d8L539. This commit changed destination of message from stdout to stderr. If we continue to hook some message arrival from debugProcess , I think we should call connectClient in stderr callback https://github.com/Microsoft/vscode-go/blob/0.6.83/src/debugAdapter/goDebug.ts#L413. This is why patches given by #1752 (comment) works.

[lggomez]

Indeed, it seems that @Sharpiro and @yui-knk hit the spot

The switch to logrus also switched the default output stream of the init messages to stderr. The workaround should fix it, although If not synchronized, and the debugProcess event handlers are non-blocking we could have a datarace causing multiple connectClient calls

What do you think @ramya-rao-a ?

[lggomez]

The previous log was restored, it should work again after updating delve from master

[ramya-rao-a]

@Sharpiro, @yui-knk Indeed, great job at getting to the root cause.
Like @lggomez mentioned, looks like the stdout/stderr issue is solved in delve itself.

Can others here get the latest delve and confirm that the issue is fixed?

[torre76]

Confirmed, updated delve on OSX using HEAD and anything works like a charm.

[Sharpiro]

I can confirm the latest delve commit fixes the debug issue. However, "restarting" a debug session for a test still fails. It looks like the test arguments do not get passed upon restart and the extension attempts to debug the file as if it were a "main" package, causing an error to occur.

[ramya-rao-a]

@Sharpiro That seems like a separate issue. Were you trying to debug tests using the codelens or a debug configuration?

[Sharpiro]

It occurs when debugging a test using code lens. I'm fairly sure it worked in the past.

[lggomez]

@Sharpiro custom debug configurations for codelens debug sessions were not supported. This was just merged on #1749 some hours ago so you're free to test it from master if you want

[Sharpiro]

ok thanks. you're right the restart debug doesn't seem to be related to this issue.

[ramya-rao-a]

Closing this issue as the fix has been made upstream in delve