Re: [PATCH 1/5] Cygwin: Make 'ulimit -c' control writing a coredump

[Jon Turney <jon.turney@dronecode.org.uk>]

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)