WebStorm 6 debugging issues?

Thanks Dan, we will take a look and respond tomorrow morning (we're in GMT+3 timezone),

Kirill

>> But if you try and debug again (without restarting WebStorm) the only breakpoint that gets triggered is one on the very first line of code (all other breakpoints are skipped).
Do you mean start the new debug session (rerun run configuration)?

I noticed the same issues when i have IDEA 12 running in the background too.

I hit this with WebStorm 6 as well.
Using 'debugger;'  in my code does seem to cause a breakpoint though!  Hope that's some help.
(I also get malloc errors once the breakpoint is hit, but I assume that's unrelated)

Yes, once the current debug run stops, and I try and start debugging again (either via the debug button in the top toolbar, or via the rerun button on the debug tab), breakpoints no longer work (other than a breakpoint on line #1 of the main program).

Hi. Me too.

I'm running a webapp, which run over Yeoman.

The app broke only once for me at the breakpoints. Even after restarting it never stopped again, but console logs do printing to the console from the same break area (function scope).

Now I discovered that the Chrome Extension stop working, and I have no idea when and what triggers it, but it happened few times.
After reinstalling the extension, the extension returns to communicate with the IDE.

I am having this problem as well. I've confirmed in both in Webstorm 6 and pycharm 2.6.3 on OSX.

Any word on a fix? I'm getting a little desperate.Why on earth is this marked as possibly fixed?

Hello!

please, check if there are symlinks in your project path - debugger doesn't stop on breakpoints if the project folder is a symlink


Best regards,
Lena

Hi Elena,

I've verified that there are no symlinks in my project path.

And, it's not that breakpoints can't be hit:
- Breakpoints on the first line of the startup file are always hit
- Breakpoints on other lines are hit the first time you run (but never again _until you restart webstorm_)

So, it would seem that WebStorm is not actually sending the breakpoint commands to node all the time.

--> Is there a way to print debug output (either from node or from WebStorm) that shows the exact debug commands being sent to node?

This might help track down the problem.

Please try WS 6.0.2 EAP http://confluence.jetbrains.net/display/WI/WebStorm+6+EAP

This version does not solve the problem
(Elena already had me try that - see http://intellij-support.jetbrains.com/requests/1676 for more info)

Here's an update.

With WS 6.0.2 EAP, node.js remote debugging sessions seem to be working correctly (breakpoints are reliably hit every time you run the app being debugged).  But, node.js debugging sessions running within WebStorm still have the issues I described:
  - A breakpoint on the first line of the starting file always gets hit
  - Breakpoints on any other line only get hit the first time you debug the node.js app.  If you try and rerun webstorm none of these other breakpoints are being hit (until you quit and restart webstorm itself)

I believe I've isolated the cause of the bug.  It appears that node (at least with node v0.6.21) needs some time to finish starting up before it can properly accept debug commands from WebStorm (and maybe WebStorm is sending them differently the first time node is run versus on subsequent runs).

Below is both an (ugly) workaround and a test case that lets me toggle the bug on and off.  Basically the workaround inserts a proxy between node and WebStorm, giving node time to startup before it begins sending the connections from WebStorm through.

Here's the exact steps to workaround the issue:

Install socat if you don't already have it (e.g. "brew install socat").
Create an executable shell script (I put mine in ~/bin/node-ws.sh) containing the following:

#!/bin/sh

ORIG_PORT=`echo $* | sed 's/.*--debug-brk=\([0-9]*\).*/\\1/'`

NEW_PORT=`expr $$ "%" 64000 + 1024`

ARGS=`echo $* | sed "s/--debug-brk=[0-9]*/--debug-brk=$NEW_PORT/"`

node $ARGS &

sleep 1

socat TCP4-LISTEN:$ORIG_PORT,fork,bind=127.0.0.1 TCP:localhost:$NEW_PORT

Hi

I'm experiencing the same issue running version 6.0.2 on Mac OS X, it's there any other solution than using a proxy to node.js?

Regards