Debugger Not Attaching Due to Race Condition in Code

[atom0s]

• Visual Studio 2013 (Update 4)
• NTVS.Dev.2015-06-14.VS.2013.msi
• Node v0.12.5

Most of the time, it seems that the debugger refuses to work properly. If I launch my application through Visual Studio, I would say about 75% of the time, it will show the debugger port in the console being 5858 and then nothing else happens. Typically if this occurs it requires me to restart Visual Studio entirely to get it to work again. And that point, it usually only works once, then dies again from there on til the next restart.

This issue happens with both the default startup path being set to the default:
C:\Program Files\nodejs\node.exe

As well as being set to something custom, such as nodemon:
C:\Users\atom0s\AppData\Roaming\npm\nodemon.cmd

Either or has the same issue.

[alejandro5042]

This may be related to the issue I reported yesterday #245. Can you confirm? I realize you're using node.js, but it could be the same bitness issue.

[atom0s]

Hello @alejandro5042 currently I am not using io.js, just using normal node with some packages such as:

• express
• passport
• sequelize
• vash

All of which I am pretty sure are the 32bit versions. Given that the debugging works sometimes but not always, I don't think that it is an issue with the version types though.

[mousetraps]

Haven't gotten the chance to look into it, but this sounds like a race condition, and we can't rule out the possibility it's related to #245 just yet... It could be that the recent x64 versions of iojs happen to exacerbate it.

[atom0s]

Thanks for the response @mousetraps - just to mention it again, I do not use io.js in my scenario. But I do seem to have a similar issue to what alejandro5042 is mentioning in his ticket.

[alejandro5042]

Actually, you bring up a good point with the race condition. Even with the io.js x86 which actually works vs. x64, I still have an issue with setting breakpoints. I cannot seem to hit a breakpoint in the first couple of lines of code, yet I can set and hit breakpoints in callbacks that occur after. I just did a little testing and observed that any breakpoint in the first 2 seconds of execution are not hit... anything after works. Thanks for attempting to investigate this @mousetraps!

[mikedavies-dev]

I have a similar issue but not so frequent, maybe 50% of the time. I get a message saying debugger listening on port 5858 and then nothing.

I've tried uninstalling 64 bit and installing 32 bit but the problem is still there.

I don't need to restart Visual Studio, I just have to stop and start the app until the debugger kicks in. After a while it gets quite bad and restarting VS does help.

Running:

VS 2015 RC
Node: v0.12.6 (x32 + x64)
NTVS: 1.1 beta

[mikedavies-dev]

After about an hour or so of testing with the x32 version, it does still happen but no where near as often as with the x64 version.

[mousetraps]

@ant-fx just realized you're on 1.1 beta - you should try one of our latest dev builds if we haven't already, as we fixed a race condition that solved similar issues
https://github.com/Microsoft/nodejstools/releases

@atom0s unfortunately I can't repro this one yet, but maybe implementing #271 will help us get to the bottom of it. In the meantime, if you want to dig into this yourself, it would be helpful if you could run NTVS under the debugger and send us the log printed to the output window.

[nrossol]

I have the exact same issue, produced like this:

1: Create an express 3 application from the built-in template.
2: Press Debug button (with Google Chrome, for example)

Result:
90% of the time for me, I only get the console window displaying the message: "Debugger listening on port 5858". The Output panel is blank for everything (Debug, Build, General). The node server is not running, the web browser does not launch. I have waited for up to 10 minutes, and there is no change from this state.

Possible Work-around:
Occasionally, hitting the "Break All (Ctrl+Alt+Break)" button will cause the yellow debug cursor to appear on the very first line of "app.js". If this happens, pressing the "Continue" button sometimes causes everything to work as expected there-after (node server launches, browser pops up, everything works, including interactive debugging).

Unfortunately, sometimes pressing the "break-all" button does not cause the yellow debug cursor to appear on the first line of app.js, and pressing "Continue" does not help at all (still stuck in the same state). Sometimes pressing the "break-all" button causes visual studio to completely freeze until you force-quit the running node.exe process.

The seemingly random nature of all these issues really does seem to suggest some kind of race-condition is at play.

[mousetraps]

@nrossol since you just joined us... have you tried the latest dev build? We fixed a similar race condition there, and I can't tell you whether it's the same one you're running into but you should definitely upgrade if you haven't already.
https://github.com/Microsoft/nodejstools/releases