Nodeclipse / nodeclipse

Nodeclipse-1 : Eclipse plugin for Node.js, PhantomJS development (Nodeclipse core plugin); Maven and Gradle (with Android) plugins
https://nodeclipse.github.io/
158 stars 78 forks source link

Improve debugger for multi-threaded applications #180

Open paulvi opened 9 years ago

paulvi commented 9 years ago

Started as http://nodeclipse.uservoice.com/forums/216804-general/suggestions/4306388-improve-debugger-for-multi-threaded-applications by Andrew and P.

https://github.com/joyent/node/issues/5318 is labeled for Node 0.12 Milestone

p-bakker commented 9 years ago

As asked on UserVoice, here's the info I have on the topic.

I want to debug a node application that uses multiple processes (through cluster). Trying this in Nodeclipse failed however.

First thing that failed was that the node app wouldn't launch properly at all when using the debug-brk options. Once that was disabled (by checking the option "run Node debug without -brk), the app can be started in debug mode, but breakpoints are never hit in the code that runs in a non-master process.

I googled and found this: https://youtrack.jetbrains.com/issue/WEB-1919. This link basically describes that in Node 0.11.x support was added to connect a debugger to forked processes, by automagically assign an incremental debug port to every forked process, while writing the debug port number out to STDERR of the master process, like "Debugger listening on port 58xx".

I see those messages showing up in the console in Nodeclipse as well.

However, Nodeclipse only launches one debug process, by default on port 5858, so it is quite logical that breakpoints aren't hit when the code is executed in another process that uses another debug port.

So, what I think needs to happen is that Nodeclipse monitors the STDERR for the messages "Debugger listening on port 58xx" and then automatically launches debug processes for these ports.

I tried to manually add and launch STANDALONE_V8 debug processes with the portnumbers that node assigns to the child processes and then breakpoints get hit.

So AFAICS it is a matter of listening to the STDERR for the port number messages, automatically launching a STANDALONE_V8 debugger on that port and making sure that these get killed/cleaned up propertly when terminating the main debug process or when one of the forked processes dies.

paulvi commented 9 years ago

Hi Paul. That is great research already.

Logically, every process (of event looper) should have own port.

https://youtrack.jetbrains.com/issue/WEB-1919 says, that since Node 0.11.5 every fork would get own port incrementally from base specified as

node –debug-brk=50093 limsSrv.js debugger listening on port 50093 debugger listening on port 50094 debugger listening on port 50095

https://github.com/joyent/node/commit/43ec1b1c2e77d21c7571acd39860b9783aaf5175

tagged as v0.11.14, Fixes joyent/node#5318

Implement support for debugging cluster workers. Each worker process is assigned a new debug port in an increasing sequence.

I.e. when master process uses port 5858, then worker 1 uses port 5859, worker 2 uses port 5860, and so on.

Introduce new command-line parameter '--debug-port=' which sets debug_port but does not start debugger. This option works for all node processes, it is not specific to cluster workers.

For Node users before 0.11.5 ever forked process should get debug port manually

I guess, using --debug=58xx (without -brk)

@p-bakker Is that right?

Now, back to Nodeclipse, I would try to first launch Debug session for master with Nodeclipse, then follow https://github.com/joyent/node/wiki/Using-Eclipse-as-Node-Applications-Debugger old way to set up Launch configurations like for remote debugging. Note that Nodeclipse already comes with modified chromedevtools 0.3.9 (skip Installation section)

I expect it should work for several debug session at the same time, though I never tried.

Currently this is not on my list to go far with this, but I will collaborate. Please share Node.js script sample that we can use to try.

paulvi commented 9 years ago

@p-bakker Please keep this thread updated

p-bakker commented 9 years ago

Still looking into this one, unfortunately wasn't able to spend much time on it. I'll report back later this week