Git development
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Brandon Williams <bmwill@google.com>
Cc: valtron <valtron2000@gmail.com>, git@vger.kernel.org
Subject: Re: Crash on MSYS2 with GIT_WORK_TREE
Date: Wed, 8 Mar 2017 12:59:00 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1703081254480.3767@virtualbox> (raw)
In-Reply-To: <20170308020918.GA1650@google.com>

Hi Brandon,

On Tue, 7 Mar 2017, Brandon Williams wrote:

> On 03/08, Johannes Schindelin wrote:
> > 
> > [...] 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.
> > 
> > I Cc:ed Brandon, the author of 4ac9006f832 (real_path: have callers
> > use real_pathdup and strbuf_realpath, 2016-12-12).
> > 
> > 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. I believe that the following call sites are problematic
> > in particular:
> 
> Welp, looks like I missed that when I made the conversion.  You're
> right, the semantics of getting the real_path were changed which would
> cause a NULL to be returned instead of the program exiting with a call
> to die().  
> 
> After a cursory look at your patch, I think all of your changes look
> sane.  I would have to take a closer look at the call sites to see if
> each caller would need to die or not.  I'm assuming you took a quick
> glace to make your decision about each call site?

I did take a quick glance, but did you have a look at the time of day I
sent this patch? You do not want to trust my judgement after that.

Another thing: may I ask you to delete the quoted parts of the mail that
you are actually not responding to? Junio also often simply keeps the rest
of the mail quoted, and I always have to scroll all the way to the end
just to verify that nothing more has been said, which can be slightly
annoying when you are tired. I do plan to read your mails in the future,
so culling the quoted-yet-unanswered part would save me trouble.

Thanks,
Dscho

  reply	other threads:[~2017-03-08 12:08 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 [this message]
2017-03-08 18:46         ` Brandon Williams
2017-03-08 22:19           ` Junio C Hamano
2017-03-08  2:36     ` Junio C Hamano
     [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=alpine.DEB.2.20.1703081254480.3767@virtualbox \
    --to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox