Re: [PATCH] ll-merge: killing the external merge driver aborts the merge
- From
- Joshua Hudson <jhudson@cedaron.com>
- Date
- Jun 27, 2023, 21:32 UTC
- 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:
Show 17 quoted lines
> 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.