[PATCH] Add minidump write utility
Sat Feb 8 20:49:00 GMT 2014
On Sat, Feb 08, 2014 at 03:00:18PM +0000, Jon TURNEY wrote:
>On 07/02/2014 16:36, Jon TURNEY wrote:
>> This patch adds a 'minidumper' utility, which functions identically to
>> 'dumper' except it writes a Windows minidump, rather than a core file.
>> I'm not sure if this is of use to anyone but me, but since I've had the patch
>> sitting around for a couple of years, here it is...
>> 2014-02-07 Jon TURNEY <email@example.com>
>> * minidumper.cc: New file.
>> * Makefile.in (CYGWIN_BINS): Add minidumper.
>> * utils.xml (minidumper): New section.
>Unfortunately there seems to be a bit of a problem with this patch. It seems
>that cygwin assumes that the JIT debugger will terminate the debugged process.
> I'm not sure if that's always been the case.
>Consider the following test case:
>$ cat segv-test.c
>int main(int argc, char *argv)
> *(char *)0 = 0;
> return 0;
>$ gcc -o segv-test.exe segv-test.c
>$ export CYGWIN="error_start:C:\cygwin\bin\true.exe"
>seg-test crashes, true runs and exits, and segv-test spins.
>dumper.exe does terminate the debugeee, but despite what utils.xml says about
>this, I don't think this hasn't been a Windows API limitation since
>DebugSetProcessKillOnExit() has existed.
>I could fix this by making minidumper also terminate the dumped process, but
>that doesn't seem the right approach.
>I don't understand what debugging scenarios the waitloop part of
>exceptions.cc:try_to_debug() is useful in, or why it doesn't wait until the
>debugger process exits, so it's not clear to me how to fix this there, but
>I'll note in passing that it seems that the thread's original priority is not
>restored after running the debugger if waitloop=false, so perhaps at least the
>following is needed:
>--- cygwin/exceptions.cc 8 Jan 2014 16:51:20 -0000 1.432
>+++ cygwin/exceptions.cc 8 Feb 2014 14:49:59 -0000
>@@ -504,10 +504,8 @@
> if (!dbg)
> system_printf ("Failed to start debugger, %E");
>+ else if (waitloop)
>- if (!waitloop)
>- return dbg;
> SetThreadPriority (GetCurrentThread (), THREAD_PRIORITY_IDLE);
> while (!being_debugged ())
> Sleep (1);
Go ahead and check in the above but I don't see how it would be possible
in a non-racy way for a dumper process to dump it's parents core unless
the parent was guaranteed to still be alive.
More information about the Cygwin-patches