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

[Jon Turney]

On 25/01/2024 18:21, Corinna Vinschen wrote:
> 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:
[...]
>> 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 seems 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?

idk

I think something like that used to exist a long time ago, see commit 
8abeff1ead5f3824c70111bc0ff74ff835dafa55

That long predates my involvement with cygwin so I've no idea why that 
was removed.

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

To be clear, not a problem with "core dumping signals", as the process 
now always end up exiting, one way or another.

It's only a problem when someone has set "CYGWIN=error_start:true" or 
something equally dumb.