New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve formatting of VM stack traces #13095
Comments
Generally, I agree with Natalie. The VM stack traces are so hard to read that dart2js also includes code for parsing them (I assume this code was copied from the stack trace package). It is almost impossible to write a Dart library which can relativize stack traces again, as you have to include both dart:io and dart:html to get access to either the current directory or window.location.href. However, one solution that Natalie came up with is to use mirrors. Unfortunately, this means that all unittest tests now import dart:mirrors which is causing a number of problems for the dart2js team. On thing in particular, is that it significantly reduces the test coverage of type inference which is extremely important to achieve performant and compact JavaScript output. However, the stack traces are so hard to read that it almost makes it worth it. |
FWIW, dart2js has been relativizing filenames from the beginning and we have never received any complaints from our users that it was confusing. |
This is definitely not stale—the stack traces are in the same format as they were when this was opened. |
It is stale from my perspective. We give the full information to developers and if you are not happy with the format then there is a way to drop it. Dropping information a-priori makes it impossible for it to be reconstituted. There is also no work planned. Reclosing. |
The Dart standard requires StackTrace.toString() to report function activations exactly: no omitted frames (e.g., from inlining), no synthetic frames, no obfuscation, and precise source locations. The base stack traces should not be lossy. |
VM stack traces are currently very difficult to read. Here's an example stack frame:
#0 main.<anonymous closure> (file:///home/nweiz/goog/dart/dart/test.dart:29:3)
Here are some issues with it:
* The initial number provides no useful information to the reader.
Here's an example of how the stack_trace package's pretty printer addresses these issues:
test.dart 29:3 main.<fn>
test.dart 29:24 main
The URIs are made relative and printed as paths if they refer to files on disk. "<fn>" is used in place of "<anonymous closure>". The function names are aligned to make them easier to read.
The text was updated successfully, but these errors were encountered: