c - GLIBC:调试内存泄漏:如何解释 mtrace() 的输出

Question

我正在尝试调试内存泄漏问题。我正在使用 mtrace()获取 malloc/free/realloc 跟踪。我已经运行了我的程序，现在有一个巨大的日志文件。到目前为止，一切都很好。但是我在解释文件时遇到问题。看看这些行:

@ /usr/java/ibm-java2-x86_64-50/jre/bin/libj9prt23.so:[0x2b270a384a34] + 0x1502570 0x68
@ /usr/java/ibm-java2-x86_64-50/jre/bin/libj9prt23.so:[0x2b270a384a34] + 0x1502620 0x30
@ /usr/java/ibm-java2-x86_64-50/jre/bin/libj9prt23.so:[0x2b270a384a34] + 0x2aaab43a1700 0xa80
@ /usr/java/ibm-java2-x86_64-50/jre/bin/libj9prt23.so:[0x2b270a384a34] + 0x1501460 0xa64

奇怪的是一次调用(相同的返回地址)负责 4 次分配。

更陌生:

@ /usr/java/ibm-java2-x86_64-50/jre/bin/libj9prt23.so:[0x2b270a384a34] + 0x2aaab43a1700 0xa2c
…
@ /usr/java/ibm-java2-x86_64-50/jre/bin/libj9prt23.so:[0x2b270a384a34] + 0x2aaab43a1700 0xa80

在这两行之间， block 0x2aaab43a1700 永远不会被释放。

有人知道怎么解释吗？一次调用如何导致 4 次分配？ malloc 如何返回一个之前已经分配的地址？

编辑 2008/09/30:GLIBC (mtrace.pl) 提供的用于分析 mtrace() 输出的脚本在这里没有任何帮助。它只会说:Alloc 0x2aaab43a1700 duplicate。但这怎么会发生呢？

Answer 1

您正在查看 mtrace 的直接输出，这非常令人困惑且违反直觉。幸运的是，有一个 perl 脚本(称为 mtrace，可在 glibc-utils 中找到)可以非常轻松地帮助解析此输出。

在调试的情况下编译您的构建，并像这样运行 mtrace:

$ gcc -g -o test test.c
$ MALLOC_TRACE=mtrace.out ./test
$ mtrace test mtrace.out

Memory not freed:
-----------------
   Address     Size     Caller
0x094d9378    0x400  at test.c:6

输出应该很多更容易理解。