1

RFNReader_NFCP.exe.4448.dmp の 0x764F135D (kernel32.dll) で未処理の例外: 0xC0000005: アクセス違反の書き込み場所 0x00000001。

void Notify( const char* buf, size_t len )
{
    for( auto it = m_observerList.begin(); it != m_observerList.end(); )
    {
        auto item = it->lock();
        if( item )
        {
           item->Update( buf, len );
            ++it;
        }
        else
        {
            it = m_observerList.erase( it );
        }
    }
}

変数itemのデバッグ ウィンドウでの値: ここに画像の説明を入力 item shared_ptr {m_interface="10.243.112.12" m_port="8889" m_clientSockets={ size=0 } ...} [3 つの強い参照、2 つの弱い参照] [デフォルト] std:: tr1::shared_ptr

しかし、item->Update() では ここに画像の説明を入力item(this)が null になります!

どうして??

4

2 に答える 2

1

ここでの問題はweak_ptr、正しく使用されている ではない可能性が最も高いです。

実際、投稿したコードはまったく問題ないので、エラーは別の場所にあるはずです。生のポインタと長さの引数は、メモリ破損の可能性を示しています。

メモリの破損により誤ってスタック フレームを台無しにすると、デバッガが嘘をつく可能性があることに注意してください。これをミニダンプからデバッグしているように見えるので、ダンプがここでいくつかの情報を飲み込んだ可能性もあります。

ここに表示されている破損したthisポインターは、スタック上の単なる値です。基になるオブジェクトは、いくつかの を維持しているため、おそらくまだ生きていますshared_ptr(オブジェクトの元のメモリ位置がマジック ナンバーによって上書きされたかどうかを確認することで、デバッグ ビルドでこれを確認できます)。偽物であるのは、実際にはスタック値だけです。VS のメモリとレジスタ ウィンドウを使用して、スタックを手動で再確認することを強くお勧めします。メモリが破損している場合は、そこに表示されるはずです。

ミニダンプに保存されるデータが多すぎる場合は、一時的にその量を増やすことも検討してください。

最後に、バッファ処理を再確認してください。どこかでめちゃくちゃになり、範囲外のバッファ書き込みが破損を引き起こした可能性が非常に高いです。

于 2013-09-11T09:21:45.307 に答える