Re: git hang with corrupted .pack

Junio C Hamano [off-list ref] wrote:

Alex Riesen [off-list ref] writes:

quoted

I seem to have problems with this change (on Cygwin). Sometimes
accessing an object in a pack fails in unpack_compressed_entry.
When it happens, both avail_in and avail_out of the stream are 0,
and the reported status is Z_BUF_ERROR.

...

Subject: Fix incorrect error check while reading deflated pack data

Wow.  
 

The right fix for this loop is likely to be to increment the initial
avail_out by one (we allocate one extra byte to terminate it with NUL
anyway, so there is no risk to overrun the buffer), and break out if we
see that avail_out has become zero, in order to detect that the stream
wants to produce more than what we expect.  After the loop, we have a
check that exactly tests this condition:

    if ((st != Z_STREAM_END) || stream.total_out != size) {
        free(buffer);
        return NULL;
    }

So here is a patch (without my previous botched attempts) to fix this
issue.  The first hunk reverts the corresponding hunk from b3118bd, and
the second hunk is the same fix proposed earlier. 

ACK.  This looks right to me too.  I forgot about that end-of-stream
marker on the input buffer, and my testing failed to have a stream
where the end-of-stream marker was in the next back window, so this
"fix" wasn't triggering.

*sigh*  Thanks for digging into this and fixing it while I was away.

-- 
Shawn.