git/t/lib-httpd
Jeff King 252d693797 test-lib: set UBSAN_OPTIONS to match ASan
For a long time we have used ASAN_OPTIONS to set abort_on_error. This is
important because we want to notice detected problems even in programs
which are expected to fail. But we never did the same for UBSAN_OPTIONS.
This means that our UBSan test suite runs might silently miss some
cases.

It also causes a more visible effect, which is that t4058 complains
about unexpected "fixes" (and this is how I noticed the issue):

  $ make SANITIZE=undefined CC=gcc && (cd t && ./t4058-*)
  ...
  ok 8 - git read-tree does not segfault # TODO known breakage vanished
  ok 9 - reset --hard does not segfault # TODO known breakage vanished
  ok 10 - git diff HEAD does not segfault # TODO known breakage vanished

The tests themselves aren't that interesting. We have a known bug where
these programs segfault, and they do when compiled without sanitizers.
With UBSan, when the test runs:

  test_might_fail git read-tree --reset base

it gets:

  cache-tree.c:935:9: runtime error: member access within misaligned address 0x5a5a5a5a5a5a5a5a for type 'struct cache_entry', which requires 8 byte alignment

So that's garbage memory which would _usually_ cause us to segfault, but
UBSan catches it and complains first about the alignment. That makes
sense, but the weird thing is that UBSan then exits instead of aborting,
so our test_might_fail call considers that an acceptable outcome and the
test "passes".

Curiously, this historically seems to have aborted, because I've run
"make test" with UBSan many times (and so did our CI) and we never saw
the problem. Even more curiously, I see an abort if I use clang with
ASan and UBSan together, like:

  # this aborts!
  make SANITIZE=undefined,address CC=clang

But not with just UBSan, and not with both when used with gcc:

  # none of these do
  make SANITIZE=undefined CC=gcc
  make SANITIZE=undefined CC=clang
  make SANITIZE=undefined,address CC=gcc

Likewise moving to older versions of gcc (I tried gcc-11 and gcc-12 on
my Debian system) doesn't abort. Nor does moving around in Git's
history. Neither this test nor the relevant code have been touched in a
while, and going back to v2.41.0 produces the same outcome (even though
many UBSan CI runs have passed in the meantime).

So _something_ changed on my system (and likely will soon on other
people's, since this is stock Debian unstable), but I didn't track
it further. I don't know why it ever aborted in the past, but we
definitely should be explicit here and tell UBSan what we want to
happen.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-21 14:10:36 -07:00
..
apache.conf test-lib: set UBSAN_OPTIONS to match ASan 2023-09-21 14:10:36 -07:00
apply-one-time-perl.sh t/lib-httpd: pass PERL_PATH to CGI scripts 2023-04-06 09:29:43 -07:00
broken-smart-http.sh t/lib-httpd: use write_script to copy CGI scripts 2014-05-23 12:41:50 -07:00
error-no-report.sh send-pack: complain about "expecting report" with --helper-status 2021-10-18 13:26:52 -07:00
error-smart-http.sh t5551: test server-side ERR packet 2019-02-06 12:20:23 -08:00
error.sh http: fix charset detection of extract_content_type() 2014-06-17 15:25:00 -07:00
incomplete-body-upload-pack-v2-http.sh remote-curl: error on incomplete packet 2020-05-24 16:26:00 -07:00
incomplete-length-upload-pack-v2-http.sh remote-curl: error on incomplete packet 2020-05-24 16:26:00 -07:00
nph-custom-auth.sh t5563: add tests for basic and anoymous HTTP access 2023-02-27 10:40:40 -08:00
passwd use distinct username/password for http auth tests 2014-01-02 10:25:03 -08:00
proxy-passwd add basic http proxy tests 2023-02-16 16:24:23 -08:00
ssl.cnf t/lib-httpd: increase ssl key size to 2048 bits 2023-02-01 10:10:34 -08:00