Sigsegv crash after upgrading to 1.4.18

Steps to Reproduce

After upgrading from Flutter v 1.3.14 to 1.4.18 our app starts crashing on specific devices.

Devices affected: Google Pixel and Samsung Galaxy s10

Exact reproduction steps are quite hard because unfortunately it looks like it is happening randomly. We also tried flutter latest beta and it happens there as well.

Issue happens in both debug builds as well as in release builds.

Logs

2019-04-19 08:59:49.904 18195-18195/? A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x65756575716e4d in tid 18195 (my.app), pid 18195 (my.app)
2019-04-19 08:59:50.033 18293-18293/? I/crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
2019-04-19 08:59:50.033 811-811/? I//system/bin/tombstoned: received crash request for pid 18195
2019-04-19 08:59:50.034 18293-18293/? I/crash_dump64: performing dump of process 18195 (target tid = 18195)
2019-04-19 08:59:50.047 18293-18293/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2019-04-19 08:59:50.047 18293-18293/? A/DEBUG: Build fingerprint: 'google/sailfish/sailfish:9/PQ2A.190405.003/5310204:user/release-keys'
2019-04-19 08:59:50.047 18293-18293/? A/DEBUG: Revision: '0'
2019-04-19 08:59:50.047 18293-18293/? A/DEBUG: ABI: 'arm64'
2019-04-19 08:59:50.047 18293-18293/? A/DEBUG: pid: 18195, tid: 18195, name: my.app  >>> com.my.app <<<
2019-04-19 08:59:50.047 18293-18293/? A/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x65756575716e4d
2019-04-19 08:59:50.047 18293-18293/? A/DEBUG:     x0  00000070b8106248  x1  0000007fc27b543c  x2  0000000012f00000  x3  0000007fc27b5320
2019-04-19 08:59:50.047 18293-18293/? A/DEBUG:     x4  00000000000000d5  x5  00000000000025bc  x6  00000000341555ac  x7  000000000032aa34
2019-04-19 08:59:50.047 18293-18293/? A/DEBUG:     x8  0000000000000004  x9  0000000000000004  x10 0000000065666552  x11 16e1187b7c137c7b
2019-04-19 08:59:50.047 18293-18293/? A/DEBUG:     x12 0000000000000000  x13 ffffffffffffffb0  x14 0000000000000070  x15 0000000000000000
2019-04-19 08:59:50.047 18293-18293/? A/DEBUG:     x16 00000070aa598368  x17 0000007143285758  x18 000000000000797f  x19 00000070b8106248
2019-04-19 08:59:50.047 18293-18293/? A/DEBUG:     x20 4665756575716e45  x21 0000000000000002  x22 0000000000000005  x23 0000000000000b9c
2019-04-19 08:59:50.048 18293-18293/? A/DEBUG:     x24 0000000000000b9c  x25 0000000000000050  x26 00000070a84d5440  x27 00000070b80f4c70
2019-04-19 08:59:50.048 18293-18293/? A/DEBUG:     x28 0000000000000001  x29 00000070b80f4c70
2019-04-19 08:59:50.048 18293-18293/? A/DEBUG:     sp  0000007fc27b5380  lr  00000070a9fe668c  pc  00000070a9fe6898
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG: backtrace:
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #00 pc 0000000000261898  /data/app/com.my.app-XqT2a59lbnBaPBLJcUTnnQ==/lib/arm64/libflutter.so (offset 0x250000)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #01 pc 0000000000261688  /data/app/com.my.app-XqT2a59lbnBaPBLJcUTnnQ==/lib/arm64/libflutter.so (offset 0x250000)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #02 pc 0000000000298f5c  /data/app/com.my.app-XqT2a59lbnBaPBLJcUTnnQ==/lib/arm64/libflutter.so (offset 0x250000)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #03 pc 000000000026ee44  /data/app/com.my.app-XqT2a59lbnBaPBLJcUTnnQ==/lib/arm64/libflutter.so (offset 0x250000)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #04 pc 000000000027093c  /data/app/com.my.app-XqT2a59lbnBaPBLJcUTnnQ==/lib/arm64/libflutter.so (offset 0x250000)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #05 pc 000000000001438c  /system/lib64/libutils.so (android::Looper::pollInner(int)+868)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #06 pc 0000000000013f8c  /system/lib64/libutils.so (android::Looper::pollOnce(int, int*, int*, void**)+60)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #07 pc 0000000000120684  /system/lib64/libandroid_runtime.so (android::android_os_MessageQueue_nativePollOnce(_JNIEnv*, _jobject*, long, int)+44)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #08 pc 00000000003e1fec  /system/framework/arm64/boot-framework.oat (offset 0x3cd000) (android.media.MediaExtractor.seekTo [DEDUPED]+140)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #09 pc 0000000000aafd60  /system/framework/arm64/boot-framework.oat (offset 0x3cd000) (android.os.MessageQueue.next+240)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #10 pc 0000000000aad6ec  /system/framework/arm64/boot-framework.oat (offset 0x3cd000) (android.os.Looper.loop+636)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #11 pc 000000000087a788  /system/framework/arm64/boot-framework.oat (offset 0x3cd000) (android.app.ActivityThread.main+664)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #12 pc 000000000056064c  /system/lib64/libart.so (art_quick_invoke_static_stub+604)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #13 pc 00000000000cf6d8  /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+232)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #14 pc 00000000004661e4  /system/lib64/libart.so (art::(anonymous namespace)::InvokeWithArgArray(art::ScopedObjectAccessAlreadyRunnable const&, art::ArtMethod*, art::(anonymous namespace)::ArgArray*, art::JValue*, char const*)+104)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #15 pc 0000000000467d38  /system/lib64/libart.so (art::InvokeMethod(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jobject*, _jobject*, unsigned long)+1440)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #16 pc 00000000003f6728  /system/lib64/libart.so (art::Method_invoke(_JNIEnv*, _jobject*, _jobject*, _jobjectArray*)+52)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #17 pc 000000000011e6d4  /system/framework/arm64/boot.oat (offset 0x114000) (java.lang.Class.getDeclaredMethodInternal [DEDUPED]+180)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #18 pc 0000000000be3e38  /system/framework/arm64/boot-framework.oat (offset 0x3cd000) (com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run+136)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #19 pc 0000000000beb020  /system/framework/arm64/boot-framework.oat (offset 0x3cd000) (com.android.internal.os.ZygoteInit.main+3088)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #20 pc 000000000056064c  /system/lib64/libart.so (art_quick_invoke_static_stub+604)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #21 pc 00000000000cf6d8  /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+232)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #22 pc 00000000004661e4  /system/lib64/libart.so (art::(anonymous namespace)::InvokeWithArgArray(art::ScopedObjectAccessAlreadyRunnable const&, art::ArtMethod*, art::(anonymous namespace)::ArgArray*, art::JValue*, char const*)+104)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #23 pc 0000000000465de8  /system/lib64/libart.so (art::InvokeWithVarArgs(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, std::__va_list)+424)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #24 pc 0000000000368494  /system/lib64/libart.so (art::JNI::CallStaticVoidMethodV(_JNIEnv*, _jclass*, _jmethodID*, std::__va_list)+652)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #25 pc 00000000000b1dac  /system/lib64/libandroid_runtime.so (_JNIEnv::CallStaticVoidMethod(_jclass*, _jmethodID*, ...)+136)
2019-04-19 08:59:50.175 18293-18293/? A/DEBUG:     #26 pc 00000000000b4738  /system/lib64/libandroid_runtime.so (android::AndroidRuntime::start(char const*, android::Vector<android::String8> const&, bool)+752)
2019-04-19 08:59:50.176 18293-18293/? A/DEBUG:     #27 pc 000000000000219c  /system/bin/app_process64 (main+1200)
2019-04-19 08:59:50.176 18293-18293/? A/DEBUG:     #28 pc 00000000000b0558  /system/lib64/libc.so (__libc_init+88)

