Skip to content
This repository has been archived by the owner on Apr 22, 2023. It is now read-only.

Commit 0aad61e8 breaks interaction via V8 debugger protocol #1745

Closed
sctb opened this issue Sep 20, 2011 · 16 comments
Closed

Commit 0aad61e8 breaks interaction via V8 debugger protocol #1745

sctb opened this issue Sep 20, 2011 · 16 comments
Labels

Comments

@sctb
Copy link

sctb commented Sep 20, 2011

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
Copy link
Author

sctb commented Sep 20, 2011

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

@ry
Copy link

ry commented Sep 20, 2011

can you please provide a method to reproduce?

cc @indutny

@sctb
Copy link
Author

sctb commented Sep 20, 2011

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
Copy link
Author

sctb commented Sep 20, 2011

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

@sctb
Copy link
Author

sctb commented Sep 28, 2011

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
Copy link
Member

indutny commented Sep 29, 2011

@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
Copy link
Author

sctb commented Sep 29, 2011

@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
Copy link
Member

indutny commented Sep 29, 2011

@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
Copy link

ry commented Sep 29, 2011

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

@sctb
Copy link
Author

sctb commented Oct 13, 2011

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

@gruseom
Copy link

gruseom commented Oct 14, 2011

@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
Copy link

gruseom commented Oct 28, 2011

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
Copy link
Author

sctb commented Nov 28, 2011

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
Copy link
Member

indutny commented Dec 9, 2011

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

indutny added a commit to indutny/node that referenced this issue Dec 17, 2011
ry pushed a commit that referenced this issue Dec 19, 2011
indutny added a commit to indutny/node that referenced this issue Dec 19, 2011
ry pushed a commit that referenced this issue Dec 19, 2011
alexkwolfe pushed a commit to alexkwolfe/node that referenced this issue Dec 23, 2011
@indutny
Copy link
Member

indutny commented Jan 16, 2012

should be fixed now, see ^

@indutny indutny closed this as completed Jan 16, 2012
@ericpromislow
Copy link

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 subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants