3

I tried to use setprop libc.debug.malloc = 1 to find out leak. I made an demo program and introduced memory leak in that but the above flag is not able to detect this leak. I tried below commands: adb shell setprop libc.debug.malloc 1 adb shell stop adb shell start

jstring Java_com_example_hellojni_HelloJni_stringFromJNI(JNIEnv* env,
jobject thiz) {
int *p = malloc(sizeof(int));
p[1] = 100;
return (*env)->NewStringUTF(env, "Hello from JNI !");
}

Any help would be appreciated.

Thanks

Mayank
  • 55
  • 2
  • 8

1 Answers1

6

libc.debug.malloc is not valgrind. It tracks native heap allocations, but doesn't really detect leaks directly. It works best in conjuction with DDMS; see this answer for information about using it for native leak chasing (and maybe this older answer).

(Note you can use valgrind on recent versions of Android, but getting it set up can be an adventure.)

FWIW, different levels of libc.debug.malloc are reasonably good at finding use-after-free and buffer overruns:

/* 1  - For memory leak detections.
 * 5  - For filling allocated / freed memory with patterns defined by
 *      CHK_SENTINEL_VALUE, and CHK_FILL_FREE macros.
 * 10 - For adding pre-, and post- allocation stubs in order to detect
 *      buffer overruns.

For example, if you set libc.debug.malloc = 10 and add a free() call to your example above, you'll likely get a warning message from the library because you set p[1] rather than p[0].

Community
  • 1
  • 1
fadden
  • 51,356
  • 5
  • 116
  • 166
  • Thanks.I tired to free also and it gives me logs but didn't mention anything about lib libhello-jni.so (it's my project so file),although logs have pid and component package name but,this information is very less ( function name where is occurred would be more helpful). I also tried valgrind, it provide memory leaks and both invalid write, but it makes app very slow. The app which I need to test is crashes randomly after some-time.I am looking for way which provides memory leak and memory corruption while app remain quite responsive. – Mayank Jan 10 '14 at 06:21
  • Setting libc.debug.malloc to 5 or 10 will find a fair number of problems. It's not as thorough as valgrind -- it won't help you with stack trashers or uninitialized values, for example -- but it's much faster. – fadden Jan 10 '14 at 06:33