最小的D程序内存泄漏？

Question

这个最小的程序:

int main()
{
  return 0;
}

编译时使用gcc和运行valgrind工作正常.

当使用编译为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

这有什么不对？

Answer 1

我的猜测是,D的运行时并没有费心去释放它的一些记忆,但我不知道.glibc特别不打算在程序关闭时释放一些东西,理论上一旦程序结束,OS就会收回它.D的运行时可能正在做同样的事情 - 虽然在glibc的情况下,它们有一个函数,当你用valgrind运行你的程序时它应该释放那些东西,以便没有valgrind报告错误.或者D的运行时可能只是彻底的内存泄漏.它必须被追踪以确定.

Answer 2

如果在valgrind中使用--leak-check = full选项,它会告诉您泄漏的位置.

我有

    ==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

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