0

We have an Android app that is written mostly in Java but uses small native module based on OpenCV library for image processing.

The module is called by JNI and all of the code in its method is inside a try-catch block that should catch any exception.

Now we rarely (about once per thousand users) get a native crash that is very puzzling for us. We cannot replicate those crashes. It is always on Android 4.4.2 or 4.4.4 but too rarely to reproduce. It doesn't seem to have any relation to our code. There are no .so files in backtrace that would suggest what it could be. We have no clue when the crash happen, users don't post a useful comment on crashes.

How could we even begin to debug something like that? Is it possible to find out what is the cause?

Typical crash report:

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'samsung/s3ve3gxx/s3ve3g:4.4.2/KOT49H/I9301IXXSAPG5:user/release-keys'
Revision: '4'
pid: 11950, tid: 11950
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
    r0 00000000  r1 00002eae  r2 00000006  r3 00000000
    r4 00000006  r5 00000002  r6 00002eae  r7 0000010c
    r8 a080001d  r9 6d596a34  sl 415ef4d8  fp beca92d4
    ip 4163fb21  sp beca8ff8  lr 40064205  pc 40073164  cpsr 000f0010
    d0  0000000000000000  d1  0000000000000000
    d2  0000000000000000  d3  0000000000000000
    d4  4391240843912408  d5  4391240843912408
    d6  4391240843912408  d7  4391240843912408
    d8  0000000000000000  d9  000005003f000000
    d10 3f00000000000038  d11 4044000000000000
    d12 4044000000000000  d13 0000000000000029
    d14 0000000000000000  d15 0000000000000000
    d16 2065766974614e28  d17 0a29646f6874654d
    d18 4391240843912408  d19 4391240843912408
    d20 4391240843912408  d21 4391240843912408
    d22 4391240843912408  d23 4391240843912408
    d24 004e004d004c004b  d25 0050004f004d004e
    d26 0000000000000000  d27 0000000000000000
    d28 001e001d001c001b  d29 0020001f001d001e
    d30 0050005000500050  d31 0000000000000000
    scr 88000013

backtrace:
    #00  pc 00022164  /system/lib/libc.so (tgkill+12)
    #01  pc 00013201  /system/lib/libc.so (pthread_kill+48)
    #02  pc 00013415  /system/lib/libc.so (raise+10)
    #03  pc 000120e3  /system/lib/libc.so
    #04  pc 00021a18  /system/lib/libc.so (abort+4)
    #05  pc 000494ff  /system/lib/libdvm.so (dvmAbort+78)
    #06  pc 0004ccfd  /system/lib/libdvm.so
    #07  pc 0004eb3b  /system/lib/libdvm.so
    #08  pc 0006ab23  /system/lib/libandroid_runtime.so
    #09  pc 00020d0c  /system/lib/libdvm.so (dvmPlatformInvoke+112)
    #10  pc 000519af  /system/lib/libdvm.so (dvmCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)+398)
    #11  pc 0002a1a0  /system/lib/libdvm.so
    #12  pc 00031650  /system/lib/libdvm.so (dvmMterpStd(Thread*)+76)
    #13  pc 0002ece8  /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)
    #14  pc 000640f9  /system/lib/libdvm.so (dvmInvokeMethod(Object*, Method const*, ArrayObject*, ArrayObject*, ClassObject*, bool)+392)
    #15  pc 0006c05f  /system/lib/libdvm.so
    #16  pc 0002a1a0  /system/lib/libdvm.so
    #17  pc 00031650  /system/lib/libdvm.so (dvmMterpStd(Thread*)+76)
    #18  pc 0002ece8  /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)
    #19  pc 00063e15  /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+336)
    #20  pc 0004d597  /system/lib/libdvm.so
    #21  pc 000520e7  /system/lib/libandroid_runtime.so
    #22  pc 0005367f  /system/lib/libandroid_runtime.so (android::AndroidRuntime::start(char const*, char const*, bool)+358)
    #23  pc 00001063  /system/bin/app_process
    #24  pc 0000e503  /system/lib/libc.so (__libc_init+50)
    #25  pc 00000d80  /system/bin/app_process

