I have been struggling with my application's almost random crashes that declare("corrupt memory heap signal 6"). I took my logcat when it crashed and ran ndk-stack on it, and got the following results. What is frustrating is that there is no fault address and the libraries that are listed are system libraries.
Any insight on how to move forward with this? If it helps, my Android application simply uses an Intent to launch a Camera Capture activity. Once the Capture is done, it calls finish() and returns.
Thanks!
pid: 31136, tid: 31136, name: .testquickstart >>> com.example.testquickstart <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Stack frame #00 pc 00021f90 /system/lib/libc.so (tgkill+12)
Stack frame #01 pc 00012fe1 /system/lib/libc.so (pthread_kill+48)
Stack frame #02 pc 000131f5 /system/lib/libc.so (raise+10)
Stack frame #03 pc 00011f2b /system/lib/libc.so
Stack frame #04 pc 00021844 /system/lib/libc.so (abort+4)
Stack frame #05 pc 00012a11 /system/lib/libc.so
Stack frame #06 pc 0000f11d /system/lib/libc.so
Stack frame #07 pc 000116eb /system/lib/libc.so (dlfree+1222)
Stack frame #08 pc 0000dc0b /system/lib/libc.so (free+10)
Stack frame #09 pc 0000d2dd /system/lib/libutils.so (android::SharedBuffer::dealloc(android::SharedBuffer const*)+6)
Stack frame #10 pc 0000f9ef /system/lib/libutils.so (android::VectorImpl::_shrink(unsigned int, unsigned int)+134)
Stack frame #11 pc 0000ae25 /system/lib/libinput.so (android::MotionEvent::initialize(int, int, int, int, int, int, int, float, float, float, float, long long, long long, unsigned int, an
droid::PointerProperties const*, android::PointerCoords const*)+116)
Stack frame #12 pc 0000f635 /system/lib/libinput.so (android::InputConsumer::initializeMotionEvent(android::MotionEvent*, android::InputMessage const*)+174)
Stack frame #13 pc 0000faeb /system/lib/libinput.so (android::InputConsumer::consume(android::InputEventFactoryInterface*, bool, long long, unsigned int*, android::InputEvent**)+282)
Stack frame #14 pc 00062ef5 /system/lib/libandroid_runtime.so (android::NativeInputEventReceiver::consumeEvents(_JNIEnv*, bool, long long, bool*)+80)
Stack frame #15 pc 000630f9 /system/lib/libandroid_runtime.so (android::NativeInputEventReceiver::handleEvent(int, int, void*)+52)
Stack frame #16 pc 000107bb /system/lib/libutils.so (android::Looper::pollInner(int)+478)
Stack frame #17 pc 00010869 /system/lib/libutils.so (android::Looper::pollOnce(int, int*, int*, void**)+92)
Stack frame #18 pc 0006a121 /system/lib/libandroid_runtime.so (android::NativeMessageQueue::pollOnce(_JNIEnv*, int)+22)
Stack frame #19 pc 0001dbcc /system/lib/libdvm.so (dvmPlatformInvoke+112)
Stack frame #20 pc 0004e123 /system/lib/libdvm.so (dvmCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)+398)
Stack frame #21 pc 00026fe0 /system/lib/libdvm.so
Stack frame #22 pc 0002dfa0 /system/lib/libdvm.so (dvmMterpStd(Thread*)+76)
Stack frame #23 pc 0002b638 /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)
Stack frame #24 pc 00060865 /system/lib/libdvm.so (dvmInvokeMethod(Object*, Method const*, ArrayObject*, ArrayObject*, ClassObject*, bool)+392)
Stack frame #25 pc 000687c7 /system/lib/libdvm.so
Stack frame #26 pc 00026fe0 /system/lib/libdvm.so
Stack frame #27 pc 0002dfa0 /system/lib/libdvm.so (dvmMterpStd(Thread*)+76)
Stack frame #28 pc 0002b638 /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)
Stack frame #29 pc 00060581 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+336)
Stack frame #30 pc 00049d0b /system/lib/libdvm.so
Stack frame #31 pc 0004cde7 /system/lib/libandroid_runtime.so
The solution actually was related to libc.so, specifically the standard template library I was using in Android NDK linking. In my Android.MK file, I was using stlport_shared to link with native opencv library. Opencv actually does not support stlport_shared library, but rather gnu_stl_shared. With the change made, no problems of this type :)
Hope this helps with others who potentially have the same issue linking with other libraries. Always make sure they are compatible.
Related
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadd00d
#00 pc 0x50f8e /system/lib/libdvm.so (dvmAbort+89)
#01 pc 0x59ee1 /system/lib/libdvm.so (dvmLinearAlloc(Object*, unsigned int)+64)
#02 pc 0x76a7b /system/lib/libdvm.so (???)
#03 pc 0x76d77 /system/lib/libdvm.so (dvmDefineClass(DvmDex*, char const*, Object*)+10)
#04 pc 0x71583 /system/lib/libdvm.so (???)
#05 pc 0x30c0c /system/lib/libdvm.so (???)
#06 pc 0x343dc /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)
#07 pc 0x6d109 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+284)
#08 pc 0x6d12d /system/lib/libdvm.so (dvmCallMethod(Thread*, Method const*, Object*, JValue*, ...)+20)
#09 pc 0x76e69 /system/lib/libdvm.so (dvmFindClassNoInit(char const*, Object*)+108)
#10 pc 0x6216b /system/lib/libdvm.so (???)
#11 pc 0x62287 /system/lib/libdvm.so (???)
#12 pc 0x65a6d /system/lib/libdvm.so (dvmVerifyCodeFlow(VerifierData*)+9760)
#13 pc 0x68c91 /system/lib/libdvm.so (???)
#14 pc 0x68ce3 /system/lib/libdvm.so (dvmVerifyClass(ClassObject*)+42)
#15 pc 0x7704d /system/lib/libdvm.so (dvmInitClass+116)
#16 pc 0x742d1 /system/lib/libdvm.so (???)
#17 pc 0x30c0c /system/lib/libdvm.so (???)
#18 pc 0x343dc /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)
#19 pc 0x6ce39 /system/lib/libdvm.so (dvmInvokeMethod(Object*, Method const*, ArrayObject*, ArrayObject*, ClassObject*, bool)+344)
#20 pc 0x73b19 /system/lib/libdvm.so (???)
#21 pc 0x30c0c /system/lib/libdvm.so (???)
#22 pc 0x343dc /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)
#23 pc 0x6ce39 /system/lib/libdvm.so (dvmInvokeMethod(Object*, Method const*, ArrayObject*, ArrayObject*, ClassObject*, bool)+344)
#24 pc 0x7431b /system/lib/libdvm.so (???)
#25 pc 0x30c0c /system/lib/libdvm.so (???)
#26 pc 0x343dc /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)
#27 pc 0x6d109 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+284)
#28 pc 0x554af /system/lib/libdvm.so (???)
#29 pc 0x48c6b /system/lib/libandroid_runtime.so (???)
#30 pc 0x4a81f /system/lib/libandroid_runtime.so (android::AndroidRuntime::start(char const*, char const*)+394)
#31 pc 0xf0d /system/bin/app_process (???)
java.lang.Throwable:
******* Java stack for JNI crash *******
at dalvik.system.DexFile.defineClass(Native Method)
at dalvik.system.DexFile.loadClassBinaryName(DexFile.java:195)
at dalvik.system.DexPathList.findClass(DexPathList.java:315)
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:58)
at java.lang.ClassLoader.loadClass(ClassLoader.java:501)
at java.lang.ClassLoader.loadClass(ClassLoader.java:461)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.lily.dexLoader.invokeStaticMethod(SourceFile:70)
at com.lily.sdk.Web.<init>(SourceFile:77)
......
I can not reproduce this crash through my android app, but the monitor system reports this kind of crash many times.
It is not clear whether the dex is broken or the system dalvik is not stable.
Does anyone has any experience on this kind of loadClass crash?
If the VM detects a serious problem, it will send diagnostics to the log, and abort. The VM in the version of Android you're using crashes itself by attempting to write to a read-only location (0xdeadd00d).
Looking at the stack trace, the last thing before dvmAbort() is dvmLinearAlloc(). Looking at a recent source file, the VM will abort in that function if it runs out of memory to allocate, or if it's unable to change the permissions on a page while in a special debug mode where pages are aggressively marked read-only. It's almost certainly the former. Looking at the logcat output would tell you for sure.
Assuming you're running out of memory, I'd guess you're running an old version of Android (<= gingerbread), where the "linear alloc" buffer was under-sized. This region of memory is used to hold class meta-data, such as tables of methods and fields, but not the data itself (which is why it can be marked read-only to help hunt for memory trashers). The only way to avoid the problem is to restructure the classes.
You can read more about the problem, and a solution deployed by Facebook engineers, in this blog post.
I was examining some ARM crashes on Android and realised some memory addresses positions are not 2-byte aligned (THUMB/ARM) but some are. Does any one know why is that so? Here is an example tombstone:
Stack frame #00 pc 00072c9a /system/lib/libdvm.so (dvmAbort+170)
Stack frame #01 pc 00050f6b /system/lib/libdvm.so (ScopedCheck::checkInstanceFieldID(_jobject*, _jfieldID*)+379)
Stack frame #02 pc 0005db56 /system/lib/libdvm.so (Check_SetBooleanField(_JNIEnv*, _jobject*, _jfieldID*, unsigned char)+150)
Stack frame #03 pc 00003a93 /system/lib/libmytestt.so (Java_com_test_jni_MyLibWrapper_getMonitorSample+259)
Stack frame #04 pc 0002d850 /system/lib/libdvm.so (dvmPlatformInvoke+80)
Stack frame #05 pc 00085b48 /system/lib/libdvm.so (dvmCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)+648)
Stack frame #06 pc 000505db /system/lib/libdvm.so (dvmCheckCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)+59)
Stack frame #07 pc 0008b96d /system/lib/libdvm.so (dvmResolveNativeMethod(unsigned int const*, JValue*, Method const*, Thread*)+317)
Stack frame #08 pc 00170ff1 /system/lib/libdvm.so
One can see that #00, #02 are 2 byte aligned while #01 and #03 are not. Any explanation of why is it so? Thanks.
I would guess that the odd addresses indicate that those functions are in THUMB mode, while the even addresses are in ARM mode. When returning from a function with bx lr, the processor will switch from ARM mode to THUMB or vice versa depending on the lowest bit of the address, so I'd guess this is what you end up seeing in the backtrace as well.
I'm having a bad issue with Android NDK. My app crashes with error 11 but the problem is that the stack dump makes no sense.
********** Crash dump: **********
Build fingerprint: 'samsung/p4noterfub/p4noterf:4.1.2/JZO54K/N8000UBCML2:user/release-keys'
pid: 27557, tid: 27557, name: com.nirai.app >>> com.nirai.app <<<
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 5d2b601c
Stack frame #00 pc 000046d2 /system/bin/linker
Stack frame #01 pc 00005c3b /system/bin/linker
Stack frame #02 pc 0004f90d /system/lib/libandroid_runtime.so
Stack frame #03 pc 0001df30 /system/lib/libdvm.so (dvmPlatformInvoke+112)
Stack frame #04 pc 0004d183 /system/lib/libdvm.so (dvmCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)+394)
Stack frame #05 pc 00027360 /system/lib/libdvm.so
Stack frame #06 pc 0002bc68 /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+180)
Stack frame #07 pc 0005fbb7 /system/lib/libdvm.so (dvmInvokeMethod(Object*, Method const*, ArrayObject*, ArrayObject*, ClassObject*, bool)+374)
Stack frame #08 pc 00067165 /system/lib/libdvm.so
Stack frame #09 pc 00027360 /system/lib/libdvm.so
Stack frame #10 pc 0002bc68 /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+180)
Stack frame #11 pc 0005f8f1 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+272)
Stack frame #12 pc 00049773 /system/lib/libdvm.so
Stack frame #13 pc 0004c169 /system/lib/libandroid_runtime.so
Stack frame #14 pc 0004d2cb /system/lib/libandroid_runtime.so (android::AndroidRuntime::start(char const*, char const*)+390)
Stack frame #15 pc 00000dcf /system/bin/app_process
Crash dump is completed
There's no reference to my lib (libtest.so) so I'm lost now!
Extra info:
NDK r8d
API 9
Testing on real unrooted device (emulator hangs with no crash)
The error seems to happen at System.load - your
NDK r8d is really old (~2012) , lot of bugs were fixed since then, strongly suggest you update to latest NDK version r10b and try rebuilding your app with new toolchain.
Android NDK error while running application find this error in logcat.
Build fingerprint: 'i1017/i1017/i1017:4.1.1/JRO03H/20130601.100904:eng/release-keys'
pid: 1981, tid: 1990, name: FinalizerDaemon >>> com.verve.rummy <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad
Stack frame #00 pc 00013778 /system/lib/libc.so
Stack frame #01 pc 00015b55 /system/lib/libc.so (dlfree+1628)
Stack frame #02 pc 00016d03 /system/lib/libc.so (free+10)
Stack frame #03 pc 0001de30 /system/lib/libdvm.so (dvmPlatformInvoke+112)
Stack frame #04 pc 0004d083 /system/lib/libdvm.so (dvmCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)+394)
Stack frame #05 pc 00027260 /system/lib/libdvm.so
Stack frame #06 pc 0002bb68 /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+180)
Stack frame #07 pc 0005f7f1 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+272)
Stack frame #08 pc 0005f81b /system/lib/libdvm.so (dvmCallMethod(Thread*, Method const*, Object*, JValue*, ...)+20)
Stack frame #09 pc 000543d3 /system/lib/libdvm.so
Stack frame #10 pc 00012b70 /system/lib/libc.so (__thread_entry+48)
Stack frame #11 pc 000122c8 /system/lib/libc.so (pthread_create+172)
I am getting this type of error in stack while running my android game.
Above i put my error log please help me for resolve this error.
Due to this my game crashes randomly.
I am using android NDK for build application
Sorry for my poor English.
Thanks in advance.
I found a very strange issue.when I try to invoke connect() in signal1.(sigslot.h).
m_connected_slots.push_back(conn);
it doesn't work.
For example.
std::list<_connection_base1<arg1_type, mt_policy> *> connections_list_test;
connections_list_test.push_back(conn);
If I create a temp list named connections_list_test.It can work and push_back is correctly.
But the m_connected_slots can't push_back.
Obviously I must be hitting some nonstandard behavior in the STL library i'm using.
Can you guys give some suggest about this issue? or some other android porting experience?
Here is some logs for this:
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0000008c
Stack frame #00 pc 00096f7a /data/data/com.molo.app/lib/libjingle_jni.so: Routine insert in /Users/gongchen/Dev/android-ndk-r8/sources/cxx-stl/stlport/stlport/stl/_list.h:427
Stack frame #01 pc 00098ae8 /data/data/com.molo.app/lib/libjingle_jni.so: Routine MoloClient in /Users/gongchen/Dev/Eclipse_workspace/P2Pdemo/jni/talk/mymolo/moloclient.cc:136
Stack frame #02 pc 00094f54 /data/data/com.molo.app/lib/libjingle_jni.so: Routine Java_com_molo_app_NativeMethod_doLogin in /Users/gongchen/Dev/Eclipse_workspace/P2Pdemo/jni/com_molo_app_NativeMethod.cc:215
Stack frame #03 pc 00017d74 /system/lib/libdvm.so
Stack frame #04 pc 00048f54 /system/lib/libdvm.so
Stack frame #05 pc 00041b16 /system/lib/libdvm.so
Stack frame #06 pc 0004e624 /system/lib/libdvm.so
Stack frame #07 pc 0001cfd4 /system/lib/libdvm.so
Stack frame #08 pc 000220dc /system/lib/libdvm.so
Stack frame #09 pc 00020fd0 /system/lib/libdvm.so
Stack frame #10 pc 0005f430 /system/lib/libdvm.so
Stack frame #11 pc 0005f656 /system/lib/libdvm.so
Stack frame #12 pc 00053b4e /system/lib/libdvm.so
Stack frame #13 pc 00011a7c /system/lib/libc.so
Stack frame #14 pc 00011640 /system/lib/libc.so