| Message ID | bc2206aa47e7e8be0642bb4540e7ddec22fbac91.1728624670.git.ps@pks.im (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Memory leak fixes (pt.9) | expand |
Patrick Steinhardt <ps@pks.im> writes: > The `obuf` member of `struct merge_options` is used to buffer output in > some cases. In order to not discard its allocated memory we only release > its contents in `merge_finalize()` when we're not currently recursing > into a subtree. > > This results in some situations where we seemingly do not release the > buffer reliably. We thus have calls to `strbuf_release()` for this > buffer scattered across the codebase. But we're missing one callsite in > git-merge(1), which causes a memory leak. > > We should ideally refactor this interface so that callers don't have to > know about any such internals. But for now, paper over the issue by > adding one more `strbuf_release()` call. Shall we mark this as #leftoverbits? -- Toon
On Fri, Oct 18, 2024 at 02:03:48PM +0200, Toon Claes wrote: > Patrick Steinhardt <ps@pks.im> writes: > > > The `obuf` member of `struct merge_options` is used to buffer output in > > some cases. In order to not discard its allocated memory we only release > > its contents in `merge_finalize()` when we're not currently recursing > > into a subtree. > > > > This results in some situations where we seemingly do not release the > > buffer reliably. We thus have calls to `strbuf_release()` for this > > buffer scattered across the codebase. But we're missing one callsite in > > git-merge(1), which causes a memory leak. > > > > We should ideally refactor this interface so that callers don't have to > > know about any such internals. But for now, paper over the issue by > > adding one more `strbuf_release()` call. > > Shall we mark this as #leftoverbits? I guess it is now marked as such :) Patrick
diff --git a/builtin/merge.c b/builtin/merge.c index 84d0f3604bc..51038eaca84 100644 --- a/builtin/merge.c +++ b/builtin/merge.c @@ -754,6 +754,7 @@ static int try_merge_strategy(const char *strategy, struct commit_list *common, clean = merge_recursive(&o, head, remoteheads->item, reversed, &result); free_commit_list(reversed); + strbuf_release(&o.obuf); if (clean < 0) { rollback_lock_file(&lock); diff --git a/t/t6424-merge-unrelated-index-changes.sh b/t/t6424-merge-unrelated-index-changes.sh index 7677c5f08d0..a7ea8acb845 100755 --- a/t/t6424-merge-unrelated-index-changes.sh +++ b/t/t6424-merge-unrelated-index-changes.sh @@ -2,6 +2,7 @@ test_description="merges with unrelated index changes" +TEST_PASSES_SANITIZE_LEAK=true . ./test-lib.sh # Testcase for some simple merges
The `obuf` member of `struct merge_options` is used to buffer output in some cases. In order to not discard its allocated memory we only release its contents in `merge_finalize()` when we're not currently recursing into a subtree. This results in some situations where we seemingly do not release the buffer reliably. We thus have calls to `strbuf_release()` for this buffer scattered across the codebase. But we're missing one callsite in git-merge(1), which causes a memory leak. We should ideally refactor this interface so that callers don't have to know about any such internals. But for now, paper over the issue by adding one more `strbuf_release()` call. Signed-off-by: Patrick Steinhardt <ps@pks.im> --- builtin/merge.c | 1 + t/t6424-merge-unrelated-index-changes.sh | 1 + 2 files changed, 2 insertions(+)