Native crash of RenderThread with signal 6 (SIGABRT)

Question

Updates!

See below

Situation

We're having a difficult to diagnose issue with our app. When we attempt to use an intent to have the camera app return a picture, we receive a low-level crash situation that we are unsure how to debug. This is occurring on Nexus 5x devices on bother Android 6.0 and Android 7.0.

Here is the stack trace from the monitor:

10-17 11:59:41.208 9925-9925/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 10-17 11:59:41.208 9925-9925/? A/DEBUG: Build fingerprint: 'google/bullhead/bullhead:7.0/NBD90W/3239497:user/release-keys' 10-17 11:59:41.208 9925-9925/? A/DEBUG: Revision: 'rev_1.0' 10-17 11:59:41.208 9925-9925/? A/DEBUG: ABI: 'arm64' 10-17 11:59:41.208 9925-9925/? A/DEBUG: pid: 5791, tid: 6054, name: RenderThread  >>> com.ourapp <<< 10-17 11:59:41.209 9925-9925/? A/DEBUG: signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- 10-17 11:59:41.230 9925-9925/? A/DEBUG: Abort message: 'Leaked 2 GPU objects!' 10-17 11:59:41.230 9925-9925/? A/DEBUG:     x0   0000000000000000  x1   00000000000017a6  x2   0000000000000006  x3   0000000000000008 10-17 11:59:41.230 9925-9925/? A/DEBUG:     x4   00006e6174736e69  x5   0000000000000000  x6   0000007629a9f000  x7   0000000000000000 10-17 11:59:41.230 9925-9925/? A/DEBUG:     x8   0000000000000083  x9   ffffffffffffffdf  x10  0000000000000000  x11  0000000000000001 10-17 11:59:41.230 9925-9925/? A/DEBUG:     x12  0000000000000018  x13  0000000000000000  x14  0000000000000000  x15  000850a8eb6af8af 10-17 11:59:41.231 9925-9925/? A/DEBUG:     x16  000000762948eed0  x17  0000007629438a2c  x18  0000000000000400  x19  00000076093b84f8 10-17 11:59:41.231 9925-9925/? A/DEBUG:     x20  0000000000000006  x21  00000076093b8450  x22  000000000000000b  x23  000000762933c040 10-17 11:59:41.231 9925-9925/? A/DEBUG:     x24  00000000ffffffff  x25  00000075f9d71490  x26  7fffffffffffffff  x27  00000075f2c54060 10-17 11:59:41.231 9925-9925/? A/DEBUG:     x28  0000007625c83238  x29  00000076093b7ae0  x30  0000007629435e58 10-17 11:59:41.231 9925-9925/? A/DEBUG:     sp   00000076093b7ac0  pc   0000007629438a34  pstate 0000000060000000 10-17 11:59:41.237 3715-9157/? E/mm-camera-sensor: port_sensor_handle_aec_update:443miss aec update window, skip 10-17 11:59:41.253 9925-9925/? A/DEBUG: backtrace: 10-17 11:59:41.254 9925-9925/? A/DEBUG:     #00 pc 000000000006ba34  /system/lib64/libc.so (tgkill+8) 10-17 11:59:41.254 9925-9925/? A/DEBUG:     #01 pc 0000000000068e54  /system/lib64/libc.so (pthread_kill+64) 10-17 11:59:41.254 9925-9925/? A/DEBUG:     #02 pc 0000000000023ed8  /system/lib64/libc.so (raise+24) 10-17 11:59:41.254 9925-9925/? A/DEBUG:     #03 pc 000000000001c790  /system/lib64/libc.so (abort+52) 10-17 11:59:41.254 9925-9925/? A/DEBUG:     #04 pc 00000000000107f4  /system/lib64/libcutils.so (__android_log_assert+224) 10-17 11:59:41.254 9925-9925/? A/DEBUG:     #05 pc 0000000000054cc0  /system/lib64/libhwui.so 10-17 11:59:41.254 9925-9925/? A/DEBUG:     #06 pc 00000000000350f8  /system/lib64/libhwui.so 10-17 11:59:41.254 9925-9925/? A/DEBUG:     #07 pc 00000000000328c8  /system/lib64/libhwui.so 10-17 11:59:41.254 9925-9925/? A/DEBUG:     #08 pc 0000000000037348  /system/lib64/libhwui.so 10-17 11:59:41.254 9925-9925/? A/DEBUG:     #09 pc 0000000000038434  /system/lib64/libhwui.so 10-17 11:59:41.254 9925-9925/? A/DEBUG:     #10 pc 0000000000039890  /system/lib64/libhwui.so (_ZN7android10uirenderer12renderthread12RenderThread10threadLoopEv+152) 10-17 11:59:41.254 9925-9925/? A/DEBUG:     #11 pc 0000000000012460  /system/lib64/libutils.so (_ZN7android6Thread11_threadLoopEPv+272) 10-17 11:59:41.254 9925-9925/? A/DEBUG:     #12 pc 000000000009bc4c  /system/lib64/libandroid_runtime.so (_ZN7android14AndroidRuntime15javaThreadShellEPv+116) 10-17 11:59:41.254 9925-9925/? A/DEBUG:     #13 pc 000000000006863c  /system/lib64/libc.so (_ZL15__pthread_startPv+208) 10-17 11:59:41.254 9925-9925/? A/DEBUG:     #14 pc 000000000001d9fc  /system/lib64/libc.so (__start_thread+16) 

