git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 3.5/4] object-file: fix mmap() leak in odb_source_loose_read_object_stream()

From
Junio C Hamano <gitster@pobox.com>
Date
Mar 7, 2026, 05:35 UTC
Message-ID
<xmqqv7f8td6b.fsf@gitster.g>
In-Reply-To
<20260307022459.GA693632@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 22 quoted lines
> Subject: object-file: fix mmap() leak in odb_source_loose_read_object_stream()
>
> We mmap() a loose object file, storing the result in the local variable
> "mapped", which is eventually assigned into our stream struct as
> "st.mapped". If we hit an error, we jump to an error label which does:
>
>   munmap(st.mapped, st.mapsize);
>
> to clean up. But this is wrong; we don't assign st.mapped until the end
> of the function, after all of the "goto error" jumps. So this munmap()
> is never cleaning up anything (st.mapped is always NULL, because we
> initialize the struct with calloc).
>
> Instead, we should feed the local variable to munmap().
>
> This leak is due to 595296e124 (streaming: allocate stream inside the
> backend-specific logic, 2025-11-23), which introduced the local
> variable. Before that, we assigned the mmap result directly into
> st.mapped. It was probably switched there so that we do not have to
> allocate/free the struct when the map operation fails (e.g., because we
> don't have the loose object). Before that commit, the struct was passed
> in from the caller, so there was no allocation at all.
Makes sense.  Thanks for finding and fixing the issue so quickly.
Show 28 quoted lines
>
> You can see the leak in the test suite by building with:
>
>   make SANITIZE=leak NO_MMAP=1 CC=clang
>
> and running t1060. We need NO_MMAP so that the mmap() is backed by an
> actual malloc(), which allows LSan to detect it. And the leak seems not
> to be detected when compiling with gcc, probably due to some internal
> compiler decisions about how the stack memory is written.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
>  object-file.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/object-file.c b/object-file.c
> index 3094140055..ab2fb9c4eb 100644
> --- a/object-file.c
> +++ b/object-file.c
> @@ -2197,7 +2197,7 @@ int odb_source_loose_read_object_stream(struct odb_read_stream **out,
>  	return 0;
>  error:
>  	git_inflate_end(&st->z);
> -	munmap(st->mapped, st->mapsize);
> +	munmap(mapped, mapsize);
>  	free(st);
>  	return -1;
>  }
Previous: Jeff KingNext: Patrick Steinhardt
Message 15 of 25 in “memory leak when cloning a repository”
  1. Jacob KellerMar 5, 2026
  2. Jeff KingMar 5, 2026
  3. 0/4 plugging some mmap() leaksJeff King, Mar 5, 2026
  4. 1/4 check_connected(): delay opening new_packJeff King, Mar 5, 2026
  5. Jacob KellerMar 5, 2026
  6. 2/4 check_connected(): fix leak of pack-index mmapJeff King, Mar 5, 2026
  7. Jacob KellerMar 5, 2026
  8. 3/4 pack-revindex: avoid double-loading .rev filesJeff King, Mar 5, 2026
  9. 4/4 Makefile: turn on NO_MMAP when building with LSanJeff King, Mar 5, 2026
  10. Jacob KellerMar 6, 2026
  11. 5/4 meson: turn on NO_MMAP when building with LSanJeff King, Mar 6, 2026
  12. Ramsay JonesMar 6, 2026
  13. Junio C HamanoMar 7, 2026
  14. 5/4 object-file: fix mmap() leak in odb_source_loose_read_object_stream()Jeff King, Mar 7, 2026
  15. Junio C HamanoMar 7, 2026
  16. Patrick SteinhardtMar 10, 2026
  17. Ramsay JonesMar 6, 2026
  18. Jeff KingMar 6, 2026
  19. Ramsay JonesMar 6, 2026
  20. Junio C HamanoMar 6, 2026
  21. Ramsay JonesMar 6, 2026
  22. Junio C HamanoMar 6, 2026
  23. Ramsay JonesMar 6, 2026
  24. Junio C HamanoMar 7, 2026
  25. Jacob KellerMar 5, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.