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/
next prev parent 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).