weak-ptr become null, crash app 1 time every week

Question

Unhandled exception at 0x764F135D (kernel32.dll) in RFNReader_NFCP.exe.4448.dmp: 0xC0000005: Access violation writing location 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 );
        }
    }
}

variable item's value in debug window: item shared_ptr {m_interface="10.243.112.12" m_port="8889" m_clientSockets={ size=0 } ...} [3 strong refs, 2 weak refs] [default] std::tr1::shared_ptr

but in item->Update(): the item(this) become null!

why??

Answer 1

The problem here is most likely not the weak_ptr, which is used correctly.

In fact, the code you posted is completely fine, so the error must be elsewhere. The raw pointer and length arguments indicate a possible memory corruption.

Be aware that the debugger might lie to you if you accidentally mess up stack frames due to memory corruption. Since you seem to be debugging this from a minidump it might also be that the dumping swallowed some info here.

Mind you, the corrupted this pointer that you are seeing here is just a value on the stack! The underlying object is most probably still alive, as you are maintaining several shared_ptrs to it (you can verify this in a debug build by checking if the original memory location of the object was overwritten by magic numbers). It's really just your stack values that are bogus. I would definitely recommend you double check the stack manually using VS's memory and register windows. If you do have a memory corruption, it should become visible there.

Also consider temporarily cranking up the amount of data saved to the minidump if it threw away too much.

Finally, be sure you double check your buffer handling. It's very likely that you messed up there somewhere and an out-of-bounds buffer write caused the corruption.

Answer 2

Note that your this is invalid (0x00000001), i.e. the object got destroyed. Notify member function was called for a destroyed object. This obviously crashes as soon as Notify tries to access an object member.