On 30/08/2020 13:47, Corinna Vinschen wrote:
On Aug 29 15:43, Jon Turney wrote:
Currently, when using CYGWIN='error_start=dumper', the core dump written
in response to an exception is non-deterministic, as the faulting
process isn't stopped while the dumper is started (it even seems
possible in theory that the faulting process could have exited before
the dumper process attaches).
Remove the waitloop argument, only used in this case, so the faulting
process busy-waits until the dump starts.
Code archaeology to determine why the code is this way didn't really turn
up any answers, but this seems a low-risk change, as this only changes
the behaviour when:
- a debugger isn't already attached
- an error_start is specified in CYGWIN env var
- an exception has occurred which will be translated to a signal
Future work: This probably can be further simplified to make it
completely synchronous by waiting for the dumper process to exit. This
would avoid the race condition of the dumper attaching and detaching
before we get around to checking for that (which we try to work around
by juggling thread priorities), and the failure state where the dumper
doesn't attach and we spin indefinitely.
So, on reflection, this idea is wrong, and it currently is the way it
has to be.
If we use CYGWIN='error_start=gdb', we should be able to continue the
thread which encountered an exception, which we can't do if it's blocked
waiting for the error_start process to exit.
So I'll tweak the patch commentary before pushing.
