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

[nrossol]

Hi! The build I used and encountered this bug in is NTVS.Dev.2015-07-15.VS.2013 (I just updated/installed it earlier today).

[atom0s]

Sorry for the delayed response. This issue happens for me with express 3 as well mainly.

@mousetraps Is there a certain way you would like me to dig into things to try and collect information for you to better find the cause of this issue?

[mousetraps]

@atom0s We already have debugger logging when you're running NTVS with the debug bits and the debugger attached, and the most helpful thing to do would be to just send us the output from the output window from one run where debugging isn't working (and one where it is, if possible.)

Then we can do a diff on those two runs, which will help us narrow down where a race condition might be coming from.

As stated in #271, in the future we plan to surface up that information via an optional logging flag so that it's easier to diagnose problems like this that we can't reproduce.

[atom0s]

I have update to Visual Studio 2015 RTM and installed the new NTVS 1.1 package from here:
http://aka.ms/ntvs1.1rc2015
(I'm not using the first link, but the 2nd one in the release since I'm not using the community version of 2015.)

While debugging my teams API project, everything works great. however our front end project that makes use of express 3 is when the issues start happening again. It seems that NTVS and express 3 have issues working well together.

Also I am unsure if I am missing something but I get literally nothing in the output window when it does and doesn't work. Such as right now testing things for this post, debugging is working. Yet the output window is completely empty. (Assuming you are referring to Visual Studio's output window.) See here: http://i.imgur.com/p9dQWjG.png

From the past tests, when debugging is not working properly, the output window was also empty.

[mousetraps]

I wasn't entirely clear, I meant you would need to download the NTVS src and attach a debugger while you're debugging in order to see this output 😃 In any case, #271 is now available in the latest dev build, which means that you can turn on Live Debugging from Tools > Node.js Tools > Diagnostic Info..., and check the Enable Node.js Tools Live Diagnostics output pane box

Then, during your debug sessions, output will be available in the Node.js Tools Live Diagnostics output pane

So when you run into an issue, you can just copy and paste the last debug session output into a window (each debug session begins with a bunch of ------s.

For instance, this is the sort of output we are expecting to see from Node v0.12.4 running a console.log('hello world') and exiting the process by closing the console window that pops up.
https://gist.github.com/mousetraps/bd5662028d9190f095cc

In your case, it would be helpful to grab the output after you launch debugging and see nothing happening.

[mousetraps]

Thx for all your patience with this issue. As I posted here I have a fix for working locally on my machine if anyone feels like building locally and giving it a shot. No one on this thread has posted logs, but it certainly seems like the same issue based on the symptoms.

[mousetraps]

A fix for this issue is now available in our latest dev build. Check it out and let us know what you think! https://github.com/Microsoft/nodejstools/releases

cc/ @atom0s @alejandro5042 @ant-fx @nrossol

[atom0s]

Very sorry for my lack of replies here. I got side tracked with other projects and lost track of this ticket. I am installing the update now and will try and report back if I see any other problems. Thank you very much for staying on top of this bug and getting things worked out. :)

[erakis]

Hi,

I was having the same problem on VS2013 (NTVS 1.1 VS 2013) and , only working first time and I had to restart Visual Studio each time. But I have found what was causing part of this problem. I was using Navicat to edit my SQLite database and this one tend to use a kind of lock mechanism or transaction while it stay opened. In my code I was also starting transaction at server startup and this was the why it was hanging...

But I must admit that sometime the debugger does not start every time, 75-80% of the time yes.

I hope it may help somebody else with that problem :)

[erakis]

mousetraps : I did what you said about the "Diagnostic Info" windows and this is what I got when the debugger doesn't start :

[20:48:26.2699168] --------------------------------------------------------------------------------
[20:48:26.2769168] AD7Engine Created (25640749)
[20:48:26.2769168] AD7Engine Called SetRegistryRoot
[20:48:26.2769168] AD7Engine Called SetLocale
[20:48:26.2769168] AD7Engine LaunchSuspended Called with flags 'LAUNCH_ENABLE_ENC' (25640749)
[20:48:27.0039168] AD7Engine Finalized (25640749)

Normaly before the Finalized line we are suppose to the the debugger trying to connect (Debugger connecting to URI: tcp://localhost:....) but the log stop there and the action too.

By the way, is it helping you more ?

My Configuration :

• Windows 7 64 Pro
• Visual Studio PRO Ultimate 2013
• Node v0.12.0
• Last NTVS installled, from https://github.com/Microsoft/nodejstools/releases/download/v1.1.Dev-3.1.2016/NTVS.Dev.2016-03-01.VS.2013.msi

This problem is more than annoying now, I have to relaunch Visual Studio 2013 a lot of time per hours while developing. I think that in a day I can relaunch it 100 times ! Even if I don't like Webstorm, I think that I will come back to it very shortly :(

Maybe we should re-open the case ?

[mjbvz]

Thank you for providing this info and sorry that you are running into problems.

@mousetraps, looking at the code, it seems we never hit this statement at the end of IDebugEngineLaunch2.LaunchSuspended:

 LiveLogger.WriteLine("AD7Engine LaunchSuspended returning S_OK");

I wonder if NodeDebugger.StartListening is timing out? That function throws an exception, which I believe would trigger this sequence of events (any other exception would do the same, but I see explicit throws in that function).

[erakis]

Is it anything new about this bug ?

[kant2002]

Maybe there need to reopen this issue? Or it is already fixed by @mjbvz

[erakis]

I think the issue should be re-opened as I'm still having the same problem multiple time everyday. It's very annoying.

[mjbvz]

@kant2002 I have not done any work to address this problem but was hoping @mousetraps may have some extra context.

@purell Since this issue was originally scoped to a problem that has been resolved to my knowledge, please open a more targeted issue to track the specific problem you are running into. We want to fix this sort of problem, but I don't want to keep reanimating this thread.

(Also changing the name of this issue to clearly state that this issue was tracking a scoped problem, not general debugger failures)

[erakis]

@mjbvz : Can I use the old title for the new post ? ie : "Debugger Doesn't Work 75% Of The Time". Or maybe "Debugger does not always start" ?

Because I don't know WHY the debugger is not starting and nor the percentage of failure but 75% is near the reality.

I only have the trace I post #246 (comment)

[mjbvz]

@purell If there are more specific situations when the debugger doesn't attach or other symptoms, try mentioning those, since it will make the issue more actionable. But if you are unsure what is going wrong, a generic title is a fine starting point.

The goal is to keep issues focused and make sure they track something we can actually resolve.

Thanks.

[mousetraps]

@purell @mjbvz @kant2002

Created a new issue to track here: #823

[erakis]

@mousetraps thank you so much. I had no time yesterday. The title you have chosen is more interesting than I thought to use. Especially since I do not know what AD7Engine is doing...