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.
Related
When ever i try to resume the flutter app after it being minimized it crashes with the error log show below:
E/Surface ( 9933): queueBuffer: error queuing buffer to SurfaceTexture, -19
E/EGL_emulation( 9933): tid 9952: swapBuffers(286): error 0x3003 (EGL_BAD_ALLOC)
F/libc ( 9933): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x3c in tid 9952 (1.raster)
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'Android/vbox86p/vbox86p:7.0/NRD90M/391:userdebug/test-keys'
Revision: '0'
ABI: 'x86'
pid: 9933, tid: 9952, name: 1.raster >>> com.example.expense_app <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3c
eax e9a1ae78 ebx f6190ca0 ecx ec411a10 edx e9a1ae00
esi 00000000 edi 00000000
xcs 00000023 xds 0000002b xes 0000002b xfs 0000006b xss 0000002b
eip f6169ad9 ebp d8c54ea8 esp d8c54da0 flags 00010282
backtrace:
#00 pc 0006ead9 /system/lib/libgui.so (_ZN7android7Surface11queueBufferEP19ANativeWindowBufferi+185)
#01 pc 0006dc97 /system/lib/libgui.so (_ZN7android7Surface27hook_queueBuffer_DEPRECATEDEP13ANativeWindowP19ANativeWindowBuffer+55)
#02 pc 0000844d /system/lib/egl/libEGL_emulation.so (_ZN20egl_window_surface_t11swapBuffersEv+93)
#03 pc 0000bf99 /system/lib/egl/libEGL_emulation.so (eglSwapBuffers+585)
#04 pc 00010d39 /system/lib/libEGL.so (eglSwapBuffersWithDamageKHR+553)
#05 pc 000112f7 /system/lib/libEGL.so (eglSwapBuffers+55)
#06 pc 00001045 /data/app/com.example.expense_app-1/lib/x86/libflutter.so (offset 0x1168000)
Lost connection to device.
Exited (sigterm)
Please any ideas as to how i can tackle 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.
I have a hello world C++ application that links with many 3rdpart and home-made libraries. It crashes immediately when trying to load it, with Segmentation Fault.
The same code, with the same dependencies, all compiled for Linux - runs successfully.
How can I start to debug it?
What could be the reason?
Edit: This is what logcat prints:
F/libc ( 8129): Fatal signal 11 (SIGSEGV), code 128, fault addr 0x0 in tid 8129 (HelloWorldApp) I/DEBUG ( 2876): *** *** *** *** *** ***
*** *** *** *** *** *** *** *** *** *** I/DEBUG ( 2876): Build fingerprint: 'Intel/cht_hr/cht_hr:5.1.1/LMY47Z/LS0000037:userdebug/test-keys' I/DEBUG ( 2876): Revision: '0' W/NativeCrashListener( 3194): Couldn't find ProcessRecord for pid 8129 I/DEBUG ( 2876): ABI: 'x86' I/DEBUG ( 2876): pid: 8129, tid: 8129, name: HelloWorldApp >>> ./StaticImageOR <<< E/DEBUG ( 2876): AM write failure (32 / Broken pipe) I/DEBUG ( 2876): signal 11 (SIGSEGV), code 128 (SI_KERNEL), fault addr 0x0 I/DEBUG ( 2876): eax ff84cadc ebx f32b7c6c ecx 00000010 edx 00000000 I/DEBUG ( 2876): esi f32c6610 edi 00000000 I/DEBUG ( 2876): xcs 00000023 xds 0000002b xes 0000002b xfs 00000000 xss 0000002b I/DEBUG ( 2876): eip f2600cfb ebp ff84c6dc esp ff84c5f4 flags 00010246 I/DEBUG ( 2876): I/DEBUG ( 2876): backtrace: I/DEBUG ( 2876): #00 pc 0062fcfb /system/lib/libcommander.so I/DEBUG ( 2876): #01 pc 0017651f /system/lib/libcommander.so I/DEBUG ( 2876): #02 pc 00001fcb /system/bin/linker (__dl__ZN6soinfo16CallConstructorsEv.part.23+1275) I/DEBUG ( 2876):
#03 pc 00001c26 /system/bin/linker (__dl__ZN6soinfo16CallConstructorsEv.part.23+342) I/DEBUG ( 2876):
#04 pc 00001c26 /system/bin/linker (__dl__ZN6soinfo16CallConstructorsEv.part.23+342) I/DEBUG ( 2876):
#05 pc 00008706 /system/bin/linker (__dl___linker_init+4998) I/DEBUG ( 2876): #06 pc 00009e0e /system/bin/linker (__dl__start+30) I/DEBUG ( 2876): I/DEBUG ( 2876): Tombstone written to: /data/tombstones/tombstone_02
So I undersatnd the problem is in libcommander loading.
How to continue with this?
Thanks!
The easiest way is to run your application under debugger, then most recent android studio is really good at debugging c++ code. For instructions how to debug jni code, find Create Hello-JNI with Android Studio in google code labs.
Other solution is to look into logcat, you might find there reason for the crash. For example you can find lines like
I/DEBUG ( 8704): signal 11 (SIGSEGV), fault addr deadbaad
...
...
which will contain call stack for the location where crash happend. With that information you can use ndk-stack - tool (see here ndk-stack), to turn frame addresses into symbolic names.
Android will put into logcat other warnings/jni error that might help you find a location of the problem.
A user with a Galaxy Note4 with Android 5.0 had my app crash yesterday. This was the stack trace.
My app is mostly just a webview wrapper of a website. Is there anything I can do to improve the webview or make it more efficient to prevent the 20 or so crashes I'm getting a week that all have this same stack trace?
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'samsung/trlteuc/trlteatt:5.0.1/LRX22C/N910AUCU2COC6:user/release-keys'
Revision: '12'
ABI: 'arm'
pid: 421, tid: 421, name: ****.app >>> org.***********.app <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: '[FATAL:jni_android.cc(249)] Check failed: false. Please include Java exception stack in crash report
'
r0 00000000 r1 000001a5 r2 00000006 r3 00000000
r4 b6fd3114 r5 00000006 r6 0000000b r7 0000010c
r8 b6fb2e04 r9 be972e14 sl 00000000 fp b3be8ac4
ip 000001a5 sp be972968 lr b6f5cff5 pc b6f7f9fc cpsr 600f0010
backtrace:
#00 pc 000369fc /system/lib/libc.so (tgkill+12)
#01 pc 00013ff1 /system/lib/libc.so (pthread_kill+52)
#02 pc 00014c0f /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 002b8bf9 /data/app/com.google.android.webview-1/lib/arm/libwebviewchromium.so
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.