[macOS][m1] App crashes in release mode upon app launch #100348
Assignees
Labels
a: release
Challenges faced when attempting to productionize an app
c: fatal crash
Crashes that terminate the process
engine
flutter/engine repository. See also e: labels.
found in release: 2.13
Found to occur in 2.13
has reproducible steps
The issue has been confirmed reproducible and is ready to work on
P1
High-priority issues at the top of the work list
platform-host-arm
Building on an ARM-based platform
platform-mac
Building on or for macOS specifically
r: fixed
Issue is closed as already fixed in a newer version
Projects
Comments
danagbemava-nc
changed the title
|
The crash is reproducible on the latest master following steps to reproduce in the original post. logsflutter doctor -v |
danagbemava-nc
added
platform-mac
|
/cc @cbracken |
|
Thanks -- taking a look! |
|
Looks like the issue is that despite everything being built as universal binaries, we're incorrectly loading the x64 snapshot when running under arm64 at runtime. Putting together a patch. |
chinmaygarde
added
P2
P1
8 tasks
|
A patch that fixes this issue is out in #100504. |
cbracken
added a commit
to cbracken/flutter
that referenced
this issue
Mar 22, 2022
Previously, flutter#100271 enabled building universal macOS binaries by default, but included a bug causing the arm64 App.framework to be built such that the TEXT section containing the app instructions built by gen_snapshot incorrectly contained x86_64 instructions rather than arm64 instructions. When building macOS (and iOS) apps, Flutter builds them in three components: * The Runner application: built by Xcode * The bundled App.framework: built from assembly code generated by gen_snapshot from the application's Dart sources. * The bundled FlutterMacOS.framework: built as part of the engine build and packaged by copying the distributed binary framework from our artifacts cache. Building App.framework consists of the following steps: * For each architecture, invoke gen_snapshot to generate architecture-specific assembly code, which is then built to object code and linked into an architecture-specific App.framework. * Use the `lipo` tool to generate a universal binary that includes both x86_64 and arm64 architectures. Previously, we were building architecture specific App.framework binaries. However, for all architectures we were (mistakenly) invoking the general `gen_snapshot` tool (which emitted x64 instructions, and which is now deprecated) instead of the architecture-specific `gen_snapshot_x86` and `gen_snapshot_arm64` builds which emit instructions for the correct architecture. This change introduces a small refactoring, which is to split the `getNameForDarwinArch` function into two functions: * `getDartNameForDarwinArch`: the name for the specified architecture as used in the Dart SDK, for example as the suffix of `gen_snapshot`. * `getNameForDarwinArch`: the name for the specified architecture as used in Apple tools, for example as an argument to `lipo`. For consistency, and to match developer expectations on Darwin platforms, this is also the name used in Flutter's build outputs. Issue: flutter#100348
cbracken
added a commit
that referenced
this issue
Mar 22, 2022
Previously, #100271 enabled building universal macOS binaries by default, but included a bug causing the arm64 App.framework to be built such that the TEXT section containing the app instructions built by gen_snapshot incorrectly contained x86_64 instructions rather than arm64 instructions. When building macOS (and iOS) apps, Flutter builds them in three components: * The Runner application: built by Xcode * The bundled App.framework: built from assembly code generated by gen_snapshot from the application's Dart sources. * The bundled FlutterMacOS.framework: built as part of the engine build and packaged by copying the distributed binary framework from our artifacts cache. Building App.framework consists of the following steps: * For each architecture, invoke gen_snapshot to generate architecture-specific assembly code, which is then built to object code and linked into an architecture-specific App.framework. * Use the `lipo` tool to generate a universal binary that includes both x86_64 and arm64 architectures. Previously, we were building architecture specific App.framework binaries. However, for all architectures we were (mistakenly) invoking the general `gen_snapshot` tool (which emitted x64 instructions, and which is now deprecated) instead of the architecture-specific `gen_snapshot_x86` and `gen_snapshot_arm64` builds which emit instructions for the correct architecture. This change introduces a small refactoring, which is to split the `getNameForDarwinArch` function into two functions: * `getDartNameForDarwinArch`: the name for the specified architecture as used in the Dart SDK, for example as the suffix of `gen_snapshot`. * `getNameForDarwinArch`: the name for the specified architecture as used in Apple tools, for example as an argument to `lipo`. For consistency, and to match developer expectations on Darwin platforms, this is also the name used in Flutter's build outputs. Issue: #100348
8 tasks
cbracken
added a commit
to cbracken/flutter
that referenced
this issue
Mar 22, 2022
Adds a test that invokes flutter run in release mode on macOS desktop, waits for successful launch and the flutter command list, then sends the 'q' command to quit the running app. This adds an integration test for flutter#100504. Issue: flutter#100348
danagbemava-nc
added
the
r: fixed
cbracken
added a commit
that referenced
this issue
Mar 22, 2022
Adds a test that invokes flutter run in release mode on macOS desktop, waits for successful launch and the flutter command list, then sends the 'q' command to quit the running app. This adds an integration test for #100504. Issue: #100348 (fix) Issue: #97978 (partial fix) Issue: #97977 (partial fix) Umbrella issue: #60113
cbracken
added a commit
to cbracken/flutter
that referenced
this issue
Mar 22, 2022
In the run_release_test_macos integration test that verifies that a release build of an app can be launched (and quit), xcodebuild from the Xcode install on the macOS bots emits a few info messages about Simulator SDK versions that are irrelevant to the functioning of this test. Ignore these instead of failing the test if they occur. Related: flutter#100526 Issue: flutter#100348 (fix) Issue: flutter#97978 (partial fix) Issue: flutter#97977 (partial fix) Umbrella issue: flutter#60113
8 tasks
cbracken
added a commit
that referenced
this issue
Mar 23, 2022
In the run_release_test_macos integration test that verifies that a release build of an app can be launched (and quit), xcodebuild from the Xcode install on the macOS bots emits a few info messages about Simulator SDK versions that are irrelevant to the functioning of this test. Ignore these instead of failing the test if they occur. Related: #100526 Issue: #100348 (fix) Issue: #97978 (partial fix) Issue: #97977 (partial fix) Umbrella issue: #60113
|
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Since the Flutter macOS Apple Chip support is ready, I went and tried it. However, it doesn't work for me if I build the app for release.
Steps to Reproduce
flutter createflutter build macosbuild/macos/Build/Products/Release/<appname>.appExpected results: The app does not crash
Actual results: The app crashes
Report collected from Console.app
Logs
The text was updated successfully, but these errors were encountered: