Make Web Dart stack traces identical to VM stack traces

[Hixie]

In https://github.com/flutter/flutter/pull/48413#issuecomment-573827770 @jacob314 says:

We fully control how Dart displays stack traces on the web (for example: it isn't depending on the browser sourcemap implementation) so if something needs to be changed on the web to provide a more uniform experience we can change it.

If we control the stack traces, the ideal thing to do would be to make them identical to what the VM generates.

[sigmundch]

I'm happy to support having VM and ddc translated stack traces look as close as it is possible (and we need a bit of research to make sure it's possible to make them identical).

My concern right now is how it is implemented today. In ddc, we are using a lot of machinery to translate stack traces in the client (e.g. using source-maps and a bit more rewrite). I have concerns on the cost of that machinery (especially for load time and refresh latency) and worry that to make them identical we add more tax. We need to investigate the tradeoffs of continuing with this approach or whether it is worth moving the translation to tools on the side to achieve the same goal. Overall, I like the idea of making them identical when using common tools in our ecosystem (e.g. flutter devtools), but I am not convinced to making them identical in the browser console when running out of the box.

@Hixie - a couple questions for you:

• is this for debugging or to make it possible to process stack traces in the client code directly? (e.g. try-catch and process the stack trace on the catch block)
• If the latter, would it be possible to achieve the same result if the stack trace can be post-process asynchronously, so we can defer loading all the data needed for the translation?

[jacob314]

As far as I know, the use cases in Flutter would be equally well served by an async stackTraceFrames method in the DartVM that returns identical hopefully structured output for DDC and the VM. As you said, that would be much cheaper to implement in DDC as it would eliminate the need to load source maps before launching the Dart application.

[Hixie]

This is only something I care about in debug mode; in release mode it doesn't matter and we should totally optimize for speed.

The use case is for machine-processing of stack traces when debugging, to make debugging easier. (For example, Flutter tries to filter out stack frames it knows are not interesting.)

I would be perfectly happy with an on-demand structured mechanism (not sure if literally async would work, i'm hesitant to allow other code to run while this is pending, lest it make things worse before we've had time to report the first problem).

[vsmenon]

We will need a level of asynchrony to do this well on the web. In our debugging tools, this isn't a problem - i.e., the browser UI thread can be stopped at a breakpoint while the debugger thread maps asynchronously.

But something like:

try {
  ...
} catch (e, st) {
  printStackSomewhere(st);
  ...
}

would become something like:

try {
  ...
} catch (e, st) {
  deobfuscate(st).then(printStackSomewhere);
  ...
}

Our customers have often asked for better debugging in prod / profile mode support, and this should work better there as well.

[woprandi]

If I understand correctly, we cannot have dart stack traces on browser console. That would help to have app easier to debug especially on production. I'm a bit worried to not see any activity for a while.

[Apidcloud]

This would be awesome to have