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

Re: [PATCH v3 07/27] bisect: fix various cases where we leak commit list items

From
Patrick Steinhardt <ps@pks.im>
Date
Nov 25, 2024, 12:38 UTC
Message-ID
<Z0RvxAkmfZhgo_LJ@pks.im>
In-Reply-To
<20241125112746.GA1069812@coredump.intra.peff.net>
On Mon, Nov 25, 2024 at 06:27:46AM -0500, Jeff King wrote:
Show 16 quoted lines
> On Wed, Nov 20, 2024 at 02:39:36PM +0100, Patrick Steinhardt wrote:
> 
> > diff --git a/bisect.c b/bisect.c
> > index 12efcff2e3c1836ab6e63d36e4d42269fbcaeaab..f6fa5c235ffb351011ed5e81771fbcdad9ca0917 100644
> > --- a/bisect.c
> > +++ b/bisect.c
> > @@ -442,9 +442,12 @@ void find_bisection(struct commit_list **commit_list, int *reaches,
> >  			best->next = NULL;
> >  		}
> >  		*reaches = weight(best);
> > +	} else {
> > +		free_commit_list(*commit_list);
> >  	}
> 
> Coverity complains about this hunk being a potential double-free, and
> I'm not sure it's wrong.

Sigh. The whole bisection code has been a bit of a nightmare to make sense of for me.

[snip]
Show 17 quoted lines
> We iterate over commit_list using "p". If the entry is UNINTERESTING, we
> free that node immediately and skip it. That's OK for a node in the
> middle of the list, since after we reverse the list by modifying the
> next pointers, nobody will refer to it anymore.
> 
> But we never updated commit_list. What if the first entry in the list is
> UNINTERESTING? We'll have freed it, but *commit_list will still point to
> it, and your free_commit_list() will be a double-free.
> 
> And for that matter, I am confused about what should be in commit_list
> after the reverse anyway. Even if we didn't free that first entry, it
> will now be the final entry in the reversed list. So wouldn't
> *commit_list always be pointing to a single node?
> 
> Should the code be freeing "list" and not "*commit_list"? Should the
> reversal be assigning "*commit_list = last" (in which case do we still
> need "list" at all)?

Mh. By now I wonder whether this code can be hit in the first place. Is there ever a case where `do_find_bisection()` returns `NULL`? Replacing the whole branch with `BUG()` doesn't make even a single test case fail.

Anyway. I'm not familiar enough with the code in question to tell, and it's clear that `*commit_list = best;` will leak `*commit_list` if it is not free'd beforehand. So I think freeing `list` is the right thing to do. Do you want to send a follow-up patch or shall I do this?

Patrick
Previous: Jeff KingNext: Jeff King
Message 10 of 33 in “Memory leak fixes (pt.10, final)”
  1. 00/27 Memory leak fixes (pt.10, final)Patrick Steinhardt, Nov 20, 2024
  2. 01/27 builtin/blame: fix leaking blame entries with `--incremental`Patrick Steinhardt, Nov 20, 2024
  3. 02/27 bisect: fix leaking good/bad terms when reading multipe timesPatrick Steinhardt, Nov 20, 2024
  4. 04/27 bisect: fix leaking `current_bad_oid`Patrick Steinhardt, Nov 20, 2024
  5. 03/27 bisect: fix leaking string in `handle_bad_merge_base()`Patrick Steinhardt, Nov 20, 2024
  6. 05/27 bisect: fix multiple leaks in `bisect_next_all()`Patrick Steinhardt, Nov 20, 2024
  7. 06/27 bisect: fix leaking commit list items in `check_merge_base()`Patrick Steinhardt, Nov 20, 2024
  8. 07/27 bisect: fix various cases where we leak commit list itemsPatrick Steinhardt, Nov 20, 2024
  9. Jeff KingNov 25, 2024
  10. Patrick SteinhardtNov 25, 2024
  11. Jeff KingNov 25, 2024
  12. Patrick SteinhardtNov 25, 2024
  13. 08/27 line-log: fix leak when rewriting commit parentsPatrick Steinhardt, Nov 20, 2024
  14. 09/27 strvec: introduce new `strvec_splice()` functionPatrick Steinhardt, Nov 20, 2024
  15. 10/27 git: refactor alias handling to use a `struct strvec`Patrick Steinhardt, Nov 20, 2024
  16. 11/27 git: refactor builtin handling to use a `struct strvec`Patrick Steinhardt, Nov 20, 2024
  17. 12/27 split-index: fix memory leak in `move_cache_to_base_index()`Patrick Steinhardt, Nov 20, 2024
  18. 13/27 builtin/sparse-checkout: fix leaking sanitized patternsPatrick Steinhardt, Nov 20, 2024
  19. 14/27 help: refactor to not use globals for reading configPatrick Steinhardt, Nov 20, 2024
  20. 15/27 help: fix leaking `struct cmdnames`Patrick Steinhardt, Nov 20, 2024
  21. 16/27 help: fix leaking return value from `help_unknown_cmd()`Patrick Steinhardt, Nov 20, 2024
  22. 17/27 builtin/help: fix leaks in `check_git_cmd()`Patrick Steinhardt, Nov 20, 2024
  23. 18/27 builtin/init-db: fix leaking directory pathsPatrick Steinhardt, Nov 20, 2024
  24. 20/27 t/helper: fix leaking commit graph in "read-graph" subcommandPatrick Steinhardt, Nov 20, 2024
  25. 19/27 builtin/branch: fix leaking sorting optionsPatrick Steinhardt, Nov 20, 2024
  26. 21/27 global: drop `UNLEAK()` annotationPatrick Steinhardt, Nov 20, 2024
  27. 22/27 git-compat-util: drop now-unused `UNLEAK()` macroPatrick Steinhardt, Nov 20, 2024
  28. 23/27 t5601: work around leak sanitizer issuePatrick Steinhardt, Nov 20, 2024
  29. 24/27 t: mark some tests as leak freePatrick Steinhardt, Nov 20, 2024
  30. 25/27 t: remove unneeded !SANITIZE_LEAK prerequisitesPatrick Steinhardt, Nov 20, 2024
  31. 26/27 test-lib: unconditionally enable leak checkingPatrick Steinhardt, Nov 20, 2024
  32. 27/27 t: remove TEST_PASSES_SANITIZE_LEAK annotationsPatrick Steinhardt, Nov 20, 2024
  33. Toon ClaesNov 21, 2024

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.