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

我正在尝试调试内存泄漏问题。我正在使用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

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

有人知道如何解释吗？一个电话怎么会导致4个分配？以及malloc如何返回先前已分配的地址？

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

最佳答案

分配内存的函数被多次调用。调用者地址指向进行分配的代码，并且该代码仅运行了不止一次。

这是C语言中的一个示例:

void *allocate (void)
{
  return (malloc(1000));
}

int main()
{
  mtrace();
  allocate();
  allocate();
}

mtrace的输出为:

内存未释放:
-----------------
地址大小调用者
0x0000000000601460 0x3e8在0x4004f6
0x0000000000601850 0x3e8在0x4004f6

请注意，调用方地址如何相同？这就是mtrace分析脚本说它们相同的原因，因为同一错误被查看一次以上，从而导致多次内存泄漏。

如果可以，使用调试标志(-g)进行编译将很有帮助:

内存未释放:
-----------------
地址大小调用者
0x0000000000601460 0x3e8位于/home/andrjohn/development/playground/test.c:6
0x0000000000601850 0x3e8位于/home/andrjohn/development/playground/test.c:6

关于c - GLIBC:调试内存泄漏:如何解释mtrace()的输出，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/153953/