history: 'reword HEAD' surfaces a memory leak

history: 'reword HEAD' surfaces a memory leak

[Kristoffer Haugsbakk]

I get a sanitizer error when I run a simple reword command:

    $ make SANITIZE=address install
    $ GIT_EDITOR=true git history reword \
        --dry-run 3cb9185f65410273787f74333cc027d2ea5daada
    update HEAD eeb9d4b5c4041739c0a19b4043924513c8aad2d2 3cb9185f65410273787f74333cc027d2ea5daada

    =================================================================
    ==116999==ERROR: LeakSanitizer: detected memory leaks

    Direct leak of 283 byte(s) in 1 object(s) allocated from:
        #0 0x712d2f6b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
        #1 0x61970a5757b2 in do_xmalloc /home/kristoffer/programming/git-worktree/git-leakcheck/wrapper.c:55
        #2 0x61970a575ec0 in do_xmallocz /home/kristoffer/programming/git-worktree/git-leakcheck/wrapper.c:89
        #3 0x61970a575ec0 in do_xmallocz /home/kristoffer/programming/git-worktree/git-leakcheck/wrapper.c:79
        #4 0x61970a575ec0 in xmallocz_gently /home/kristoffer/programming/git-worktree/git-leakcheck/wrapper.c:102
        #5 0x61970a309ca0 in unpack_compressed_entry /home/kristoffer/programming/git-worktree/git-leakcheck/packfile.c:1732
        #6 0x61970a310bf0 in unpack_entry /home/kristoffer/programming/git-worktree/git-leakcheck/packfile.c:1885
        #7 0x61970a311fbf in cache_or_unpack_entry /home/kristoffer/programming/git-worktree/git-leakcheck/packfile.c:1528
        #8 0x61970a311fbf in packed_object_info_with_index_pos /home/kristoffer/programming/git-worktree/git-leakcheck/packfile.c:1610
        #9 0x61970a313097 in packed_object_info /home/kristoffer/programming/git-worktree/git-leakcheck/packfile.c:1720
        #10 0x61970a313097 in packfile_store_read_object_info /home/kristoffer/programming/git-worktree/git-leakcheck/packfile.c:2214
        #11 0x61970a2caae8 in odb_source_files_read_object_info odb/source-files.c:58
        #12 0x61970a2c69a7 in odb_source_read_object_info odb/source.h:326
        #13 0x61970a2c69a7 in do_oid_object_info_extended /home/kristoffer/programming/git-worktree/git-leakcheck/odb.c:572
        #14 0x61970a2c69a7 in odb_read_object_info_extended /home/kristoffer/programming/git-worktree/git-leakcheck/odb.c:710
        #15 0x61970a2c7cbe in odb_read_object /home/kristoffer/programming/git-worktree/git-leakcheck/odb.c:756
        #16 0x61970a101d5a in repo_get_commit_buffer /home/kristoffer/programming/git-worktree/git-leakcheck/commit.c:399
        #17 0x61970a101d5a in repo_get_commit_buffer /home/kristoffer/programming/git-worktree/git-leakcheck/commit.c:391
        #18 0x61970a346bf6 in repo_logmsg_reencode /home/kristoffer/programming/git-worktree/git-leakcheck/pretty.c:716
        #19 0x619709ebbe64 in commit_tree_ext builtin/history.c:127
        #20 0x619709ebd17f in commit_tree_with_edited_message builtin/history.c:183
        #21 0x619709ebd17f in cmd_history_reword builtin/history.c:717
        #22 0x619709ec186f in cmd_history builtin/history.c:998
        #23 0x619709d87ca0 in run_builtin /home/kristoffer/programming/git-worktree/git-leakcheck/git.c:506
        #24 0x619709d87ca0 in handle_builtin /home/kristoffer/programming/git-worktree/git-leakcheck/git.c:782
        #25 0x619709d8c9a6 in run_argv /home/kristoffer/programming/git-worktree/git-leakcheck/git.c:865
        #26 0x619709d8c9a6 in cmd_main /home/kristoffer/programming/git-worktree/git-leakcheck/git.c:986
        #27 0x619709d83f54 in main /home/kristoffer/programming/git-worktree/git-leakcheck/common-main.c:9
        #28 0x712d2f229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

    SUMMARY: AddressSanitizer: 283 byte(s) leaked in 1 allocation(s).

