a30cd7a5b9
Currently, when using CYGWIN's error_start facility, the faulting process isn't stopped while the error_start process is started when the fault is caused by an exception. (it even seems possible in theory that the faulting process could have exited before the error_start process attaches). This leads to e.g. the core dump written by CYGWIN='error_start=dumper' in response to an exception being non-deterministic. Remove the waitloop argument from try_to_debug(), only used in the exception case, so the faulting process busy-waits until the error_start process attaches. 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 If error_start invokes something which doesn't attach using DebugActiveProcess(), we will spin indefinitely, but that will also currently occur for any of the existing other uses of try_to_debug(), which default to waitloop=TRUE. |
||
|---|---|---|
| .. | ||
| CVSChangeLogs.old | ||
| cygserver | ||
| cygwin | ||
| doc | ||
| lsaauth | ||
| testsuite | ||
| utils | ||
| CONTRIBUTORS | ||
| COPYING | ||
| COPYING.LIB | ||
| CYGWIN_LICENSE | ||
| Makefile.common | ||
| Makefile.in | ||
| README | ||
| acinclude.m4 | ||
| aclocal.m4 | ||
| autogen.sh | ||
| c++wrap | ||
| ccwrap | ||
| config.guess | ||
| config.sub | ||
| configure | ||
| configure.ac | ||
| configure.cygwin | ||
| install-sh | ||
README
THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Cygwin documentation is available on the net at https://cygwin.com You might especially be interested in https://cygwin.com/faq/faq.html#faq.programming.building-cygwin