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

Re: [PATCH v2] http: fix memory leak in fetch_and_setup_pack_index()

From
Jeff King <peff@peff.net>
Date
May 29, 2026, 05:36 UTC
Message-ID
<20260529053659.GC1099450@coredump.intra.peff.net>
In-Reply-To
<ahjUmMCKxREamQE-@lorenzo-VM>
On Fri, May 29, 2026 at 01:49:44AM +0200, LorenzoPegorari wrote:
Show 15 quoted lines
> Inside the function `fetch_and_setup_pack_index()`, when the pack
> obtained using `parse_pack_index()` fails to be verified by
> `verify_pack_index()`, the function returns without closing and freeing
> said pack.
> 
> Fix this by calling `close_pack_index()` to munmap the index file for
> the leaking pack (which might have been mmapped by `fetch_pack_index()`
> or `verify_pack_index()`), and then free it, when the verification
> fails.
> 
> Also, do some more cleanup by removing the useless call to the function
> `unlink()`. This is not necessary anymore since 63aca3f7f1 (dumb-http:
> store downloaded pack idx as tempfile, 2024-10-25), when
> `fetch_pack_index()` started registering its return value (in this case
> `tmp_idx`) as a tempfile to be deleted at process exit.

I think the patch as-is is OK. But when I see this kind of "also, do this..." in a commit message it is a good time to consider whether that should happen in a separate patch.

Here it does not make sense to remove the unlink() afterwards; you'd wonder why it was not present in the cleanup added by your patch.

But it _could_ be done as a preparatory patch. And the rationale for doing that on its own I think is roughly:

  1. It is mostly doing nothing, because 63aca3f7f1 registered it as a
     tempfile, so it will be cleaned up at process end anyway (whether
     we succeed in fetching it or not).
  2. It is maybe a little harmful, because we are going to unlink() it
     now, and then later the tempfile code will try to unlink() it again
     (so a simultaneous fetch could have created the same file).

For something this small, though, I am OK just lumping it together. There are diminishing returns from polishing it further.

-Peff
Previous: LorenzoPegorariNext: Jeff King
Message 6 of 13 in “http: fix memory leak in fetch_and_setup_pack_index()”
  1. http: fix memory leak in fetch_and_setup_pack_index()LorenzoPegorari, May 19, 2026
  2. Jeff KingMay 19, 2026
  3. Lorenzo PegorariMay 28, 2026
  4. Jeff KingMay 29, 2026
  5. http: fix memory leak in fetch_and_setup_pack_index()LorenzoPegorari, May 28, 2026
  6. Jeff KingMay 29, 2026
  7. Jeff KingMay 29, 2026
  8. Lorenzo PegorariJun 1, 2026
  9. Lorenzo PegorariJun 1, 2026
  10. 0/2 http: fix memory leak in fetch_and_setup_pack_index()LorenzoPegorari, Jun 1, 2026
  11. 1/2 http: cleanup function fetch_and_setup_pack_index()LorenzoPegorari, Jun 1, 2026
  12. 2/2 http: fix memory leak in fetch_and_setup_pack_index()LorenzoPegorari, Jun 1, 2026
  13. Jeff KingJun 2, 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.