【问题标题】:setprop libc.debug.malloc = 1 is not workingsetprop libc.debug.malloc = 1 不工作
【发布时间】:2014-01-28 11:42:40
【问题描述】:

我尝试使用 setprop libc.debug.malloc = 1 来找出泄漏。 我制作了一个演示程序并在其中引入了内存泄漏,但上面的标志无法检测到这种泄漏。 我尝试了以下命令: adb shell setprop libc.debug.malloc 1 adb 外壳停止 adb shell 启动

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 !");
}

任何帮助将不胜感激。

谢谢

【问题讨论】:

    标签: android memory-leaks android-ndk native


    【解决方案1】:

    libc.debug.malloc 不是 valgrind。它跟踪本机堆分配,但并不真正直接检测泄漏。它与 DDMS 结合使用效果最佳;请参阅this answer 了解有关将其用于本机泄漏追踪的信息(可能还有this older answer)。

    (请注意,您可以在最新版本的 Android 上使用 valgrind,但设置它可能是一次冒险。)

    FWIW,不同级别的 libc.debug.malloc 相当擅长发现 use-after-free 和缓冲区溢出:

    /* 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.
    

    例如,如果您设置libc.debug.malloc = 10 并在上面的示例中添加free() 调用,您可能会从库中收到一条警告消息,因为您设置了p[1] 而不是p[0]

    【讨论】:

    • 谢谢。我也厌倦了释放,它给了我日志,但没有提到任何关于 lib libhello-jni.so 的内容(这是我的项目 so 文件),虽然日志有 pid 和组件包名称但是,此信息非常少(发生的函数名称会更有帮助)。我还尝试了 valgrind,它提供内存泄漏和无效写入,但它使应用程序非常慢。我需要测试的应用程序在一段时间后随机崩溃。我正在寻找在应用程序保持相当响应的同时提供内存泄漏和内存损坏的方法。
    • 将 libc.debug.malloc 设置为 5 或 10 会发现很多问题。它不像 valgrind 那样彻底——例如,它不会帮助你处理堆栈垃圾或未初始化的值——但它要快得多。
    猜你喜欢
    • 2017-03-30
    • 2015-09-13
    • 1970-01-01
    • 1970-01-01
    • 2014-11-07
    • 2016-04-12
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多