diff options
author | Ævar Arnfjörð Bjarmason <avarab@gmail.com> | 2022-07-28 02:13:42 +0300 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2022-07-28 02:35:40 +0300 |
commit | c68d5dbc945347359f8a1431740e4e9ad9d99efc (patch) | |
tree | d9a8b3a378e4974143a0515917721586baf32564 /upload-pack.c | |
parent | 3e3b9321cae0a09c066d1ff78f986d7382ea6898 (diff) |
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>
Diffstat (limited to 'upload-pack.c')
-rw-r--r-- | upload-pack.c | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/upload-pack.c b/upload-pack.c index 09f48317b0..b217a1f469 100644 --- a/upload-pack.c +++ b/upload-pack.c @@ -455,6 +455,7 @@ static void create_pack_file(struct upload_pack_data *pack_data, return; fail: + free(output_state); send_client_data(3, abort_msg, sizeof(abort_msg), pack_data->use_sideband); die("git upload-pack: %s", abort_msg); |