debugger: overview and improve

[bmeck]

As discussed on IRC the Node debugger could use some care to improve user experience this issue will be used to aggregate goals and discuss improvement vs. refactor. More can be added to the list as needed.

Features:

• [x] ability to not listen on a port, but rather a fd
• [x] blackboxing (in particular built: in modules)
• [x] exposing require for bootstrapping (req. by @bajtos for node-inspector)
• [x] break on tick
• [x] break when tick is queued
• [x] break on require (evaluation phase)
• [x] source maps
• [ ] child debugging (isolate / child / cluster)
  • this should propagate up the process tree ideally, and not require the use of sockets (but be able to for things like http://strongloop.com/strongblog/whats-new-nodejs-v0-12-debugging-clusters/ )
• [x] gdb syntax
• [x] default mode is non repl
• [x] way to insert callback at breakpoint
• [x] expose heap profiler (maybe just for dumping to disk?)
• [x] expose cpu profiler
• [ ] features in devtools async errors http://www.html5rocks.com/en/tutorials/developertools/async-call-stack/
• [x] JS API to extend the debugging protocol / better integrate with 3rd party tools.
• [ ] Propagate breakpoints when swapping source files (req. by @Slava for meteor)
• [x] Custom pretty printer hooks
• [ ] Reverse debugging (would need v8 snapshot/restoration [performance will be terrible])

[indutny]

Could you please add gdb-compatible syntax here?

[indutny]

And making default mode non-repl.

[bmeck]

All the resources/research has been gathered, implementation starting a dirty prototype at https://github.com/bmeck/node/tree/debugger-api , we will be using a separate Isolate / thread for JS debugger extension.

[3y3]

Hello @bmeck, @indutny , I inspect the issue, that related with debugger and I hope you can help me: My current target - create node native module, what includes v8::internal API. Reason - I need v8::internal::Isolate::Current()->debug()->debug_context(); Unfortunately, then I try to #include "../src/v8.h", I have a lot of errors. Are you know any projects that uses v8::internal API? Or maybe you have some examples?

[trevnorris]

@3y3 Sorry. It's marked v8::internal for a reason. The issues you'd run into trying to keep up with V8's internal changes could cause psychological damage.

But if there's functionality you want out of V8 then I'd suggest posting it here: https://groups.google.com/forum/#!forum/v8-users

[bmeck]

@3y3 what are you trying to do w/ the debug context? There are probably other ways to approach your goal.

[3y3]

@trevnorris , @bmeck , thank you for responses. I try to redefine DebugCommandProcessor.prototype.processDebugRequest function, part of v8/src/debug-debugger.js (I work on some pr for node-inspector - support Profiler, HeapProfiler, Console Tracing). Profiler and Heap profiler works fine on 0.10 and 0.11 but only if application not paused (because I use tcp socket for communication between app and node-inspector). I want to create API for extending debugger protocol (compatible with 0.10). After some days of researches in v8 sources I chose this way to solve problem. My final target - add console, profiler and heapprofiler events to v8 debugger protocol.

[bmeck]

The proper way to extend the debugger protocol is to use v8::Debug using SetDebugEventListener & SetMessageHandler. Most likely the course of this issue is to move off the default debugger agent in order to avoid the problems of running in the same Isolate, so be wary of investing too much into it. After 0.12 lands this issue will start to pick up.

[3y3]

If you are interested, I have a partial win in my research. Thanks to your comments I finished to trying use internal API and I found the way to do that I want with help of common API. I created a library v8-debug, that provide simple API for extending current v8 debugger protocol from node process.

[3y3]

7886, #7883 will be important for this issue:

7883 - application crashes if we try to inspect global.process 7886 - add v8debug to global scope if node started with --debug flag. Now v8debug will be added only if exists --debug-brk. v8debug object is all that we need to extent debugger API

[bmeck]

@3y3 we need to be very carful about v8debug, since it looks like we are going to move the debugging agent to a different isolate. right now it is a somewhat hidden api, I am unsure about how much this api is used outside of node-inspector

[3y3]

@bmeck , by dirty hacking way I use big part of v8debug now in node-inspector. I use it to implement Profiler and Heap Profiler full compatible with 0.10 (work is finished and waits @bajtos review) (All that I need for this - redefining requests router function - and I writed this in small library v8-debug). I have in plans to implement console tracing and async callstack with his help and I can't imagine how to implement async callstack without v8debug API. In current situation I'm discouraged by one of two facts 'Node provides access to v8debug API' or 'Node provides access to v8debug API not in all debugging time' (works with --debug-brk but not with --debug). I'm not propose to provide direct access to v8debug from common node process, but debugging process it needs. I see that more of features was checked, are you implemented it somewhere?

[bmeck]

@3y3 checked features have been prototyped on my local machine, but all the various things are not combined until I know which version of v8 0.12 will end up as. There are a few gists lying about that I could dig up but I am not committing to anything until I have a stable base to work on. We could be developing on 0.11.x since that has v8 with the newer features that will be needed for some of these features, but I would rather wait and discuss spec / needs before doing a full implementation.

[bnoordhuis]

Most likely the course of this issue is to move off the default debugger agent in order to avoid the problems of running in the same Isolate

FWIW, the built-in debug agent is gone in V8 3.27. I started work on a new agent so we can upgrade to 3.27 but it's pretty tedious work (not really complicated, just tedious.) I keep getting distracted by web comics.

[pmuellr]

I would also be interested in looking at being able to connect to the debugger with a WebSocket. Some PaaS's only allow HTTP traffic across their exposed application ports, and thus can't handle the v8 debug protocol proper.

I'm interested enough I'd be willing to contribute this code, if there's interest. :-)

[rlidwka]

Some PaaS's only allow HTTP traffic

Don't use PaaS then. :)

When you use node, you usually want to control everything. PaaS's are just too limiting. Also, vendor locks. Why not buy VPS instead? They're cheap nowadays.

And it's certainly not a good reason to change debugger protocol.

[bmeck]

@pmuellr sending the payloads over a generic stream would be great. especially since the debugger protocol does have clear message sizes.

Do you have any ideas for how to get around the problem of a blocked event loop on the PaaS though? We can't accept a websocket request if the event loop is already blocked the way things stand. Either way, I think having a way to attach a debugger to a uv_stream would be great. We just need to be sure that the stream handles all transformation outside of node's isolate.

[pmuellr]

I think I have some homework to do :-) Been a while since I've looked into the murky world of "what happens when things are blocked", and even then, it wasn't with node, but but chrome.

[jasnell]

@bmeck ... do we need to keep this one open?

[bmeck]

close it.

On Wed, Jun 3, 2015 at 12:46 PM, James M Snell notifications@github.com wrote:

@bmeck https://github.com/bmeck ... do we need to keep this one open?

— Reply to this email directly or view it on GitHub https://github.com/joyent/node/issues/7473#issuecomment-108543424.