Doctor summary (to see all details, run flutter doctor -v):
✓] Flutter (Channel unknown, v1.4.18, on Mac OS X 10.14.4 18E226, locale en-NL)
    • Flutter version 1.4.18 at /Library/flutter
    • Framework revision 8bea3fb2eb (7 days ago), 2019-04-11 13:11:22 -0700
    • Engine revision 72986c39ea
    • Dart version 2.2.1 (build 2.2.1-dev.3.1 None)

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • ANDROID_HOME = Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1248-b01)
    • All Android licenses accepted.

[✓] iOS toolchain - develop for iOS devices (Xcode 10.2.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 10.2.1, Build version 10E1001
    • ios-deploy 1.9.4
    • CocoaPods version 1.6.1

[✓] Android Studio (version 3.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 34.0.1
    • Dart plugin version 182.5215
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1248-b01)

[✓] IntelliJ IDEA Community Edition (version 2019.1.1)
    • IntelliJ at /Applications/IntelliJ IDEA CE.app
    • Flutter plugin version 34.0.4
    • Dart plugin version 191.6183.88

[✓] VS Code (version 1.28.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 2.15.0

[!] Connected device
    ! No devices available

• No issues found!

How exactly was the APK that generated that stack trace built? Which version of libflutter.so was used, and was it debug, profile, or release?

I tried symbolizing the trace with the ARM64 builds of engine version 72986c39ea3669ef26d4d7d7cd0c44f513fcd117 but the symbols did not resolve.

@jason-simmons

@jason-simmons I updated the stacktrace with the release variant of the engine of revision: 72986c39ea . The apk was generated with following command flutter build apk --release --target-platform=android-arm64

Also the issue seems to occur more frequently when I am calling a lot of methods through methodchannels.

This trace symbolizes to:

third_party/libcxx/include/__hash_table:97
flutter/shell/platform/android/platform_view_android.cc:171
flutter/shell/common/shell.cc:824
flutter/fml/message_loop_impl.cc:140
flutter/fml/platform/android/message_loop_android.cc:92

The crash happens within a deferred task queued from Shell::OnEngineHandlePlatformMessage. This task is posted on the platform thread to handle a message sent from Dart to the Java embedder.

Is there anything unusual about the lifecycle of the FlutterView and Flutter engine in your app? For example, does anything interact with Flutter APIs from a thread other than the platform thread?

The crash implies that the PlatformViewAndroid is in a bad state (possibly deleted) when the deferred task runs. But the task holds a weak pointer to the PlatformViewAndroid and should not proceed if the PlatformViewAndroid was destructed before the task executes.

Thanks for the explanation I was able to find the route cause and applied a fix to the crash. The issue was the following: we have developed a library that executes some process on a different thread than the main thread (because we do not want to block main in this case). The result of the processing is not reported back on the Android main thread but on the same thread as where we do the processing. I couldn't find any documentation that this was wrong so I assumed I could get away with this. Based on your remark and the documentation of https://github.com/flutter/flutter/wiki/The-Engine-architecture I figured out that my implementation has a mistake and we should report back the result of the operation on the Platform Thread (because my lib runs on Android this is the Android main thread).

Is it an idea to add some remarks on the Plugin documentation (https://flutter.dev/docs/development/packages-and-plugins/developing-packages) about this behavior or maybe even better add an assertion that when we report back to the methodchannel on a different thread then the Platform thread?

@matthew-carroll

@matthew-carroll The relevant FlutterJNI methods now have a @UiThread annotation. Should these methods raise an assertion at runtime if they are invoked on a different thread?

@jason-simmons

@jason-simmons we can add an exception if not on the main thread. Do you think we should? If so, should we throw in debug and release, or just in debug?

I'd vote for adding an exception in debug mode.

@matthew-carroll

@matthew-carroll I added this to your plate and put in a plausible-sounding very conservative milestone based on @jason-simmons' comments in the triage meeting; please update the milestone (and assignee) as appropriate. Thanks.

@dnfield

Note: I'm waiting on a resolution to the BuildConfig.DEBUG implementation that @dnfield is working on here: #31928

Once that's in the engine, I'll have a PR that resolves this ticket.

flutter-team-archive/engine#8821 will unblock this

This issue is solved here: flutter-team-archive/engine#8830

Flutter will now force a crash if any FlutterJNI methods marked with @UiThread are invoked off the main thread.

2c9e37c Cause crash in FlutterJNI if invoked on non-main thread (flut…

Roll engine 8811392..2c9e37c (4 commits) (#32069)

It looks like this change caused a regression in the Android Flutterfire transactions implementations; see #32657

The bug is in the plugins implementation and I'll try to fix it there. Once a fix is available, apps that use Firebase transactions on Android will need to upgrade plugins in order to be compatible with versions of Flutter that include this change. We may want to use pubspec.yaml SDK version constraints to enforce this constraint at build time.

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 flutter doctor -v and a minimal reproduction of the issue.

Navigation Menu

Repository navigation

Sigsegv crash after upgrading to 1.4.18 #31263

Steps to Reproduce

Logs

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Sigsegv crash after upgrading to 1.4.18 #31263

Description

Steps to Reproduce

Logs

Activity

jason-simmons commented on Apr 18, 2019

remonh87 commented on Apr 19, 2019

jason-simmons commented on Apr 19, 2019

remonh87 commented on Apr 23, 2019

jason-simmons commented on Apr 23, 2019

matthew-carroll commented on Apr 24, 2019

jason-simmons commented on Apr 24, 2019

Hixie commented on Apr 30, 2019

matthew-carroll commented on May 2, 2019

dnfield commented on May 2, 2019

matthew-carroll commented on May 3, 2019

collinjackson commented on May 14, 2019

github-actions commented on Aug 30, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions