From: Guilhem Bonnefille <guilhem.bonnefille@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Git List <git@vger.kernel.org>
Subject: Re: Suspicious fetch-pack behaviour
Date: Tue, 8 Jan 2019 08:26:42 +0100 [thread overview]
Message-ID: <CA+BUw6h5YdimR7cBV_=Mp4KqUMvJr6-njFPEpp-pjPBCcOKx6A@mail.gmail.com> (raw)
In-Reply-To: <20190108063456.GA17588@sigill.intra.peff.net>
Le mar. 8 janv. 2019 à 07:34, Jeff King <peff@peff.net> a écrit :
>
> On Thu, Jan 03, 2019 at 10:52:48AM +0100, Guilhem Bonnefille wrote:
>
> > One of my users reported a strange problem: a simple HTTPS clone did
> > not work with Git 1.8.3.1 on RedHat 7.
> > I did many tests and I was not able to understand why his clone don't
> > work while I'm able to do it on other similar host.
> >
> > Nevertheless, we did more investigations. One of them: a raw strace.
> > I discovered two strange behaviours:
> > - fetch-pack closes its standard input and standard output and then
> > tries to print the references on standard input and finaly dies.
> > - git-remote-https does not react to fetch-pack death and continue
> > polling an empty set of FD.
> >
> > [...]
> >
> > 2769 poll(NULL, 0, 1000) = 0 (Timeout)
>
> We actually don't use poll() very much in Git. And poking around the
> v1.8.3.1 source, I do not see any places where remote-https would call
> poll(), and none outside of "git help" and "git credential-cache-daemon"
> that would ever provide a timeout like "1000".
>
> I wonder if this poll is actually being run by libcurl. Is it possible
> to get a backtrace of the looping process with gdb?
Quite hard to debug as it occured on a computer provided by a
customer, far from me...
> I'd also point out that v1.8.3.1 is over 5 years old, and there have
> been quite a few http-related fixes over the years.
Yes, it is an old version, but it is the version provided with RedHat 7.
> There is a good
> chance that if this is a Git bug, it has long since been fixed. Is it
> possible to reproduce with a more modern version of Git?
>
What is surprisingly is that I was unable to reproduce with the same
version on an other computer.
During this time, my user discovered the IT team of the customer
prvide a much more recent version of Git (2.X). With this new version,
the problem was not reproduced.
Thanks for all your investigations.
--
Guilhem BONNEFILLE
-=- JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/
prev parent reply other threads:[~2019-01-08 7:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-03 9:52 Suspicious fetch-pack behaviour Guilhem Bonnefille
2019-01-07 3:37 ` brian m. carlson
2019-01-08 6:34 ` Jeff King
2019-01-08 7:26 ` Guilhem Bonnefille [this message]
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='CA+BUw6h5YdimR7cBV_=Mp4KqUMvJr6-njFPEpp-pjPBCcOKx6A@mail.gmail.com' \
--to=guilhem.bonnefille@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.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 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.