The `--dry-run` is optional.

I get this on master, next, and seen, respectively:

1. `master`: 17ff1f98 (Sync with 'master', 2026-09-02)
2. 17ff1f98 (Sync with 'master', 2026-09-02)
3. 99855fed (Merge branch 'cc/early-scan-options' into seen, 2026-09-02)

I do not get this error when testing on the commit that introduced `git
history reword` (see later bisect log).

It’s too technical for me, but it seems that git-history(1) just
triggers a memory leak in the internal library (name?) code. Maybe you
need a packfile and/or a commit graph?

Bisecting told me that the first bad commit is 13763ecf (Merge branch
'ps/receive-pack-shallow-optim', 2026-03-02).

I tried to make an automated test for it but didn’t quite hack it. I got
an ad hoc repo to reproduce. Running a GC or commit-graph (and/or) might
have what have done it.

But it seems to happen every time I run the command in a “real repo” as
long as I don’t violate one of the preconditions (“can’t replay merge
commits yet!” etc.).

BISECT SCRIPT

Note: hopefully this isn’t sensitive to if there are
refs pointing to that commit. The commit is just
`git rev-parse origin/master`.

```
#!/bin/sh

# No setup. Just use this repo.
make SANITIZE=address || exit 125
: >err.txt
GIT_EDITOR=true ./bin-wrappers/git history reword 3cb9185f65410273787f74333cc027d2ea5daada 2>err.txt || {
    grep -q 'detected memory leaks' err.txt && exit 1
}

exit 0
```

BISECT LOG

    $ git bisect log
    git bisect start
    # status: waiting for both 'good' and 'bad' commits
    # bad: [1630431f326e15fcde608827b5ff38422528eb59] The 21st batch
    git bisect bad 1630431f326e15fcde608827b5ff38422528eb59
    # status: waiting for 'good' commit(s), 'bad' commit known
    # good: [d205234cb05a5e330c0f7f5b3ea764533a74d69e] builtin/history: implement "reword" subcommand
    git bisect good d205234cb05a5e330c0f7f5b3ea764533a74d69e
    # bad: [27caa6b4f7bce94fc1f07b96bcb0bcef8c5215f5] Merge branch 'en/backfill-fixes-and-edges'
    git bisect bad 27caa6b4f7bce94fc1f07b96bcb0bcef8c5215f5
    # bad: [6cdef943d28fa7d6964ec570b33a0bff4c80ea8c] Merge branch 'ps/odb-sources' into ps/object-counting
    git bisect bad 6cdef943d28fa7d6964ec570b33a0bff4c80ea8c
    # good: [94336d77bcbf4360b67a9454d8bf2e84b3d88ae7] Merge branch 'sd/doc-my1c-api-config-reference-fix'
    git bisect good 94336d77bcbf4360b67a9454d8bf2e84b3d88ae7
    # bad: [13763ecf7d92be72beff75c59163c5448d9e085e] Merge branch 'ps/receive-pack-shallow-optim'
    git bisect bad 13763ecf7d92be72beff75c59163c5448d9e085e
    # good: [bb9c781f4f4be2e6bf6285149ba7007fdaa735e7] Merge branch 'ps/history-ergonomics-updates'
    git bisect good bb9c781f4f4be2e6bf6285149ba7007fdaa735e7
    # good: [2cc71917514657b93014134350864f4849edfc83] The 8th batch
    git bisect good 2cc71917514657b93014134350864f4849edfc83
    # good: [664bd4e15a99a477acb616337df0f9fa95c729c3] Merge branch 'ty/symlinks-use-unsigned-for-bitset'
    git bisect good 664bd4e15a99a477acb616337df0f9fa95c729c3
    # good: [05c4af5c8f3d7310c8a3b2909d30ce761c6757aa] Merge branch 'kh/doc-am-xref'
    git bisect good 05c4af5c8f3d7310c8a3b2909d30ce761c6757aa
    # good: [427d39ca4f4f7a0e66652d92340af43cbda5135e] Merge branch 'ps/meson-gitk-git-gui'
    git bisect good 427d39ca4f4f7a0e66652d92340af43cbda5135e
    # good: [34113149cfde760b6b791939c6d8d87d27ca2767] Merge branch 'kh/doc-patch-id-4'
    git bisect good 34113149cfde760b6b791939c6d8d87d27ca2767
    # good: [024b4c96976fabdc8b73f4183d6bb8626ffe2c7d] commit: make `repo_parse_commit_no_graph()` more robust
    git bisect good 024b4c96976fabdc8b73f4183d6bb8626ffe2c7d
    # good: [bb5da75d6116c35924a04a418ef4c3182663d0a2] commit: use commit graph in `lookup_commit_reference_gently()`
    git bisect good bb5da75d6116c35924a04a418ef4c3182663d0a2
    # first 'bad' commit: [13763ecf7d92be72beff75c59163c5448d9e085e] Merge branch 'ps/receive-pack-shallow-optim'

