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, 19:25 UTC
Message-ID: <xmqqv8theehf.fsf@gitster.g>
In-Reply-To: <RFC-patch-1.3-78431bdc8f0-20220525T234908Z-avarab@gmail.com>

Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:

Show 10 quoted lines

> Change the BUG() function invoked be "test-tool" to be the "real" one,
> instead of one that avoids producing core files. In
> a86303cb5d5 (test-tool: help verifying BUG() code paths, 2018-05-02)
> to test the (then recently added) BUG() function we faked up the
> abort() in favor of an exit with code 99.
>
> 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?

> Let's just stop faking it, and call abort(). As a86303cb5d5 notes this
> will produce core files on some OS's, but as the default behavior for
> that is to dump them in the current directory they'll be placed in the
> trash directory that we'll shortly me "rm -rf"-ing.

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.

> +	elif test_match_signal 6 $exit_code && list_contains "$_test_ok" sigabrt
> +	then
> +		return 0
>  	elif test_match_signal 13 $exit_code && list_contains "$_test_ok" sigpipe

Not a new problem, but these numberings are probably not very portable. I am willing to take this as-is and let people on minority platforms complain ;-)