Re: Valgrind updates
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jan 27, 2009, 04:46 UTC
- Message-ID
- <alpine.DEB.1.00.0901270544450.14855@racer>
- In-Reply-To
- <alpine.DEB.1.00.0901270512171.14855@racer>
Hi,
On Tue, 27 Jan 2009, Johannes Schindelin wrote:
Show 43 quoted lines
> 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