weak_ptr reset affects shared_ptr?

user_776237 0
Viewed 362

I'm not very used to using weak_ptr and I'm facing a quite confusing situation. I'm using Intel XE 2019 Composer update 5 (package 2019.5.281) in combinaison with Visual Studio 2019 ver. 16.2.5. I compile in 64-bit. I use the standard C++ 17.

Here is the code for my spike solution:

#include <memory>
#include <iostream>

using namespace std;

int main( int argc, char* argv[] )
{
    shared_ptr<int> sp = make_shared<int>( 42 );
    cout << "*sp = " << *sp << endl;

    weak_ptr<int> wp = sp;
    cout << "*sp = " << *sp << ", *wp = " << *wp.lock() << endl;

    wp.reset();
    cout << "*sp = " << *sp << endl;

    return 0;
}

The output I expected to have is:

*sp = 42
*sp = 42, *wp = 42
*sp = 42

...but here is what I obtained:

*sp = 42
*sp = 42, *wp = 42
*sp = -572662307

What is goin on? Is it normal for the shared_ptr to be modified/invalidated when the/an associated weak_ptr is reset? I'm a little confused about the results I obtained. To say the truth I didn't expect this result...

EDIT 1

While the bug occurs in 64-bit configuration, it doesn't in 32-bit. In this later configuration, the result is what is expected.

EDIT 2

The bug occurs only in Debug. When I build in Release, I get the expected result.

icc visual-studio-2019 c++17 smart-pointers c++
2 Answers

It appears it is a real bug on Intel ICC side; I have reported it.

Thanks again for helping me to pin-point this problem.

user_7762370

It looks like a bug in debug library, with sentinel values.It's easy to check, by using line I mentioned:

int i = 1; cout << i << " " << ++i << endl;

If output is 2 2 instead of 1 2, then compiler is not compliant and possibly still considers such case an UB. Sentinel values may be used erroneously in this case with call of reset(). Similar thing happens with deleting object created by placement new within preallocated static buffer, in debug mode it gets overwritten by some implementations with sentinel values.

user_27427170
Related