この投稿では、shared_ptr スマート ポインターに関する私の失敗について話します。ゲーム Death-Mask に次のレベルの世代を実装した後、ある記憶に気づきました。漏れがある新しいレベルごとに、消費される RAM が + 1 メガバイト増加しました。一部のオブジェクトがメモリ内に残り、解放されなかったのは明らかです。この事実を修正するには、レベルが過負荷になったときにリソースを正しく実装する必要がありましたが、明らかに実行されていませんでした。私はスマート ポインターを使用していたので、この問題を解決するにはいくつかのオプションがありました。1 つ目はコードを手動でレビューすること (長くて退屈)、2 つ目は lldb デバッガーの機能と libstdc++ ソース コードを調べて自動追跡の可能性を調べることです。カウンタの変更。
インターネット上では、すべてのアドバイスは要約すると、手動でコードを確認して修正し、問題のあるコード行を見つけたら鞭で自分を叩くというものでした。また、C++11 標準にスマート ポインターが登場する前に、90 年代と 2000 年代以降に開発されたすべての主要プロジェクトと同様に、メモリを操作するための独自のシステムを実装することも提案されました。すべてのshared_ptrsのコピーのコンストラクターでブレークポイントを使用しようとしましたが、数日経っても何も役に立ちませんでした。 libstdc++ ライブラリにロギングを追加するというアイデアがありましたが、人件費が膨大であることが判明しました。
カウボーイ ビバップ (1998)
プライベート変数shared_ptr –の変更を追跡するという解決策が突然思いつきました。 use_count。これは、lldb に組み込まれているウォッチポイントを使用して行うことができます。make_shared でshared_ptr を作成した後、次の行を使用して lldb のカウンターへの変更を追跡できます。
セットを見る var カメラ._M_refcount._M_pi->_M_use_count
「カメラ」はどこにあるのかこれは、カウンタの状態を追跡する必要があるshared_ptrオブジェクトです。もちろん、shared_ptr の内部は libstdc++ のバージョンによって異なりますが、一般的な原理は理解できます。ウォッチポイントをインストールした後、アプリケーションを起動して各カウンターの変更のスタックトレースを読み取り、コードを確認して (原文どおり!)、問題を見つけて修正します。私の場合、オブジェクトはキャッシュ テーブルとゲーム ロジック テーブルから解放されませんでした。この方法が、shared_ptr を使用する際のリークへの対処に役立ち、このメモリ ツールをさらに気に入っていただけることを願っています。デバッグを楽しんでください。
