Re: [PATCH] Add minidump write utility

[Jon TURNEY <jon dot turney at dronecode dot org dot uk>]

On 08/02/2014 20:49, Christopher Faylor wrote:
> On Sat, Feb 08, 2014 at 03:00:18PM +0000, Jon TURNEY wrote:
>> On 07/02/2014 16:36, Jon TURNEY wrote:
>> 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.
[snip]
>> 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.

On reflection, given the below, adding an option so that, when running
minidumper standalone, terminating the dumped process can be disabled, but
defaulting to behaving in the same way as dumper seems like an adequate
solution for the moment.

>> 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
>> +  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.

This is a good point.   I think I was expecting to achieve that by the parent
waiting until the error_start process exits, but of course, that isn't what is
wanted if it's a debugger.

Looking into this a bit more, according to this ChangeLog entry, this is
deliberate, so I think I'll leave this alone until I understand it better...

2003-02-13  Christopher Faylor

	* exceptions.cc (try_to_debug): Don't reset priority when returning
	from non-waitloop call.