Native crash peak on Samsung devices

Question

In the last month I saw a strong peak of native crashes on Google Play Console and they are coming from Samsung devices at 98% mostly Android 10 (90%) and secondarily Android 9 (10%). More than the half of cases are about Samsung S9 devices, while the rest is about a pretty recent device models (Samsung s10+, Note9, etc).

There is the stacktrace:

  #00  pc 0000000000083360  /apex/com.android.runtime/lib64/bionic/libc.so (abort+176)
  #01  pc 0000000000008a74  /system/lib64/liblog.so (__android_log_assert+324)
  #02  pc 00000000003fb0dc  /system/lib64/libhwui.so (android::uirenderer::renderthread::EglManager::swapBuffers(android::uirenderer::renderthread::Frame const&, SkRect const&)+276)
  #03  pc 00000000003fae4c  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::SkiaOpenGLPipeline::swapBuffers(android::uirenderer::renderthread::Frame const&, bool, SkRect const&, android::uirenderer::FrameInfo*, bool*)+92)
  #04  pc 0000000000407c8c  /system/lib64/libhwui.so (android::uirenderer::renderthread::CanvasContext::draw()+716)
  #05  pc 0000000000406d38  /system/lib64/libhwui.so (_ZNSt3__110__function6__funcIZN7android10uirenderer12renderthread13DrawFrameTask11postAndWaitEvE3$_0NS_9allocatorIS6_EEFvvEEclEv$c303f2d2360db58ed70a2d0ac7ed911b+216)
  #06  pc 0000000000417a44  /system/lib64/libhwui.so (android::uirenderer::WorkQueue::process()+228)
  #07  pc 0000000000417770  /system/lib64/libhwui.so (android::uirenderer::renderthread::RenderThread::threadLoop()+80)
  #08  pc 00000000000137a4  /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+284)
  #09  pc 00000000000e3b14  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+36)
  #10  pc 0000000000085330  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)

~~In addition, also another issue appeared on Samsung devices only and Android 10 only (device model distribution seems pretty random):~~ this was solved without any particular action taken

#00  pc 0000000002cfeadc  /data/app/com.google.android.webview-8w0eiuwFhdVaEviNzD1U7g==/base.apk!libmonochrome.so (offset 0x15b000)

I have no clue on what is causing the issue, but I also attach my build.gradle file dependencies because these problems are usually linked to Google libraries.

Did anyone see the same issue?

UPDATE Regarding the first issue, one of the major changes I applied to the app activity in which crashes happen, is about the newer Android View Binding. Since the crash seems to be related to UI, maybe this is the case. Does anyone use View Binding as well?

UPDATE 2 It looks like that switching to the old findViewById (just in the Activity that was active at the time of the crash) instead of using View Binding made the problem disappear. For the moment I'm testing it on a small pool of beta testers but at this time I should have already seen some crash report. I will keep this post updated.

