crashpad::`anonymous namespace'::HandleAbortSignal

[sentry]

Sentry Issue: BINARYNINJA-2K

STATUS_FATAL_APP_EXIT / 0x7ff6e3e558c6: Fatal Error: STATUS_FATAL_APP_EXIT / 0x7ff6e3e558c6
  File "crashpad_client_win.cc", line 230, in crashpad::`anonymous namespace'::HandleAbortSignal
  File "throw.cpp", line 79, in _CxxThrowException
  File "thread0.cpp", line 33, in std::_Throw_Cpp_error
  File "thread", line 127, in std::thread::join
  File "debuggercontroller.cpp", line 50, in BinaryNinjaDebugger::DebuggerController::~DebuggerController
...
(22 additional frame(s) were not displayed)

@bdash says:

The immediate cause of the crash is that DebuggerController's destructor calls std::thread::join on m_debuggerEventThread while it is executing on the debugger event thread. Attempting to join the current thread results in std::system_error(std::errc::resource_deadlock_would_occur) being thrown, and since that exception is not handled the app exits.

DebuggerController is destroyed on this thread because the DebuggerFileAccessor is the final reference to the controller, and it is deleted in response to TargetExitedEventType, DetachedEventType, and LaunchFailureEventType

[xusheng6]

Root Cause Analysis

The crash is caused by a race condition between event processing and controller destruction.

The Race Window

In EventHandler (debuggercontroller.cpp), when a TargetExitedEventType / DetachedEventType / LaunchFailureEventType arrives:

m_state->SetConnectionStatus(DebugAdapterNotConnectedStatus);  // makes IsConnected() return false
// ... ~8 lines of cleanup ...
if (m_accessor) { delete m_accessor; }  // releases DbgRef<DebuggerController>

Between these two lines, another thread can observe the controller as "not connected" and call Destroy(), which removes the controller from the global state.controllers array — dropping that reference.

How Destroy() Gets Called During the Window

In uinotification.cpp, OnBeforeCloseFile:

if (controller->IsConnected())    // races with SetConnectionStatus above!
{
    // spawn detached thread → QuitAndWait + Destroy
}
else
{
    controller->Destroy();         // removes global array ref directly
}

Or from Python FFI: BNDebuggerDestroyController → Destroy().

The Crash Sequence

1. Target exits → HandleExitProcess posts TargetExitedEventType (adapter thread blocks on future.get())
2. Event thread dispatches → EventHandler sets ConnectionStatus(NotConnected)
3. Another thread (main thread closing a tab, or Python) sees IsConnected() == false → calls Destroy() → removes controller from global array
4. Event thread continues → deletes m_accessor
5. ~DebuggerFileAccessor → ~DbgRef<DebuggerController> → Release() → refcount hits 0 → ~DebuggerController → m_debuggerEventThread.join() — but we ARE the event thread → crash (cannot join a thread from itself)

Why It's Rare

The race window is only ~8 lines of code. The other thread must call Destroy() in exactly this narrow window between setting NotConnected and deleting the accessor.

Minidump Corroboration

The minidump confirms this analysis:

• Thread 43: HandleExitProcess → PostDebuggerEvent → blocked on future.get() (the event poster)
• Thread 26 (crashed): Event thread → EventHandler → delete m_accessor → ~DebuggerController → join() on self
• Threads 44/45: Two ExecuteAdapterAndWait → Semaphore::Wait (one is the original Go(), the other is QuitAndWait()'s ExecuteAdapterAndWait(DebugAdapterQuit) from the UI close path)
• No thread currently in Destroy() — it already completed and the stack moved on

Fix

Defer the delete m_accessor to a detached std::thread. Even if the accessor's DbgRef is the last reference, ~DebuggerController and its join() call will execute on the detached thread (not the event thread), allowing the event thread to exit cleanly.