Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Commit 0aad61e8 breaks interaction via V8 debugger protocol #1745

Closed
sctb opened this Issue · 16 comments

5 participants

@sctb

When making a backtrace request to the V8 debugger agent while broken inside a stdin 'data' handler (via exception or debugger statement) the debugger agent responds with header that indicates that an excessively large JSON response will follow (> 25MB). This seems to cause node's CPU utilization to become pegged at ~100% and the response is never completed. This issue was not present in 0aad61e's parent.

@sctb

Prefix of the response: https://gist.github.com/1230388

@ry
ry commented

can you please provide a method to reproduce?

cc @indutny

@sctb

I'm using a tool that we're building in Emacs for developing in Node, but I think I'm able to reproduce the issue using the Node debugger (I can't use stdin with the Node debugger, but an HTTP handler seems to behave the same way):

# cat test.js

require('http').createServer(function (req, res) {
    debugger;
}).listen(8000, 'localhost');

# node debug test.js

debug> run
< debugger listening on port 5858
... connecting... ok
break in #<Object>.[anonymous](...), /Users/sctb/Downloads/test.js:1
==> require('http').createServer(function (req, res) {
  2     res.writeHead(200, {'Content-Type': 'text/plain'});
  3     res.end('Hello World\n');
debug> c
break in #<Server>.[anonymous](...), /Users/sctb/Downloads/test.js:4
  2     res.writeHead(200, {'Content-Type': 'text/plain'});
  3     res.end('Hello World\n');
==>     debugger;
  5 }).listen(8000, 'localhost');
  6 
debug> bt

At that point Node's CPU utilization jumps up to 100%.

@sctb

I've opened http://code.google.com/p/v8/issues/detail?id=1705 to get some input from the V8 folks.

@sctb

It looks like the v8 folks are considering the issue of large backtraces a feature request. Is there anything that can be done on the Node side? From what I can see, debugging of Node IO callbacks is completely broken (which to me means debugging a running Node app is broken).

@indutny
Owner

@sctb you can try using node 0.5.x with a new debugger, AFAIK it works here fine. I guess, we need to those port changes from latest debugger to 0.4.x. Requesting backtrace here is not really important for making print thing working.

@ryah what do you think?

@sctb

@indutny In case it wasn't clear, I was using 0.5.7 (or master) in the above steps to reproduce the issue. Are you saying that when you perform these steps you aren't experiencing the same behavior as I am? Where does 'print' come in? I'm trying to get a backtrace for its own sake.

@indutny
Owner

@sctb sorry, looks like I missed your point. I think I may take a look at v8's debuggers and probably fix it, because Feature Requests ain't being processed quickly by v8 team. print come from 0.4.x debugger and it was using bt and it was really slooow. For now just try to use repl and console.trace() - it should work fine with 0.5.x debugger

@ry
ry commented

@indutny We are not back porting the debugger changes to v0.4. That branch is only getting critical fixes now.

@sctb

@indutny Did you happen to check into this on the v8 side?

@gruseom

@indutny I posted http://code.google.com/p/v8/issues/detail?id=1705#c4 to explain why this problem is so troublesome for us. I know you're working on similar things so want to get your take. Seems to me this bug makes it impossible to use the Debugger Protocol with Node. Any time you have the misfortune to request a backtrace when some frame anywhere in the stack contains a large array, the system basically does a DOS attack on you by writing out more JSON than can ever be read, and the only solution is to kill the process. Surely it would be a mistake to try to fix this on the Node side? Node isn't doing anything wrong by using large arrays. On the contrary, it's the debugger's job to work with any well-formed program in the language it targets. My questions: (1) do you agree or what am I missing? (2) what do you see as the best way to fix this?

@gruseom

Just to follow up: the solution is not to use the JSON protocol in the first place but rely on V8's debugger objects instead.

@sctb

As of 0.6.3, the simple test case that I posted above continues causes the issue. The node debugger is still unable to debug a running web server.

@indutny
Owner

@sctb http://codereview.chromium.org/8873053, we're going to backport this to node once it'll get merged.

@indutny indutny referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@indutny indutny referenced this issue from a commit in indutny/node
@indutny indutny [debugger] request backtrace w/o refs, see #1745 1656791
@indutny indutny referenced this issue from a commit in indutny/node
@indutny indutny request backtrace w/o refs, see #1745 7f4c94c
@alexkwolfe alexkwolfe referenced this issue from a commit in alexkwolfe/node
@indutny indutny debugger: Request backtrace w/o refs, see #1745
Fixes #2379
3125c79
@indutny
Owner

should be fixed now, see ^

@indutny indutny closed this
@ericpromislow

I realize this issue is closed, but there seems to be a problem in v8 anyway. Without the inlineRefs flag set to true (!),
I was seeing json response strings containing around 45,000 entries in the refs.properties section with names of
1, 2, 3, ..., 45000 or so. Looks like total garbage.

Anyone know how to search http://codereview.chromium.org for that bug?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.