The Catch Block Never Joined the Worker Thread

The abort was not a data race at all. It was std::terminate from a joinable std::thread destructor. I rebuilt the failure as a labeled lab case, not a traffic report.

Happy-path tests joined every worker they started. The catch block never did that join. ThreadSanitizer stayed quiet the whole time. Why would a sanitizer miss a process that simply vanished?

This write-up is a debugging retrospective. The reusable part is the exit-path method. Treat the snippets as a reconstructed harness. I am not inventing production metrics or a customer outage.

The symptom that lied

The binary printed nothing useful on failure. It died with an abort, not a segfault. Several teammates said "race" before anyone opened a stack. Have you seen that reflex on a flaky shutdown test?

I reproduced it with one flag and one throw. Success always joined. Setup failure always aborted. That pattern is a clue. Races rarely line up with one Boolean.

g++ -std=c++17 -g -O0 -pthread joinable_abort.cpp -o joinable_abort
./joinable_abort            # happy path: prints ok
./joinable_abort --fail     # abort: no useful what()

What I captured first

I did not start by rewriting shutdown code. I captured the abort stack under gdb. The frame that mattered was not my lambda. It was std::thread::~thread.

#0  __GI_raise
#1  __GI_abort
#2  std::terminate
#3  std::thread::~thread
#4  run_batch(bool)

Ask one question at that frame. Is this thread still joinable? If yes, the destructor must call std::terminate. That is the contract in the C++ standard. It is not undefined behavior in the race sense. It is defined suicide.

Wrong hypotheses I wrote down

I listed three cheap guesses before the stack. Write them down anyway. Unwritten guesses come back as "fixes."

1. Data race on the task queue flag.
2. Exception escaping from the worker itself.
3. A sanitizer hole on ARM only.

Guess one failed a basic test. ThreadSanitizer reported nothing at -O1. Guess two failed the stack. The worker lambda had a try/catch. Guess three failed the laptop repro. The abort happened on one core. So the stack won. The guesses did not.

Minimal repro

Label this as lab code. It is the shape an agent often emits. Join lives on the success path only. The throw sits after std::thread construction. Destructor then runs during unwind.

// lab-only: joinable_abort.cpp
#include <iostream>
#include <stdexcept>
#include <string_view>
#include <thread>
#include <chrono>

static void worker_body() {
    std::this_thread::sleep_for(std::chrono::milliseconds(20));
}

static int run_batch(bool fail_setup) {
    std::thread worker(worker_body); // joinable from here
    if (fail_setup) {
        throw std::runtime_error("setup failed after spawn");
    }
    worker.join();
    return 0;
}

int main(int argc, char** argv) {
    const bool fail =
        argc > 1 && std::string_view(argv[1]) == "--fail";
    try {
        run_batch(fail);
        std::cout << "ok\n";
        return 0;
    } catch (const std::exception& ex) {
        std::cerr << "caught: " << ex.what() << "\n";
        return 1;
    }
}

Build it. Run both paths. The happy path looks professional. The fail path never prints caught:. Why not? Unwind starts. worker is still joinable. ~thread calls std::terminate. Your catch in main never runs. That is why logs looked empty.

Numbered debug workflow

Use this sequence the next time a process vanishes on errors only.

1. Confirm the signal. Is it SIGABRT, not SIGSEGV?
2. Run under gdb with catch throw and bt on abort.
3. If ~thread is on the stack, stop talking about races.
4. Print every std::thread local in the dying frame.
5. Draw every exit path: return, throw, and early co_return if any.
6. Add a test per exit path before you touch the fix.
7. Prefer join or std::jthread. Do not detach to silence abort.
8. Re-run the fail flag. Then re-run ThreadSanitizer for leftover races.

gdb -q ./joinable_abort
(gdb) catch throw
(gdb) run --fail
(gdb) bt
(gdb) info threads

Step five is the one people skip. Agents skip it too. They patch the happy path. They leave the catch block untouched. Your job is the matrix of exits, not a prettier lambda.

Where a free model actually helped

I did not ask a model to "make shutdown thread-safe." That prompt already produced this bug class once. After the stack named ~thread, I used MonkeyCode only as a checklist expander. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I used its free model access and free server option to list exit paths I might have missed, then I compiled those paths myself.

