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

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On Jan 25 14:50, Jon Turney wrote:
> 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.

try_to_debug() is only calling IsDebuggerPresent() as test, and that's
nothing but a flag in the PEB which is set by the OS after a debugger
attached to the process.  So the test is by definition extremely
flaky, if the debugger is connecting and disconnecting, as you
already pointed out.

I'm wondering if we can't define our own way to attach to a process,
allowing to "WaitForDebugger" as long as the debugger is a Cygwin
debugger.  If we define a matching function (along the lines of
prctl(2) on Linux), we could change our debuggers, core dumpers
and stracers to call this attach function.

The idea would be to define some shared mutex object, the inferior
waits for and the debugger releases after having attached.

Is there really any need to support non-Cygwin debuggers?

> 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.

Hmm, ok.  This signal stuff *is* complicated and I'd be happy
if anybody finds out how to fix that...


Corinna