BinaryNinjaDebugger::DebuggerUICallbacks::NotifyRebaseBinaryView

[sentry]

Sentry Issue: BINARYNINJA-2H

SIGSEGV / SI_KERNEL / 0x0: Fatal Error: SIGSEGV / SI_KERNEL / 0x0
  File "debuggercontroller.cpp", line 4514, in BinaryNinjaDebugger::DebuggerUICallbacks::NotifyRebaseBinaryView
  File "debuggercontroller.cpp", line 4579, in BinaryNinjaDebugger::DebuggerController::RebaseToAddress

@bdash says:

I think this is due to a lifetime issue with the debugger's UI callbacks. DebuggerUI::DebuggerUI calls DebuggerController::SetDebuggerUICallbacks and passes a pointer stored in m_uiCallbacks. DebuggerUI::~DebuggerUI deletes that object, but nothing unregisters the callbacks from the DebuggerController. I'm not sure what, if anything prevents the DebuggerController from making a UI callback after the DebuggerUI goes away.

[xusheng6]

Root Cause Analysis

This is a use-after-free on the DebuggerUICallbacks pointer.

The lifetime issue

1. DebuggerUI constructor (ui/ui.cpp:1701) allocates m_uiCallbacks = new DebuggerUICallbacks and passes it to the controller via SetDebuggerUICallbacks().
2. DebuggerController stores the C-API callback pointer and context in its own std::unique_ptr<DebuggerUICallbacks> m_uiCallbacks.
3. DebuggerUI destructor deletes the local m_uiCallbacks object, but never unregisters it from the controller — the controller still holds a pointer to the now-freed context.
4. When DebuggerController::RebaseToAddress() is later called on the event thread, it calls m_uiCallbacks->NotifyRebaseBinaryView() which dereferences the freed context pointer → SIGSEGV.

How DebuggerController outlives DebuggerUI

DebuggerUI is owned by a unique_ptr in the global g_viewFrameMap, keyed by ViewFrame*. When the user closes the binary view tab, the ViewFrame is destroyed, which erases the map entry and destroys the DebuggerUI.

However, DebuggerController uses reference counting (DbgRef). It can be kept alive by the global controller array, the DebuggerFileAccessor, and its own event thread. So closing the tab kills the UI but the controller keeps running.

A possible scenario to trigger this

1. User launches a debug target (e.g., remote debugging or a large binary where the launch/attach is slow).
2. The launch is taking too long, so the user stops the session and closes the binary view tab.
3. Closing the tab destroys the ViewFrame → destroys DebuggerUI → deletes m_uiCallbacks, but the controller's copy still points to freed memory.
4. Meanwhile, the event thread in the controller finishes processing — the target stops, a loaded module is detected, and RebaseToAddress() is called.
5. RebaseToAddress() calls m_uiCallbacks->NotifyRebaseBinaryView() → invokes the callback with the dangling context pointer → crash.

Fix

PR #1040: Unregister the UI callbacks from the controller in ~DebuggerUI() before deleting them. SetDebuggerUICallbacks(nullptr) now clears the controller's copy. The existing null check in RebaseToAddress() then safely returns false instead of crashing.