4

这个最小的程序：

int main()
{
  return 0;
}

当使用 valgrind 编译gcc和运行时工作得很好。

编译为 D 程序时使用

dmd test_new.d && valgrind ./test_new

我得到：

HEAP SUMMARY:
    in use at exit: 360 bytes in 4 blocks
  total heap usage: 22 allocs, 18 frees, 52,024 bytes allocated

LEAK SUMMARY:
   definitely lost: 288 bytes in 3 blocks
   indirectly lost: 0 bytes in 0 blocks
     possibly lost: 0 bytes in 0 blocks
   still reachable: 72 bytes in 1 blocks
        suppressed: 0 bytes in 0 blocks

使用 gdc：

gdc -o test_new test_new.d && valgrind ./test_new

我明白了

HEAP SUMMARY:
    in use at exit: 568 bytes in 4 blocks
  total heap usage: 23 allocs, 19 frees, 52,664 bytes allocated

LEAK SUMMARY:
   definitely lost: 496 bytes in 3 blocks
   indirectly lost: 0 bytes in 0 blocks
     possibly lost: 0 bytes in 0 blocks
   still reachable: 72 bytes in 1 blocks
        suppressed: 0 bytes in 0 blocks

这里有什么问题？

4

3 回答 3

5

如果您将 --leak-check=full 选项与 valgrind 一起使用，它会告诉您泄漏的位置。

我有

    ==32630== HEAP SUMMARY:
    ==32630==     in use at exit: 136 bytes in 4 blocks
    ==32630==   total heap usage: 16 allocs, 12 frees, 49,992 bytes allocated
    ==32630== 
    ==32630== 40 bytes in 1 blocks are definitely lost in loss record 4 of 4
    ==32630==    at 0x4026A68: calloc (vg_replace_malloc.c:566)
    ==32630==    by 0x8051C93: _d_monitor_create (in /home/dave/stack/test_new)
    ==32630==    by 0x8055B4F: thread_joinAll (in /home/dave/stack/test_new)
    ==32630==    by 0x804E47E: _D2rt6dmain24mainUiPPaZi6runAllMFZv (in /home/dave/stack/test_new)
    ==32630==    by 0x804E3F3: _D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv (in /home/dave/stack/test_new)
    ==32630==    by 0x804EA29: main (in /home/dave/stack/test_new)
    ==32630== 
    ==32630== LEAK SUMMARY:
    ==32630==    definitely lost: 40 bytes in 1 blocks
    ==32630==    indirectly lost: 0 bytes in 0 blocks
    ==32630==      possibly lost: 0 bytes in 0 blocks
    ==32630==    still reachable: 96 bytes in 3 blocks
    ==32630==         suppressed: 0 bytes in 0 blocks

它似乎与线程和监视器的创建有关，请参阅mutex 文档

于 2013-02-10T20:45:37.430 回答
5

我的猜测是 D 的运行时不会费心释放它的一些内存，但我不知道。glibc 特别不会在程序关闭时释放一些东西，因为理论上操作系统将在程序结束后立即回收它。D 的运行时可能会做同样的事情——尽管在 glibc 的情况下，它们有一个函数应该在你用 valgrind 运行程序时释放这些东西，以免 valgrind 报告错误。或者 D 的运行时可能只是发生了彻底的内存泄漏。必须追查才能确定。

于 2013-02-10T20:35:48.477 回答
1

看起来 D 的运行时正在创建内存泄漏（在您main被调用之前/在main返回之后运行的东西）。您可以通过在下运行程序来查看正在进行的活动，ltrace并strace查看是否有任何malloc不是free'd 或者是否有任何mmap未映射的操作

于 2013-02-10T20:30:26.480 回答