Re: [RFC PATCH 1/3] test-tool: don't fake up BUG() exits as code 99

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 3, 2022, 21:05 UTC
Message-ID: <xmqqczfpe9ua.fsf@gitster.g>
In-Reply-To: <xmqqv8theehf.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 13 quoted lines

>> However, in doing so we've been fooling ourselves when it comes to
>> what trace2 events we log. The events tested for in
>> 0a9dde4a04c (usage: trace2 BUG() invocations, 2021-02-05) are not the
>> real ones, but those that we emit only from the "test-tool".
>
> I can fully agree with the above reasoning, i.e. let's test what we
> do use in production, instead of something nobody uses for real, if
> we were adding a test for BUG() in vacuum, but why did we have to
> "fake" it in the first place?
> ...
> Are we sure that the reason no longer applies?  How do we know?  We
> would want to explain that to future developers in the proposed log
> message, I would think.

We can flip it the other way around.

I do not think I ever saw anybody asked anybody on this list who got a BUG() message to use the coredump to do something useful. Don't modern distros ship with "ulimit -c 0" these days?

It might be possible that a better direction is to introduce GIT_ABORT_ON_BUG environment or core.abortOnBUG configuration that chooses between abort() and exit(99), or something like that, and then we switch to use the latter by default over time?