Vscode: Debugger not working properly, breakpoints won't trigger

[toml01]

• VSCode Version: 1.0.0
• OS Version: Windows 10

I'm working on a node.js project, using express.
I created the following POST route:

Putted a breakpoint in the cb function of the route. When it arrives there, the program stops, but the breakpoint won't "trigger", VSCode looks like the server just runs as usual.
When the breakpoint isn't there - the program runs as it supposed to.

I opened the developer console, and when it supposedly reaches that breakpoint (again, not showing that the program stopped or anything) it prints to the console:

The same problem occurs on every post route so I can't debug them at all, but not on get routes (tried only get and post).

[weinand]

@TomL94 are you launching the server through VS Code or are you attaching to a running server?
What version of node.js are you using?

I could not reproduce your problem on Windows 10, but I'm not sure that I understand your second parameter 'upload' to 'router.post'. I left it out and everything was working fine for me.

The message 'waiting for debug protocol on stdin/stdout' is normal and occurs at the start of every debug session.

[molant]

@weinand I'm having the same issue. My breakpoints in nodejs get reached, the execution stops but I don't see anything in the debugger window (but if I press F5 the execution continues). Strangely, when the code throws an exception and the debugger is set to capture all uncaught exceptions I can see the variables, call stack. etc.
If I set the debugger to break on entry it works as expected until I continue the execution to stop on a breakpoint.

This has also happened to other teammates in different times and versions but we've never found out how to reproduce it consistently (although once it happens doesn't seem to get fixed).

I'm currently running node 5.11.0 (was also happening with 5.10.1), Windows 10 14316 and the latest stable and insider versions of vs code (happens in both).

My alias is antonmo in case you want more information over Skype or follow up internally to get more info.

Thanks!

[rhurkes]

VSCode version: 1.0.0
OS: OSX El Capitan
Node versions tried: 0.10.42, 4.4.3, 5.0.0, 5.9.1, 6.0.0
Express: 4.13.4

There are some weird conditions for this behavior that I've come across. I can recreate in every version of Node when trying to launch or attach my big app that uses Express's router:
http://expressjs.com/en/4x/api.html#express.router

I then tried the Express 'Hello World' sample located here:
http://expressjs.com/en/starter/hello-world.html
and set a breakpoint on 'res.send('Hello World!');'

Everything worked fine when debugging via launch or attach _except_ for when I tried using Node 6.0.0 - then I observed the issue again. It's like it's hitting the breakpoint, but there is no visual indication in VSCode that it has done so, and watches/evaluations/stack don't have access to any of the expected objects.

[psulek]

@rhurkes i have same issue with vscode (1.0) and node v6.

[psulek]

@rhurkes So i unstalled node v6 and installed node-v5.11.0 and it works again. So issue is related to vscode 1.0 and node v6.

[schemburkar]

Same issue as @rhurkes for me in express app. It now works with node v4.4.3 but not in v6
VSCode seems to stop at the breakpoint without any debug info with current line highlight, watch etc. I can then blindly step through using F8, without the current line being highlighted.

Debugger works on stopOnEntry but not in node/express handlers.

[molant]

@psulek I'm runing node 5.11 and I'm having the same issue with the insider and the stable (and I had randomly for quite a few versions of vscode and node now).

[infeng]

i have same problem
node: 6.0.0
os: windows10 14332
vscode: 1.0

[weinand]

VS Code 1.0 does not yet support node v6.
node v6 appeared after we had finished VS Code 1.0.
Try the upcoming VS Code 1.1 - the Insider release is already available.

[jasonmit]

I'm experiencing this in node 4.4.3, I'll report back with more details shortly.

Update: nothing in the developer console. Also, I am attaching to the process via node --debug-brk. Some breakpoints will hit and I can inspect, others will hit but cannot be inspected.

[rhurkes]

For anyone seeing issues in places besides node 6.0, verify that nvm (or similar) isn't confusing things. I had to use launch.json's runtimeExecutable setting to get node 4.4.3 working with nvm while node 6 was installed as an OS package.

[jasonmit]

@rhurkes I am attaching to the process in this case, so I don't specify a runtimeExecutable. Also, some breakpoints hit and can be inspected whiled others hit and cannot be inspected.

Here is the stacktrace of an error I get when I attach to the process. I'm unsure if this is the underlying issue or not..

shell.ts:416 Cannot read property 'getItem' of undefined: TypeError: Cannot read property 'getItem' of undefined
    at t.getItem (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:33:4937)
    at t.expand (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:32:31848)
    at t.expand (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:45:4868)
    at file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:97:10912
    at e.invoke (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:31:219)
    at e.fire (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:31:1672)
    at e.setFocusedStackFrame (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:79:8322)
    at e.setFocusedStackFrameAndEvaluate (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:103:20519)
    at file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:103:16041
    at Object.h [as _notify] (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:23:22735)e.onUnexpectedError @ shell.ts:416(anonymous function) @ shell.ts:318e.onUnexpectedError @ errors.ts:73u @ errors.ts:88e.invoke @ callbackList.ts:65e.fire @ event.ts:107e.setFocusedStackFrame @ debugViewModel.ts:36e.setFocusedStackFrameAndEvaluate @ debugService.ts:418(anonymous function) @ debugService.ts:258h @ winjs.base.raw.js:1440__dirname.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:1311h @ winjs.base.raw.js:1440__dirname.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

