Open Hixie opened 4 years ago
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:
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.
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).
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.
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.
This would be awesome to have
In https://github.com/flutter/flutter/pull/48413#issuecomment-573827770 @jacob314 says:
If we control the stack traces, the ideal thing to do would be to make them identical to what the VM generates.