0

I'm running C++ application with some parts written in Java. For that I'm running JVM inside with the help of JNI. I enable ASan, a suite of sanitizers, to detect leaks (specifically LSan). It detects leaks and reports it at the end of the run with stack trace of the corresponding memory allocations.

The problem is, it reports couple of issues with the backtrace without any symbols only for Java code.

  1. Is there a way I can symbolizes these addresses?
  2. What are those unknown module and how can I symbolize that?

Example stack trace:

Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x4be0ed in malloc (/path/to/my/binary+0x4be0ed)
#1 0x7f047a6ebd2c  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x958d2c)
#2 0x7f047a3a3cee  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x610cee)
#3 0x7f047a695f8d  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x902f8d)
#4 0x7f047a3e44ff  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x6514ff)
#5 0x7f047a690c82  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x8fdc82)
#6 0x7f047a693137  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x900137)
#7 0x7f047a6933ec  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x9003ec)
#8 0x7f0466ad17a6  (<unknown module>)
#9 0x7f0466ac0e3f  (<unknown module>)
#10 0x7f0466ac0e3f  (<unknown module>)
#11 0x7f0466ac0e3f  (<unknown module>)
#12 0x7f0466ac0e3f  (<unknown module>)
#13 0x7f0466ac0e3f  (<unknown module>)
#14 0x7f0466ac0e3f  (<unknown module>)
#15 0x7f0466ac0e3f  (<unknown module>)
#16 0x7f0466ac0e3f  (<unknown module>)
#17 0x7f0466ac0e3f  (<unknown module>)
#18 0x7f0466ac0e3f  (<unknown module>)
#19 0x7f0466ab94e6  (<unknown module>)
#20 0x7f047a42a48f  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x69748f)
#21 0x7f047a428b8e  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x695b8e)
#22 0x7f047a82bc3e  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0xa98c3e)
#23 0x7f047a5ae365  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x81b365)
#24 0x7f047a5b5706  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x822706)
#25 0x7f047a5b6e24  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x823e24)
#26 0x7f047a41dbd0  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x68abd0)
#27 0x7f0466ae2a87  (<unknown module>)
#28 0x7f0466ac10f5  (<unknown module>)
#29 0x7f0466ac0e3f  (<unknown module>)

Second example:

Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x4be0ed in malloc (/path/to/my/binary+0x4be0ed)
#1 0x7f047a6ebd2c  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x958d2c)
#2 0x7f047a1d4538  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x441538)
#3 0x7f047a1d45f4  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x4415f4)
#4 0x7f047a3e4e58  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x651e58)
#5 0x7f047a3e4eb6  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x651eb6)
#6 0x7f047a49ceb9  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x709eb9)
#7 0x7f0475cd6e8c in Java_java_lang_System_setIn0 (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/libjava.so+0x14e8c)
#8 0x7f0466ad17a6  (<unknown module>)
#9 0x7f0466ac10f5  (<unknown module>)
#10 0x7f0466ab94e6  (<unknown module>)
#11 0x7f047a42a48f  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x69748f)
#12 0x7f047a428b8e  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x695b8e)
#13 0x7f047a429187  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x696187)
#14 0x7f047a864f9a  (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0xad1f9a)
#15 0x7f047a4ab81e in JNI_CreateJavaVM (/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so+0x71881e)
#16 0x71c1ab in jni::JVMManager::Start() /path/.../jni/jvm_manager.cpp:138:17
#17 0x4f3fbe in (anonymous namespace)::maybe_setup_jvm(...) /path/to/my/main/file.cpp:48:30
#18 0x4f3fbe in main /path/to/my/main/file.cpp:158:22
#19 0x7f04798c7d09 in __libc_start_main csu/../csu/libc-start.c:308:16
vpshastry
  • 81
  • 1
  • 7
  • I see this, somewhat related, solution https://stackoverflow.com/a/61645803/1095269. I'm trying to understand how does the async-profiler do this that can be employed with LSan. – vpshastry Mar 07 '23 at 21:06
  • LSan is not a Java aware profiler, it cannot get Java stack traces, since JVM stack layout is totally different from the layout of native frames. In contrast, async-profiler *is* a Java profiler. It has a [special mode](https://github.com/async-profiler/async-profiler/blob/malloc/README.md#finding-native-memory-leaks) for finding native memory leaks. [Here](https://github.com/async-profiler/async-profiler/discussions/491) are some more details. – apangin Mar 07 '23 at 22:25

0 Answers0