Breakpoints broken via Attach to running NodeJS process (broken in 0.10.5 and 0.10.6)

[igorvaschuk]

Updated on two machines and on both machines breakpoints are no longer getting hit, despite Code appearing to be attached to the process.
Runing process via "nodemon --debug ./bin/www", then attaching via "Attach" in VS Code.
Debugging via "Launch" works fine and breakpoints are hit.
OS: Windows 10
Node version: v4.2.2
Project created via Visual Studio 2015 with NTVS -> New Project->Templates->Other Languages->JavaScript->Basic Node.js Express 4 Application

[bpasero]

@igorvaschuk which nodejs version?

[weinand]

@igorvaschuk I've installed MEAN and created a first app with "mean init yourNewApp". Since I'm unfamiliar with MEAN could you please guide me how to create an app that lives in ./bin/www so that I can reproduce the problem.

BTW, I could not reproduce the attach problem with an express app.

[gclifford]

I was also getting this when running on Ubuntu. I was trying to attach to a standard expressjs app and it would not hit any of the break point. If I used Launch it worked fine.

[weinand]

@igorvaschuk @gclifford could you please try to use a non-default debug port for the express app, e.g. something like "node --debug=5555 bin/www" and then modify the launch config in VSCode to the same port. In my experiments I've seen a problem with the standard 5858 debug port.

[jpierson]

I'm noticing that I'm having problems lately hitting breakpoints in VSCode for my node project as well. Somewhat recently nodemon was added to the mix via gulp-nodemon where gulp was already used for launching the debug mode of the app. I'm guessing that there may be something with how nodemon works which is causing problems for VSCode. Not sure where or if this can be addressed.

Possible realated issues:

• using debug module when running under nodemon remy/nodemon#546
• How do I run nodemon in debug mode? ColemanGariety/gulp-nodemon#92
• How can I use node-inspector with gulp-nodemon ? ColemanGariety/gulp-nodemon#85

[jpierson]

@weinand I've tried your advice with the debug port but it didn't seem to help in my case.

[gclifford]

@weinand I am not experiencing this anymore. I am wondering if there was a difference between the TypeScript code and sourceMaps and the debugger got confused.

[bartvanderwal]

👍! This is really vital!

As Ward Bell stated in the comment on John Papa's blog on debugging in VS Code: "Whether client or server side. Auto-refresh as we do with nodemon should be part of the solution."

I switched over from Visual Studio NTVS to Visual Studio Code because of the terrible stalling of the UI in VS 2015 while editing typescript. VS Code is a lot more workable, but live debugging is now still not possible.

EDIT: It's working now somewhat, see my comment below.

[weinand]

@bartvanderwal I suggest that you file a separate issue for your feature request because this issue is a bug.

[bartvanderwal]

Thanks for the quick reply @weinand, but actually it IS working now. Somewhat. At least I won't post an issue. I posted some more details of my setup in a Stackoverflow answer In case this might help anyone

[weinand]

If breakpoints in your startup code are not hit in "attach" mode, but they work in "launch" mode please try to start your target with the "--debug-brk" option instead of the "--debug" option.

The "--debug-brk" option makes sure that the target stops on entry and that VS Code gets a chance to properly register the breakpoints. When starting with "--debug" only, the debugger runs over the startup code before VS Code has a chance to register the breakpoints.

In "launch" mode it is not necessary to set stopOnEntry to true in order to get the breakpoint in startup code hit because VS Code behind the scenes always launches the debugger with "--debug-brk" (but hides the break on entry event to the user).

[weinand]

@bartvanderwal I've created this feature-request for the automatic reattach: #2103

[bartvanderwal]

That looks great @weinand! I'll try it out shortly.

[ianwesterfield]

I have found one weird and somewhat impractical workaround with node --debug (default port) and node-inspector.

Same-module breakpoints in vscode begin working as expected after setting and hitting just one breakpoint using node-inspector in that module. Breakpoints set by vscode in other modules fail to hit until node-inspector first hits a breakpoint in the same module.

UPDATE 2016/2/4

I copied the project directory to another location and the issue was not reproducible. I pointed VS Code and node back over to the original location and, again, could not reproduce this behavior. Possibly something was wrong with the project directory? Now the only thing breaking are the breakpoints 👍

[alexisbg]

My Express 4 application is experiencing a nearly similar issue but some there are some interesting clues.

It runs on a Debian 8 box, Node.js version is 4.3.0 and VS Code 0.10.8 runs on Windows 7. I start it with:
node --debug-brk server/server.js

VS Code breaks at the first line. Next every breakpoints in server/server.js are correctly handled by VS Code. But all the breakpoints ouside this file will never stop.

On VS Code Debug view, server/server.js is marked as "content streamed from server" but not on Exporer view. By the way its breakpoints are only visible in the Debug view. It seems that only this file is processed by VS Code.

On the other hand, Node Inspector works like a charm:
node-debug --web-host=192.168.101.102 server/server.js

[alexisbg]

VS Code has been updates to v0.10.10 but there is still the same behaviour.

After reflection, I figured out that VS Code was not able to map remote files to those of the Explorer view. I investigated the vscode-debug-node project and I have found the localRoot and remoteRoot parameters of attach configuration:
https://github.com/Microsoft/vscode-node-debug/blob/master/src/node/nodeDebug.ts#L146

And there is a short description about them on January release page, below "Remote Debugging":
https://code.visualstudio.com/updates/vJanuary#_nodejs-debugging

These 2 parameters fix the issue. Here is a launch.json configuration sample:

{
    "name": "Attach to my.remote.linux.box",
    "type": "node",
    "request": "attach",
    "address": "my.remote.linux.box",
    "port": 5858,
    "localRoot": "${workspaceRoot}",
    "remoteRoot": "/path/to/project/root/on/remote/host"
}

I hope this can help.

[weinand]

Since there are so many issues discussed here and many issues have been addressed, I no longer have a clear view what problem is still open. Please open new items for everything that is still not working.