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

在这两行之间,块0x2aaab43a1700永远不会被释放.

有谁知道如何解释这个？一次调用如何导致4次分配？而malloc如何返回之前已分配的地址？

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

Answer 1

你正在研究mtrace的直接输出,这非常令人困惑和违反直觉.幸运的是,有一个perl脚本(在glibc-utils中可以找到mtrace),它可以很容易地帮助解析这个输出.

通过调试编译您的构建,并运行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

输出应该是一个很多更容易消化.

Answer 2

分配内存的功能被多次调用.调用者地址指向执行分配的代码,并且该代码只是多次运行.

这是C中的一个例子:

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

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

mtrace的输出是:

Memory not freed:
-----------------
           Address     Size     Caller
0x0000000000601460    0x3e8  at 0x4004f6
0x0000000000601850    0x3e8  at 0x4004f6

请注意来电者地址是如何相同的？这就是为什么mtrace分析脚本说它们是相同的,因为同样的错误被多次看到,导致几次内存泄漏.

如果您可以:使用调试标志(-g)进行编译是有帮助的:

Memory not freed:
-----------------
           Address     Size     Caller
0x0000000000601460    0x3e8  at /home/andrjohn/development/playground/test.c:6
0x0000000000601850    0x3e8  at /home/andrjohn/development/playground/test.c:6