[dart2wasm] Help to deal with minified errors from deployed apps

[mkustermann]

The default of dart2wasm is now -O2, which is sound mode but does perform minification and stripping. When customers run into errors in production they may get errors and stack traces that aren't very useful, such as:

Got error: Instance of 'minified:Class100', stack:
    at wasm://wasm/000159de:wasm-function[189]:0x55e4
    at wasm://wasm/000159de:wasm-function[190]:0x563b
    at wasm://wasm/000159de:wasm-function[121]:0x4153
    at wasm://wasm/000159de:wasm-function[120]:0x40d6
    at app.mjs:111:49

Now the stack trace can be decoded using source maps (see #56232 for remaining items), the <obj.runtimeType>.toString() cannot.

The VM has similar situations with stripping symbolic information (emitting it as DWARF that isn't part of the deployed app) and obfuscating names. It has solved this by

• exposing a NativeRuntime.buildId used to identify the exact deployed app version
• having flutter symbolize to decode stack traces
• writing an obfuscation map allowing users to map obfuscated names back to original names (see here)

We may also want to have some convenience utilities to help users deal with production errors.

[rakudrama]

dart2js has been used in deployment with minification and optimizations like this.

In addition to issues mentioned in #56232, there are two extra pieces of information stored as an extension in the source maps.

• Inlining information so that squeezed-out frames are re-inserted into the symbolically mapped stack. Without this it is very hard to understand the error.
• A minification dictionary, so that text in messages of the form minified:XX can be replaced with the original name. The runtime emits some names as minified and a few with original names (e.g. Type 'double' is not a subtype of type 'minified:aU<String, minified:g7>').

[mkustermann]

Thanks for the info, @rakudrama . Maybe some follow up questions:

• Does dart2js's output contain any build id like information that allows the app at runtime to uniquely identify the version (and e.g. logging build id together with error will allow decoding on server, as the server may store a database of build id and sourcem aps)
• Does Dart or Flutter provide any tools for decoding

I guess the usage of minified:XXX naming convention was done so one can easily identify places in logs where deobfuscation is needed?

[sigmundch]

Does dart2js's output contain any build id like information that allows the app at runtime to uniquely identify the version (and e.g. logging build id together with error will allow decoding on server, as the server may store a database of build id and sourcem aps)

Traditionally we use the deployed URL as the ID. Typically, internal teams encode the buildid into the URL since multiple versions are live at once in production. Internal systems can transform the .js URL to find the corresponding .map URL that can be fetched from a limited access internal host.

We've noticed that it's more common for external users to reuse URLs for their deployed assets over time, which makes the hosted URL not sufficient. I could see build ids as a viable alternative to make this simpler to use and integrate. That said, I wish we provided better guidelines for proper hosting practices. In particular, we've also noticed users run into issues when adopting simple hosting configurations. The issues are typical of lack of version management in roll outs. For example, we've had multiple reports of users accidentally mixing deferred loaded libraries from new builds on clients running old versions of their code.

Does Dart or Flutter provide any tools for decoding

Yes! We have tools, but the integration is a bit custom. I wish we had exposed it as a dart symbolize tool. We currently have two deobfuscation tools, one in Dart available in the Dart SDK repo (https://github.com/dart-lang/sdk/blob/def23ea4c893b03236d9c3c4fb807c7837ae070c/pkg/dart2js_tools/bin/deobfuscate.dart), the other in Java for internal teams to deobfuscate server-side to integrate with internal crash reporting systems.

The deobfuscator can unmangle names, reverse error messages, and split out inlined call frames. The tool assumes dart2js source map extensions, which are enabled by default.

I guess the usage of minified:XXX naming convention was done so one can easily identify places in logs where deobfuscation is needed?

Precisely, you can find more examples in the deobfuscation tool.