[PATCH] fix segfault in fsck-cache (2nd attempt)

From

AGAndreas Gal <gal@uci.edu>

Date

Apr 24, 2005, 05:55 UTC

Message-ID

<Pine.LNX.4.58.0504232250210.9799@sam.ics.uci.edu>

In-Reply-To

<Pine.LNX.4.58.0504232056160.2344@ppc970.osdl.org>

Here is how to trigger it:

echo blob 100 > .git/objects/00/ae4e8d3208e09f2cf7a38202a126f728cadb49

The patch below seems to work with ZLIB 1.1 and 1.2.

Signed-off-by: Andreas Gal <gal@uci.edu>

@@ -155,6 +155,8 @@
 
        inflateInit(&stream);
        ret = inflate(&stream, 0);
+       if (ret < Z_OK)
+               return NULL;
        if (sscanf(buffer, "%10s %lu", type, size) != 2)
                return NULL;
 
On Sat, 23 Apr 2005, Linus Torvalds wrote:

> 
> 
> On Sun, 24 Apr 2005, Jonas Fonseca wrote:
> >
> > It seems by far the easiest to let diff-cache take care of skipping
> > files which have not been modified. The alternative is to keep
> > diff-cache's lazy checking and make cogito's diff jump through hoops.
> > Note, although the new SHA1 signature is derived, diff-cache still
> > prints the special no-SHA1 for the modified file.
> 
> The reason I don't want this is that if the commands keep on silently
> fixing things like this up, then performance will go down the toilet.
> 
> What _should_ happen is that you do an "update-cache --refresh" before    
> doing the diff-cache. That way you do _not_ end up having to check the    
> sha1 match over and over again if you just did a "touch" on the file.
> 
> In other words, you're adding bandage for a problem that shouldn't exist,
> and you're doing it in a way which means that _if_ the problem exists,    
> you'll never fix it, but you'll just rely on your bandage all the time.
> 
> So cogito definitely does not have to jump through any hoops at all. It
> should just make sure to keep the cache up-to-date if it ever cares (ie
> do "update-cache --refresh"). 
> 
> Some commands obviously won't care.
> 
> 		Linus
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>