From: Clemens Buchacher <drizzd@aon.at>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: Jeff King <peff@peff.net>, Junio C Hamano <gitster@pobox.com>,
Sverre Rabbelier <srabbelier@gmail.com>,
Samium Gromoff <_deepfire@feelingofgreen.ru>,
git@vger.kernel.org, Tay Ray Chuan <rctay89@gmail.com>,
Mike Hommey <mh@glandium.org>
Subject: Re: Fw: git-core: SIGSEGV during {peek,ls}-remote on HTTP remotes.
Date: Mon, 2 Nov 2009 20:21:46 +0100 [thread overview]
Message-ID: <20091102192145.GA12718@localhost> (raw)
In-Reply-To: <alpine.LNX.2.00.0911011829130.14365@iabervon.org>
On Sun, Nov 01, 2009 at 07:59:45PM -0500, Daniel Barkalow wrote:
> I've been looking at it, just now, and I might try to clean stuff up. The
> problem I'm running into is that, in some cases, you have to call
> setup_git_directory_gently(), and it might determine that there is no git
> repo, but then the various environment functions don't distinguish between
> the situation where you haven't called it at all and the situation where
> you called it and determined there to be no answer. Furthermore, a lot of
> functions seem to be getting git_path(something), ignoring the fact that
> there is no repo, and acting like there is a repo that has simply not got
> the file it is looking for.
Indeed. In particular, you can cause most git commands which take a path
argument to segfault in GIT_DIR:
$ git grep -- /
Segmentation fault
$ git ls-files /
Segmentation fault
$ git show HEAD /
Segmentation fault
$ git diff HEAD /
Segmentation fault
You get the idea. It looks like at some point each of these calls
get_git_work_tree(), which returns NULL. I was trying to fix it this weekend
but got confused by the setup api (to be documented in
Documentation/technical/api-setup.txt). I don't think fixing all the callers
of get_git_work_tree() is the right thing to do. Instead, we should die() if
there is no work tree and a different function should be used to check
whether or not a work tree exists.
I will try to understand this convoluted codepath when I have gathered the
patience to do it. But while you're looking at it, maybe you can also take
this issue into consideration.
Thanks,
Clemens
next prev parent reply other threads:[~2009-11-02 19:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-31 22:07 Fw: git-core: SIGSEGV during {peek,ls}-remote on HTTP remotes Samium Gromoff
2009-11-01 4:27 ` Junio C Hamano
2009-11-01 14:46 ` Sverre Rabbelier
2009-11-01 20:16 ` Daniel Barkalow
2009-11-01 20:54 ` Sverre Rabbelier
2009-11-02 4:10 ` Junio C Hamano
2009-11-01 19:43 ` Daniel Barkalow
2009-11-01 20:15 ` Junio C Hamano
2009-11-01 21:19 ` Daniel Barkalow
2009-11-01 23:04 ` Jeff King
2009-11-02 0:59 ` Daniel Barkalow
2009-11-02 19:21 ` Clemens Buchacher [this message]
2009-11-01 8:19 ` Mike Hommey
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=20091102192145.GA12718@localhost \
--to=drizzd@aon.at \
--cc=_deepfire@feelingofgreen.ru \
--cc=barkalow@iabervon.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mh@glandium.org \
--cc=peff@peff.net \
--cc=rctay89@gmail.com \
--cc=srabbelier@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;
as well as URLs for NNTP newsgroup(s).