Issue 1705 in v8: Debugger protocol: excessively large backtrace response
codesite...@google.com
Owner: ----
New issue 1705 by sc...@skysheet.com: Debugger protocol: excessively large
backtrace response
http://code.google.com/p/v8/issues/detail?id=1705
Using the remote debugging agent and Node.js, I'm seeing backtrace
responses that are so large that the response isn't even fully received
after several minutes of Node process being pegged at 100% CPU. I've
attached a file of a portion of such a response. Is there supposed to be
some way to limit the size of the JSON responses sent by the debugger
protocol?
Attachments:
message.txt 52.0 KB
codesite...@google.com
Comment #1 on issue 1705 by yan...@chromium.org: Debugger protocol:
http://code.google.com/p/v8/issues/detail?id=1705
There is currently no way to limit the response size. But then this begs
the question how a large response should be handled. A JSON response
chopped off at a certain point is only of limited value as it cannot be
parsed reasonably.
Any suggestions on how this case could be handled?
codesite...@google.com
Comment #2 on issue 1705 by sc...@skysheet.com: Debugger protocol:
http://code.google.com/p/v8/issues/detail?id=1705
The debugger agent already has mechanisms by which it reduces response
size, such as omitting refs for nested object properties. Perhaps something
like that but for objects with many properties (such as large arrays) might
help here.
Another possibility is that the 'backtrace' command should not return
complete frame objects, but rather only provide basic information such as
sourceLineText, enclosing function, script, position, etc. The 'frame'
command (or perhaps a new one: 'frames') could be used to obtain more
information about specific frames of interest. Most of the time there's
only a prefix of the top of the stack that represents the user's code that
they care about, and they shouldn't be forced to suffer a slow (or broken)
debugging experience because some low-level library function happened to
have a large buffer allocated as a local variable.
codesite...@google.com
Labels: Type-FeatureRequest
Comment #3 on issue 1705 by yan...@chromium.org: Debugger protocol:
excessively large backtrace response
http://code.google.com/p/v8/issues/detail?id=1705
(No comment was entered for this change.)
codesite...@google.com
Comment #4 on issue 1705 by danielga...@gmail.com: Debugger protocol:
http://code.google.com/p/v8/issues/detail?id=1705
Hi, I must plead the case for this bug. It's not merely a feature request;
on the contrary, it makes the Debugger Protocol unusable. We've built an
Emacs source-level debugging client (along the lines of edebug) for
Node/V8, but until this problem is fixed, we can't use it.
Here's my understanding of the problem. V8 produces JSON describing the
local state of each stack frame in a backtrace. When that local state
includes a large array (or, probably, any object with too many properties),
it doggedly keeps writing it out in JSON, far too much JSON to be handled,
so the process hangs and there is no choice but to kill it and restart the
session.
Such a debugger is unusable. There is no way to know before requesting a
backtrace whether some large object is lurking beneath you in some stack
frame and will blow up and hang the session if you issue the request. (This
is particularly true if you're calling a library whose internals you know
nothing about.) As it stands today, the Debugger Protocol's policy appears
to be "Only use me with code that will never have any large arrays
anywhere." This is an impossible burden for the user, so as things stand
today, not only can we not release our client, we can't even use it
ourselves.
The solution is to do what any remote debugging protocol must do when
describing very large state: provide a description of only some of it (e.g.
for an array, the first n values for reasonable n), plus some indication
that m unprovided values remain. Additionally, one might offer a mechanism
for requesting additional portions of the omitted state; but this is a
nice-to-have, since the user can get at anything they want by evaluating an
appropriate expression in the appropriate frame - that is, they can do so
as long as the system hasn't become completely unresponsive! So,
while "dole out large state in portions on demand" can fairly be described
as a feature request, "don't hang forever" is surely a bug, and surely an
important one.
We really like the Debugger Protocol and are eager to use it. It makes
things possible that are otherwise not possible. We've got this great
debugging client that is about to make my programming life so much easier
that it makes me slobber, so I fervently hope you guys will understand why
this is important and please fix it.
codesite...@google.com
Comment #5 on issue 1705 by danielga...@gmail.com: Debugger protocol:
http://code.google.com/p/v8/issues/detail?id=1705
This is a follow-up to comment 4, in case anyone has this issue in the
future. The solution we found is not to use the Debugger Protocol at all
but simply call into V8's debug object model (i.e., the in-process
debugger) directly. This means reimplementing a subset of the protocol,
since we have to format our own JSON messages to send to the client. But
that isn't too hard to do, and it works. It also has the advantages that
one can send only the information one is going to use on the other side,
and can reduce the number of round trips in certain cases (e.g. if you want
to do a step-out repeatedly until hitting a recognized script).
codesite...@google.com
Comment #6 on issue 1705 by smor...@gmail.com: Debugger protocol:
Hi, we are trying to build a debugger as well and this issue renders the
remote debugging scenario completely unusable. Commenter 2 & 4 both make
reasonable suggestions. Please consider fixing so we don't have to go thru
unnatural gyrations.
thanks.
codesite...@google.com
Comment #7 on issue 1705 by 911....@gmail.com: Debugger protocol:
Hi!
inlineRefs=true helped me:
{..."type":"request","command":"backtrace","arguments":{"inlineRefs":true...}...}
codesite...@google.com
Status: WorkingAsIntended
Comment #8 on issue 1705 by yan...@chromium.org: Debugger protocol:
The JSON protocol is slated for the chopping block. I don't think anybody
should still rely on it.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
codesite...@google.com
Comment #9 on issue 1705 by int...@gmail.com: Debugger protocol:
What is the recommended replacement? The doc page at
https://code.google.com/p/v8/wiki/DebuggerProtocol doesn't seem to be
offering any alternatives.