メモリリークを修正することはどれほど重要ですか？

Valgringによって、いくつかのGTK +プログラムがメモリリークを起こすことがわかりました。これらのリークを修正することはどれほど重要ですか？多くの場合、これらのプログラムは非常にうまく機能しますが、一方で、漏れているコードの一部を他のプログラムにコピーしたいかどうかはわかりません。そして、GTK +-プログラムのアイデアが高速に動作することであるかどうかはわかりません。したがって、リークがあります。

したがって、オープンソースプログラムでメモリリークを見つけることがある場合、それを修正する必要がありますか、たとえば効率性の問題があるので、プログラマの元のアイデアは小さなリークコードを書くことでしたか？

メモリリークを修正することの重要性は、問題の重大度と、他に何をする必要があるかによって異なります。私の経験では、小さなメモリリークは、ほとんどのアプリケーションでかなり害が少ない傾向があります。通常、デスクトップアプリセッションの存続期間は、小さなメモリリークによる劣化を確認するのに十分な長さではありません。

24時間年中無休で稼働するサーバーを作成している場合、小さなメモリリークが時間の経過とともに増加し、大きな問題になる可能性があります。しかし、多くの企業がサーバーを毎日または毎週再起動するようにスケジュールしているのはそのためです。多くの場合、メモリリークを見つける努力は得られるものに比べて過剰であるため、定期的にサーバーを再起動し、より重要なものに進む方が簡単です。

短時間実行されるプログラムでは、メモリリークはそれほど重要ではありません。OSは終了時にすべてを再利用しますが、他のリソースが解放されない可能性があります。

しかし、短時間のランニングは相対的であり、数時間で漏れが制御不能になったり、気付かずに数週間積み重なることがあります。

私のアドバイスは、もしリードが彼がそれを修正することを気にかけているなら、修正案とともにトラッカーにバグを提出することです。

漏れのタイプも重要です。リークする割り当ては、開発者がクリーンアップのために意図的にOSに依存している1回限りの割り当てである可能性があります。これらは、valgrindで誤検知を与えます。

この1つの主題に関する私の確かに独断的な意見では、少なくとも広く適用されることを目的とする図書館では、物理的な漏れの言い訳はありません。したがって、GTK +開発者が自分で修正するまでバグを出したいと思います。

ライブラリがatexitコールバックを登録して、少なくともアンロードされたときに割り当てたメモリを解放するのは簡単です。ボートでの小さな割り当ての費用を避けたい場合、そもそもそれらを行うべきではありません。

わずかなメモリチャンクのボートロードを一度に割り当てたいだけの遅延プログラムでも、シャットダウン時にすべてのメモリを削除する単純な順次アロケ​​ータを使用できます。アロケーターがアライメントを処理したくない場合は、プールするすべてのチャンクを最大アライメント境界までパディングできます。これらの小さなメモリチャンクをすべて個別に解放しないことで、シャットダウン時間を短縮できるというメリットがある場合、同様に、メモリをストレートシーケンシャル形式でプールするシーケンシャルアロケータを使用することで、ささいな労力と引き換えに対称的に大きなメリットを得ることができますよりもはるかに高速な割り当てmallocよりキャッシュに優しいメモリパターン。ライブラリの完了時に、アロケータによってプールされた連続メモリのすべての大きなブロックのみが解放されます。ライブラリがしなけれmallocばならないのは、気にする必要のない呼び出しをのfreeようなものに置き換え、コールバックをseq_malloc呼び出しseq_purgeて、atexitアンロード時に割り当てられたすべてのメモリを解放することです。

そうしないと、メモリリーク検出ツールでこの厄介なライブラリがメッセージを散らかしてしまい、フィルターで除外する必要があります。さらに悪いことに、それらを体系的に除外しないと、彼らはあなた自身のアプリケーションの漏れを覆い隠し、あなたの同僚はそれらを見落とす習慣を発達させ、そもそもあなた自身のチームを防ぐ上で漏れ検出ツールの有用性を減らすかもしれません漏れやすいコードをプッシュします。それはひどくandく、何よりも、上記のソリューションを使用することがいかに簡単かを考えると、これを意図的に行うことを支持する議論がまったく説得力がないと思います。

論理リーク（ガベージコレクションでさえ保護できないより複雑な種類）はより複雑な問題であり、割り当てられたすべてのメモリをパージする限り、短命のプログラムが論理リークを持つことの正当化を見つけることができます論理的なリークを回避するためにリソース管理について多くのことを考える必要があるため、シャットダウンします（GCを備えた言語ではおそらくそうです）。しかし、最も怠physicalな状況でも物理的リークを回避することがいかに些細なことかを考えると、物理的リークを回避するための合理的な言い訳は見つかりません。

とにかく、少なくとも私はvalgrindのリークを除外して、少なくとも自分のチームを見つけられるようにする能力を台無しにしないようにします。

FWIW、ユーザーが私が取り組んでいるアプリケーションでリークを報告した場合、私はそれを修正したいでしょう（特にバグレポートに修正のためのコードが含まれていれば！）。ただし、リークが小さく、他の問題がより緊急度の高い場合（たとえば、頻繁に発生するクラッシュするバグ）は、すぐには発生しない可能性があります。しかし、私は間違いなく感謝し、最終的にそれを修正するために働きます。必ず知らせてください。彼らはそれを感謝し、それを修正するために働くでしょう（ほとんどの場合）、または彼らは気にしませんし、それはすべてあなたがいくらかの時間を要するでしょう。