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

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

On 24/01/2024 14:39, Corinna Vinschen wrote:
> On Jan 24 13:28, Jon Turney wrote:
>> 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.
> 
> Uh, sounds a lot.  10 secs?  Not longer, I think.
> 
> If you want to do that for 3.5, please do it this week.  You can
> push the change without waiting for approval.

Thanks.

I pushed a small change adding this timeout.

>> (Ofc, all this is working around the fact that Win32 API doesn't have a
>> WaitForDebuggerPresent(timeout) function)
> 
> Yeah, and there's no alternative way using the native API afaics :(

So this situation with a JIT debugger is even stranger than my 
emendations to the documentation say.

Because we're hitting try_to_debug() in exception::handle(), which has 
some code to replay the exception via ExceptionContinueExecution (which 
I guess the debugger will catch as a first-chance) (and goes into a mode 
where it ignores the next half-million exceptions... no idea what that's 
about!)

That's not the same as signal_exit() with a coredumping signal (haven't 
checked if those are all generated from exceptions, but seemly probable, 
so the try_to_debug() there maybe isn't doing anything?), where we're 
going to exit thereafter.

The practical upshot of this is if the JIT debugger doesn't terminate or 
fix the erroring process, we'll just replay the faulting instruction and 
invoke the JIT debugger again.