Setting breakpoints seems to no longer work

[dylan-bourque]

After a recent update to either VS Code, the extension or the Delve debugger, I am no longer able to debug my Go programs. Setting a breakpoint from within the IDE seems to work correctly (I see the red dot for the breakpoint in the gutter) but when I launch the application none of my breakpoints are set. They all show greyed out in the gutter and the tooltip says "Unverified Breakpoint" when I hover my mouse over the indicator.

When I launch my application within the Delve debugger directly (via dlv debug or dlv exec), I am able to set breakpoints and step through the code.

Please feel free to contact me directly if you need more details.

Environment:

Linux (CentOS 7) Visual Studio Code ver 1.0.0 Go extension ver 0.6.38 Delve debugger ver 0.11.0-alpha

$GOPATH/src/scratch/test.go:

package main
import "fmt"
func main() {
   fmt.Println("This is a test.")
}

$GOPATH/src/scratch/.vscode/launch.json:

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

The console log in VS Code Developer Tools shows the following when I launch the debugger:

[Mon May 09 2016 15:16:58] [ERROR] rawDebugSession.ts:225waiting for debug protocol on stdin/stdout shell.ts:477Did not get a thread from debug adapter with id 0.: Error: Did not get a thread from debug adapter with id 0. at file:////usr/share/code/resources/app/out/vs/workbench/workbench.main.js:99:26579 at Object.h as _notify at Object.n.undefined.R.enter (file:////usr/share/code/resources/app/out/vs/workbench/workbench.main.js:23:21055) at n.undefined.t.Class.define._run (file:////usr/share/code/resources/app/out/vs/workbench/workbench.main.js:23:22881) at n.undefined.t.Class.define._completed (file:////usr/share/code/resources/app/out/vs/workbench/workbench.main.js:23:22322) at Object.h as _notify at Object.n.undefined.R.enter (file:////usr/share/code/resources/app/out/vs/workbench/workbench.main.js:23:21055) at n.undefined.t.Class.define._run (file:////usr/share/code/resources/app/out/vs/workbench/workbench.main.js:23:22881) at n.undefined.t.Class.define._completed (file:////usr/share/code/resources/app/out/vs/workbench/workbench.main.js:23:22322) at file:////usr/share/code/resources/app/out/vs/workbench/workbench.main.js:78:29067

[fdiaconeasa]

I'm getting the same issue on Mac OS X. No other changes, except updating vscode.

[lukehoban]

I can't seem to reproduce this. The only difference for me is I am on VS Code 1.1 now. Any chance you can test on 1.1?

Also - is the repro steps above exactly what both of you can repro with? At whcih step are you setting the breakpoint, when is it turning grey, etc.?

[fdiaconeasa]

I'm running the latest vscode version.

1. open the golang project in vscode
2. open a go source file
3. set a breakpoint in a valid location and notice it is red -> so it is valid
4. start your debug session
5. notice the breakpoint turns to grey

I couldn't yet establish a more narrow scenario, as sometimes it works, sometimes it doesn't [debugging].

[dylan-bourque]

Luke,

Thanks for following up. I'm seeing the same behavior at @federaldi. I get a "normal" red dot in the gutter when setting a breakpoint in the code editor. When I launch the program, the red dot turns grey and starts showing a tooltip that says "Unverified breakpoint". It's the same when I try to set a breakpoint in a running program.

The debugger breaks correctly if I set the stopOnEntry option in launch.json, but I can't seem to get it to set/accept any other breakpoints.

I have not upgraded to VS Code 1.1 yet. I will give it a shot and let you know.

[dylan-bourque]

I upgraded to VS Code 1.1 this morning. Seeing the same behavior, but a different error in the VS Code Developer Tools console.

