Re: fatal: serious inflate inconsistency

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jun 8, 2007, 18:52 UTC
Message-ID: <alpine.LFD.0.98.0706081136480.4205@woody.linux-foundation.org>
In-Reply-To: <20070608182412.GQ2335@cip.informatik.uni-erlangen.de>

On Fri, 8 Jun 2007, Thomas Glanzmann wrote:

>
>         fatal: serious inflate inconsistency: -3 (invalid distance too far back)

Whee. That's Z_DATA_ERROR, and yeah, I think the only thing that causes it is a corrupt zlib input stream.

> I talked to Michael and he is certain that the machine has a memory
> corruption the next thing I am going to do is compiling a kernel in an
> endless loop. Again if somone needs shell access just send me your ssh
> key.

I'd not expect memory corruption to be that *repeatable*. But the message certainly implies zlib data stream corruption _somewhere_, although the fact that it seems to be so repeatable does make me suspect program error.

Of course, it could be a hard bit-error in memory, but even then it would kind of have to hit the same page allocation history each time to be repeatable. And the page cache is the only thing that is that sticky under Linux, so it would have to be something like the zlib static data or code that had hit the memory corruption.

Sounds strange. I wonder if we might have finally hit a case of different versions of zlib acting differently?

But it _could_ just be a git bug too.

I don't think it's on the kernel.org side (or we would have had more reports of this), but maybe there is some wild pointer thing inside git, and nobody else noticed because it depends on some specific memory allocation pattern (which in turn depends on things like kernel memory layout choices, and on libc 'malloc()' implementation etc).

I'll build with ElectricFence, and see if it says anything for me. It passes all the tests, but fetching the kernel is almost certainly going to do things that we don't test for..

			Linus