We can reliably trigger this when we use an intent to call up the camera app to retrieve a picture with the following code:

Intent intent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE);  if (intent.resolveActivity(fragmentContext.getPackageManager()) == null) {    return; }  try {    File photoFile = FileUtils.createImageFile(fragmentContext);     data.addFileUpload(photoFile.getAbsolutePath());    Uri photoUri = FileProvider.getUriForFile(fragmentContext, OurApplication.FILE_PROVIDER, photoFile);     intent.putExtra(MediaStore.EXTRA_OUTPUT, photoUri);     startActivityForResult(intent, REQUEST_TAKE_PHOTO); } catch (IOException ignored) { } 

As shown, there isn't anything usual here.

Environment

We are able to trigger this on our test devices which are Nexus 5x. One device is Android 6 and the other is Android 7. They both produce similar stack traces (the one shown is from Android 7.0).

Triggering Context

It seems that we are able to trigger this event given either of the following two situations:

1. The Google Maps is loaded in the activity that starts the camera
2. A low memory situation (which we triggered with Chrome loaded with a tab or two of cnn.com)

What we've tried

We've tried to piece-wise remove functionality from the app until we could not longer trigger this crash but we've always been able to trigger it given a low memory situation.

Questions

• Has anyone run in to this before and found a way to solve it?
• Suggestions on how to further debug this issue?
• Any links for hints?

Updates

2016/11/02 - There is an open bug report as noted in the comments. Different device/builds (Nexus 5x, 6P and Pixel with Android 6, 7.0 and 7.1) are reporting the same problem with various different types of situations as well. I'll continue to post updates with more information. The situation has been classified as a defect with priority of small. I would consider staring that bug and raising your concerns there.

2016/12/14 - I'm personally still having this issue even with the various security updates that have been applied. There isn't any more information other than other people reporting the same issues across various devices. Please check out the linked bug report, star and comment there. If I find anything that works, I'll post here!

2017/07/31 - For people that are still experiencing this issue, one user has attempted doing staged roll outs to their user base and removing various features to attempt to diagnose what the issue is. In their situation, by removing com.google.android.gms:play-services-maps:11.0.1, their situation has appeared to have been resolved. Unfortunately, maps are a core component of our applications; thus, this is not acceptable in our situation. In my opinion, this still appears to have to do with consumption of ram in various situations that causes the issue when resuming the activity.

2017/12/05 - No changes or real acknowledgement from Google. From what I've found, this issue appears to have been resolved in Android 8.0 and on some devices running various updates to Android 7.x

Answer 1

I run into this problem too while working on improvements of my app where I wanted to make the camera preview a bit smoother. Instead of closing it down if not needed by stopping the preview and making the surface invisible I only stopped the preview and left the surface visible. (this makes a nice still image and has a shorter restart time) This caused the "Leaked 2 GPU objects!" crash if the app became closed.

I assume there are only two situations where the preview is closing clean: a) if the preview is running b) if the preview is stopped and! the surface is removed from view (invisible).