C++空のプログラムメモリは、

Question

次のコード

int main(){ 
    return 0; 
} 

を検討リークIは、Gでそれをコンパイル++とvalgrindの出力を渡します。出力は次のとおりです。

==11752== HEAP SUMMARY: 
==11752==  in use at exit: 72,704 bytes in 1 blocks 
==11752== total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated 
==11752== 
==11965== LEAK SUMMARY: 
==11965== definitely lost: 0 bytes in 0 blocks 
==11965== indirectly lost: 0 bytes in 0 blocks 
==11965==  possibly lost: 0 bytes in 0 blocks 
==11965== still reachable: 72,704 bytes in 1 blocks 
==11965==   suppressed: 0 bytes in 0 blocks 

しかし、gccでCで同じコードをコンパイルすると、このvalgrindの出力を生成します。

==11771== HEAP SUMMARY: 
==11771==  in use at exit: 0 bytes in 0 blocks 
==11771== total heap usage: 0 allocs, 0 frees, 0 bytes allocated 
==11771== 
==11771== All heap blocks were freed -- no leaks are possible 

それは空のC++プログラムは、実際にメモリを割り当てないように

をコンパイルするように見えます見えますそれを解放してください（それは "まだ到達可能な"リークですので災害ではありません）。なぜこれが起こっているのかわかりません。

このテストはg ++ 6.3のlinux（solus os）で行いました。

誰かが何が起こっているのか説明できますか？

Answer 1

それは「まだ到達可能」だから、それは災害ではないのですがそれもリークではありません

を漏らします。 極端にはですが、いくつかのグローバルポイントがメモリブロックを解放しないようにプログラムで共通です。 free INGを行うことである

だけで複数のスレッドがあれば合併症を引き起こす可能性があり（他のスレッドの下からcarperをヤンクも出スレッド）
• を実行している場合
• は合併症を引き起こす可能性がプログラム終了遅くなり
• 不必要な作業クリーンアップの他の部分は、このブロック、などなど

私はなぜこれが起こっているか見当もつかないにアクセスすることができます。

ヒントを得るには、valgrind --leak-check=full --show-reachable=yes ...を実行してください。ブロックが割り当てられた場所がわかります。