git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Enzo Matsumiya <ematsumiya@suse.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v3] pager: fix crash when pager program doesn't exist
Date: Wed, 24 Nov 2021 10:55:22 -0500	[thread overview]
Message-ID: <YZ5gao4sZF3R9mD8@coredump.intra.peff.net> (raw)
In-Reply-To: <20211124145409.8779-1-ematsumiya@suse.de>

On Wed, Nov 24, 2021 at 11:54:09AM -0300, Enzo Matsumiya wrote:

> When prepare_cmd() fails for, e.g., pager process setup,
> child_process_clear() frees the memory in pager_process.args, but .argv
> was pointed to pager_process.args.v earlier in start_command(), so it's
> now a dangling pointer.
> 
> setup_pager() is then called a second time, from cmd_log_init_finish()
> in this case, and any further operations using its .argv, e.g. strvec_*,
> will use the dangling pointer and eventually crash. According to trivial
> tests, setup_pager() is not called twice if the first call is
> successful.
> 
> This patch makes sure that pager_process is properly initialized on
> setup_pager().
> 
> Add a test to catch possible regressions.

Oh, good. I just replied in the separate thread suggesting this
direction, but I see you had already sent this. :)

This patch looks good to me. Two small nits:

> diff --git a/pager.c b/pager.c
> index 52f27a6765c8..d93304527d62 100644
> --- a/pager.c
> +++ b/pager.c
> @@ -124,6 +124,8 @@ void setup_pager(void)
>  
>  	setenv("GIT_PAGER_IN_USE", "true", 1);
>  
> +	child_process_init(&pager_process);
> +

You could drop the CHILD_PROCESS_INIT initializer in the declaration of
pager_process now. I'm OK with keeping it, though, as a
belt-and-suspenders thing. If we don't run setup_pager() at all I don't
think anybody should look at it (since we won't have installed our
signal/atexit cleanup handlers), but it doesn't hurt.

> diff --git a/t/t7006-pager.sh b/t/t7006-pager.sh
> index 0e7cf75435ec..0be9bcba49a8 100755
> --- a/t/t7006-pager.sh
> +++ b/t/t7006-pager.sh
> @@ -786,4 +786,9 @@ test_expect_success TTY 'git returns SIGPIPE on propagated signals from pager' '
>  	test_path_is_file pager-used
>  '
>  
> +test_expect_success TTY 'handle attempt to run an invalid pager' '
> +	test_config pager.show invalid-pager &&
> +	test_terminal git show
> +'

Yep, this should trigger the bug. I agree with Eric that "non-existent"
is probably more descriptive, as the key thing here is that
start_command() fails immediately, rather than us piping to the broken
pager.

-Peff

      parent reply	other threads:[~2021-11-24 15:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-24 14:54 [PATCH v3] pager: fix crash when pager program doesn't exist Enzo Matsumiya
2021-11-24 15:15 ` Eric Sunshine
2021-11-24 15:55 ` Jeff King [this message]

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=YZ5gao4sZF3R9mD8@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=ematsumiya@suse.de \
    --cc=git@vger.kernel.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).