Re: git hang with corrupted .pack

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 20, 2009, 17:13 UTC
Message-ID: <7vzl7mng35.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7viqeaovmp.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 9 quoted lines

>> We now abort the loop if inflate() returns Z_BUF_ERROR without
>> consuming the entire input buffer it was given, or has filled
>> the entire output buffer but has not yet returned Z_STREAM_END.
>> Either state is a clear indicator that this loop is not working
>> as expected, and should not continue.
>
> When the inflated contents is of size 0, avail_out would be 0 and avail_in
> would still have something because the input stream needs to have the end
> of stream marker that is more than zero byte long.

After thinking about this a bit more, I am reasonably sure that this is it. The contents does not have to be a 0-length string, but you would hit this if the pure-data portion of the deflated stream aligns at the end of your (un)pack window and it happens to require another use_pack() to move the window to read the end-of-stream signal. In that situation, the output buffer has already been filled, but you haven't read the input stream fully. Would't the new check incorrectly trigger in such a case?

>>  		st = git_inflate(&stream, Z_FINISH);
>> +		if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out))
>> +			break;

We won't see this on 64-bit platforms because we use larger (un)pack window and the condition is much less likely to be met.