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.
