Skip to content
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

Closed
nex3 opened this issue Sep 5, 2013 · 5 comments
Closed

Improve formatting of VM stack traces #13095

nex3 opened this issue Sep 5, 2013 · 5 comments
Labels
area-vm closed-as-intended Closed as the reported issue is expected behavior type-enhancement A request for a change that isn't a bug

Comments

@nex3
Copy link
Member

nex3 commented Sep 5, 2013

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.

  • The phrase "anonymous closure" is very verbose.
  • Using a file URI to identify the file is confusing for users who are used to thinking about their files in terms of paths.
  • Using an absolute URI is unnecessarily verbose and ends up making it harder to tell what file an error occurred in.
  • Attaching the line and column numbers to the URI makes it harder to copy and paste the URI in most Unix terminals.
  • The URIs aren't vertically aligned, making them harder to read.

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.

@peter-ahe-google
Copy link
Contributor

peter-ahe-google commented Sep 5, 2013

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.

@peter-ahe-google
Copy link
Contributor

FWIW, dart2js has been relativizing filenames from the beginning and we have never received any complaints from our users that it was confusing.

@kevmoo kevmoo added type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) and removed priority-unassigned labels Feb 29, 2016
@iposva-google iposva-google added the closed-obsolete Closed as the reported issue is no longer relevant label May 19, 2016
@nex3
Copy link
Member Author

nex3 commented May 19, 2016

This is definitely not stale—the stack traces are in the same format as they were when this was opened.

@nex3 nex3 reopened this May 19, 2016
@nex3 nex3 removed the closed-obsolete Closed as the reported issue is no longer relevant label May 19, 2016
@iposva-google
Copy link
Contributor

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.

@nex3 nex3 reopened this Jun 8, 2016
@zanderso zanderso added type-enhancement A request for a change that isn't a bug and removed type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) labels Jun 13, 2016
@rmacnak-google
Copy link
Contributor

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.

@rmacnak-google rmacnak-google added the closed-as-intended Closed as the reported issue is expected behavior label Jun 28, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-vm closed-as-intended Closed as the reported issue is expected behavior type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

6 participants