Re: [PATCH 0/2] fix http deadlock on giant ref negotiations
- From
Jeff King <peff@peff.net>
- Date
- May 15, 2015, 08:53 UTC
- Message-ID
- <20150515085355.GA18890@peff.net>
- In-Reply-To
- <1431679490.14042.42.camel@kaarsemaker.net>
On Fri, May 15, 2015 at 10:44:50AM +0200, Dennis Kaarsemaker wrote:
Show 12 quoted lines
> > I applied the test from your patch, but couldn't get it to fail even > > with stock git. The test above it shrunk a bit, but I was able to tweak > > yours to generate tags from 2001..100000, which I thought would have > > worked. I suspect it's something silly like the size not being quite > > big enough for the pipe buffer on my system, or something like that. > > Though I couldn't get it to fail even with 200,000 tags, so perhaps it's > > something else. > > The shrinkage in the test above it will actually work around the issue, > as there are now fewer already-fetched tags to negotiate. Either > reverting that shrinkage or executing the new test twice should do the > trick.
Ah, right, that makes sense. I was creating the right number of tags, but not with half of them already in the repo when I did the critical fetch. I got it to fail by adding and fetching another 48,000, and then adding and fetching another 50,000 on top of that.
Interestingly, with my patch the _first_ fetch fails, that otherwise succeeds with stock git. My patch sets a maximum size on the spool buffer, and we exceed it. I guess 1MB isn't enough for pathological cases. I'm hesitant to let it expand indefinitely for security reasons, but we could probably bump it to 10MB or something.
I dunno. I'm not excited about introducing new size restrictions that were not there before.
Maybe it's time to implement git-over-websockets. ;)
-Peff