[cyan-haru-25]

i had same problem. but I had resolved this problem.
I tried following environments. and its OK.

• OS : windows8.1
• vsCode : v1.2.0
• node : v6.2.1 and v5.10.1 and v4.4.3
• using port : 80

my launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch",
            "type": "node",
            "request": "launch",
            "program": "${workspaceRoot}/bin/www",
            "stopOnEntry": false,
            "args": [],
            "cwd": "${workspaceRoot}",
            "preLaunchTask": null,
            "runtimeExecutable": null,
            "runtimeArgs": [
                "--nolazy"
            ],
            "env": {
                "NODE_ENV": "development"
            },
            "externalConsole": false,
            "sourceMaps": true,
            "outDir": "${workspaceRoot}"
        },
    ]
}

this point is

"program": "${workspaceRoot}/bin/www",

Step

• you must stop _npm start_
• start debug with Launch

that's all

[chawk]

I had this issue, but this was due to some breakpoints being applied within the Node.JS source code, when I removed those breakpoints everything worked fine.

[BoogalooJB]

I had this issue, but I was using node 7.4.0. When I switched back to node 6.9, everything worked as expected (I had to set runTimeExecutable because I'm using nvm and the version set with nvm seems to have no effect in VS Code).

[weinand]

@BoogalooJB VS Code uses the 'node' executable found via the PATH environment variable. If you manage node versions with nvm, you have to restart VS Code because otherwise it does not see updated environment variables. (But your approach will work too).

[GordonSmith]

FWIW I was seeing this same issue in a node app written in TS and called from an external Test module (also coded in TS) - no express used.
What fixed it for me was correcting my "outDir" to point at the folder where the generated JS was: "outDir": ""${workspaceRoot}/dist-dev"

Previously I had it set to "outDir": ""${workspaceRoot}/dist-dev/Test" which allowed me to set the breakpoints on the Test module, but not the app module.

Question: "outDir" is saying its deprecated, what should it be replaced with?

[isidorn]

@GordonSmith please use "outFiles", more details https://code.visualstudio.com/updates/v1_6#_glob-pattern-support-for-source-map-setup

[jrwiegand]

I am having this problem now. I am not sure if this started with the release of v1.9.0 or v1.9.1. I was definitely debugging with breakpoints in v1.8.x. Not sure how to solve this issue. I am using gulp, I don't know if that makes a difference for debugging as I am using the given configuration from vscode's debug configuration.

OS : macOS Sierra 10.12.3
vsCode : v1.9.1
node : v7.5.0 or v6.9.5 (I tried both)
using port : 8080

launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "launch",
            "name": "Gulp default",
            "cwd": "${workspaceRoot}",
            "program": "${workspaceRoot}/node_modules/gulp/bin/gulp.js",
            "args": [
                "default"
            ]
        },
        {
            "type": "node",
            "request": "attach",
            "name": "Attach to Process",
            "port": 5858
        }
    ]
}

Edit: I was able to debug with the following addition to launch.json

{
            "type": "node",
            "request": "launch",
            "name": "Launch Program",
            "program": "${workspaceRoot}/server.js",
            "cwd": "${workspaceRoot}",
            "restart": true
},

[wgv-sethlivingston]

{ "restart": true } was the secret sauce for me, too.

[jrwiegand]

The debugger stopped working again and I did a little bit more digging. I found that the protocol using inspector to fix the situation ("protocol": "inspector"). So the current version I have is the following:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "launch",
            "name": "Launch Program",
            "program": "${workspaceRoot}/server.js",
            "cwd": "${workspaceRoot}",
            "restart": true,
            "protocol": "inspector"
        }
    ]
}

However, even with this change the gulp tasks are not working.

[weinand]

Since there are so many "me too" reports piggy-backed on this issue, I can no longer follow them in details and I'm closing the issue.

If you still experience your problem in VS Code 1.11.0, please create a new issue with detailed steps.

[timhuff]

I just ran into this issue. Another solution to try, future reader: For me, it ended up being that I hadn't properly capitalized a letter in my require statement. Breakpoints in the test worked fine but not in the required file. It ran the code, even with the messed up caps, but didn't stop at the breakpoint.

[GerryFudd]

"Since there are so many "me too" reports piggy-backed on this issue, I can no longer follow them in details and I'm closing the issue."

That's an option? Doesn't the number of me too comments indicate that this is a serious problem that is very much not resolved?

[weinand]

No, most of the "me too"s are unrelated to the original issue and should have been filed as separate issues.

If you have another "me too" please file a new issue and we will investigate.

I'm locking this issue now.