This is the mail archive of the cygwin-patches mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add minidump write utility

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  <>
>> 	* New file.
>> 	* (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"
>$ ./segv-test
>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
> 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/        8 Jan 2014 16:51:20 -0000       1.432
>+++ cygwin/        8 Feb 2014 14:49:59 -0000
>@@ -504,10 +504,8 @@
>   if (!dbg)
>     system_printf ("Failed to start debugger, %E");
>-  else
>+  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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]