Why does std::shared_ptr call my destructor twice?

Question

In this program, why is the destructor on line 14 is called twice for the same instance of mystruct_t?

I'm assuming that all pointer manipulation in this program is thread safe. I think the atomic updates do not work on my system or compiler. I tried this on MSVC 2017, MSVC 2019 and on clang

/* This crashes for me (line 19) */
#include <iostream>
#include <vector>
#include <thread>
#include <memory>
#include <chrono>
#include <assert.h>

struct mystruct_t {
    int32_t nInvocation = 0;
    ~mystruct_t();
    mystruct_t() = default;
};
mystruct_t::~mystruct_t() {
    nInvocation++;
    int nInvoke = nInvocation;
    if (nInvoke > 1) {
        /* destructor was invoked twice */
        assert(0);
    }
    /* sleep is not necessary for crash */
    //std::this_thread::sleep_for(std::chrono::microseconds(525));
}
std::shared_ptr<mystruct_t> globalPtr;
void thread1() {
    for (;;) {
        std::this_thread::sleep_for(std::chrono::microseconds(1000));
        std::shared_ptr<mystruct_t> ptrNewInstance = std::make_shared<mystruct_t>();
        globalPtr = ptrNewInstance;
    }
}
void thread2() {
    for (;;) {
        std::shared_ptr<mystruct_t> pointerCopy = globalPtr;
    }
}
int main()
{
    std::thread t1;
    t1 = std::thread([]() {
        thread1();
        });
    std::thread t2;
    t2 = std::thread([]() {
        thread2();
        });
    for (int i = 0;; ++i) {
        std::this_thread::sleep_for(std::chrono::microseconds(1000));
        std::shared_ptr<mystruct_t> pointerCopy = globalPtr;
        globalPtr = nullptr;
    }
    return 0;
}

Answer 1

As several users here already mentioned, you're running into undefined behavior since you globally (or foreign threaded) alter your referred object while thread-locally, you try to copy assign it. A drawback of the sharedPtr especially for newcomers is the quite hidden danger in the suggestion, you're always thread safe in copying them. As you do not use references, this can become even harder to see in doubt. Always try to see the shared_ptr as a regular class in the first place with a common ('trivial') member-wise copy assigment where interferences are always possible in non-protected threading environments.

If you're going to encounter similar situations with that or similar code in future, try to use a robust channeled broadcasting/event based scheme instead of locally placed locks! The channels (buffered or single data based) themselves care about the proper data lifetime then, ensuring the sharedPtr's underlying data 'rescue'.