On Fri, Jun 03 2022, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> 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? Per a86303cb5d5 (test-tool: help verifying BUG() code paths, 2018-05-02) I think it was to get rid of coredump clutter outside of trash directories (which would require some non-standard config), which doesn't seem worth it. >> 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. I was trying to get the above across, i.e. that the reasoning still applies, but that the fakery isn't worth it. >> + 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 ;-) I'll test it better for portability before a non-RFC.
