Do not use zlib 1.1.3 with git packs!

Do not use zlib 1.1.3 with git packs!

[Johannes Schindelin]

Hi,

I had a strange effect when trying to repack a git repository on my iBook: 
first, "git-repack -a -d" would quit without an error message when about 
57% of the objects were written (*not* when deltifying them!).

It became even stranger when I tracked it to a segmentation fault in 
adler32(), where the debugger insisted that a buffer was NULL, but the 
calling code insisted it was not.

Upgrading to zlib 1.2.3 helped. That is, after I had a complete systen 
fsck-up, since virtually every binary, including su, login and getty, are 
linked to zlib on Mac OS X. (Yeah, yeah, no Linux, I know.)

Ciao,
Dscho

P.S.: This _might_ be related to the git-repack issue that came up a few 
days ago.

Re: Do not use zlib 1.1.3 with git packs!

[Johannes Schindelin]

Hi,

On Sat, 29 Apr 2006, Johannes Schindelin wrote:

> Upgrading to zlib 1.2.3 helped.

Apparently I was too enthusiastic to have a working system again.

The problem showed again, but with a different repository.

This time, though, I have an idea what could be the culprit.

In create_delta(), there might be illegal accesses. The function adler32() 
is called for BLK_SIZE bytes (which is 16 bytes at the moment), starting 
from data, which is initially trg_buf, and is incremented until it is 
(trg_buf + trg_size).

I gather that close to the end, adler32() tries to read 15 bytes after the 
end of the allocated target buffer.

Am I wrong?

Ciao,
Dscho

Re: Do not use zlib 1.1.3 with git packs!

[Nicolas Pitre]

On Sat, 29 Apr 2006, Johannes Schindelin wrote:

> Hi,
> 
> On Sat, 29 Apr 2006, Johannes Schindelin wrote:
> 
> > Upgrading to zlib 1.2.3 helped.
> 
> Apparently I was too enthusiastic to have a working system again.
> 
> The problem showed again, but with a different repository.
> 
> This time, though, I have an idea what could be the culprit.
> 
> In create_delta(), there might be illegal accesses. The function adler32() 
> is called for BLK_SIZE bytes (which is 16 bytes at the moment), starting 
> from data, which is initially trg_buf, and is incremented until it is 
> (trg_buf + trg_size).
> 
> I gather that close to the end, adler32() tries to read 15 bytes after the 
> end of the allocated target buffer.
> 
> Am I wrong?

You're not.  My bad.

(I'm testing a version where adler32 has been replaced with rabin 
 polynomial so that issue will be gone at the same time.
 A patch should be coming in less than an hour.)


Nicolas

Re: Do not use zlib 1.1.3 with git packs!

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> On Sat, 29 Apr 2006, Johannes Schindelin wrote:
>
>> I gather that close to the end, adler32() tries to read 15 bytes after the 
>> end of the allocated target buffer.
>> 
>> Am I wrong?
>
> You're not.  My bad.

Thanks both, for catching this while still in "next".