Our company have an Android app that's been out for a few months now, where very few crashes have been reported.
But with Lollipop upgrades being rolled out to our customers devices, we got reports about intermittent Segmentation fault (SIGSEGV) crashes. And the crashes only occur on Android 5.0 devices - like upgraded Samsung Galaxy 5, Sony Xperia Z3, new HTC devices (unsure of model name) and a few other. All Android 4+ devices runs our app without problems, but all tested Android 5 devices so far get these crashes.
We have been able to reproduce them, in the sense that we on our own devices get these crashes. But we have so far been able to locate the source of the crashes, or find a pattern in what causes them.
This one of the reported crash dumps:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'samsung/klteactivexx/klteactive:5.0/LRX21T/xxxxxx:user/release-keys'
Revision: '8'
ABI: 'arm'
pid: 8779, tid: 10227, name: hwuiTask2 >>> com.ourcompany.ourapp <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xbd04a008
r0 9d04a00c r1 b6f6b87c r2 9d04a000 r3 ffffffe2
r4 00000001 r5 07ffffff r6 00000002 r7 b6f6b894
r8 00000002 r9 fffffffc sl b6f6b87c fp 0000001f
ip 00000004 sp 9ee71a8c lr b6f37f4d pc b6f36a52 cpsr 00010030
backtrace:
#00 pc 0003ca52 /system/lib/libc.so (arena_run_reg_alloc+101)
#01 pc 0003df49 /system/lib/libc.so (je_arena_tcache_fill_small+96)
#02 pc 0004bad7 /system/lib/libc.so (je_tcache_alloc_small_hard+14)
#03 pc 000476af /system/lib/libc.so (je_malloc+302)
#04 pc 0000fa5f /system/lib/libc.so (malloc+10)
#05 pc 00000b09 /system/lib/libstdc++.so (operator new(unsigned int)+4)
#06 pc 000e2ecf /system/lib/libskia.so (SkPathRef::Editor::Editor(SkAutoTUnref<SkPathRef>*, int, int)+32)
#07 pc 000df1c1 /system/lib/libskia.so (SkPath::incReserve(unsigned int)+12)
#08 pc 000e0631 /system/lib/libskia.so (SkPath::addRRect(SkRRect const&, SkPath::Direction)+120)
#09 pc 000e0745 /system/lib/libskia.so (SkPath::addRoundRect(SkRect const&, float, float, SkPath::Direction)+76)
#10 pc 0003e6fd /system/lib/libhwui.so
#11 pc 0003e2ad /system/lib/libhwui.so
#12 pc 000314b3 /system/lib/libhwui.so
#13 pc 0001512b /system/lib/libhwui.so
#14 pc 0000ef11 /system/lib/libutils.so (android::Thread::_threadLoop(void*)+112)
#15 pc 000602f5 /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+72)
#16 pc 0000ea81 /system/lib/libutils.so
#17 pc 000137bb /system/lib/libc.so (__pthread_start(void*)+30)
#18 pc 0001189b /system/lib/libc.so (__start_thread+6)
We have no native code in the app written by ourself, and the only libs we're using besides the Android libs are GSon 2.3.1, Ormlite 4.48 and Spring 1.0.0.
I'm a bit unsure how to proceed with these errors, so any help would be welcome. I have seen suggestions to use NDK Stack Tool to translate the crash dump to something more readable, but with no pre-existing knowledge about NDK, I have so far not been able to get it to work in my dev enviroment (Windows7, Eclipse Kepler.
Anyone who has any similiar experiences when Android 5.0 upgrades started to roll out to customers, or have any ideas on how or where I should continue to look for the cause?
I guess NDK Stack Tool is my best hope, but I have so far been unable to find a good tutorial that get's me anywhere with it.
Related
I have an Android app published on Google Play that is implemented in large part in RenderScript (native, not using support library APIs). The app sometimes seems to crash in libCB.so. Crash rate is 1.40% as reported by the Google Play Console.
The crash seems to occur in all Android versions from 6.0 to 8.1 (API levels 23–27). I haven't received a report from older versions even though the app's minSdkVersion is 18 (Android 4.3). All kinds of devices from various manufacturers seem to be affected, both cheap no-name products as well as hi-end devices.
The app uses the Camera 1 API to capture frames from a live preview video (setPreviewCallbackWithBuffer). The PreviewCallback sends the frame data through a series of RenderScripts that process that input. At two stages the processed data is then also sent to two different TextureViews. I can provide more details if necessary.
I'm not sure what causes the problem since I was not able to reproduce it locally on any of my own test devices.
Does anyone know what might be the cause of this issue or if there is any workaround?
Here's a typical backtrace:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'Xiaomi/land/land:6.0.1/MMB29M/V9.2.2.0.MALMIEK:user/release-keys'
Revision: '0'
ABI: 'arm'
pid: 17840, tid: 17862, name: JNISurfaceTextu >>> com.app.my <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x38
r0 00000000 r1 00000000 r2 00000002 r3 00000000
r4 00000000 r5 ef8e0a38 r6 00000002 r7 00000000
r8 ab06e808 r9 00000000 sl 00000000 fp ef8e0c30
ip e044d8f8 sp ef8e09f8 lr e03ac9b3 pc e03ac89c cpsr 800f0030
backtrace:
#00 pc 0003189c /system/vendor/lib/libCB.so (cl_mem_non_local_event_cache_state_transition+15)
#01 pc 000319af /system/vendor/lib/libCB.so (cl_mem_grant_access_to_device_internal+58)
#02 pc 00031ae5 /system/vendor/lib/libCB.so (cb_grant_access_to_device+84)
#03 pc 0000eb61 /system/vendor/lib/librs_adreno.so
#04 pc 0000683b /system/vendor/lib/librs_adreno.so
#05 pc 000068a1 /system/vendor/lib/librs_adreno.so
#06 pc 00007f33 /system/vendor/lib/librs_adreno.so
#07 pc 00009707 /system/vendor/lib/librs_adreno.so
#08 pc 00009ee5 /system/vendor/lib/librs_adreno.so
#09 pc 000088f5 /system/vendor/lib/librs_adreno.so (rsdVendorScriptInvokeForEach3+236)
#10 pc 00019bf9 /system/vendor/lib/libRSDriver_adreno.so (_Z29rsdVendorInvokeForEachWrapperPKN7android12renderscript7ContextEPNS0_6ScriptEjPPKNS0_10AllocationEjPS6_PKvjPK12RsScriptCall+84)
#11 pc 00019cfb /system/vendor/lib/libRSDriver_adreno.so (_Z27rsdScriptInvokeForEachMultiPKN7android12renderscript7ContextEPNS0_6ScriptEjPPKNS0_10AllocationEjPS6_PKvjPK12RsScriptCall+38)
#12 pc 0002ebf3 /system/lib/libRS.so (_ZN7android12renderscript7ScriptC10runForEachEPNS0_7ContextEjPPKNS0_10AllocationEjPS4_PKvjPK12RsScriptCall+294)
#13 pc 00033e41 /system/lib/libRS.so (_ZN7android12renderscript22rsp_ScriptForEachMultiEPNS0_7ContextEPKvj+48)
#14 pc 000311ff /system/lib/libRS.so (_ZN7android12renderscript8ThreadIO16playCoreCommandsEPNS0_7ContextEi+338)
#15 pc 00023d27 /system/lib/libRS.so (_ZN7android12renderscript7Context10threadProcEPv+646)
#16 pc 0004185b /system/lib/libc.so (_ZL15__pthread_startPv+30)
#17 pc 000192a5 /system/lib/libc.so (__start_thread+6)
Well, we had a similar issue with opencv c++ code compiled for Android.
Our mistake was setting timers which call jni functions and forgetting them to purge afterwards. Eventually garbage collector wasn't able to follow the references which causes memory leak. So our app used to crash unless it was killed by the user for like, maybe a whole day.
Are you setting timers anywhere in your code?
Or are you keeping the track of the threads (if anyone of them exists) which call jni functions?
You might want to check this if you are interested: Timer::purge()
Are the crashes mostly related to libCB.so? If so, it could be a bug in Qualcomm RenderScript driver. I suspect it only affects certain SOC.
Please file a bug in https://buganizer.corp.google.com/issues?q=componentid:192772, and attach the potential steps to reproduce this.
I have reports from several users that my app is crashing after about 5 minutes of intensive use. I have received crash logs on Google Play and an example is attached below. The message seems to be:
JNI ERROR (app bug): weak global reference table overflow (max=51200)'
I'm not familiar with the JNI and would appreciate so any advice/explanations/suggestions on how to figure this out. The likely cause is something in my code is not getting cleaned up, but what?
The devices that this issue has been reported on are Nexus 5.x, Galaxy S7 and Nexus 6.
The relevant code can be found in my open source project: https://gitlab.com/hodgskin-callan/Invention. However, I don't have the minimum code to reproduce the issue and it does not reproduce on my Nexus 9. I suspect this issue is not affecting the majority of the Android users.
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'google/bullhead/bullhead:7.1.1/N4F26T/3687331:user/release-keys'
Revision: 'rev_1.0'
ABI: 'arm'
pid: 10404, tid: 10404, name: .x10host.pathos >>> com.x10host.pathos <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'art/runtime/indirect_reference_table.cc:132] JNI ERROR (app bug): weak global reference table overflow (max=51200)'
r0 00000000 r1 000028a4 r2 00000006 r3 00000008
r4 f300558c r5 00000006 r6 f3005534 r7 0000010c
r8 00000000 r9 0000000a sl 00001785 fp f0385400
ip 0000000b sp ffde7b50 lr f1a065e7 pc f1a08e44 cpsr 200f0010
backtrace:
#00 pc 00049e44 /system/lib/libc.so (tgkill+12)
#01 pc 000475e3 /system/lib/libc.so (pthread_kill+34)
#02 pc 0001d8a5 /system/lib/libc.so (raise+10)
#03 pc 000193f1 /system/lib/libc.so (__libc_android_abort+34)
#04 pc 00017034 /system/lib/libc.so (abort+4)
#05 pc 0031a5f1 /system/lib/libart.so (_ZN3art7Runtime5AbortEPKc+328)
#06 pc 000b5205 /system/lib/libart.so (_ZN3art10LogMessageD2Ev+1132)
#07 pc 001bc42b /system/lib/libart.so (_ZN3art22IndirectReferenceTable3AddEjPNS_6mirror6ObjectE+194)
#08 pc 0023a097 /system/lib/libart.so (_ZN3art9JavaVMExt16AddWeakGlobalRefEPNS_6ThreadEPNS_6mirror6ObjectE+46)
#09 pc 0027f483 /system/lib/libart.so (_ZN3art3JNI16NewWeakGlobalRefEP7_JNIEnvP8_jobject+418)
#10 pc 0000de14 /data/app/com.x10host.pathos-2/lib/arm/libmonodroid.soapp/com.x10host.pathos-2/lib/arm/libmonodroid.so
There's a long, but very useful piece of documentation on this subject here:
https://developer.xamarin.com/guides/android/troubleshooting/troubleshooting/#Global_Reference_Messages
For a first pass through, you should attempt to enable the system property through a .txt file that has it's Build Action set to $(AndroidEnvironment):
i.e. debug.mono.log gref
https://developer.xamarin.com/guides/android/advanced_topics/environment/#Xamarin.Android_System_Properties
You would then obtain an adb logcat from the device which will include this logging.
However if that doesn't work to your favor:
You should be able to query directly via:
Java.Interop.JniRuntime.CurrentRuntime.GlobalReferenceCount
Java.Interop.JniRuntime.CurrentRuntime.WeakGlobalReferenceCount
The local references are also tracked in Java.Interop.JniEnvironment.LocalReferenceCount which is a thread-local value.
suddenly when opening my app i got one crash and i uploaded the crash log below.But it happens sometime only not every time and every device.
Can anyone help me to understand the crash log and why its happening for sometimes and some devices. what is main reason for the below crash?
Revision: '14'
ABI: 'arm'
pid: 1834, tid: 8022, name: pool-3-thread-1 >>> com.example <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'art/runtime/check_jni.cc:65] JNI DETECTED ERROR IN APPLICATION: java_array == null'
r0 00000000 r1 00001f56 r2 00000006 r3 00000000
r4 942bfdb8 r5 00000006 r6 00000002 r7 0000010c
r8 00000000 r9 b4e4f520 sl af17a800 fp 00000965
ip 00001f56 sp 942bf498 lr b6f26fd5 pc b6f4aeb4 cpsr 60070010
backtrace:
#00 pc 00037eb4 /system/lib/libc.so (tgkill+12)
#01 pc 00013fd1 /system/lib/libc.so (pthread_kill+52)
#02 pc 00014bef /system/lib/libc.so (raise+10)
#03 pc 00011531 /system/lib/libc.so (__libc_android_abort+36)
#04 pc 0000fcbc /system/lib/libc.so (abort+4)
#05 pc 0021d161 /system/lib/libart.so (art::Runtime::Abort()+160)
#06 pc 000a831b /system/lib/libart.so (art::LogMessage::~LogMessage()+1322)
#07 pc 000b1a49 /system/lib/libart.so (art::JniAbort(char const*, char const*)+1060)
#08 pc 000b1fa5 /system/lib/libart.so (art::JniAbortF(char const*, char const*, ...)+60)
#09 pc 001be127 /system/lib/libart.so (art::JNI::GetArrayLength(_JNIEnv*, _jarray*)+570)
#10 pc 00001171 /data/app/com.example-1/lib/arm/library.so (Java_com_example_value_encypt+48)
#11 pc 004986f9 /data/dalvik-cache/arm/data#app#com.example-1#base.apk#classes.dex
This kind of crash was happening to my app too. I could not figure it out through the logs. Once, I got hold of a device on which it crashed and found that it was crashing at a place where I was clearing the WebView cache. The problem was that the function to do that was deprecated, so in most of the phones it worked while in few others, it crashed. Since this was occurring probably even before Crashlytics got initialised, I was not getting any actual crash reports except from these kind of logs from Play Store.
What I would suggest is, check the device models from Play Store, and try to get a hold of one of these devices and try to see logcat crash report as it would point you to the actual problem.
since December 2015, we are experiencing a strange crash only on a limited number of devices running Android 6.0 and 6.0.1. Most of them are Nexus 5.
First the log of the crash pulled from the Play Store. Looking int art_method.cc, it looks like the mapping of a certain method to native code fails. Maybe it is compilation induced?
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'google/hammerhead/hammerhead:6.0.1/MMB29Q/2480792:user/release-keys'
Revision: '0'
ABI: 'arm'
pid: 18737, tid: 18737, name: omittedapp >>> com.omitteddomain.omittedapp <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'art/runtime/art_method.cc:245] Failed to find native offset for dex pc 0x58 in android.view.View com.omitteddomain.omittedapp.PlotWidget.a(android.view.ViewGroup, android.view.LayoutInflater, java.util.List)'
r0 00000000 r1 00004931 r2 00000006 r3 b6f24b7c
r4 b6f24b84 r5 b6f24b34 r6 00000001 r7 0000010c
r8 b4c3f800 r9 b4c3de44 sl b361d3db fp b4c23450
ip 00000006 sp beb2ca90 lr b6c93b61 pc b6c95f50 cpsr 40070010
backtrace:
#00 pc 00041f50 /system/lib/libc.so (tgkill+12)
#01 pc 0003fb5d /system/lib/libc.so (pthread_kill+32)
#02 pc 0001c30f /system/lib/libc.so (raise+10)
#03 pc 000194c1 /system/lib/libc.so (__libc_android_abort+34)
#04 pc 000174ac /system/lib/libc.so (abort+4)
#05 pc 00333971 /system/lib/libart.so (art::Runtime::Abort()+228)
#06 pc 000f45fb /system/lib/libart.so (art::LogMessage::~LogMessage()+2226)
#07 pc 000f08d1 /system/lib/libart.so (art::Barrier::~Barrier()+216)
#08 pc 0035b473 /system/lib/libart.so (art::ThreadList::Dump(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+162)
#09 pc 00333a35 /system/lib/libart.so (art::Runtime::Abort()+424)
#10 pc 000f45fb /system/lib/libart.so (art::LogMessage::~LogMessage()+2226)
#11 pc 000ef88b /system/lib/libart.so (art::ArtMethod::ToNativeQuickPc(unsigned int, bool)+918)
#12 pc 00329055 /system/lib/libart.so (art::CatchBlockStackVisitor::VisitFrame()+180)
#13 pc 0033ccbd /system/lib/libart.so (art::StackVisitor::WalkStack(bool)+224)
#14 pc 0032910d /system/lib/libart.so (art::QuickExceptionHandler::FindCatch(art::mirror::Throwable*)+92)
#15 pc 0034a61d /system/lib/libart.so (art::Thread::QuickDeliverException()+140)
#16 pc 003fb7d9 /system/lib/libart.so (artThrowNullPointerExceptionFromCode+20)
#17 pc 00a15f01 /data/app/com.omitteddomain.omittedapp-1/oat/arm/base.odex (offset 0x59d000)
The only other occurrence of a similar crash (here Android ART: "Failed to find Dex offset for PC offset ...") has been reported to be potentially related to an infinite recursion issue. While we had an infinite recursion issue in the very same "a" method, it has been already fixed.
Some additional info:
The PlotWidget class in question display a chart to the user via a third party library. The cart view is configured inside the above "a" method. We changed the library multiple times with no difference in the outcome.
All of the third party libraries are up to date.
We have been able to test the app with the same data displayed to one of the afflicted user, without being able to reproduce the issue (being sensitive information, we were provided only the data strictly required to render the chart).
Attempts to reproduce the issue have failed with every combination of configuration/flavor, proguard enabled/disabled, zipalign yes/no, etc.
The app is compiled with Android Studio 1.5, with the latest SDK, targeting API 23. Before setting a lower target API and release an useless update for the umpteenth time, I'd like to know is someone experienced and solved similar issues.
Any advice is welcome.
I have an app on the Play Store, it has an IntentService that does some work when the app starts, and it's causing native crashes on Android 5.0. This service just scans the assets folder for app updating purposes.
Specifically, this crash seems to happen on Samsung S5 after the ugrade to Lollipop, but I don't know if it's strictly related to that device, as it's an Italian app and here that's still the only widely diffuse (i.e. that I know of) device that's getting Lollipop. However, I tried it on the emulator, with stock Android 5, and it's working fine.
I'm attaching the stack trace, any help on how to proceed would be appreciated... with native problems, I don't know where to put my hands.
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'samsung/kltexx/klte:5.0/LRX21T/G900FXXU1BNL9:user/release-keys'
Revision: '14'
ABI: 'arm'
pid: 24219, tid: 24259, name: IntentService[I >>> it.mydomain.myapp <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
r0 afcb8c00 r1 001000e6 r2 af201428 r3 00000000
r4 76eb1338 r5 700981c0 r6 af50e4c2 r7 afcb8c00
r8 af201070 r9 b4f7e300 sl b4efac64 fp fffffb18
ip 00100002 sp af200f60 lr b4cd52ab pc b4cd52ca cpsr 600f0030
backtrace:
#00 pc 000d32ca /system/lib/libart.so (art::ClassLinker::FindClassInPathClassLoader(art::ScopedObjectAccessAlreadyRunnable&, art::Thread*, char const*, art::Handle<art::mirror::ClassLoader>)+77)
#01 pc 000d3739 /system/lib/libart.so (_ZN3art11ClassLinker9FindClassEPNS_6ThreadEPKcNS_6HandleINS_6mirror11ClassLoaderEEE.part.404+356)
#02 pc 000d5ded /system/lib/libart.so (art::ClassLinker::CreateArrayClass(art::Thread*, char const*, art::Handle<art::mirror::ClassLoader>)+88)
#03 pc 000d37d1 /system/lib/libart.so (_ZN3art11ClassLinker9FindClassEPNS_6ThreadEPKcNS_6HandleINS_6mirror11ClassLoaderEEE.part.404+508)
#04 pc 000d5ded /system/lib/libart.so (art::ClassLinker::CreateArrayClass(art::Thread*, char const*, art::Handle<art::mirror::ClassLoader>)+88)
#05 pc 000d37d1 /system/lib/libart.so (_ZN3art11ClassLinker9FindClassEPNS_6ThreadEPKcNS_6HandleINS_6mirror11ClassLoaderEEE.part.404+508)
#06 pc 001fe583 /system/lib/libart.so (art::Array_createObjectArray(_JNIEnv*, _jclass*, _jclass*, int)+422)
This is a known issue - but unfortunately not documented anywhere.
I too faced it in our app and solved by not using zopfli.
For my app - happened only on OS 5.0.x.
Some links which talk about the same:
Native crash at /system/lib/libart.so on lollipop android 5.0.1 samsung
http://developer.samsung.com/forum/board/thread/view.do?boardName=General&messageId=279862&frm=7&tagValue=lollipop&curPage=1