Re: history: 'reword HEAD' surfaces a memory leak

[Patrick Steinhardt]

On Thu, Sep 03, 2026 at 05:26:44PM +0200, Kristoffer Haugsbakk wrote:
> I get a sanitizer error when I run a simple reword command:
> 
>     $ make SANITIZE=address install
>     $ GIT_EDITOR=true git history reword \
>         --dry-run 3cb9185f65410273787f74333cc027d2ea5daada
>     update HEAD eeb9d4b5c4041739c0a19b4043924513c8aad2d2 3cb9185f65410273787f74333cc027d2ea5daada
> 
>     =================================================================
>     ==116999==ERROR: LeakSanitizer: detected memory leaks
> 
>     Direct leak of 283 byte(s) in 1 object(s) allocated from:
>         #0 0x712d2f6b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>         #1 0x61970a5757b2 in do_xmalloc /home/kristoffer/programming/git-worktree/git-leakcheck/wrapper.c:55
>         #2 0x61970a575ec0 in do_xmallocz /home/kristoffer/programming/git-worktree/git-leakcheck/wrapper.c:89
>         #3 0x61970a575ec0 in do_xmallocz /home/kristoffer/programming/git-worktree/git-leakcheck/wrapper.c:79
>         #4 0x61970a575ec0 in xmallocz_gently /home/kristoffer/programming/git-worktree/git-leakcheck/wrapper.c:102
>         #5 0x61970a309ca0 in unpack_compressed_entry /home/kristoffer/programming/git-worktree/git-leakcheck/packfile.c:1732
>         #6 0x61970a310bf0 in unpack_entry /home/kristoffer/programming/git-worktree/git-leakcheck/packfile.c:1885
>         #7 0x61970a311fbf in cache_or_unpack_entry /home/kristoffer/programming/git-worktree/git-leakcheck/packfile.c:1528
>         #8 0x61970a311fbf in packed_object_info_with_index_pos /home/kristoffer/programming/git-worktree/git-leakcheck/packfile.c:1610
>         #9 0x61970a313097 in packed_object_info /home/kristoffer/programming/git-worktree/git-leakcheck/packfile.c:1720
>         #10 0x61970a313097 in packfile_store_read_object_info /home/kristoffer/programming/git-worktree/git-leakcheck/packfile.c:2214
>         #11 0x61970a2caae8 in odb_source_files_read_object_info odb/source-files.c:58
>         #12 0x61970a2c69a7 in odb_source_read_object_info odb/source.h:326
>         #13 0x61970a2c69a7 in do_oid_object_info_extended /home/kristoffer/programming/git-worktree/git-leakcheck/odb.c:572
>         #14 0x61970a2c69a7 in odb_read_object_info_extended /home/kristoffer/programming/git-worktree/git-leakcheck/odb.c:710
>         #15 0x61970a2c7cbe in odb_read_object /home/kristoffer/programming/git-worktree/git-leakcheck/odb.c:756
>         #16 0x61970a101d5a in repo_get_commit_buffer /home/kristoffer/programming/git-worktree/git-leakcheck/commit.c:399
>         #17 0x61970a101d5a in repo_get_commit_buffer /home/kristoffer/programming/git-worktree/git-leakcheck/commit.c:391
>         #18 0x61970a346bf6 in repo_logmsg_reencode /home/kristoffer/programming/git-worktree/git-leakcheck/pretty.c:716
>         #19 0x619709ebbe64 in commit_tree_ext builtin/history.c:127
>         #20 0x619709ebd17f in commit_tree_with_edited_message builtin/history.c:183
>         #21 0x619709ebd17f in cmd_history_reword builtin/history.c:717
>         #22 0x619709ec186f in cmd_history builtin/history.c:998
>         #23 0x619709d87ca0 in run_builtin /home/kristoffer/programming/git-worktree/git-leakcheck/git.c:506
>         #24 0x619709d87ca0 in handle_builtin /home/kristoffer/programming/git-worktree/git-leakcheck/git.c:782
>         #25 0x619709d8c9a6 in run_argv /home/kristoffer/programming/git-worktree/git-leakcheck/git.c:865
>         #26 0x619709d8c9a6 in cmd_main /home/kristoffer/programming/git-worktree/git-leakcheck/git.c:986
>         #27 0x619709d83f54 in main /home/kristoffer/programming/git-worktree/git-leakcheck/common-main.c:9
>         #28 0x712d2f229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
> 
>     SUMMARY: AddressSanitizer: 283 byte(s) leaked in 1 allocation(s).

