1

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
blkhatpersian
  • 437
  • 6
  • 18
  • 1
    Something called `free()`, and the malloc implementation discovered that the heap was corrupted. Having the stack trace isn't all that useful, because it only tells you where you what was executing when the problem was *found*, not when the problem was *caused*. There are various tools, such as valgrind, that can help here, though getting them to work on Android can be an experience. The easiest to use is the built-in malloc debug stuff; see http://stackoverflow.com/questions/21028422/setprop-libc-debug-malloc-1-is-not-working/21033514#21033514 . – fadden Mar 03 '14 at 20:29
  • Will try it now, thanks fadden! If it works, I'll be sure to post back and request you create the same post as an answer so I can credit you. – blkhatpersian Mar 03 '14 at 20:31
  • Actually I cannot use this method. I did enable native heap with DDMS, but nothing showed. Looking at the older articles that I realized that I need the libcdebug.so and that require installing something like Cyanogenmod. It is a company phone so I cannot modify anything using that – blkhatpersian Mar 03 '14 at 21:57
  • 1
    Do you get an ANR before the crash? – JonnyBoy Sep 11 '14 at 17:11
  • No ANR before the crash, but thank you for responding JonnyBoy. 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 :) – blkhatpersian Sep 17 '14 at 21:48

1 Answers1

0

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.

blkhatpersian
  • 437
  • 6
  • 18