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

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

スレッド化とモニターの作成に関係しているようですミューテックスのドキュメントを参照してください

于 2013-02-10T20:45:37.430 に答える
5

私の推測では、D のランタイムはメモリの一部を解放することを気にしていませんが、わかりません。とにかくプログラムが終了するとすぐにOSがそれを再利用しようとしているという理論に基づいて、glibcは具体的にはプログラムのシャットダウン時にいくつかのものを解放することを気にしません。D のランタイムも同じことを行っている可能性がありますが、glibc の場合、valgrind がエラーを報告しないようにするために、valgrind を使用してプログラムを実行するときにそのようなものを解放するはずの関数があります。または、D のランタイムで完全なメモリ リークが発生している可能性があります。確実に追跡する必要があります。

于 2013-02-10T20:35:48.477 に答える
1

Dのランタイムがメモリリーク（main呼び出される前/main戻る前に実行されるもの）を作成しているようです。プログラムを実行することで、どのようなアクティビティが実行されているltraceかstraceを確認し、マップされていmallocない操作freeがあるかどうか、またはmmapマップされていない操作があるかどうかを確認できます。

于 2013-02-10T20:30:26.480 に答える