私のプログラム (テキストモードの Web ブラウザ) は動的にメモリを割り当てています。
もちろん、実行時に不要なブロックを解放します。そして、通常の終了前にすべてを解放します。これにより、メモリ リーク チェッカーが誤検出を起こさないようにします (また、主要なリファクタリングが必要になった場合に柔軟に対応できるようにします)。
今、私がしていないのは、異常終了する前にメモリを解放することです。(現在、私のプログラムはシグナルで終了し、mallocs/reallocs が失敗した後に終了します。)
私の質問は、このスタイルが悪いと思いますか? 異常終了時に解放する必要がありますか?
いいえ。単純に手を投げて、プログラムの終了後に OS にメモリを再利用させることはまったく問題ないと思います。これが本当に異常な状況であり、プログラムを終了させることが意図されている場合、適切に動作するプログラムは、ディスク リソース/ロックをクリーンアップし、できるだけ早く終了する必要があると思います。
私の意見では、クラッシュ時にメモリを解放する必要はありません。プロセスが終了すると、OS はメモリを解放するので、終了するだけです。
一方、他のリソース (開いているファイルなど) は閉じるか、少なくともフラッシュする必要があります。
リーク検出ツールでの誤検出を回避する場合を除いて、通常の終了時にメモリを再利用する必要はありません。
プログラムが異常終了した場合、原因によってはメモリを解放できないことがあります。たとえば、破損したヒープに起因する SIGSEGV は、ヒープ上の他のものを解放しようとしても、おそらく絶望的な作業になることを意味します。
プロセスの異常終了は、他のプロセスによって割り当てられた場合、他のプロセスが使用できない (事実上、それらが解放されていることを意味する) メモリ ブロックにはつながりません。
バグのない OS が各プロセスのメモリ チャンクを追跡し、それらを連続した仮想メモリ空間に変換できるように、OS ディレクティブを使用してメモリを割り当て/解放します。プロセスが停止すると、OS ローダーがそれを通知し、すべてのメモリがリコールされます。プロセスがメモリを共有すると、事態は複雑になります。
ピアリング プロセスは、プロセスによって派生/起動/分岐されていない場合 (たとえば、マルチメディア リソースにアクセスするために多くのプロセスを提供する外部コンポーネントを検討してください)、プロセスを提供するためのメモリ (バッファなど) を作成した可能性があります。これらの外部コンポーネントの所有権のポリシーによっては、処理されたプロセスの終了時にそのメモリが解放されない場合があります。
異常終了シナリオの前後にコミットされたすべてのメモリを監査することをお勧めします。
異常終了時には、できるだけ処理を少なくしたいと考えています。中断するプロセスのいじくり回しを最小限に抑えることは、中断の理由にできるだけ近づくことができることを意味し、それ以降の処理はプロセスを「汚染」していると見なされるため、デバッグがより困難になります。
OS がプログラムの終了時にメモリを再利用しない場合のみ。DOS とその「スティッキー メモリ」は、そのような OS の例です。最近のほとんどの OS では、異常終了時に free() を実行することは問題ではありません。
いいえ、プログラムが常に異常終了しない限り。:)とにかく、OSはそれを解放する素晴らしい仕事をします。実際、多くの怠惰なプログラマーは、通常の終了で物事を解放することさえ気にしません - しかし、これは他のメモリーリーク (本当の問題であるもの) を検出することを困難にします。