git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Git List" <git@vger.kernel.org>,
	"Александр Булаев" <aleks.bulaev@gmail.com>
Subject: Re: [PATCH] repository: pre-initialize hash algo pointer
Date: Fri, 19 Jan 2018 02:54:26 -0500	[thread overview]
Message-ID: <CAPig+cTOw5NsSmLHYcBEidDzNyiidJ0Dw1dF227KWDL9JrASvw@mail.gmail.com> (raw)
In-Reply-To: <20180119041825.727904-1-sandals@crustytoothpaste.net>

On Thu, Jan 18, 2018 at 11:18 PM, brian m. carlson
<sandals@crustytoothpaste.net> wrote:
> There are various git subcommands (among them, clone) which don't set up
> the repository (that is, they lack RUN_SETUP or RUN_SETUP_GENTLY) but
> end up needing to have information about the hash algorithm in use.
> Because the hash algorithm is part of struct repository and it's only
> initialized in repository setup, we can end up dereferencing a NULL
> pointer in some cases if we call one of these subcommands and look up
> the empty blob or empty tree values.
>
> In the future, we can add a command line option for this or read it from
> the configuration, but until we're ready to expose that functionality to
> the user, simply initialize the repository structure to use the current
> hash algorithm, SHA-1.
>
> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
> ---
> I'm still quite mystified as to why this is working on Linux and not
> macOS, but I can only guess that compilers are just very advanced and
> have somehow concluded that we would clearly never dereference a NULL
> pointer, so they picked the only non-NULL value.

Now that we know (due to Duy's excellent detective work[1]) that the
trigger is files with names differing only in case on case-insensitive
filesystems, the commit message can be updated appropriately.

> I haven't included a test because I have no way to reproduce the issue.
> This patch is the first from a series I'm working on where I do expand
> the use of the hash struct and therefore caused a segfault on clone, so
> I can imagine what's going on without having a way to prove it affects
> this particular case.
>
> If someone with access to macOS can provide a test, I'd be very
> grateful.

Done. Find the test here[2]. It fails without your fix on MacOS and
(presumably) Windows, and succeeds with the fix.

> My apologies for the error and inconvenience.

[1]: https://public-inbox.org/git/CACsJy8BTFm_0sv=roL1OKKW=1DyU3vqD50NKyHg3KQ7G+mAepQ@mail.gmail.com/
[2]: https://public-inbox.org/git/20180119074001.GA55929@flurp.local/

  reply	other threads:[~2018-01-19  7:54 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-18 20:55 git 2.16.0 segfaults on clone of specific repo Александр Булаев
2018-01-18 21:03 ` Randall S. Becker
2018-01-19  0:15 ` Eric Sunshine
2018-01-19  2:47   ` brian m. carlson
2018-01-19  3:06     ` Eric Sunshine
2018-01-19  3:39       ` Randall S. Becker
2018-01-19  3:40       ` brian m. carlson
2018-01-19  5:31         ` Duy Nguyen
2018-01-19  7:40           ` Eric Sunshine
2018-01-19  8:22             ` Duy Nguyen
2018-01-19  8:28               ` Eric Sunshine
2018-01-19 17:25             ` Todd Zullinger
2018-01-20  0:23               ` Eric Sunshine
2018-01-19 22:31             ` brian m. carlson
2018-01-20  0:15               ` Eric Sunshine
2018-01-20  0:23                 ` brian m. carlson
2018-01-20  0:27                   ` Eric Sunshine
2018-01-19  4:18       ` [PATCH] repository: pre-initialize hash algo pointer brian m. carlson
2018-01-19  7:54         ` Eric Sunshine [this message]
2018-01-19 19:24           ` Junio C Hamano
2018-01-19 21:48             ` Eric Sunshine
2018-01-19 22:25               ` Junio C Hamano
2018-01-19 23:14             ` brian m. carlson
2018-01-20  7:01             ` Junio C Hamano
2018-01-20  9:38               ` Eric Sunshine
2018-01-20 20:33         ` [PATCH] t: add clone test for files differing only in case brian m. carlson
2018-01-21  1:19           ` Eric Sunshine
2018-01-21  7:33           ` Junio C Hamano
2018-01-21  7:46             ` Eric Sunshine
2018-01-21  8:07               ` Eric Sunshine
2018-01-21 19:55                 ` brian m. carlson
2018-01-21 11:50           ` Duy Nguyen
2018-01-21 18:47             ` Eric Sunshine

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=CAPig+cTOw5NsSmLHYcBEidDzNyiidJ0Dw1dF227KWDL9JrASvw@mail.gmail.com \
    --to=sunshine@sunshineco.com \
    --cc=aleks.bulaev@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sandals@crustytoothpaste.net \
    /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).