This feels familiar, even though it doesn't reproduce on my machine. Do
you have "i18n.commitencoding" set? In any case, I think the following
patch should fix it:

diff --git a/builtin/history.c b/builtin/history.c
index 000155ad9c..bca95b9d05 100644
--- a/builtin/history.c
+++ b/builtin/history.c
@@ -158,6 +158,7 @@ static int commit_tree_ext(struct repository *repo,
 	*out = lookup_commit_or_die(&rewritten_commit_oid, "rewritten commit");
 
 out:
+	repo_unuse_commit_buffer(repo, commit_with_message, original_message);
 	free_commit_extra_headers(original_extra_headers);
 	strbuf_release(&commit_message);
 	free(original_author);

I know that we've already been discussing this memory leak on the
mailing list at one point in time, and we've already had a patch similar
to the above. So why wasn't this merged...?

Ah, the discussion was in [1]. Cc'ing Kaartic.

Thanks!

Patrick

[1]: https://lore.kernel.org/git/20260614141600.620272-1-kaartic.sivaraam@gmail.com/

Re: history: 'reword HEAD' surfaces a memory leak

[Kaartic Sivaraam]

On 9/7/26 16:43, Patrick Steinhardt wrote:
> 
> This feels familiar, even though it doesn't reproduce on my machine. Do
> you have "i18n.commitencoding" set? In any case, I think the following
> patch should fix it:
> 
> diff --git a/builtin/history.c b/builtin/history.c
> index 000155ad9c..bca95b9d05 100644
> --- a/builtin/history.c
> +++ b/builtin/history.c
> @@ -158,6 +158,7 @@ static int commit_tree_ext(struct repository *repo,
>   	*out = lookup_commit_or_die(&rewritten_commit_oid, "rewritten commit");
>   
>   out:
> +	repo_unuse_commit_buffer(repo, commit_with_message, original_message);
>   	free_commit_extra_headers(original_extra_headers);
>   	strbuf_release(&commit_message);
>   	free(original_author);
> 
> I know that we've already been discussing this memory leak on the
> mailing list at one point in time, and we've already had a patch similar
> to the above. So why wasn't this merged...?
>

My bad, I suppose. There was a suggestion by Peff that the commit 
message was misleading. Per [2], the leak only happens when we get a 
commit that isn't cached in the commit slab. I was trying to identify 
the specific case in which we get a commit that's not cached in the slab 
but eventually got busy with other work. I will get around to it soon 
and send a long pending re-roll.

[[ References ]]

[2]: 
https://lore.kernel.org/git/94b0bed5-c86a-4291-b958-52f09faebd29@gmail.com/

--
Sivaraam

Re: history: 'reword HEAD' surfaces a memory leak

[Patrick Steinhardt]

On Mon, Sep 07, 2026 at 05:16:44PM +0530, Kaartic Sivaraam wrote:
> On 9/7/26 16:43, Patrick Steinhardt wrote:
> > 
> > This feels familiar, even though it doesn't reproduce on my machine. Do
> > you have "i18n.commitencoding" set? In any case, I think the following
> > patch should fix it:
> > 
> > diff --git a/builtin/history.c b/builtin/history.c
> > index 000155ad9c..bca95b9d05 100644
> > --- a/builtin/history.c
> > +++ b/builtin/history.c
> > @@ -158,6 +158,7 @@ static int commit_tree_ext(struct repository *repo,
> >   	*out = lookup_commit_or_die(&rewritten_commit_oid, "rewritten commit");
> >   out:
> > +	repo_unuse_commit_buffer(repo, commit_with_message, original_message);
> >   	free_commit_extra_headers(original_extra_headers);
> >   	strbuf_release(&commit_message);
> >   	free(original_author);
> > 
> > I know that we've already been discussing this memory leak on the
> > mailing list at one point in time, and we've already had a patch similar
> > to the above. So why wasn't this merged...?
> > 
> 
> My bad, I suppose. There was a suggestion by Peff that the commit message
> was misleading. Per [2], the leak only happens when we get a commit that
> isn't cached in the commit slab. I was trying to identify the specific case
> in which we get a commit that's not cached in the slab but eventually got
> busy with other work. I will get around to it soon and send a long pending
> re-roll.
> 
> [[ References ]]
> 
> [2]:
> https://lore.kernel.org/git/94b0bed5-c86a-4291-b958-52f09faebd29@gmail.com/

Awesome, thanks!

Patrick

Re: history: 'reword HEAD' surfaces a memory leak

[Kristoffer Haugsbakk]

On Mon, Sep 7, 2026, at 14:12, Patrick Steinhardt wrote:
> On Mon, Sep 07, 2026 at 05:16:44PM +0530, Kaartic Sivaraam wrote:
>> On 9/7/26 16:43, Patrick Steinhardt wrote:
>> >
>> > This feels familiar, even though it doesn't reproduce on my machine. Do
>> > you have "i18n.commitencoding" set? In any case, I think the following
>> > patch should fix it:
>> >
>> >[snip]
>> >
>>
>> My bad, I suppose. There was a suggestion by Peff that the commit message
>> was misleading. Per [2], the leak only happens when we get a commit that
>> isn't cached in the commit slab. I was trying to identify the specific case
>> in which we get a commit that's not cached in the slab but eventually got
>> busy with other work. I will get around to it soon and send a long pending
>> re-roll.
>>
>> [[ References ]]
>>
>> [2]:
>> https://lore.kernel.org/git/94b0bed5-c86a-4291-b958-52f09faebd29@gmail.com/
>
> Awesome, thanks!

Thanks, everyone. It makes sense that the commit graph was the
triggering factor.