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 archeology 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 occured 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. > --- > winsup/cygwin/exceptions.cc | 8 ++------ > winsup/cygwin/winsup.h | 2 +- > 2 files changed, 3 insertions(+), 7 deletions(-)
I'm a bit fuzzy on the implications but it doesn't look like it hurts a lot(*). Let's get it in. Thanks, Corinna (*) Famous last words alarm...
