search

ssbssa / heob

Detects buffer overruns and memory leaks.
Boost Software License 1.0
155 stars 25 forks source link

When running with a debugger, commands are not processed during breakpoint #5

Closed orgads closed 6 years ago

orgads commented 6 years ago

The extra heob window is blocked, and pressing keys has no effect.

I would like to have a breakpoint in my application, then enable heob, and on another breakpoint stop it.

Another alternative is to introduce an API similar to CALLGRIND_START_INSTRUMENTATION and STOP.

ssbssa commented 6 years ago

Yes, the heob window is blocked because the dedicated thread in the target application that's waiting for commands is paused as well when reaching a breakpoint. I don't think I can change that.

How does CALLGRIND_START_INSTRUMENTATION work? Do you need to include callgrind.h in the target application and then you put these commands in the desired locations of the source? Something like this is actually already possible, but I haven't advertised it (wasn't sure if anyone would want to use it). You can see how it works in allocer.cpp, if you look for heob_control, but I guess I should put it into a header file for easier use.

ssbssa commented 6 years ago

Actually, since for start/stop it's just an integer flag that's toggled, a simple WriteProcessMemory() should be enough. But clear/show do a lot more, so I can't change them to non-blocking behavior.

ssbssa commented 6 years ago

I've changed start/stop so it's working for processes that are paused in a debugger as well.

And I've created a new heob.h that can be included by user code to send commands via heob_control().

orgads commented 6 years ago

Thanks! I'll try it on Sunday