memory-leaks - 最小 D 程序中的内存泄漏?

标签 memory-leaks valgrind d

这个最小的程序:

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

这里有什么问题?

最佳答案

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

关于memory-leaks - 最小 D 程序中的内存泄漏?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/14802212/

相关文章:

android - 无法在 Android 4.4.4 上获得分配

Node.js 服务器不释放内存

iphone - ARC 中 CFArray 的内存泄漏

profiling - 为什么 valgrind Massif 不报告任何函数名称或代码引用?

open-source - D 中是否有任何开源项目?

crash - 相同的代码在共享库中无法(某种程度上)工作,但在程序中直接使用时可以工作

c++ - OpenCV 函数中的内存泄漏 : cvQueryFrame()

c - Valgrind 下的程序输出显着不同

C、使用 valgrind 和 void* 变量进行无效写入

arrays - 为什么是 &array != &array[0]?