git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>,
	 Lauri Niskanen <ape@ape3000.com>,
	 git@vger.kernel.org,  Patrick Steinhardt <ps@pks.im>
Subject: Re: [PATCH 1/6] stash: tell setup_revisions() to free our allocated strings
Date: Mon, 22 Sep 2025 14:26:44 -0700	[thread overview]
Message-ID: <xmqqms6mrxez.fsf@gitster.g> (raw)
In-Reply-To: <20250922202509.GE2205919@coredump.intra.peff.net> (Jeff King's message of "Mon, 22 Sep 2025 16:25:09 -0400")

Jeff King <peff@peff.net> writes:

> On Mon, Sep 22, 2025 at 12:36:22PM -0700, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>> 
>> > Yeah, I had originally written just:
>> >
>> >   test_expect_success 'stash show -- does not leak' '
>> > 	git stash show --
>> >   '
>> >
>> > but it felt funny, since the test is doing nothing in a build without
>> > SANITIZE=leak. If we are OK with that funniness, I can switch back to
>> > that.
>> 
>> We have a prerequisite for that.  Very nice vehicle for
>> documentation purposes, even though we do not care about a single
>> "stash show" invocation for correctness or performance reasons.
>
> Ah, nice. It crossed my mind that we could try marking it as such, but I
> forgot (or never knew) that we already had this prereq available. I
> guess it was mainly used as "!SANITIZE_LEAK" before for suppressing
> leaks.
>
>> Perhaps I can squash the following in, unless you have other changes
>> in mind.
>
> Thanks, that looks perfect for the code change. But we probably need to
> update the discussion of the test in the commit message. Here's what I
> came up with (replacing patch 1):

Thanks, will replace then.

> -- >8 --
> Subject: [PATCH] stash: tell setup_revisions() to free our allocated strings
>
> In "git stash show", we do a first pass of parsing our command line
> options by splitting them into revision args and stash args. These are
> stored in strvecs, and we pass the revision args to setup_revisions().
>
> But setup_revisions() may modify the argv we pass it, causing us to leak
> some of the entries. In particular, if it sees a "--" string, that will
> be dropped from argv. This is the same as other cases addressed by
> f92dbdbc6a (revisions API: don't leak memory on argv elements that need
> free()-ing, 2022-08-02), and we should fix it the same way: by passing
> the free_removed_argv_elements option to setup_revisions().
>
> The added test here is run only with SANITIZE=leak, without checking its
> output, because the behavior of stash with "--" is a little odd:
>
>   1. Running "git stash show" will show --stat output. But running "git
>      stash show --" will show --patch.
>
>   2. I'd expect a non-option after "--" to be treated as a pathspec, so:
>
>        git stash show -p 1 -- foo
>
>      would look treat "1" as a stash (a synonym for stash@{1}) and
>      restrict the resulting diff to "foo". But it doesn't. We split the
>      revision/stash args without any regard to "--". So in the example
>      above both "1" and "foo" are stashes. Which is an error, but also:
>
>        git stash show -- foo
>
>      treats "foo" as a stash, not a pathspec.

All good.  I do regret that I didn't resist harder against the "1 is
the same as stash@{1}" or insisted that the parser be written more
robustly if we wanted to support such syntax, but that also is way
too late to change now.

> These are both oddities that we may want to address (or may not, if we
> want to retain historical quirks). But they are well outside the scope
> of this patch. So for now we'll just let the tests confirm we aren't
> leaking without otherwise expecting any behavior. If we later address
> either of those points and end up with another test that covers "stash
> show --", we can drop this leak-only test.

OK.  

By the way this also solves the original "git stash show -p --invalid";
do we want to credit the bug reporter and mention that issue as well?

Thanks.

> Signed-off-by: Jeff King <peff@peff.net>
> ---
>  builtin/stash.c  | 3 ++-
>  t/t3903-stash.sh | 4 ++++
>  2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/stash.c b/builtin/stash.c
> index f5ddee5c7f..e5ab3c4cf5 100644
> --- a/builtin/stash.c
> +++ b/builtin/stash.c
> @@ -957,6 +957,7 @@ static void diff_include_untracked(const struct stash_info *info, struct diff_op
>  static int show_stash(int argc, const char **argv, const char *prefix,
>  		      struct repository *repo UNUSED)
>  {
> +	struct setup_revision_opt opt = { .free_removed_argv_elements = 1 };
>  	int i;
>  	int ret = -1;
>  	struct stash_info info = STASH_INFO_INIT;
> @@ -1015,7 +1016,7 @@ static int show_stash(int argc, const char **argv, const char *prefix,
>  		}
>  	}
>  
> -	argc = setup_revisions(revision_args.nr, revision_args.v, &rev, NULL);
> +	argc = setup_revisions(revision_args.nr, revision_args.v, &rev, &opt);
>  	if (argc > 1)
>  		goto usage;
>  	if (!rev.diffopt.output_format) {
> diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
> index 0bb4648e36..daf96aa931 100755
> --- a/t/t3903-stash.sh
> +++ b/t/t3903-stash.sh
> @@ -1741,4 +1741,8 @@ test_expect_success 'submodules does not affect the branch recorded in stash mes
>  	)
>  '
>  
> +test_expect_success SANITIZE_LEAK 'stash show handles -- without leaking' '
> +	git stash show --
> +'
> +
>  test_done

  reply	other threads:[~2025-09-22 21:26 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-19 10:18 [BUG] git stash show -p with invalid option aborts with double-free in show_stash() (strvec_clear) Lauri Niskanen
2025-09-19 13:11 ` Kristoffer Haugsbakk
2025-09-19 16:00   ` Junio C Hamano
2025-09-19 16:48     ` Jeff King
2025-09-19 17:13       ` Junio C Hamano
2025-09-19 16:58     ` Junio C Hamano
2025-09-19 17:20       ` Jeff King
2025-09-19 18:15         ` Junio C Hamano
2025-09-19 19:56           ` Jeff King
2025-09-19 22:33             ` [PATCH 0/6] fixing double-frees and leaks via setup_revisions() Jeff King
2025-09-19 22:40               ` [PATCH 1/6] stash: tell setup_revisions() to free our allocated strings Jeff King
2025-09-22 15:45                 ` Junio C Hamano
2025-09-22 19:05                   ` Jeff King
2025-09-22 19:36                     ` Junio C Hamano
2025-09-22 20:25                       ` Jeff King
2025-09-22 21:26                         ` Junio C Hamano [this message]
2025-09-23  0:48                           ` Jeff King
2025-09-19 22:45               ` [PATCH 2/6] revision: manage memory ownership of argv in setup_revisions() Jeff King
2025-09-19 22:48               ` [PATCH 3/6] revision: add wrapper to setup_revisions() from a strvec Jeff King
2025-09-20  5:10                 ` Eric Sunshine
2025-09-20  5:48                   ` Jeff King
2025-09-19 22:49               ` [PATCH 4/6] treewide: use setup_revisions_from_strvec() when we have " Jeff King
2025-09-19 22:50               ` [PATCH 5/6] treewide: pass strvecs around for setup_revisions_from_strvec() Jeff King
2025-09-19 23:11                 ` Jeff King
2025-09-19 22:51               ` [PATCH 6/6] revision: retain argv NULL invariant in setup_revisions() Jeff King
2025-09-19 23:07                 ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqms6mrxez.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=ape@ape3000.com \
    --cc=git@vger.kernel.org \
    --cc=kristofferhaugsbakk@fastmail.com \
    --cc=peff@peff.net \
    --cc=ps@pks.im \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).