memory leak HardwareBreakpoints::cpuContextMenu and friends

[sorokin]

Leak sanitizer reports these leaks:

Indirect leak of 48 byte(s) in 1 object(s) allocated from:
    #0 0x7f5c95377d80 in operator new(unsigned long) (/nix/store/784rh7jrfhagbkydjfrv68h9x3g4gqmk-gcc-8.3.0-lib/lib/libasan.so.5+0xedd80)
    #1 0x7f5c7e695267 in HardwareBreakpointsPlugin::HardwareBreakpoints::stackContextMenu() /home/ivan/d/edb-debugger/plugins/HardwareBreakpoints/HardwareBreakpoints.cpp:253
    #2 0x694aac in Debugger::Debugger(QWidget*) /home/ivan/d/edb-debugger/src/Debugger.cpp:485
    #3 0x4e683a in start_debugger /home/ivan/d/edb-debugger/src/main.cpp:96
    #4 0x4e683a in main /home/ivan/d/edb-debugger/src/main.cpp:255

Indirect leak of 48 byte(s) in 1 object(s) allocated from:
    #0 0x7f5c95377d80 in operator new(unsigned long) (/nix/store/784rh7jrfhagbkydjfrv68h9x3g4gqmk-gcc-8.3.0-lib/lib/libasan.so.5+0xedd80)
    #1 0x7f5c7e69ba38 in HardwareBreakpointsPlugin::HardwareBreakpoints::cpuContextMenu() /home/ivan/d/edb-debugger/plugins/HardwareBreakpoints/HardwareBreakpoints.cpp:324
    #2 0x694aac in Debugger::Debugger(QWidget*) /home/ivan/d/edb-debugger/src/Debugger.cpp:485
    #3 0x4e683a in start_debugger /home/ivan/d/edb-debugger/src/main.cpp:96
    #4 0x4e683a in main /home/ivan/d/edb-debugger/src/main.cpp:255

Indirect leak of 48 byte(s) in 1 object(s) allocated from:
    #0 0x7f5c95377d80 in operator new(unsigned long) (/nix/store/784rh7jrfhagbkydjfrv68h9x3g4gqmk-gcc-8.3.0-lib/lib/libasan.so.5+0xedd80)
    #1 0x7f5c7e6985d7 in HardwareBreakpointsPlugin::HardwareBreakpoints::dataContextMenu() /home/ivan/d/edb-debugger/plugins/HardwareBreakpoints/HardwareBreakpoints.cpp:288
    #2 0x694aac in Debugger::Debugger(QWidget*) /home/ivan/d/edb-debugger/src/Debugger.cpp:485
    #3 0x4e683a in start_debugger /home/ivan/d/edb-debugger/src/main.cpp:96
    #4 0x4e683a in main /home/ivan/d/edb-debugger/src/main.cpp:255

The lines in the stack trace corresponds to the lines where QMenu is created:

	auto menu = new QMenu(tr("Hardware Breakpoints"));

Notice that QMenu is created without a parent. At first I thought to fix the problem by passing QWidget* parent to cpuContextMenu and this is fine for usages in addPluginContextMenu. But I stuck at the usage in finishPluginSetup.

What do you think is the best way to fix the problem?

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[10110111]

I suppose for the purpose of cleanliness, the best way is to save the menu as member unique_ptr in class HardwareBreakpoints.

But OTOH, does there exist a scenario when there'll be more than one call to <plugin-name>::dataContextMenu()? If not, we might just as well ignore this "leak", since it doesn't lead to systematic increase in memory consumption over EDB run time.

[sorokin]

If not, we might just as well ignore this "leak", since it doesn't lead to systematic increase in memory consumption over EDB run time.

This approach make it difficult to find real leaks. When you have 1000 false positives and you got one real one it is much more difficult to notice than when you have 0 and you got one.

[sorokin]

I looked at what qactions have shortcuts and apparently there is only one such action: Assemble (Space). I guess I can just introduce a new function something like IPlugin::globalShortcuts to be used in finishPluginSetup. This will limit usages of cpuContextMenu and friends only to the places where real menu need to be created.

[eteran]

Thanks, I'll check into this

[eteran]

I think probably the "correct" solution would be for something in Debugger.cpp to take ownership of these QAction objects so they get destroyed when the new owner gets destroyed. I'll think about it for a little bit.