問題タブ [dangling-pointer]

windbg を使用してソフトウェア Use-After-Free バグをデバッグしています (ソース コードにアクセスできません)。

どこ

windbg と 'PageHeap' を使用すると、そのオブジェクトがいつ解放され (!heap -p -a 0xXXXXXXXX)、再使用されるかを簡単に知ることができます。

私の質問は、そのオブジェクトがいつ作成されているかを知る方法は何ですか。

どうも

私の C++ コードに非常に奇妙な点があることに気付きました。

deleteヒープからメモリを消去してb->doIt()失敗すると思いました。しかし、このコードを実行している間は機能し、「hello」も表示されます。

なんで？

私は Rust で C ライブラリをラップしており、その関数の多くは構造体へのポインターによってパラメーターを受け取ります。構造体自体が他の構造体へのポインターを持っていることがよくあります。オーバーヘッドを削減するために、Rust データを C 構造体にマーシャリングした結果をキャッシュする機能を提供したいと思います。

C ライブラリがいくつかのパラメーターを期待する方法の例を次に示します。

そして、所有している「キャッシュされた」バージョンがどのように見えるかを想像する方法：

のp_fooフィールドは、内の値barを指すように構築されるか、存在する場合はヌル ポインタになります。SomefooNone

もちろん、ここでの問題は、値Cachedが移動される場合、ストレートmemcpyは不適切であり、bar.p_fooさらにリダイレクトする必要があるということです。bar.p_fooこれは、定義可能な移動セマンティクスを備えたC++で簡単に保証できますが、Rustは「使用されるまで設定しない」以外の解決策を提供しますか? そのようにすることは確かに機能しますが、これらのキャッシュされた値が再利用される以上に (またはそれに近い頻度で) 移動されるとは思いません。これらを設定するには少し作業が必要です。特にネスト/チェーンが深い/長い場合。Boxまた、ヒープ上にサブ構造を配置したくありません。

明確にするために、Rustで複製したいC++で書くことができるものを次に示します。

私はLLVMプラグインを書いています。その中で、プログラム内のさまざまな関数の流れに沿ってデータを取得するポインターのグローバル配列を作成します。ポインターが関数スコープ内のアドレスを取得する場合、そのスコープの外に出ると、OS が適切と見なすようにメモリの内容が上書きされるリスクがあると想定するのは論理的です。

もちろん、プログラム内のすべてのスコープを通じて、ポインターの内容を変更できないようにする方法があるかどうかを知りたいです（変更する必要がある場合を除く） 。

フラグのようなものvolatileでうまくいくと思いましたが、不揮発性命令と比較してシーケンシャルな位置を保持するだけのようです。

出力する次のコードを書きました45。

の有効期間はnスコープで終了するため、このコードがエラーまたは警告を発すると予想していました。GCC 6.1.0 と Clang 3.8.0 と libubsan サニタイザーを使用しても、問題は発生しません。

ヴァルグリンドも文句を言わない。アセンブリを見ると、GCC はスタックから同じ値を再利用しているだけです。

NULL ポインターを参照するのは未定義の動作であることはわかっていますが、ダングリング ポインターはどうでしょうか。(未定義の動作である場合は、標準から引用してください。)

証拠がないと言うだけでなく、未定義の動作であることを誰かに証明してもらいたいです。複製には、引用されていない主張をする多くの回答があります。Cでは、「有効期間外にオブジェクトを使用する」ことは未定義の動作であると明示的に述べています。C++ では、これは当てはまりません。実際、§3.8 はそれほど直接的なことは何も言っていないようです。

質問を再開して、カーゴカルトではなく実際の証拠を入手できるようにしてください。

共有メモリ バッファーを使用して内部状態を格納する C ライブラリの Python バインディングを作成しています。これらのバッファーの割り当てと解放は、ライブラリ自体によって Python の外部で行われますが、Python 内からラップされたコンストラクター/デストラクター関数を呼び出すことで、これが発生するタイミングを間接的に制御できます。いくつかのバッファーを Python に公開して、それらから読み取ることができるようにしたいと思います。場合によっては、それらに値をプッシュします。パフォーマンスとメモリ使用量は重要な問題であるため、可能な限りデータのコピーを避けたいと考えています。

私の現在のアプローチは、ctypes ポインターを直接表示する numpy 配列を作成することです。

これは、コピーを回避するだけでなく、numpy のインデックス作成と代入構文を使用して、それを他の numpy 関数に直接渡すことができることも意味します。

ただし、本質的に危険でもあります。

これをより安全にするために、配列の内容を読み書きする前に、基になる C ポインターが解放されているかどうかを確認できる必要があります。これを行う方法についていくつかの考えがあります。

• 1 つの方法は、 の属性np.ndarrayへの参照を保持するのサブクラスを生成し、基になるメモリへの読み取り/書き込みを行う前かどうかをチェックし、そうである場合は例外を発生させることです。_cbufMyWrapperNone
• .viewキャストやスライスなどにより、同じバッファに複数のビューを簡単に生成できます。そのため、これらはそれぞれへの参照_cbufとチェックを実行するメソッドを継承する必要があります。これは をオーバーライドすることで実現できると思います__array_finalize__が、正確な方法はわかりません。
• 「ポインターチェック」メソッドは、配列の内容を読み書きする操作の前にも呼び出す必要があります。オーバーライドするメソッドの完全なリストを取得するには、numpy の内部構造について十分に知りません。

np.ndarrayこのチェックを実行するサブクラスを実装するにはどうすればよいですか? 誰でもより良いアプローチを提案できますか?

更新:このクラスは、私が望むほとんどのことを行います:

例えば：

私が見逃した他のエッジケースがあると確信しています。

更新 2: @ivan_pozdeevweakref.proxyが示唆するように、私はをいじりました。いいアイデアですが、残念ながら、numpy 配列でどのように機能するかわかりません。によって返されるnumpy配列へのweakrefを作成しようとすることができます：.buffer

np.ndarrayここでの問題は、返されたインスタンスがwrap.bufferすぐに範囲外になることだと思います。回避策は、クラスが初期化時に配列をインスタンス化し、それへの強い参照を保持し、ゲッターが配列に.buffer()a を返すようにすることです。weakref.proxy

ただし、バッファがまだ割り当てられている間に同じ配列に 2 番目のビューを作成すると、これが壊れます。

これは深刻に壊れています - を呼び出した後、 numpy 配列ビューであった をwrap2.__del__()読み書きできるだけでなく、読み書きもできます。buf2wrap2._cbufbufwrap2.__del__()wrap2._bufferNone