Attaching to process after running the process leaks binary view

[emesare]

Screen.Recording.2026-03-31.at.3.20.18.PM.mov

Tested both dbgeng and native windows adapter and both will leak

[xusheng6]

This does not happen on macOS This affects the macOS as well. Repro steps:

1. Open helloworld (can be anything different from the second binary used later)
2. Run it under the debugger
3. Stop debugging
4. Close the file. get_memory_usage_info() reports 0 binary views
5. Open the file again
6. Run helloworld_thread
7. Use the debugger to attach to it
8. Run get_memory_usage_info() and observe 'Active BinaryView objects': 3. This is already not expected -- it should be 2
9. Stop debugging
10. Close the binary
11. Run get_memory_usage_info() and observe it still reports 'Active BinaryView objects': 3 (update: I see 2 in all my recently testing, so maybe consider it a 2)

[xusheng6]

yeah so the second operation does not have to be an attach -- it could also just be a launch with ASLR disabled. The first launch must be ASLR disabled, but it can be a different binary

[xusheng6]

Hmmm interesting -- I actually cannot repro this on Windows, despite the original report is from Windows

[xusheng6]

Per my tests the DebuggerController is not leaked

[bdash]

When following the steps in #1042 (comment) I do see a DebuggerController leaked:

Possible leak of BinaryNinjaDebuggerAPI::DebuggerController, referenced at:
0   libdebuggerui.dylib                 0x00000001353016f8 ProcessListWidget::ProcessListWidget(QWidget*, BinaryNinjaDebuggerAPI::DbgRef<BinaryNinjaDebuggerAPI::DebuggerController>) + 164
1   libdebuggerui.dylib                 0x000000013530273c AttachProcessDialog::AttachProcessDialog(QWidget*, BinaryNinjaDebuggerAPI::DbgRef<BinaryNinjaDebuggerAPI::DebuggerController>) + 312
2   libdebuggerui.dylib                 0x000000013539c52c std::__1::__function::__func<GlobalDebuggerUI::SetupMenu(UIContext*)::$_23, void (UIActionContext const&)>::operator()(UIActionContext const&) + 636

The underlying cause is that AttachProcessDialog is leaked:

debugger/ui/ui.cpp

Lines 858 to 864 in 5fde139

	auto dialog = new AttachProcessDialog(context->mainWindow(), controller);
	if (dialog->exec() != QDialog::Accepted)
	return;
	uint32_t pid = dialog->GetSelectedPid();
	if (pid == 0)
	return;

AttachProcessDialog owns a ProcessListWidget which in turn holds a ref on a DebuggerController.

I do not see the 'Active BinaryView objects': 3 that @xusheng6 mentions though, so perhaps there is a second issue at play.

[xusheng6]

When following the steps in #1042 (comment) I do see a DebuggerController leaked:

Possible leak of BinaryNinjaDebuggerAPI::DebuggerController, referenced at:
0   libdebuggerui.dylib                 0x00000001353016f8 ProcessListWidget::ProcessListWidget(QWidget*, BinaryNinjaDebuggerAPI::DbgRef<BinaryNinjaDebuggerAPI::DebuggerController>) + 164
1   libdebuggerui.dylib                 0x000000013530273c AttachProcessDialog::AttachProcessDialog(QWidget*, BinaryNinjaDebuggerAPI::DbgRef<BinaryNinjaDebuggerAPI::DebuggerController>) + 312
2   libdebuggerui.dylib                 0x000000013539c52c std::__1::__function::__func<GlobalDebuggerUI::SetupMenu(UIContext*)::$_23, void (UIActionContext const&)>::operator()(UIActionContext const&) + 636

The underlying cause is that AttachProcessDialog is leaked:

debugger/ui/ui.cpp

Lines 858 to 864 in 5fde139
auto dialog = new AttachProcessDialog(context->mainWindow(), controller);
if (dialog->exec() != QDialog::Accepted)
return;

uint32_t pid = dialog->GetSelectedPid();
if (pid == 0)
return;

AttachProcessDialog owns a ProcessListWidget which in turn holds a ref on a DebuggerController.

I do not see the 'Active BinaryView objects': 3 that @xusheng6 mentions though, so perhaps there is a second issue at play.

Yeah this does look like an actual leak, but I believe it is a different one. I will look into it

[xusheng6]

also @bdash seems like you have a patch that also makes the DebuggerController ref-counted -- can you check that in (later)?

[xusheng6]

also interestingly, in the video mason posted (#1042 (comment)), the leak is also caused by a leaking AttachProcessDialog. Only I am running into a different bug xD