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

Re: [PATCH] Copy resolve_ref() return value for longer use

From
Junio C Hamano <gitster@pobox.com>
Date
Nov 13, 2011, 05:57 UTC
Message-ID
<7vehxcpns5.fsf@alter.siamese.dyndns.org>
In-Reply-To
<1320719428-1802-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:
Show 28 quoted lines
> resolve_ref() may return a pointer to a static buffer. Callers that
> use this value outside of a block should copy the value to avoid some
> hidden resolve_ref() call that may change the static buffer's value.
>
> The bug found by Tony Wang <wwwjfy@gmail.com> in builtin/merge.c
> demonstrates this. The first call is in cmd_merge()
>
> branch = resolve_ref("HEAD", head_sha1, 0, &flag);
>
> Then deep in lookup_commit_or_die() a few lines after, resolve_ref()
> may be called again and destroy "branch".
>
> lookup_commit_or_die
>  lookup_commit_reference
>   lookup_commit_reference_gently
>    parse_object
>     lookup_replace_object
>      do_lookup_replace_object
>       prepare_replace_object
>        for_each_replace_ref
>         do_for_each_ref
>          get_loose_refs
>           get_ref_dir
>            get_ref_dir
>             resolve_ref
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
Thanks.

The above log message with the callchain would be a perfect explanation for a patch to fix builtin/merge.c and nothing else, but among 50+ callsites of resolve_ref(), only 5 places are modified in this patch, and it is not explained in the commit log message at all how they were chosen. Were the other 40+ or so places inspected and deemed to be OK? Or is this "I just did a few of them in addition to the immediate need of fixing what was reported, and the rest are left as an exercise to the readers" patch?

Some variables that receive xstrdup()'ed result with this patch are globals whose lifetime lasts while the process is alive, and I do not think it is a huge problem that this patch does not free it, but it seems the patch does not free some other function scope variables once their use is done even when it is fairly easy to do so.

How much overhead would it incur if we return xstrdup()'ed memory from the resolve_ref() and make it the caller's responsibility to free it? Would it make the calling site too ugly?

Previous: Nguyễn Thái Ngọc DuyNext: Nguyen Thai Ngoc Duy
Message 7 of 31 in “Re: git bug(?) for commit baf18fc261ca475343fe3cb9cd2c0dded4bc1bb7”
  1. Nguyen Thai Ngoc DuyNov 7, 2011
  2. Tony WangNov 7, 2011
  3. Nguyen Thai Ngoc DuyNov 7, 2011
  4. Tony WangNov 7, 2011
  5. Nguyen Thai Ngoc DuyNov 7, 2011
  6. Copy resolve_ref() return value for longer useNguyễn Thái Ngọc Duy, Nov 8, 2011
  7. Junio C HamanoNov 13, 2011
  8. Nguyen Thai Ngoc DuyNov 13, 2011
  9. Junio C HamanoNov 13, 2011
  10. 1/2 Convert many resolve_ref() calls to read_ref*() and ref_exists()Nguyễn Thái Ngọc Duy, Nov 13, 2011
  11. 2/2 Copy resolve_ref() return value for longer useNguyễn Thái Ngọc Duy, Nov 13, 2011
  12. Junio C HamanoNov 13, 2011
  13. Nguyen Thai Ngoc DuyNov 14, 2011
  14. Junio C HamanoNov 14, 2011
  15. Jeff KingNov 14, 2011
  16. Nguyen Thai Ngoc DuyNov 15, 2011
  17. 01/10 Allow resolve_ref() caller to decide whether to receive static bufferNguyễn Thái Ngọc Duy, Nov 15, 2011
  18. 02/10 cmd_merge: convert to single exit pointNguyễn Thái Ngọc Duy, Nov 15, 2011
  19. 03/10 merge: do not point "branch" to a resolve_ref()'s static bufferNguyễn Thái Ngọc Duy, Nov 15, 2011
  20. 04/10 commit: move resolve_ref() closer to where the return value is usedNguyễn Thái Ngọc Duy, Nov 15, 2011
  21. 05/10 checkout: do not try xstrdup() on NULLNguyễn Thái Ngọc Duy, Nov 15, 2011
  22. 06/10 reflog-walk.c: request allocated buffer from resolve_ref()Nguyễn Thái Ngọc Duy, Nov 15, 2011
  23. 07/10 receive-pack: request resolve_ref() to allocate new bufferNguyễn Thái Ngọc Duy, Nov 15, 2011
  24. 08/10 notes: request resolve_ref() to allocate new bufferNguyễn Thái Ngọc Duy, Nov 15, 2011
  25. 09/10 fmt-merge-msg: request resolve_ref() to allocate new bufferNguyễn Thái Ngọc Duy, Nov 15, 2011
  26. 10/10 branch: request resolve_ref() to allocate new bufferNguyễn Thái Ngọc Duy, Nov 15, 2011
  27. Junio C HamanoNov 15, 2011
  28. Junio C HamanoNov 13, 2011
  29. Tony WangDec 10, 2011
  30. Nguyen Thai Ngoc DuyDec 10, 2011
  31. Tony WangDec 11, 2011

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.