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.