The useful output was boring. It listed throw after spawn, return before join, constructor failure of a later object, and a catch that rethrows. I turned each item into a test flag. I discarded any rewrite that called detach(). A model can enumerate branches. It cannot see your destructor. You still own the stack.

The fix that keeps the abort honest

Join on every path, including unwind. The smallest honest fix is RAII. A join guard joins if joinable. It does not detach. Detach turns abort into a use-after-free festival.

struct JoinOnExit {
    std::thread& t;
    ~JoinOnExit() {
        if (t.joinable()) {
            t.join();
        }
    }
};

static int run_batch(bool fail_setup) {
    std::thread worker(worker_body);
    JoinOnExit guard{worker};
    if (fail_setup) {
        throw std::runtime_error("setup failed after spawn");
    }
    return 0; // guard joins here too
}

std::jthread is cleaner on C++20. Its destructor requests stop and joins. That is not magic either. You still must check the stop token inside the worker. Otherwise you join a thread that never looks up. Want a hung shutdown instead of an abort? That is how you get one.

static int run_batch_jthread(bool fail_setup) {
    std::jthread worker([](std::stop_token st) {
        while (!st.stop_requested()) {
            std::this_thread::sleep_for(std::chrono::milliseconds(5));
        }
    });
    if (fail_setup) {
        throw std::runtime_error("setup failed after spawn");
    }
    return 0;
}

Artifact: exit-path decision table

Keep this table next to any thread spawn. Fill the last column from a real run, not from a prompt.

Exit path	Joinable at unwind?	detach used?	Observed result
Success, explicit join	no	no	prints ok
throw after spawn	yes	no	std::terminate
return before join	yes	no	std::terminate
catch and rethrow, no join	yes	no	std::terminate
RAII JoinOnExit	no	no	catch in main runs
detach on error	no	yes	process lives, worker is a ghost
std::jthread, worker ignores stop	no	no	shutdown can hang
std::jthread, worker checks stop	no	no	fail path is catchable

The ghost row is the trap. Abort is ugly and honest. Detach is polite and false. Which failure would you rather debug at 2 a.m.?

Artifact: test plan you can paste

Do not call this coverage. Call it exit-path proof. Each command must observe a distinct row.

# A. happy path
./joinable_abort

# B. setup failure must be catchable after the fix
./joinable_abort --fail
# expect: caught: setup failed after spawn
# expect: exit code 1, not abort

# C. sanitizer is a second pass, not the first
g++ -std=c++17 -fsanitize=thread -g -O1 -pthread joinable_abort.cpp -o joinable_tsan
./joinable_tsan --fail

# D. prove we did not detach
# grep the diff: detach is a review reject
git grep -n "detach(" -- '*.cpp'

Add one more flag if your real code constructs a second object after the thread. Constructor throws are exit paths. Agents forget those too. Did your last generated "fix" add a logger after spawn? That logger can throw. Then you are back at ~thread.

Limitations

This method does not prove lock-freedom. It does not prove memory orders. It does not replace ThreadSanitizer for real sharing bugs. It only answers one question. Can this thread object die joinable?

Do not use a model as an oracle for the C++ abstract machine. Do not paste secrets into any web session. Do not treat free model access as a substitute for gdb. The free server option is fine for compiling this harness. It is not a formal verifier. I am not claiming quotas, model names, or hardware details here. Those numbers go stale. The destructor rule does not.

Who should not use this approach? Anyone about to detach to green a test. Anyone shipping a lock-free ring buffer from a chat transcript. Anyone who cannot run the fail flag locally. If you cannot observe SIGABRT yourself, you are not debugging. You are decorating.

What I will do next time

I will still let a model list branches after I have a stack. I will not let it own shutdown. I will keep one RAII guard per thread. I will keep the decision table in the review notes. Short rules survive better than slogans.

If you compile this harness and the fail path still aborts, look at ~thread before you look at queues. That single frame saves a week. The free model access and free server option are enough to generate extra exit-path tests once that frame is in hand. Keep the stack first. Keep the prompt second.