1. コードの数が少なく、よく知っている場合。コードを直接確認することができます(malloc、free、newdeleteがペアで使用されているか、デストラクタが仮想関数を使用していないか?fork時にfdなどの親プロセスのリソースが解放されていないか?ダングリングポインタなど)。gdb、ステップ/ブレークポイントを使用して直接デバッグすることもできます。どのステップが間違っていたのかを知ることができます。メモリ リークの場合、最初に大きなメモリ リークが割り当てられると、エラー メッセージが直接表示されます。
2. 見慣れないコードがたくさんあります。
varglind lea check -full などの検出ツールを使用します。確実に漏れている場所、漏れている可能性がある場所、間接的に漏れている場所がわかります。肯定的な場合は修正するのが良いですが、可能であれば間接的な場合は再度検討する必要があります。
3. コアダンプ ファイル スタック
オーバーフローを引き起こすメモリ リークなど、一部のメモリ リークはクラッシュを引き起こし、コア ファイルを生成します。ulimit は有効かどうかとサイズ制限を確認できます。レジスタの値、スタックポインタ、関数呼び出しなどのその時のメモリの状態を保存します。
コア ファイルには、最初にどのようなエラー (メモリ リークなど) が発生したかが表示されます。gdb を使用してコア ファイルをデバッグできます。たとえば、エラー発生時に bt コマンドを呼び出して関数呼び出しスタック フレーム情報を表示し、frame を呼び出してスタック フレームに関するより具体的な情報を表示できます。次に、対応する関数の位置でポイントをブレークして、どのステップが間違っているかを確認します。メモリ アドレス情報を対応する関数名の行番号に変換できる addr2line ツールがあり、分析に便利です (
コア例外のその他の理由: 範囲外の読み取りと書き込み、ゼロによる除算例外、強制終了など)信号、マルチスレッド共有データ構造、ロックなし、不正なポインタなど)
4.
malloc をリロードするときに最初のシーンでない場合、特に他のライブラリを使用している場合には、発生する可能性のあるエラーはまったく発生しません。これらのライブラリの最後で割り当てが使用されていますか? そのメカニズムを理解していないと、メモリ リークが発生しやすくなります。したがって、malloc と free をオーバーロードしてログを書き込むことができます。たとえば、xxx 関数によって割り当てられたメモリの量を書き込み、free はその逆を実行して、リークが発生している場所を分析します。