code around pc:
    40073144 e8bd00f0 e3700a01 912fff1e e2600000  
    40073154 ea006e48 e92d50f0 e3a07f43 ef000000  
    40073164 e8bd50f0 e3700a01 912fff1e e2600000  
    40073174 ea006e40 e92d50f0 e3a070ee ef000000  
    40073184 e8bd50f0 e3700a01 912fff1e e2600000  
    40073194 ea006e38 f200429a bf0080b9 f040f891  
    400731a4 4001e92d f2c02a04 2a1080a5 8093f2c0  
    400731b4 f2c02a20 2a408088 ea4fdb7f f1bc1c92  
    400731c4 dd6c0f0a 0600e92d 0f40f1bc f500dd4a  
    400731d4 f5016e80 ebae7920 ea4f0e09 ea4f5e4e  
    400731e4 f50e5e5e ebbc7e20 dd3b1f9e f04fbfc4  
    400731f4 ebd9090a dd35199e 0a0eeb01 0a3ff02a  
    40073204 1c9eebac bfd245e1 0c09ebac f04f46e1  
    40073214 f8910c00 f891f240 f921f280 f921028d  
    40073224 f8da428d f1b93000 f9000901 f900028d  
    40073234 f10a428d d1ee0a40 0f00f1bc f5bcd02b  

code around lr:
    400641e4 447b4b13 42b3e010 6a1ed10e 44784811  
    400641f4 ec50f7fb e9e8f00d 46224631 efaaf00e  
    40064204 d00a3001 e00b2400 2b00681b 480ad1eb  
    40064214 44782403 ec3ef7fb f001e002 6804f9ff  
    40064224 f9fcf001 46206005 bf00bd70 0003b1d2  
    40064234 0003b1c6 0003b1be 0003b19a bf7ef7ff  
    40064244 4a3e4b3d e92d447b b08b43f0 4606589c  
    40064254 6823460d 930946a1 f9e0f001 8000f8d0  
    40064264 d0482d00 f0104628 280ff8f7 d8444604  
    40064274 ffe4f7ff d1064286 4629200f e8b2f00d  
    40064284 d03c2800 482ee02e f7fb4478 482deb82  
    40064294 e0154478 d11342b0 482b6a06 f7fb4478  
    400642a4 4a2aebfa 46332120 a801447a f96ef013  
    400642b4 a8012101 fc8cf01a 46061c42 e011d104  
    400642c4 28006800 e02cd1e6 46294630 f00d4622  
    400642d4 1c43e8ee d11e4607 f9a0f001 29046801
Zbyszek
  • 1,420
  • 18
  • 23
  • 1
    I believe that Android ART was optional in Android 4.4.2. Is it possible that the users having the problem have switched it on and you could reproduce this way? Ie perhaps you are touching a bug in early ART release. – hack_on Feb 23 '17 at 21:58

1 Answers1

1

This is likely to be either a bug in the implementation of Android that the user is running, or a bug in the way your code/opencv are using JNI. This will be hard for SO people to debug as we have less information than you, but here are some suggestions for trying to track it down:

  • Test on the same hardware/OS revision as the users that have the issue.
  • Test with many images/data as it could be a format problem or size issue that triggers the fault.
  • Test by changing relevant OS settings like ART.
  • Test by doing things users may do like flipping between landscape and portrait mode just as the app is processing a large image.
  • Put some instrumentation around the JNI calls to audit things like size and format of images. Find a way to get this information, this SO Question gives some suggestions.

Without the information on why/when it crashed, you can't reproduce and without reproducing you can't fix it.

Community
  • 1
  • 1
hack_on
  • 2,532
  • 4
  • 26
  • 30