Debugger not working properly, breakpoints won't trigger #5422

toml01 · 2016-04-17T20:30:40Z

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 · 2016-04-18T12:17:53Z

@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 · 2016-04-22T17:18:33Z

@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 · 2016-05-01T00:23:44Z

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 · 2016-05-01T09:14:07Z

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

psulek · 2016-05-01T09:17:40Z

@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 · 2016-05-05T02:56:37Z

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 · 2016-05-05T23:43:01Z

@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 · 2016-05-07T03:53:14Z

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

weinand · 2016-05-07T07:27:29Z

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 · 2016-05-10T19:47:52Z

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 · 2016-05-10T20:01:13Z

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 · 2016-05-10T20:07:51Z

@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 · 2016-06-12T09:17:07Z

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 · 2016-08-13T18:19:25Z

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.

ghost · 2017-01-06T11:32:34Z

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 · 2017-01-06T11:43:49Z

@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 · 2017-01-26T10:12:08Z

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 · 2017-01-26T10:21:02Z

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

jrwiegand · 2017-02-22T12:49:46Z

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 · 2017-03-06T23:43:46Z

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

jrwiegand · 2017-03-09T18:18:46Z

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 · 2017-04-06T12:33:10Z

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 · 2017-08-12T03:31:10Z

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 · 2017-11-14T22:42:00Z

"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 · 2017-11-14T22:49:09Z

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.

dbaeumer assigned isidorn Apr 18, 2016

isidorn assigned weinand and unassigned isidorn Apr 18, 2016

weinand added the debug Debug viewlet, configurations, breakpoints, adapter issues label Apr 22, 2016

psulek mentioned this issue May 1, 2016

Breakpoints not hit when debugging NodeJS via Launch #2553

Closed

hyndsite mentioned this issue May 6, 2016

Breakpoints Ignored and Not Triggered #6164

Closed

weinand mentioned this issue Jun 3, 2016

Debugger is not stopping/showing at the breakpoint in node v6.1.0 #6967

Closed

weinand closed this as completed Apr 6, 2017

sthiago mentioned this issue Jun 17, 2017

Unable to get into debugger/hit breakpoints on windows 10 & ActiveState 5.24 raix/vscode-perl-debug#26

Open

microsoft locked and limited conversation to collaborators Nov 14, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Debugger not working properly, breakpoints won't trigger #5422

Debugger not working properly, breakpoints won't trigger #5422

toml01 commented Apr 17, 2016

weinand commented Apr 18, 2016 •

edited

Loading

molant commented Apr 22, 2016

rhurkes commented May 1, 2016

psulek commented May 1, 2016

psulek commented May 1, 2016

schemburkar commented May 5, 2016

molant commented May 5, 2016

infeng commented May 7, 2016

weinand commented May 7, 2016 •

edited

Loading

jasonmit commented May 10, 2016 •

edited

Loading

rhurkes commented May 10, 2016

jasonmit commented May 10, 2016 •

edited

Loading

cyan-haru-25 commented Jun 12, 2016 •

edited

Loading

chawk commented Aug 13, 2016

ghost commented Jan 6, 2017

weinand commented Jan 6, 2017

GordonSmith commented Jan 26, 2017 •

edited

Loading

isidorn commented Jan 26, 2017

jrwiegand commented Feb 22, 2017 •

edited

Loading

wgv-sethlivingston commented Mar 6, 2017

jrwiegand commented Mar 9, 2017

weinand commented Apr 6, 2017

timhuff commented Aug 12, 2017

GerryFudd commented Nov 14, 2017

weinand commented Nov 14, 2017

Debugger not working properly, breakpoints won't trigger #5422

Debugger not working properly, breakpoints won't trigger #5422

Comments

toml01 commented Apr 17, 2016

weinand commented Apr 18, 2016 • edited Loading

molant commented Apr 22, 2016

rhurkes commented May 1, 2016

psulek commented May 1, 2016

psulek commented May 1, 2016

schemburkar commented May 5, 2016

molant commented May 5, 2016

infeng commented May 7, 2016

weinand commented May 7, 2016 • edited Loading

jasonmit commented May 10, 2016 • edited Loading

rhurkes commented May 10, 2016

jasonmit commented May 10, 2016 • edited Loading

cyan-haru-25 commented Jun 12, 2016 • edited Loading

chawk commented Aug 13, 2016

ghost commented Jan 6, 2017

weinand commented Jan 6, 2017

GordonSmith commented Jan 26, 2017 • edited Loading

isidorn commented Jan 26, 2017

jrwiegand commented Feb 22, 2017 • edited Loading

wgv-sethlivingston commented Mar 6, 2017

jrwiegand commented Mar 9, 2017

weinand commented Apr 6, 2017

timhuff commented Aug 12, 2017

GerryFudd commented Nov 14, 2017

weinand commented Nov 14, 2017

weinand commented Apr 18, 2016 •

edited

Loading

weinand commented May 7, 2016 •

edited

Loading

jasonmit commented May 10, 2016 •

edited

Loading

jasonmit commented May 10, 2016 •

edited

Loading

cyan-haru-25 commented Jun 12, 2016 •

edited

Loading

GordonSmith commented Jan 26, 2017 •

edited

Loading

jrwiegand commented Feb 22, 2017 •

edited

Loading