All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: valtron <valtron2000@gmail.com>,
	git@vger.kernel.org, Brandon Williams <bmwill@google.com>
Subject: Re: Crash on MSYS2 with GIT_WORK_TREE
Date: Tue, 07 Mar 2017 18:36:49 -0800	[thread overview]
Message-ID: <xmqqh9344hq6.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1703080104580.3767@virtualbox> (Johannes Schindelin's message of "Wed, 8 Mar 2017 01:51:22 +0100 (CET)")

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> The problem is actually even worse: On *Linux*, this happens:
>
> 	$ GIT_WORK_TREE=c:/invalid git rev-parse HEAD
> 	Segmentation fault (core dumped)
>
> The reason is this: when set_git_work_tree() was converted from using
> xstrdup(real_path()) to real_pathdup(), we completely missed the fact that
> the former passed die_on_error = 1 to strbuf_realpath(), while the latter
> passed die_on_error = 0. As a consequence, work_tree can be NULL now, and
> the current code does not expect set_git_work_tree() to return
> successfully after setting work_tree to NULL.

Ouch.

> Brandon, I have a hunch that pretty much all of the xstrdup(real_path())
> -> real_pathdup() sites have a problem now. The previous contract was that
> real_path() would die() if the passed path is invalid. The new contract is
> that real_pathdup() returns NULL in such a case.

OK, so it appears that we'd better audit all the callsites of
real_pathdup() and see if anybody _assumes_ that the return values
are not NULL.  They all need fixing.

Thanks for digging it through to the root cause.

  parent reply	other threads:[~2017-03-08  3:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-07 21:28 Crash on MSYS2 with GIT_WORK_TREE valtron
2017-03-07 23:03 ` Johannes Schindelin
2017-03-08  0:51   ` Johannes Schindelin
2017-03-08  1:08     ` valtron
2017-03-08 12:03       ` Johannes Schindelin
2017-03-08  2:09     ` Brandon Williams
2017-03-08 11:59       ` Johannes Schindelin
2017-03-08 18:46         ` Brandon Williams
2017-03-08 22:19           ` Junio C Hamano
2017-03-08  2:36     ` Junio C Hamano [this message]
     [not found]       ` <xmqqa88w4bbp.fsf@gitster.mtv.corp.google.com>
2017-03-08 15:34         ` Johannes Schindelin
2017-03-08 17:24           ` Junio C Hamano
2017-03-08  1:05   ` Johannes Schindelin

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=xmqqh9344hq6.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=valtron2000@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.