(Android) Native crash at /system/lib/libhoudini.so on Asus Phone - android

I received crash errors very much from user at Google Play.
And all those error occur on Asus phone ( Asus zenfone 4,5,6 and fonepad 7).
I don't known what those error is and how do i can fix those errors.
Hope someone can help me.
Log:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'asus/WW_ZenFone/ASUS_T00I:4.3/JSS15Q/WW_ZenFone-V4.1.0-20140428:user/release-keys'
Revision: '0'
pid: 6848, tid: 6958, name: fusoftware.ohtv >>> com.bfusoftware.ohtv <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr dead0000
eax 00000000 ebx 00000001 ecx 65441edc edx 00000000
esi 00000008 edi 0000b0b8
xcs 00000073 xds 0000007b xes 0000007b xfs 00000043 xss 0000007b
eip 651c3325 ebp 81cb6d0c esp 81cb6ce4 flags 00210246
backtrace:
#00 pc 00142325 /system/lib/libhoudini.so.3.4.5.44375
#01 pc 00073704 /system/lib/libhoudini.so.3.4.5.44375
#02 pc 00072599 /system/lib/libhoudini.so.3.4.5.44375
#03 pc 0006ecb5 /system/lib/libhoudini.so.3.4.5.44375
#04 pc 0006eeef /system/lib/libhoudini.so.3.4.5.44375
#05 pc 0013bbc9 /system/lib/libhoudini.so.3.4.5.44375
#06 pc 00139a1e /system/lib/libhoudini.so.3.4.5.44375
#07 pc 000ffe5f [stack:6958]

I don't think this is anything you can avoid yourself. This is a direct crash from the device and the OS not your app.
I've had this as well, its not necessarily a problem with your app though. The phone could be doing lots of things in the background which causes something within the OS to crash, but your app somehow receives the crash report, not sure why, I would guess because your app was in the foreground when something within the OS crashed, your app received the crash info.

libhoudini is responsible for running Arm code on x86 devices.
Sometimes it have bugs that are causing apps to crash.
The best solution is to include the x86 library too, that way the native code will run natively without using libhoudini, thus preventing any chance for such crashes.

the android 6.0 system, I also met, looks like Google is not fundamentally solved this problem, the only way to solve is the X86 and arm library must be left apart.

Related

How to automatic reproduce a native crash for android?

I got a native crash from GitHub. The native crash is as follows:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'google/android_x86/x86:7.1.2/N2G48B/327:user/release-keys'
Revision: '0'
ABI: 'x86'
pid: 3201, tid: 3201, name: le.startup_name >>> com.example.startup_name <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: '[FATAL:flutter/shell/platform/android/platform_view_android_jni_impl.cc(1469)] Check failed: fml::jni::CheckException(env).
'
eax 00000000 ebx 00000c81 ecx 00000c81 edx 00000006
esi c7ffe98c edi c7ffe934
xcs 00000073 xds 0000007b xes 0000007b xfs 0000003b xss 0000007b
eip c7f28c10 ebp cfffd288 esp cfffd22c flags 00200296
backtrace:
#00 pc 00000c10 [vdso:c7f28000] (__kernel_vsyscall+16)
#01 pc 0007ae8c /system/lib/libc.so (tgkill+28)
#02 pc 00076665 /system/lib/libc.so (pthread_kill+85)
#03 pc 00027eda /system/lib/libc.so (raise+42)
#04 pc 0001eec6 /system/lib/libc.so (abort+86)
#05 pc 000009da /data/app/com.example.startup_name-2/lib/x86/libflutter.so (offset 0x147e000)
stack:
......
I can manually reproduce the native crash on my machine according to the steps from the issues of GitHub. However, I want to replicate the native crash automatically. I build a workflow graph. The workflow graph is as follows.
Tombstone files --> .so file --> c source code (native crash source code) --> test generation tool --> test cases --> run test cases --> crash reproduction
I want to reproduce the native crash according to the workflow. I should learn how to find a test-generation tool and run the generated test cases. I just get a native crash same as the original native crash.

SIGSEGV in RenderScript app

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.

How do I diagnose the cause of a Xamarin Android Weak Reference Table Overflow?

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.

Xamarin Android app is crashing when installed from the store

I have created an application which is using webservices, qrcode scanning ( zing).
When I run my app in debug mode everything is working fine.
Also when those apk files are sideloaded on different devices everything is fine.
The release version is publish and signed though Ad-Hoc and saved to disk. side loading this file also works fine.
I have uploaded the file to the PlayStore to debug and test the application prior to delivering to the customer, but when the app is installed through the Playstore, the app crashes directly after the splashscreen.
looking at the reports which are generated for me by android I really have no clue where to look for my solution.
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'samsung/jfltexx/jflte:5.0.1/LRX22C/I9505XXUHOB7:user/release-keys'
Revision: '11'
ABI: 'arm'
pid: 21093, tid: 21163, name: Thread-73837 >>> mobilesr.mobilesr <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
r0 00000000 r1 00000000 r2 00001002 r3 00000000
r4 af4cf020 r5 00000000 r6 00000000 r7 b4dfac70
r8 b6ef9e04 r9 b4e69300 sl b46eaca0 fp b4e4f1c0
ip b4dfaca0 sp b46eac28 lr b4ba60e8 pc b6ea1464 cpsr 60070030
backtrace:
#00 pc 00011464 /system/lib/libc.so (strlen+83)
#01 pc 000a40e4 /system/lib/libart.so (std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::operator<< <std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*)+44)
#02 pc 0022dd03 /system/lib/libart.so (art::Thread::Attach(char const*, bool, _jobject*, bool)+338)
#03 pc 00218089 /system/lib/libart.so (art::Runtime::AttachCurrentThread(char const*, bool, _jobject*, bool)+12)
#04 pc 001b242b /system/lib/libart.so (art::JII::AttachCurrentThread(_JavaVM*, _JNIEnv**, void*)+190)
#05 pc 00009774 /data/app/mobilesr.mobilesr-1/lib/arm/libmonodroid.so
Does anybody has some thoughts on where I have to look for the solution?
I need to get this version working in the store.
greetings,
thanks for the info, I'll keep it in mind for future debugging sessions.
About the app, yesterday evening, directly after uploading and publishing the new APK, the system kept crashing with the report as shown above, this morning, everything was working fine, the app is completely functioning from within the store.
I don't know, but I think it's a time issue. installing the app directly after publishing it through pushing it to the app, might result in a broken version because it's not completely ready yet or some like that. It could also be some kind of check from the system back to the store and because it can't be found yet the app is halted.
anyway, for me the app is working, so at this moment I'm happy.
Greetings,

Native crash in /system/lib/libart.so

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

Categories

Resources