Re: Suspicious fetch-pack behaviour
- Date: Tue, 8 Jan 2019 01:34:56 -0500
- From: Jeff King <peff@xxxxxxxx>
- Subject: Re: Suspicious fetch-pack behaviour
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 18.104.22.168 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
v22.214.171.124 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?
I'd also point out that v126.96.36.199 is over 5 years old, and there have
been quite a few http-related fixes over the years. 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?