upload-pack: fix a memory leak in create_pack_file()
commitc68d5dbc945347359f8a1431740e4e9ad9d99efc
authorÆvar Arnfjörð Bjarmason <avarab@gmail.com>
Wed, 27 Jul 2022 23:13:42 +0000 (28 01:13 +0200)
committerJunio C Hamano <gitster@pobox.com>
Wed, 27 Jul 2022 23:35:40 +0000 (27 16:35 -0700)
treed9a8b3a378e4974143a0515917721586baf32564
parent3e3b9321cae0a09c066d1ff78f986d7382ea6898
upload-pack: fix a memory leak in create_pack_file()

Fix a memory leak that's been reported by some versions of "gcc" since
"output_state" became malloc'd in 55a9651d26a (upload-pack.c: increase
output buffer size, 2021-12-14).

In e75d2f7f734 (revisions API: have release_revisions() release
"filter", 2022-04-13) it was correctly marked as leak-free, the only
path through this function that doesn't reach the free(output_state)
is if we "goto fail", and that will invoke "die()".

Such leaks are not included with SANITIZE=leak (but e.g. valgrind will
still report them), but under some gcc optimization (I have not been
able to reproduce it with "clang") we'll report a leak here
anyway. E.g. gcc v12 with "-O2" and above will trigger it, but not
clang v13 with any "-On".

The GitHub CI would also run into this leak if the "linux-leaks" job
was made to run with "GIT_TEST_SANITIZE_LEAK_LOG=true".

See [1] for a past case where gcc had similar trouble analyzing leaks
involving a die() invocation in the function.

1. https://lore.kernel.org/git/patch-v3-5.6-9a44204c4c9-20211022T175227Z-avarab@gmail.com/

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t1060-object-corruption.sh
upload-pack.c