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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
