From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Schindelin Subject: Re: Valgrind updates Date: Tue, 27 Jan 2009 05:26:34 +0100 (CET) Message-ID: References: <20090120044447.GF30714@sigill.intra.peff.net> <20090120141932.GB10688@sigill.intra.peff.net> <20090120232439.GA17746@coredump.intra.peff.net> <20090121001551.GB18169@coredump.intra.peff.net> <20090121003739.GA18373@coredump.intra.peff.net> <20090121190757.GB21686@coredump.intra.peff.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Jeff King , Junio C Hamano , git@vger.kernel.org To: Linus Torvalds X-From: git-owner@vger.kernel.org Tue Jan 27 05:27:36 2009 Return-path: Envelope-to: gcvg-git-2@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1LRfXy-00053p-JO for gcvg-git-2@gmane.org; Tue, 27 Jan 2009 05:27:35 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751601AbZA0E0M (ORCPT ); Mon, 26 Jan 2009 23:26:12 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751389AbZA0E0L (ORCPT ); Mon, 26 Jan 2009 23:26:11 -0500 Received: from mail.gmx.net ([213.165.64.20]:39386 "HELO mail.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751181AbZA0E0K (ORCPT ); Mon, 26 Jan 2009 23:26:10 -0500 Received: (qmail invoked by alias); 27 Jan 2009 04:26:07 -0000 Received: from pD9EB30BF.dip0.t-ipconnect.de (EHLO noname) [217.235.48.191] by mail.gmx.net (mp045) with SMTP; 27 Jan 2009 05:26:07 +0100 X-Authenticated: #1490710 X-Provags-ID: V01U2FsdGVkX1/UgYJUioXU1Sh9GbaZxPZvq+ujmaRnc1vWwewP88 Y8I8YYH8G422BQ X-X-Sender: gene099@racer In-Reply-To: User-Agent: Alpine 1.00 (DEB 882 2007-12-20) X-Y-GMX-Trusted: 0 X-FuHaFi: 0.51 Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: 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