ABORTING: HEAP MEMORY CORRUPTION on NDK env. (POCO Library, Sqlite3, Cocos2dx)

Question

I'm facing 'ABORTING: HEAP MEMORY CORRUPTION' problem on Android NDK environment.

If I backtrace with ndk-gdb, it is mainly occurring on malloc/dlfree functions in libc.so and after long hours of tracing the problem, it mostly happens inside sqlite3_xxx function calls, which absolutely working fine on iOS env.

I just can't find where I have to go deep.

Have anyone encountered similar problem and fixed?

Solution 1

1. I have seen memory problems, but not 'ABORTING: HEAP MEMORY CORRUPTION' that you report.

2. You have to find out which heap is corrupt: the Java one or the C/C++ one. Or it maybe your sql. If the log is not informative, you may try to locate the error message in the binaries.

3. If it is the C/C++ heap, what worked for me was replacing the standard malloc/calloc/free with my own versions.

   #define malloc(x) myMalloc(x, __FILE__,__LINE__,__func__)
   

   and so on; myMalloc() and friends print debug information so that you can find out where memory was allocated and freed. I had the source of the library and could compile it. Then logging, logging, logging...

   #include <android/log.h>
   #define LOGD(...) __android_log_print(ANDROID_LOG_DEBUG  , "~~~~~~", __VA_ARGS__)
   #define DLOG(...) __android_log_print(ANDROID_LOG_DEBUG  , "~~~~~~", __VA_ARGS__)
   

   I also made myMalloc() zero the allocated memory -- just in case. One more trick is to allocate a larger chuck and put a guard value in the end of it. If that value gets corrupt -- you see.

4. If it is the Java heap, you will have to log your native function calls (I myself have never seen problems in the Java heap, usually Java complains about its JNI-specific stuff).

Solution 2

For my program, 'ABORTING: HEAP MEMORY CORRUPTION' shows when there are thread safety issues. Specifically with Cocos2d-x framework, its getFileData() function of ZipUtils may crash when loading .plist atlas and addImageAsync() at the same time on Android. Though the codes works fine on iOS.

Comments

[Locke]

Thank you. Your answer is the kinda golden rule which all developers should try at least, but I think I was too lazy.

[Locke]

BTW, I chose dirty way to write down logs to check where the code actually crashes and I found that I was hallucinated by the stack trace. The place where code actually crashes was the call to enqueueXXX of POCO::NotificationQueue class. I think I did some mistake around there. Funny that iOS devices never complained about that.

[Locke]

Till now I was assuming there must be some specific compiler options or other build settings I need to check. Thanks again.