Breaking change: switch PRODUCT builds to use DWARF stack traces by default

[mraleph]

Proposed change

We would like to switch PRODUCT variant of the Dart Native Runtime to use DWARF stack traces (aka non-symbolic stack traces) mode by default. Currently this option is opt-in and is exposed as --split-debug-info in flutter tooling.

Benefits of change

Switching to DWARF stack traces shrinks AOT snapshot by allowing the compiler to drop objects representing program structure which is only used for formatting symbolic stack traces. Information is either fully discarded or converted into a native debugging format (DWARF), which then can be used by native tooling to symbolise stack traces from an AOT compiled Dart application.

Removing these program structure objects shrinks both snapshot and baseline memory footprint of an AOT compiled Dart app by 10-20%.

Enabling --split-debug-info is currently recommended by Flutter's own documentation if users are seeking to reduce the size (see https://docs.flutter.dev/perf/app-size#reducing-app-size)

This is also the mode which we recommend by default to any application that is concerned by its download size and memory footprint.

Affected code

Any code that expects specific symbolic stack trace format will be affected, though such code should probably be considered unportable already as StackTrace.toString is not specified.

Users will see non-symbolic stack traces on errors and would need to symbolize them manually, unless they are already using third party crash reporting services which understand these stacks.

Users need to be aware that they will need to preserve debug information produced by the build process if they wish to symbolize release stacks.

Dependencies and timeline for the change

Flutter tooling is almost ready for this change - it is capable of symbolising non-symbolic stack traces. Most commonly used crash reporting libraries (Crashlytics and Sentry) are either already support the change or will support in the near future. We would like to target early next year for flipping the flag.

• Make sure that Sentry is ready for this change
• Make sure that Crashlytics is ready for this change
• flutter run --release should automatically detect and symbolise DWARF stack traces in the output from the app.
• There should be a way to symbolize AOT compiled CLI apps (dart compile exe), i.e. we should provide dart symbolize command which serves as a counter part of flutter symbolize

[mraleph]

/cc @itsjustkevin to drive approvals

[itsjustkevin]

@vsmenon @Hixie @grouma new breaking change request.

[grouma]

This most likely has no impact to ACX so SGTM. You'll want to loop in @annagrin from a debugging perspective.

[mraleph]

This has no impact on Web and no impact on debuggability of Native side either (as PRODUCT does not support debugging to begin with).

[sigmundch]

@mraleph does this affect tools? For example, snapshots we build for our compiler and analysis tools? If so, would a crash from a compiler built as an aot snapshot be obfuscated and require additional plumbing to diagnose?

[mraleph]

If so, would a crash from a compiler built as an aot snapshot be obfuscated and require additional plumbing to diagnose?

By default - yes. That being said this only changes default, it does not take capability away. You can still set the flag to false when building CLI tools.

We can also choose to select different default for CLI tools - because if think that size / memory savings don't matter there.

[itsjustkevin]

@sigmundch and @mraleph have we come to an agreement on an approach here that feels good?

[sigmundch]

Yes, I'm happy with the resolution - My only preference is that we change our internal build rules to include the flag explicitly to make the transition smoother. That way the internal team can choose how to adopt the flag on a tool-by-tool basis over time.

[itsjustkevin]

@mraleph to move this forward, if you agree with the comment by @sigmundch, can we open an issue tracking the associated work?

CC @athomas

[mraleph]

My recent experience with one internal user is indicating that we might not be completely ready for this yet. So I would like to punt on this for a bit.

[itsjustkevin]

@mraleph do we already have a process that you know of labeling these changes that are on hold for now?

[mraleph]

I will just close this - and the we reopen it when we have a better internal signal.