Re: Suspicious fetch-pack behaviour

From: Jeff King <peff@peff.net>
Date: Jan 8, 2019, 06:34 UTC
Message-ID: <20190108063456.GA17588@sigill.intra.peff.net>
In-Reply-To: <CA+BUw6jXTt6QGXvdFjRDNqJcij+1hNP5xybUUuGqo3bY0=ueuA@mail.gmail.com>

On Thu, Jan 03, 2019 at 10:52:48AM +0100, Guilhem Bonnefille wrote:

Show 15 quoted lines

> 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?

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. 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?

-Peff