All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Brandon Williams <bmwill@google.com>,
	Stefan Beller <sbeller@google.com>,
	git@vger.kernel.org
Subject: Re: Crash on MSYS2 with GIT_WORK_TREE
Date: Wed, 8 Mar 2017 16:34:14 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1703081304130.3767@virtualbox> (raw)
In-Reply-To: <xmqqa88w4bbp.fsf@gitster.mtv.corp.google.com>

Hi Junio,

On Tue, 7 Mar 2017, Junio C Hamano wrote:

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > 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.

Indeed.

> I just looked at 4ac9006f ("real_path: have callers use real_pathdup and
> strbuf_realpath", 2016-12-12) and it seems all hunks that replaces
> xstrdup(real_path(...)) with real_pathdup(...) in the commit share the
> same issue.  

Right, I tried to convey that information in my email to which you
replied.

> The one in canonicalize_ceiling_entry() looks OK, though.

Yes, it immediately tests whether NULL was returned.

> ec9629b3 ("submodule absorbing: fix worktree/gitdir pointers
> recursively for non-moves", 2017-01-25) introduces a new use of
> real_pathdup() and the result is immediately used to call
> connect_work_tree_and_git_dir() without checking its NULL-ness, but
> the argument to new_git_dir is something that came from git_path()
> that was successfully passed to safe_create_leading_directories(),
> so this one should be OK.
> 
> 1c16df23 ("Merge branch 'bw/realpath-wo-chdir'", 2017-01-18) turns a
> few xstrdup(real_path(...)) in dir.c without thinking.  I think that
> evil merge probably should be reverted.

Rather than a heavy-handed reversal, I would really prefer to perform a
diligent audit of all real_pathdup() callers and adjust them
appropriately.

Turns out that the canonicalize_ceiling_entry() caller is *the only one*
handling NULL correctly. All other callers need to be changed.

Will send something out in a moment.

Ciao,
Johannes

  parent reply	other threads:[~2017-03-08 15:35 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
     [not found]       ` <xmqqa88w4bbp.fsf@gitster.mtv.corp.google.com>
2017-03-08 15:34         ` Johannes Schindelin [this message]
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.1703081304130.3767@virtualbox \
    --to=johannes.schindelin@gmx.de \
    --cc=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sbeller@google.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.