Thread (14 messages) flat view 14 messages, 7 authors, 2016-06-15

Re: git hang with corrupted .pack

From: Nicolas Pitre <nico@fluxnic.net>
Date: 2016-06-15 22:47:33

On Wed, 14 Oct 2009, Shawn O. Pearce wrote:
Nicolas Pitre [off-list ref] wrote:
quoted
quoted
Some types of corruption to a pack may confuse the deflate stream
which stores an object.  In Andy's reported case a 36 byte region
of the pack was overwritten, leading to what appeared to be a valid
deflate stream that was trying to produce a result larger than our
allocated output buffer could accept.
...
quoted
This is unfortunate that making a test case for this isn't exactly 
trivial.
Hmmm.  We could do something like manually create a pack file of
one non-delta blob whose pack header length is 16, but use a zlib
stream whose result body is 64.  Prior to this fix, we'd be stuck
in the infinite loop.  :-)
Ah, of course.
Its a PITA to create though, you have to hand-craft the test vector
and save it in the repository, we can't produce such a pack with
any real code we ship.
Can be done easily with dd though, see do_corrupt_object() in t5303 for 
example.


Nicolas
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help