From: Joshua Hudson <jhudson@cedaron.com>
Date: Tue, 27 Jun 2023 21:32:13 GMT
Subject: Re: [PATCH] ll-merge: killing the external merge driver aborts the merge
Message-ID: <e7e5809d-5405-1e0b-f4e7-2d97e6748a09@cedaron.com>
In-Reply-To: <xmqqilb8fvgu.fsf@gitster.g>

On 6/27/2023 2:26 PM, Junio C Hamano wrote:
> Joshua Hudson <jhudson@cedaron.com> writes:
>
>> Try changing kill -9 $$ to exit 137 # 128 + 9
> Yeah, but then (1) we are not simulating a case where the external
> merge driver hits a segfault or receives a signal from outside and
> dies involuntarily, and (2) we are codifying that even on Windows,
> program that was killed by signal N must exit with 128 + N, and
> these are the reasons why I did not go that route.
>
> Stepping back a bit, how does one typically diagnose programatically
> on Windows, after "spawning" a separate program, if the program died
> involuntarily and/or got killed?  It does not have to be "exit with
> 128 + signal number"---as long as it can be done programatically and
> reliably, we would be happy.  The code to diagnose how the spawned
> program exited in run_command(), which is in finish_command() and
> then in wait_or_whine(), may have to be updated with such a piece of
> Windows specific knowledge.

abort() => 3

Killed => no you can't detect it

Faulted => exit code has the high bit set ( >= 0x8000000 )

My starting off with "the logical equivalent of calling abort()" has 
proven to be an unfortunate word choice. I need to harden up the exit 
pathway on my side _anyway_. An OOM at least does turn into Faulted.