BinaryNinjaDebugger::LldbAdapter::~LldbAdapter

[sentry]

Sentry Issue: BINARYNINJA-QJ

unknown 0x00000000 / 0x00000000 / 0x7ff80573c846: Fatal Error: unknown 0x00000000 / 0x00000000 / 0x7ff80573c846
  File "lldbadapter.cpp", line 70, in BinaryNinjaDebugger::LldbAdapter::~LldbAdapter
  File "lldbadapter.cpp", line 69, in ~LldbAdapter
  File "lldbadapter.cpp", line 69, in BinaryNinjaDebugger::LldbAdapter::~LldbAdapter
  File "debuggerstate.cpp", line 1487, in BinaryNinjaDebugger::DebuggerState::~DebuggerState
  File "debuggercontroller.cpp", line 94, in BinaryNinjaDebugger::DebuggerController::~DebuggerController
...
(28 additional frame(s) were not displayed)

[plafosse]

BINARYNINJA-QJ: exception escapes LLDB adapter destructor

Sentry issue: https://vector35.sentry.io/issues/7716890449/

Representative event: 03ab937c459c40ee57c769ee8ebf7f8a

Finding

Two macOS Free stable occurrences on binaryninja@6.0.10601 have the same
symbolized failure. One is grouped as BINARYNINJA-QJ and the other is grouped
under the older generic abort issue BINARYNINJA-13. Both occur on the detached
file-close worker created by NotificationListener: the user closes the last
tab for an active debugger file, chooses to stop debugging, and the worker runs
QuitAndWait followed by Destroy.

The controller releases DebuggerState, which deletes LldbAdapter. Its
destructor calls SBProcess::Destroy and SBDebugger::Destroy. The next frame
is the compiler's terminate helper, followed by std::terminate, proving that
a C++ exception escaped the implicitly non-throwing destructor. The event does
not identify which of the two LLDB calls threw or what LLDB target state caused
it.

Reproduction

The customer workflow is known, but the backend state that makes LLDB throw is
not captured. Closing an arbitrary active LLDB session is therefore only a
plausible trigger, not a deterministic reproduction.

Reproduction status: no deterministic repro.

Suggested patch

Treat both external-library teardown calls as independent best-effort cleanup:
catch standard and unknown exceptions from SBProcess::Destroy, then still
attempt SBDebugger::Destroy under its own guard. This prevents an LLDB cleanup
failure from terminating Binary Ninja and records the exception for later
diagnosis.

Patch confidence: medium. The terminate path is definitive, but the originating
LLDB exception is unavailable.