On 23/01/2024 14:29, Corinna Vinschen wrote:
On Jan 23 14:20, Jon Turney wrote:
Even then this is clearly not totally bullet-proof. Maybe the right thing to
do is add a suitable timeout here, so even if we fail to notice the
DebugActiveProcess() (or there's a custom JIT debugger which just writes the
fact a process crashed to a logfile or something), we'll exit eventually?
Timeouts are just that tiny little bit more bullet-proof, they still
aren't totally bullet-proof.
What timeout were you thinking of? milliseconds?
Oh no, tens of seconds or something, just as a fail-safe.
To be clear, I'm suggesting something like this:
- while (!being_debugged ())
+ while (!being_debugged () || GetTickCount64() > timeout)
Sleep (0);
As the comment above identifies, the concern is that if the executed
command runs too quickly, we don't notice and get stuck there.
This isn't a concern when invoking gdb, as if the debugee is allowed to
continue, being_debugged will return TRUE and we'll exit the loop.
But if we're invoking dumper, if it attaches and detaches quickly
enough, we never notice and just get stuck.
(Ofc, all this is working around the fact that Win32 API doesn't have a
WaitForDebuggerPresent(timeout) function)
