Hi, 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. Ciao, 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