UPDATE 3 ─ 2022 With the latest updates of Android 11, some things have changed, especially this. I don't know whether it was because I switched to API 31 or because I uploaded again Crashlytics symbols, but now I see a lot of new crash reports in Google Play console:

  #00  pc 0000000000053350  /apex/com.android.runtime/lib64/bionic/libc.so (fdsan_error(char const*, ...)+588)
  #00  pc 000000000005304c  /apex/com.android.runtime/lib64/bionic/libc.so (android_fdsan_close_with_tag+736)
  #00  pc 0000000000053884  /apex/com.android.runtime/lib64/bionic/libc.so (close+16)
  #00  pc 000000000000371c  /system/lib64/libTcpOptimizer.mobiledata.samsung.so (close+220)
  #00  pc 00000000001e7c24  /vendor/lib64/libgsl.so (!!!0000!6a7f7ec785028d96437db04399d932!4e552d6!+28)
  #00  pc 00000000000bb5f8  /vendor/lib64/libgsl.so (gsl_syncobj_destroy+152)
  #00  pc 000000000025d538  /vendor/lib64/egl/libGLESv2_adreno.so (!!!0000!10f39af3d5dda97a64124dee6a3783!4e552d6!+456)
  #00  pc 0000000000244ff8  /vendor/lib64/egl/libGLESv2_adreno.so (!!!0000!04fe7c7713a0660472688458ecb7a2!4e552d6!+144)
  #00  pc 000000000002b928  /system/lib64/libEGL.so (android::eglSwapBuffersWithDamageKHRImpl(void*, void*, int*, int)+776)
  #00  pc 0000000000027ea4  /system/lib64/libEGL.so (eglSwapBuffersWithDamageKHR+72)
  #00  pc 00000000003b0724  /system/lib64/libhwui.so (android::uirenderer::renderthread::EglManager::swapBuffers(android::uirenderer::renderthread::Frame const&, SkRect const&)+176)
  #00  pc 00000000003a3e30  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::SkiaOpenGLPipeline::swapBuffers(android::uirenderer::renderthread::Frame const&, bool, SkRect const&, android::uirenderer::FrameInfo*, bool*)+92)
  #00  pc 00000000003ac81c  /system/lib64/libhwui.so (android::uirenderer::renderthread::CanvasContext::draw()+1196)
  #00  pc 00000000003ae9e4  /system/lib64/libhwui.so (_ZNSt3__110__function6__funcIZN7android10uirenderer12renderthread13DrawFrameTask11postAndWaitEvE3$_0NS_9allocatorIS6_EEFvvEEclEv$c303f2d2360db58ed70a2d0ac7ed911b+524)
  #00  pc 000000000039cefc  /system/lib64/libhwui.so (android::uirenderer::WorkQueue::process()+208)
  #00  pc 00000000003bf0ec  /system/lib64/libhwui.so (android::uirenderer::renderthread::RenderThread::threadLoop()+88)
  #00  pc 000000000001553c  /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+320)
  #00  pc 0000000000014db0  /system/lib64/libutils.so (thread_data_t::trampoline(thread_data_t const*)+408)
  #00  pc 00000000000b6234  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+64)
  #00  pc 0000000000050e64  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)

This seems of course correlated to both the fdsan problem linked above and obscure abort stacktraces I'm seeing since two years ago. So I started digging into my code, looking for any fd-related bug and I came out with the following:

BUG #1: Found a bug in the code where I never closed a file descriptor after having passed it to [MediaExtractor].setDataSource(FileDescriptor), because I thought [MediaExtractor].release(). I was wrong.

BUG #2: Found another subtle bug in JNI code where I'm receiving a file descriptor and I use it to open a stream with fdopen() and then I close it with fclose() when finished. This whole stream thing is made inside a third-party library and I wasn't aware of that ─ or I didn't really care about ─ and I was also calling close() over the same already-closed file descriptor. This lead to the so called double-close bug and guess what? fdsan is responsible for detecting this kind of bug and then abort. Before Android 11, fdsan behavior was to just output a silent warning, but then default settings changed to a fatal abort signal. This could not be a coincidence...?

I sent out a version of the app with the above fixes to beta testers. Looking forward to post some positive results.

user_7583812 · Answer

Even I've experienced this crash in some of the ads in the app. Even you would be able to reproduce the webview crash by calling webview.loadUrl("chrome://crash"), this should crash your webview and you would be able to reproduce the scenario.

The only way to supress these crashes is to override onRenderProcessGone in webview client and handle the crash by yourself in this case Ads SDK have to handle as the webview is implemented by them.

Ref: https://github.com/mopub/mopub-android-sdk/issues/312

user_1026605 · Answer

I'm experiencing the same as the 2nd issue (libmonochrome.so) and this is caused by the webview crashing. This is caused by a corrupted/malicious ad. Unfortunately unless Google adresses the issue this is impossible to fix...

user_1950812 · Answer

Two years have passed since I posted the question ─ 2.5 years since the problem first appeared ─ and now it seems I've found the root cause.

The obscure stacktraces I was seeing are a bit misleading, but this is indicative of the underlaying problem which is related to file descriptors, in fact the problem first came out when I implemented JNI code that uses FDs received from the Java side.

The solution of the problem was ensuring I was not double-closing the file descriptors, so I do the following steps:

On the Java side, detach the file descriptor from the ParcelFileDescriptor object. Now it's up to your JNI code to close the file descriptor, so you don't have to call ParcelFileDescriptor.close() anymore!
Open a stream over the file descriptor using fdopen() on JNI side and perform operations on the file
Call fclose() over the file descriptor when finished
That's all, no other calls to close() need to be done

In the end, double check ─ but don't double close :') ─ how you manage file descriptors, especially if you implemented some native code in your application.

Native crash peak on Samsung devices

3 Answers