Crash on fail ~CCheckQueue() destructor? #29930

Is there an existing issue for this?

• I have searched the existing issues

Current behaviour

This will crash the application when false:

    ~CCheckQueue()
    {
        assert(m_worker_threads.empty());
    }

Expected behaviour

Possibly do something more like this?

    ~CCheckQueue() {   
        try {
            if (!m_worker_threads.empty()) {
                // Attempt to stop worker threads if they haven't been stopped yet.
                StopWorkerThreads();
            }
        } catch (const std::exception& e) {
            LogPrint(BCLog::UTIL, "Exception in ~CCheckQueue: %s\n", e.what());
        }
    }

I am not very familiar with the code base. This just looked weird to me.

Steps to reproduce

Open settings in bitcoin-qt, adjust and save.

Relevant log output

Crash with:

assertion failure in the file checkqueue.h at line 198. The assertion that failed is m_worker_threads.empty()

How did you obtain Bitcoin Core

Compiled from source

What version of Bitcoin Core are you using?

26.1

Operating system and version

Windows, MinGW64 (using portable_endian.h)

Machine specifications

No response

Open settings in bitcoin-qt, adjust and save.

I am not able to reproduce this. What exactly did you adjust in settings before clicking on ok?

Any setting, or just clicking ok (cancel is fine). It's probably something slightly different in MinGW pthread support. so assert(m_worker_threads.empty()); causing a crash still analyzing.

So I understand assert will tell us what part of the code crashed, but it doesn't really tell us anything about the worker that wont stop, (thread id etc) so far it's only the settings box -> everything else seems to work after #29931 fingers crossed. gui syncing now.

This was fixed in Bitcoin Core 27.x (https://github.com/bitcoin/bitcoin/commit/498994b6f55d04a7940f832e7fbd17e5acdaff15)

Is this still an issue with a recent version of Bitcoin Core? If yes, what are the exact steps to reproduce?

Thanks for your very helpful response maflcko. As you indicate, the code in question was changed anyway, just didn't see the thread. V26.1 is that latest I can compile, haven't updated to c++20. Thanks yes close.