Re: Valgrind updates

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Tue, 27 Jan 2009, Johannes Schindelin wrote:

> On Mon, 26 Jan 2009, Linus Torvalds wrote:
> 
> > On Tue, 27 Jan 2009, Johannes Schindelin wrote:
> > > 
> > > Just that much, most of the backtraces are pretty repetitive.  In 
> > > fact, I think most if not all of them touch xwrite.c (I got other 
> > > errors from my patches, as I expected).
> > > 
> > > ==valgrind== Syscall param write(buf) points to uninitialised byte(s)
> > > ==valgrind==    at 0x5609E40: __write_nocancel (in /lib/libpthread-2.6.1.so)
> > > ==valgrind==    by 0x4D0380: xwrite (wrapper.c:129)
> > > ==valgrind==    by 0x4D046E: write_in_full (wrapper.c:159)
> > > ==valgrind==    by 0x4C0697: write_buffer (sha1_file.c:2275)
> > > ==valgrind==    by 0x4C0B1C: write_loose_object (sha1_file.c:2387)
> > 
> > Looks entirely bogus.
> 
> And it gets worse.
> 
> I suspected that zlib does something "cute" with alignments, i.e. that 
> it writes a possibly odd number of bytes, but then rounds up the buffer 
> to the next multiple of two of four bytes.
> 
> Yet, the buffer in question is 195 bytes, stream.total_count (which 
> totally agrees with size - stream.avail_out) says it is 58 bytes, and 
> valgrind says that the byte with offset 51 is uninitialized.
> 
> So it is definitely a zlib error.  And a strange one at that.  Even 
> allowing for a header, if we have 51 valid bytes in the buffer 
> (remember: the 52nd byte is reported uninitialized by valgrind), even on 
> a 64-bit machine, it should not be rounded up to 58 bytes reported by 
> zlib.  And the address of the buffer seems to be even 16-byte aligned 
> (that's probably valgrind's doing).
> 
> Just for bullocks, I let valgrind check if offset 51 is the only 
> uninitialized byte (who knows what zlib is thinking that it's doing?), 
> and here's the rub: offset 51 is indeed the _only_ one which valgrind 
> thinks is uninitialized!
> 
> Wasn't there some zlib wizard in the kernel community?  We could throw 
> that thing at him, to see why it behaves so strangely...
> 
> Of course, it could also be a valgrind issue, as you suggested.  Hmpf.

FWIW this test was done with 3.4.0.SVN.

Just to be sure, I upgraded to 3.5.0.SVN, the very newest update (well, as 
new as I could make my git svn mirror of valgrind and VEX deliver).  Still 
there.

Off to bed,
Dscho