I spotted these when testing v2.36.0, but waited until after the release since there's no v2.36.0 regressions here. The scariest issue here by far is one I caused and am now fixing in 4/4. As noted I don't think it had any real practical fallout, but we should obviously fix it sooner than later. I think the 3/4 issue is likewise just a bit scary, but I haven't analyzed it as much. In that case we'd pass uninitialized memory to a syscall. It's clear that the --valgrind mode for the test suite is useful, but it's sooo sloooow (it takes around a full day to complete, and for me the full tests otherwise run in ~2 minutes). I'll try to run it in the background with some regularity going forward anyway. Aside: I do see that there's occasionaly FreeBSD runs in the "main" git/git CI. How are those hooked up? Running it in GitHub CI would take approximately forever (I think it would run into a hard timeout), but if we can hook up a CI runner on some dedicated hardware. Ævar Arnfjörð Bjarmason (4): tests: make RUNTIME_PREFIX compatible with --valgrind log test: skip a failing mkstemp() test under valgrind commit-graph.c: don't assume that stat() succeeds object-file: fix a unpack_loose_header() regression in 3b6a8db3b03 commit-graph.c | 6 ++++-- object-file.c | 8 ++++++-- t/t0060-path-utils.sh | 4 ++-- t/t1006-cat-file.sh | 10 ++++++++-- t/t1450-fsck.sh | 13 +++++++++++-- t/t4202-log.sh | 11 +++++++---- t/test-lib.sh | 1 + 7 files changed, 39 insertions(+), 14 deletions(-) -- 2.36.0.879.gd068ac2c328
