native crashes open in android 4.3 & 4.4

[Alex Ho]

Hi,

I have an app using JNI. It has been running without any native crash with android 4.2 and below. But since 4.3 & 4.4 was released, there has been a few native crash reports daily from devices running android 4.3 and 4.4. I have not rebuilt my native code which is working fine with 4.2. Could you please take a look at the crash report and give me some suggestions how to prevent the crashes? Can this be a new android os (4.3 & 4.4) problem? Thank you in advance.

Native crash at /system/lib/libc.so

in /system/lib/libc.so (tgkill+12), /system/lib/libc.so (pthread_kill+48)

Native crash at /system/lib/libhwui.so

in /system/lib/libhwui.so, /system/lib/libandroid_runtime.so

Native crash at /system/lib/libc.so

in /system/lib/libc.so (dlmalloc+2679), /system/lib/libc.so (malloc+10)

Native crash at /system/lib/libc.so

in /system/lib/libc.so (__memcpy_base+231)

[Christopher Masser]

same problem here

[Alex Ho]

Seeing more crashes now. But I cannot reproduce on the devices I have. Really appreciate if someone can point out a way to troubleshoot.

[Alex Ho]

ThThis is something typical trace I got from google developer console. Does it matter if I compile my library with a older ndk version? Why is it only for android 4.3 & 4.4?

backtrace:
#00 pc 00022044 /system/lib/libc.so (tgkill+12)
#01 pc 00013097 /system/lib/libc.so (pthread_kill+50)
#02 pc 0001328f /system/lib/libc.so (raise+10)
#03 pc 00011ffb /system/lib/libc.so
#04 pc 000218f8 /system/lib/libc.so (abort+4)
#05 pc 00012acd /system/lib/libc.so
#06 pc 0000f1ed /system/lib/libc.so
#07 pc 000100f9 /system/lib/libc.so (dlmalloc+604)
#08 pc 0000dcc7 /system/lib/libc.so (malloc+10)
#09 pc 000835b5 /system/lib/libcrypto.so
#10 pc 00083a15 /system/lib/libcrypto.so (CRYPTO_malloc+76)
#11 pc 0005ad1d /system/lib/libcrypto.so (BUF_MEM_new+16)
#12 pc 00047e51 /system/lib/libcrypto.so
#13 pc 00045a45 /system/lib/libcrypto.so
#14 pc 00045ac1 /system/lib/libcrypto.so (ASN1_template_new+64)
#15 pc 00045981 /system/lib/libcrypto.so
#16 pc 00045ac1 /system/lib/libcrypto.so (ASN1_template_new+64)
#17 pc 00045981 /system/lib/libcrypto.so
#18 pc 000458db /system/lib/libcrypto.so (ASN1_item_ex_new+6)
#19 pc 00043dc5 /system/lib/libcrypto.so (ASN1_item_ex_d2i+700)
#20 pc 00043af7 /system/lib/libcrypto.so (ASN1_item_d2i+42)
#21 pc 00049141 /system/lib/libcrypto.so (d2i_X509+16)
#22 pc 000182a7 /system/lib/libssl.so (ssl3_get_server_certificate+174)
#23 pc 000175ad /system/lib/libssl.so (ssl3_connect+780)
#24 pc 00027c27 /system/lib/libssl.so (SSL_do_handshake+50)
#25 pc 0000aeaf /system/lib/libjavacrypto.so
#26 pc 0001ea50 /system/lib/libdvm.so (dvmPlatformInvoke+116)
#27 pc 0004f667 /system/lib/libdvm.so (dvmCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)+398)
#28 pc 00027ee0 /system/lib/libdvm.so
#29 pc 0002f3d8 /system/lib/libdvm.so (dvmMterpStd(Thread*)+76)
#30 pc 0002ca7c /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)
#31 pc 00061ae3 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+338)

[David Turner]

malloc() is calling abort(), which typically happens when it detects that your heap is corrupted.

There are probably memory-stomping bugs in your native code, these very often are very difficult to find and may or may not crash your process, depending on plenty of different factors (e.g. the state of the heap when your process starts, the pattern of allocations and memory writes your code performs, and even the malloc() / free() implementation details).

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-ndk.
For more options, visit https://groups.google.com/d/optout.

[Alex Ho]

Thank you. I will look for memory-stompong bugs. Is there any particular reasons that this only happens on android 4.3 & 4.4? Is it an improvement in the analytics? Otherwise, it really bugs me.

I use directbuffer heavily in my code as a way to exchange data between native code and java code. I wonder if that can be a problem in new android os?

[Brendon Costa]

On 29 May 2014 03:17, Alex Ho <hongbi...@gmail.com> wrote:

ompong bugs. Is there any particular reasons that this only happens on android 4.3 & 4.4? Is it an improvement in the analytics? Otherwise, it really bugs me.

I use directbuffer heavily in my code as a way to exchan

In case code review doesn't work for finding issues you can use valgrind on android to detect native memory bugs in many cases. It takes some time to setup valgrind and makes the app run about 10x times slower so in some cases it is not feasible to actually use valgrind. But once you know how to use it, it can be a very useful tool.