debugger truncates strings #15393
Comments
|
Matthias, is the VM debugger interface truncating the strings? cc @devoncarew. |
|
This comment was originally written by @mhausner Yes it is truncating strings and lists and maps, generally any long textual representation of an a dart value. I added this when complaints came in that the debugger crashed when there were large objects in stack traces, e.g. a list with 1M entries. See issue #8024. The debugger/user can inspect large objects in pieces. If you have a better idea how to prevent problems like the one outlined in issue #8024, let me know. |
|
This comment was originally written by @mhausner By the way, this truncation happens in the textual representation of an object that the debugger sends along. The textual value is created using the object's toString() method. There is another bug open that requests the debugger not to call toString on objects unless the user specifically requests it. If I do remove these implicit toString() calls, I can remove the truncation as well. It will then be entirely in the user's control whether they request a textual representation that takes up lots of memory. |
|
This comment was originally written by ovangl...@gmail.com Why does toString need to be called when you first create the textual representation? Surely that work could be deferred until absolutely necessary. 99% of the time the representation will never be viewed, so you avoid the work of constructing the string completely. I mean, there is very little instance information displayed in a stack trace, so why would you need to be generating anything? (commenting with no experience in how debuggers work, so feel free to ignore) |
|
This comment was originally written by ovangle...@gmail.com That sounded kind of stupid, but I meant why can't you pass back an abstract representation who's textual value is computed lazily? |
|
This comment was originally written by @mhausner That can certainly be done. We tried to minimize the number of calls the debugger front-end has to make over the wire. If the debug target is remote, the latency might be an issue if the debugger has to make dozens or hundreds of calls. The solution could be: call toString on basic values like numbers and strings (and truncate the latter if necessary), delay the call to toString for others. |
|
This comment was originally written by @zoechi Maybe you could add a [...] button/link to truncated values where a click invokes a call that returns the value as whole? - just brainstorming, don't ask for an pull request ;-) |
DartBot
added
Type-Defect
area-vm
|
Legacy debugging protocol removed in 6249c2b |
This issue was originally filed by ovang...@gmail.com
What steps will reproduce the problem?
What is the expected output? What do you see instead?
Expected: The full dprint of the object
{Intersection (edge1:0)&(edge2:0)=(0.0, 0.0, NaN), Intersection (edge1:5)&(edge2:5)=(40.0, 40.0, NaN), Intersection (edge1:0)&(edge2:9)=(0.0, 0.0, NaN), Intersection (edge1:1)&(edge3:0)=(20.0, 5.0, NaN), Intersection (edge1:2)&(edge3:0)=(20.0, 5.0, Na
<more intersections follow this>
Observed:
A truncated dprint:
{Intersection (edge1:0)&(edge2:0)=(0.0, 0.0, NaN), Intersection (edge1:5)&(edge2:5)=(40.0, 40.0, NaN), Intersection (edge1:0)&(edge2:9)=(0.0, 0.0, NaN), Intersection (edge1:1)&(edge3:0)=(20.0, 5.0, NaN), Intersection (edge1:2)&(edge3:0)=(20.0, 5.0, N...
Please provide any additional information below.
Due to the length of the output, this information is difficult to inspect manually, but it could be copied out into a separate window and formatted. It can't, however be copied out and pasted if the string is truncated. In some cases (eg. Lists) the instance can be drilled into to find the data you're looking for. In others (eg. Hashsets) there are too many levels to look for each item, and the tree collapses and you have to drill down every time the object you'd like to inspect goes out of scope, (eg. the object was created in a loop).
The only option is to insert a print statement and use the output of that to obtain the information, which might
a) not actually be the information you're looking for
b) Require you to restart the debugger to load the new code (with prints) and proceed back to where you left off.
This is obviously intentional functionality, but I'd like to know why the debugger is allowed to throw away potentially useful debugging information.
The text was updated successfully, but these errors were encountered: