Leak sanitizer - 如何追踪非动态未知模块？

问题描述 投票：0回答：1

示例：Java 源代码

Foo.java
：

public class Foo {
    public static void main(String[] args) {}
};

我在 Ubuntu 24.04 docker 上运行它，并预加载了地址清理程序（包含泄漏清理程序），并根据 github 问题 加上了 dlopen/dlclose 拦截器。 Java 编译器和启动器来自 

openjdk-8-jdk
包。

javac Foo.java
LD_PRELOAD="/usr/lib/llvm-17/lib/clang/17/lib/linux/libclang_rt.asan-x86_64.so:/root/libinterceptor.so" java Foo

拦截器代码为

#define _GNU_SOURCE
#include <dlfcn.h>
#include <link.h>
#include <stdio.h>
#include <string.h>

int dlclose(void *handle) {
    printf("Intercepted a dlclose call, handle %ld\n", (intptr_t)handle);
    return 0;
}

void* dlopen(const char* filename, int flags){
    typedef void* (*dlopen_t)(const char*, int);
    dlopen_t original_dlopen = (dlopen_t)dlsym(RTLD_NEXT, "dlopen");

    flags |= RTLD_NODELETE;
    void *ret = original_dlopen(filename, flags);
    printf("Intercepted a dlopen call for %s, handle %ld, injecting RTLD_NODELETE\n", filename, (intptr_t)ret);
    return ret;
}

报告了许多（误报）内存泄漏。这很好，它们很可能是由于垃圾收集和泄漏消毒器无法了解那里发生的情况而造成的。我不是在问如何处理它们，我知道我应该忽略它们，因为它们是误报，我用它们来演示手头的问题。 lsan错误输出部分：

Direct leak of 120 byte(s) in 1 object(s) allocated from:
    #0 0x7f3d1c0fb372 in malloc (/usr/lib/llvm-17/lib/clang/17/lib/linux/libclang_rt.asan-x86_64.so+0xfb372) (BuildId: 91f375f2a48c6b133a56d8cc059d017ae5de4982)
    #1 0x7f3d17f8c7b4  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x98c7b4) (BuildId: d38655f827ac6a65fdbe1898b1278717fdb89a4e)
    #2 0x7f3d178d29bd  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x2d29bd) (BuildId: d38655f827ac6a65fdbe1898b1278717fdb89a4e)
    #3 0x7f3d178d2a7a  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x2d2a7a) (BuildId: d38655f827ac6a65fdbe1898b1278717fdb89a4e)
    #4 0x7f3d17af07a9  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x4f07a9) (BuildId: d38655f827ac6a65fdbe1898b1278717fdb89a4e)
    #5 0x7f3d17a5ac4d  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x45ac4d) (BuildId: d38655f827ac6a65fdbe1898b1278717fdb89a4e)
    #6 0x7f3d17a5c3ca  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x45c3ca) (BuildId: d38655f827ac6a65fdbe1898b1278717fdb89a4e)
    #7 0x7f3d17a6323a  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x46323a) (BuildId: d38655f827ac6a65fdbe1898b1278717fdb89a4e)
    #8 0x7f3d180c3a34  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0xac3a34) (BuildId: d38655f827ac6a65fdbe1898b1278717fdb89a4e)
    #9 0x7f3d180c4680  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0xac4680) (BuildId: d38655f827ac6a65fdbe1898b1278717fdb89a4e)
    #10 0x7f3d180c64c4  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0xac64c4) (BuildId: d38655f827ac6a65fdbe1898b1278717fdb89a4e)
    #11 0x7f3d17af25d7  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x4f25d7) (BuildId: d38655f827ac6a65fdbe1898b1278717fdb89a4e)
    #12 0x7f3d17af36b9  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x4f36b9) (BuildId: d38655f827ac6a65fdbe1898b1278717fdb89a4e)
    #13 0x7f3d17e59707  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x859707) (BuildId: d38655f827ac6a65fdbe1898b1278717fdb89a4e)
    #14 0x7f3d17e5b308  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x85b308) (BuildId: d38655f827ac6a65fdbe1898b1278717fdb89a4e)
    #15 0x7f3d17ca99cb  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x6a99cb) (BuildId: d38655f827ac6a65fdbe1898b1278717fdb89a4e)
    #16 0x7f3d07a24dc7  (<unknown module>)
    #17 0x7f3d07a080f5  (<unknown module>)
    #18 0x7f3d07a004e6  (<unknown module>)
    #19 0x7f3d17cb2884  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x6b2884) (BuildId: d38655f827ac6a65fdbe1898b1278717fdb89a4e)
    #20 0x7f3d17d2e75e  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x72e75e) (BuildId: d38655f827ac6a65fdbe1898b1278717fdb89a4e)
    #21 0x7f3d17d2efbf  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x72efbf) (BuildId: d38655f827ac6a65fdbe1898b1278717fdb89a4e)
    #22 0x7f3d1bac6c8a in JNU_NewStringPlatform (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/libjava.so+0x1dc8a) (BuildId: 95ab745b31a25f66a623ffeaf6822cdc641c5fab)
    #23 0x7f3d1babf2cb in Java_java_lang_System_initProperties (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/libjava.so+0x162cb) (BuildId: 95ab745b31a25f66a623ffeaf6822cdc641c5fab)
    #24 0x7f3d07a185e6  (<unknown module>)
    #25 0x7f3d07a07e3f  (<unknown module>)
    #26 0x7f3d07a004e6  (<unknown module>)
    #27 0x7f3d17cb2884  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x6b2884) (BuildId: d38655f827ac6a65fdbe1898b1278717fdb89a4e)
    #28 0x7f3d17cb115e  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x6b115e) (BuildId: d38655f827ac6a65fdbe1898b1278717fdb89a4e)
    #29 0x7f3d17cb179f  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x6b179f) (BuildId: d38655f827ac6a65fdbe1898b1278717fdb89a4e)

问题在于：很多泄漏报告在堆栈跟踪中都有 

<unknown module>
。 我的问题是如何将它们变成已知的库，以便我可以跟踪发生的情况。我并不是真的专门询问Java，这只是我遇到它的一个例子 - 但它可能特定于Java启动器或其他程序。

如果

<unknown module>
是由动态加载或卸载引起的，那么拦截
dlopen
或
dlclose
就足够了。然而，我得到的唯一标准输出是

Intercepted a dlopen call for /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so, handle 89747636617344, injecting RTLD_NODELETE
Intercepted a dlopen call for librt.so.1, handle 89747636681856, injecting RTLD_NODELETE
Intercepted a dlopen call for /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/libverify.so, handle 89747636684928, injecting RTLD_NODELETE
Intercepted a dlopen call for /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/libjava.so, handle 89747636686464, injecting RTLD_NODELETE
Intercepted a dlopen call for /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/libzip.so, handle 89747636688000, injecting RTLD_NODELETE
Intercepted a dlopen call for (null), handle 139900452795104, injecting RTLD_NODELETE
Intercepted a dlopen call for /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/libzip.so, handle 89747636688000, injecting RTLD_NODELETE
Intercepted a dlopen call for /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/libnio.so, handle 89747636689536, injecting RTLD_NODELETE

没有 dlclose 行，并且没有一个句柄（转换为十六进制，不计算 nullptr 文件名的主程序）与 

<unknown module>
s 中出现的地址范围匹配 - 可能与 ASLR 有关。最重要的是，
<unknown module>
仍然出现在lsan错误输出中，因此这种方法要么无法阻止卸载，要么问题不是由动态加载/卸载引起的。

如何找出哪些库对应于

<unknown module>
s？

java c memory-leaks stack-trace address-sanitizer
1个回答
0
投票

JVM JIT 编译的代码和某些内部应用程序可能会显示为 

<unknown module>
，因此确认这一点的最简单方法是将原始地址与实际加载的库进行映射。典型的方法是在运行时检查 
/proc/[pid]/maps
（或使用 pmap 之类的东西）并查看哪些区域与报告的地址匹配。

您还可以尝试启用更详细的 ASan/LSan 选项：

导出 

ASAN_SYMBOLIZER_PATH
以指向 LLVM 符号器并设置 
ASAN_OPTIONS=symbolize=1,print_module_map=2
（对于 
LSAN_OPTIONS
也类似），以便清理程序吐出更详细的库映射，否则可能会错过这些映射。如果它仍然显示 
<unknown module>
，则可能是 JIT 代码或 JVM 在私有映射中分配的内容，但没有相应的文件支持库。有时，您可以强制 JVM 保留更多帧指针或生成更多可调试代码（使用 
-XX:+PreserveFramePointer
和 
-XX:+UnlockDiagnosticsVMOptions -XX:+DebugNonSafepoints
，以便清理程序可以更好地展开并标记这些堆栈帧。

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.