[Mon May 16 2016 09:53:20] [ERROR] rawDebugSession.ts:363 waiting for debug protocol on stdin/stdout index.html?config={"pathArguments"%3A[]%2C"programStart"%3A0%2C"enablePerformance"%3Afalse%2C"verbo…:28 [uncaught exception]: TypeError: Cannot set property 'stoppedDetails' of undefinedonError @ index.html?config={"pathArguments"%3A[]%2C"programStart"%3A0%2C"enablePerformance"%3Afalse%2C"verbo…:28(anonymous function) @ index.html?config={"pathArguments"%3A[]%2C"programStart"%3A0%2C"enablePerformance"%3Afalse%2C"verbo…:100emitOne @ events.js:90emit @ events.js:182window.onerror @ /usr/share/code/resources/electron.asar/renderer/init.js:107i.globals.onerror @ errorTelemetry.ts:62 index.html?config={"pathArguments"%3A[]%2C"programStart"%3A0%2C"enablePerformance"%3Afalse%2C"verbo…:31 TypeError: Cannot set property 'stoppedDetails' of undefined at e.rawUpdate (debugModel.ts:728) at debugService.ts:248 at dirname.undefined.t.Class.define.done (winjs.base.raw.js:1782) at Object.h as _notify at Object.dirname.undefined.P.enter (winjs.base.raw.js:1127) at dirname.undefined.t.Class.define._run (winjs.base.raw.js:1343) at dirname.undefined.t.Class.define._completed (winjs.base.raw.js:1311) at Object.h as _notify at Object.dirname.undefined.P.enter (winjs.base.raw.js:1127) at dirname.undefined.t.Class.define._run (winjs.base.raw.js:1343)onError @ index.html?config={"pathArguments"%3A[]%2C"programStart"%3A0%2C"enablePerformance"%3Afalse%2C"verbo…:31(anonymous function) @ index.html?config={"pathArguments"%3A[]%2C"programStart"%3A0%2C"enablePerformance"%3Afalse%2C"verbo…:100emitOne @ events.js:90emit @ events.js:182window.onerror @ /usr/share/code/resources/electron.asar/renderer/init.js:107i.globals.onerror @ errorTelemetry.ts:62 debugModel.ts:728 Uncaught TypeError: Cannot set property 'stoppedDetails' of undefinede.rawUpdate @ debugModel.ts:728(anonymous function) @ debugService.ts:248dirname.undefined.t.Class.define.done @ winjs.base.raw.js:1782h @ winjs.base.raw.js:1448dirname.undefined.P.enter @ winjs.base.raw.js:1127dirname.undefined.t.Class.define._run @ winjs.base.raw.js:1343__dirname.undefined.t.Class.define._completed @ winjs.base.raw.js:1311h @ winjs.base.raw.js:1440dirname.undefined.P.enter @ winjs.base.raw.js:1127__dirname.undefined.t.Class.define._run @ winjs.base.raw.js:1343__dirname.undefined.t.Class.define._completed @ winjs.base.raw.js:1311(anonymous function) @ v8Protocol.ts:47e.dispatch @ v8Protocol.ts:117e.handleData @ v8Protocol.ts:84(anonymous function) @ v8Protocol.ts:39emitOne @ events.js:90emit @ events.js:182readableAddChunk @ _stream_readable.js:153Readable.push @ _stream_readable.js:111onread @ net.js:531

[dylan-bourque]

Late this morning I got a prompt that there was a 1.1.1 update to VS Code available. I downloaded and installed the update (because the changes specifically call out fixes for debugging issues) but the behavior was the same.

[dylan-bourque]

I was able to determine today that, at least on my system, the problem seems to be related to whether or not the source file is opened via the VS Code Explorer window vs. opened with a full path.

Following my original example, if I click test.go in the VS Code Explorer window, the code editor shows only "test.go" in the header area. If I set a breakpoint on the first line of main() and launch the debugger, my program will not hit it.

If, however, I use the File->Open dialog to open the same file, the header in the code editor shows "test.go /home/dylan/gocode/src/scratch" instead and the IDE sets the breakpoints correctly and the debugger stops.

Hope this helps. :)

[dylan-bourque]

Unfortunately, the latest VS Code update (version 1.3) has broken my workaround from May 26. Today, I am completely unable to set breakpoints and step through my Go code in the debugger. :(

The new "Open Editors" view appears to always show file with the workspace-relative path (test.go rather than /home/dylan/gocode/src/scratch/test.go), regardless of whether they're opened via the project Explorer window or the File->Open menu.

[shamsfk]

I have a same problem in mac os x 10.11.5 vsc 1.3.1 everything including delve freshly installed

[spotlmnop]

same problem in mac os x 10.11.5 vsc 1.3.1 Go extension version: 0.6.42

[tnine]

Same here. Os X 10.11.6 VS 1.3.1 Go ext 0.6.42. Note that until I updated to 0.6.42, I did not experience this issue.

Delve Info:

Delve Debugger Version: 0.11.0-alpha Build: v0.11.0

Go Info: go version go1.6.3 darwin/amd6

[endophage]

Still broken with 1.4.0 release of VSCode. (Go plugin 0.6.42, Mac OS 10.11.6, Golang 1.6.3, Delve 0.11.0)

[tnine]

I'm not sure if this helps, but I built Delve from source, and this issue went away. Specifically, I'm running this sha. 218c2b953b13c439a645ede821d3aaca7b71ff7b. I don't know if this issue lies in delve or in the go plugin.

[burrbd]

Seeing same problem with VSCode 1.4.0, Mac OS 10.11.5, Golang 1.6.1, Delve 0.11.0.

[dylan-bourque]

Interestingly, everything is working fine for me now on my Windows 10 system.

Windows: Windows 10 (build 1607) VS Code v1.4.0 Go v1.6.3 Delve v0.11.0-alpha (via "go get github.com/derekparker/delve/cmd/dlv")

Linux: CentOS 7 VS Code v1.4.0 Go v1.6 Delve v0.11.0-alpha (also via "go get ..")

[endophage]

Hmmm tried manually building the 218... commit mentioned by tnine. Now I get a panic unrelated to my code (or dlv it appears for that matter) when I try to run the debugger.

unexpected fault address 0xb01dfacedebac1e
fatal error: fault
[signal 0xb code=0x1 addr=0xb01dfacedebac1e pc=0x405f975]
goroutine 1 [running, locked to thread]:
runtime.throw(0x493af30, 0x5)
    /usr/local/Cellar/go/1.6.3/libexec/src/runtime/panic.go:547 +0x90 fp=0xc82015dcf0 sp=0xc82015dcd8
runtime.sigpanic()
    /usr/local/Cellar/go/1.6.3/libexec/src/runtime/sigpanic_unix.go:27 +0x2ba fp=0xc82015dd40 sp=0xc82015dcf0
runtime.aeshashbody()
    /usr/local/Cellar/go/1.6.3/libexec/src/runtime/asm_amd64.s:1087 +0xc5 fp=0xc82015dd48 sp=0xc82015dd40
fatal error: unexpected signal during runtime execution

[7sDream]

same here.

Environment

Linux Deepin 15.2 (Debian based) VSCode version: 1.4.0 vscode-go version: 0.6.43 go version: 1.6.3 dlv version: 0.11.0-alpha (from go get

launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch",
            "type": "go",
            "request": "launch",
            "mode": "debug",
            "program": "${workspaceRoot}",
            "env": {},
            "args": ["-port", "8000"],
            "showLog": true
        },
        {
            "name": "Remote",
            "type": "go",
            "request": "launch",
            "mode": "remote",
            "remotePath": "${workspaceRoot}",
            "port": 2345,
            "host": "127.0.0.1",
            "program": "${workspaceRoot}",
            "env": {},
            "args": [],
            "showLog": true
        }
    ]
}

Screenshot

Bug description

I set a breakpoint at line 55.

Notice that there is a "create breakpoint" log in output window (in red color), but it seems not work.

The program just run and printed out some log I written (start with [INFO] in white color)

[hatuan]

Here is golang breakpoint work and don't work

[roblourens]

Is this still a problem for ya'll?

[tezli]

Yes

[roblourens]

I don't know if this is true for everyone but it sounds like a couple of you can open two copies of a file with its path displayed differently. @hatuan if you click on the first breakpoint to open the file, and hover the mouse over the tab title, can you compare the path in the tooltip to the path for the second breakpoint?

[dylan-bourque]

I upgraded by VS Code and all extensions to the latest versions this morning and I'm still seeing this behavior on my CentOS 7 system.

CentOS 7.2.1511 Go v1.6.3 VS Code v1.7.1 Go Extension v0.6.47 Delve debugger v0.11.0-alpha (via go get github.com/derekparker/delve/cmd/dlv)

The breakpoint shows correctly in the source window when I click the gutter or use the keyboard shortcut. After launching the debugger, the breakpoint is greyed out and is never hit.

@roblourens - I was seeing exactly the behavior you're describing prior to VS Code redesigning the "Open Editors" feature. When I used File->Open to open a file, the tab would show the full path to the source file and breakpoints worked. Files opened via the project Explorer window would show only the file name and breakpoints were broken. Today, the behavior is the same (i.e. broken) regardless of how I open the source file.

[roblourens]

Can you paste what you see in the debug console when you start debugging and try to set a breakpoint?

And are there any errors in the devtools console?

[dylan-bourque]

I have a vanilla project in $GOPATH/src/test loaded in VS Code and launch it from the "Debug" tool window.

I set a breakpoint at line 6 and it correctly shows as a red dot in the margin. When the process launches, the breakpoint indicator changes to a grey dot with a black center for a fraction of a second before the "This is a test" string is written to the console, the process exits, and the breakpoint turns back into a red dot.

Debug Console output:

2016/11/07 11:20:04 server.go:41: Using API v1
2016/11/07 11:20:04 debugger.go:61: launching process with args: [./debug]
API server listening at: 127.0.0.1:2345
2016/11/07 11:20:04 debugger.go:390: continuing
This is a test.

test.go:

package main

import "fmt"

func main() {
    fmt.Println("This is a test.")
}

launch.json:

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

[roblourens]

Maybe you said this above, but are you able to debug and set breakpoints with delve alone?

[dylan-bourque]

That is correct, @roblourens. Breakpoints work correctly if I use the Delve debugger directly.

If it helps with troubleshooting, my Linux system is an AWS virtual machine using one of the pre-canned CentOS 7 AMIs. I don't know which one exactly off the top of my head but I could find out.

[roblourens]

It looks like people are seeing this in a few OS's, and I don't have an EC2 account. I did try it again with the same Go version as you in Ubuntu, but still not seeing an issue. I'm not sure what else to say - there is a bunch of logging in the debug adapter that would be very useful to see, but you need to clone and build the extension to enable it. If you have the time for that I could help you set it up. Otherwise, the only thing I can think of is changing it to write those logs while debugging. We do something similar for vscode-chrome-debug. Not sure when I'd have time for that though.

[dylan-bourque]

I got some free time and spun up a new, clean system in our AWS environment and was not able to reproduce this behavior anymore.

We still have 3 CentOS systems where we cannot set breakpoints, but we've all switched to new machines.

As far as I'm concerned, the problems have been resolved by an update to 1 of the pieces or were a symptom of those particular machines.

Thanks for investigating, though.

[mattetti]

@dylan-bourque if the issue has been solved would you mind closing this issue? (too bad we don't know what component fixed the issue tho).

[dylan-bourque]

No problem, @mattetti.

[datanotion]

I'm seeing this problem again with the latest version of Code (1.12.1) while trying to debug a NativeScript app. Any others seeing the same, or am I alone?

[alpha-rain]

Yes i am having this issue right now debugging JavaScript with nodejs 7.10.0, in Code (1.12.1)

[AdiedX]

The debugger worked with Golang but abruptly stopped working within a span of an hour. I tested it on a nodeJS project. It works. I reinstalled go-delve with:

brew uninstall go-delve/delve/delve brew install go-delve/delve/delve --HEAD

The issue continues to persist with go projects.

VS Code 1.13.1 Go 1.7.5 Delve 1.0.0-rc.1

[ramya-rao-a]

All,

This is already a very long thread on a closed issue. Please log a new issue. Notifications on closed issues usually don't get our attention as much as a new or open issue would.

Also try using delve from command line to ensure that this is not a delve problem.