Git development
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: zlib@gzip.org, valgrind-users@lists.sourceforge.net,
	Mark Brown <broonie@sirena.org.uk>, Jeff King <peff@peff.net>,
	Junio C Hamano <gitster@pobox.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: Valgrind updates
Date: Tue, 27 Jan 2009 22:52:39 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.1.00.0901272241250.14855@racer> (raw)
In-Reply-To: <alpine.LFD.2.00.0901271006060.3123@localhost.localdomain>

Hi,

[Cc'ed the valgrind-users list, maybe the valgrind Gods can see that our 
 case is pretty strange, and tell us what we do wrong.]

Note to valgrind experts: this is _not_ about the Conditional thing in 
zlib, but about an uninitialized byte _in the middle_ of the zlib output 
buffer.

 On Tue, 27 Jan 2009, Linus Torvalds wrote:

> Hmm. The zlib faq has a note about zlib doing a conditional on 
> uninitialized memory that doesn't matter, and that is what the 
> suppression should be about (to avoid a warning about "Conditional jump 
> or move depends on uninitialised value").
> 
> But that one is documented to not matter for the actual output (zlib 
> FAQ#36).
> 
> It's possible that zlib really does leave padding bytes around that 
> literally don't matter, and that don't get initialized. That really 
> would be bad, because it means that the output of git wouldn't be 
> repeatable. But I doubt this is the case - original git used to actually 
> do the SHA1 over the _compressed_ data, which was admittedly a totally 
> and utterly broken design (and we fixed it), but it did work. Maybe it 
> worked by luck, but I somehow doubt it.
> 
> Some googling did find this:
> 
> 	http://mailman.few.vu.nl/pipermail/sysprog/2008-October/000298.html
> 
> which looks very similar: an uninitialized byte in the middle of a 
> deflate() packet.
> 
> Anyway, I'm just going to Cc 'zlib@gzip.org', since this definitely is 
> _not_ the same issue as in the FAQ, and we're not the only ones seeing it.
>
> [...]
>
> Dscho wrote:
>
> > 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.
> 
> The thing to note here is that what we are passing in to "write_buffer()" 
> is _exactly_ what zlib deflated for us:
> 
>  - 'compressed' is the allocation, and is what we used to initialize 
>    'stream.next_out' with (at the top of the code sequence above)
> 
>  - 'size' is gotten from 'stream.total_out' at the end of the compression.
> 
> Oh Gods of zlib, please hear our plea for clarification..

To help ye Gods, I put together this almost minimal C program:

-- snip --
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <zlib.h>

int main(int argc, char **argv)
{
	const char hdr[] = {
		0x74, 0x72, 0x65, 0x65, 0x20, 0x31, 0x36, 0x35,
		0x00,
	};
	int hdrlen = sizeof(hdr);
	const char buf[] = {
		0x31, 0x30, 0x30, 0x36, 0x34, 0x34, 0x20, 0x66,
		0x69, 0x6c, 0x65, 0x31, 0x00, 0x10, 0x00, 0x00,
		0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		0x00, 0x31, 0x30, 0x30, 0x36, 0x34, 0x34, 0x20,
		0x66, 0x69, 0x6c, 0x65, 0x32, 0x00, 0x20, 0x00,
		0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		0x00, 0x00, 0x31, 0x30, 0x30, 0x36, 0x34, 0x34,
		0x20, 0x66, 0x69, 0x6c, 0x65, 0x33, 0x00, 0x30,
		0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		0x00, 0x00, 0x00, 0x31, 0x30, 0x30, 0x36, 0x34,
		0x34, 0x20, 0x66, 0x69, 0x6c, 0x65, 0x34, 0x00,
		0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		0x00, 0x00, 0x00, 0x00, 0x31, 0x30, 0x30, 0x36,
		0x34, 0x34, 0x20, 0x66, 0x69, 0x6c, 0x65, 0x35,
		0x00, 0x50, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
		0x00, 0x00, 0x00, 0x00, 0x00,
	};
	int len = sizeof(buf);
	z_stream stream;
	unsigned char *compressed;
	int size, ret, i;
	FILE *out;

	memset(&stream, 0, sizeof(stream));
	deflateInit(&stream, Z_BEST_SPEED);
	size = 8 + deflateBound(&stream, len+hdrlen);
	compressed = malloc(size);
	if (!compressed)
		return 1;

	stream.next_out = compressed;
	stream.avail_out = size;

	stream.next_in = (unsigned char *)hdr;
	stream.avail_in = hdrlen;
	while ((ret = deflate(&stream, 0)) == Z_OK)
		/* nothing */;
	/* deflate() returns Z_BUF_ERROR at this point */

	stream.next_in = (unsigned char *)buf;
	stream.avail_in = len;
	ret = deflate(&stream, Z_FINISH);
	if (ret != Z_STREAM_END)
		return 1;

	if (deflateEnd(&stream) != Z_OK)
		return 1;

	out = fopen("/dev/null", "w");
	fwrite(compressed + 51, 51, 1, out);
	fwrite(compressed + 51, 1, 1, stderr);
	fflush(out);
	fclose(out);

	free(compressed);
	return 0;
}
-- snap --

... which produces this output...

-- snip --
==6348== Memcheck, a memory error detector.
==6348== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==6348== Using LibVEX rev exported, a library for dynamic binary translation.
==6348== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==6348== Using valgrind-3.5.0.SVN, a dynamic binary instrumentation framework.
==6348== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==6348== For more details, rerun with: -v
==6348== 
==6348== Use of uninitialised value of size 8
==6348==    at 0x4E2FC5B: (within /usr/lib/libz.so.1.2.3.3)
==6348==    by 0x4E317B6: (within /usr/lib/libz.so.1.2.3.3)
==6348==    by 0x4E2DF9C: (within /usr/lib/libz.so.1.2.3.3)
==6348==    by 0x4E2E654: deflate (in /usr/lib/libz.so.1.2.3.3)
==6348==    by 0x400957: main (valgrind-testcase.c:60)
==6348== 
==6348== Syscall param write(buf) points to uninitialised byte(s)
==6348==    at 0x5103D50: write (in /lib/libc-2.6.1.so)
==6348==    by 0x50A9AE2: _IO_file_write (in /lib/libc-2.6.1.so)
==6348==    by 0x50A9748: (within /lib/libc-2.6.1.so)
==6348==    by 0x50A9A4B: _IO_file_xsputn (in /lib/libc-2.6.1.so)
==6348==    by 0x509FDBA: fwrite (in /lib/libc-2.6.1.so)
==6348==    by 0x4009D7: main (valgrind-testcase.c:69)
==6348==  Address 0x53da87b is 51 bytes inside a block of size 195 alloc'd
==6348==    at 0x4C222CB: malloc (in /usr/local/lib/valgrind/amd64-linux/vgpreload_memcheck.so)
==6348==    by 0x4008D7: main (valgrind-testcase.c:45)
,==6348== 
==6348== Syscall param write(buf) points to uninitialised byte(s)
==6348==    at 0x5103D50: write (in /lib/libc-2.6.1.so)
==6348==    by 0x50A9AE2: _IO_file_write (in /lib/libc-2.6.1.so)
==6348==    by 0x50A9748: (within /lib/libc-2.6.1.so)
==6348==    by 0x50A9A83: _IO_do_write (in /lib/libc-2.6.1.so)
==6348==    by 0x50AA048: _IO_file_sync (in /lib/libc-2.6.1.so)
==6348==    by 0x509EDB9: fflush (in /lib/libc-2.6.1.so)
==6348==    by 0x4009E0: main (valgrind-testcase.c:70)
==6348==  Address 0x4020000 is not stack'd, malloc'd or (recently) free'd
==6348== 
==6348== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 15 from 4)
==6348== malloc/free: in use at exit: 0 bytes in 0 blocks.
==6348== malloc/free: 7 allocs, 7 frees, 268,835 bytes allocated.
==6348== For counts of detected errors, rerun with: -v
==6348== Use --track-origins=yes to see where uninitialised values come from
==6348== All heap blocks were freed -- no leaks are possible.
-- snap --

Note that the error only occurs when fwrite()ing to stderr, not 
any other file.

This is with valgrind compiled from a git-svn mirror updated today, i.e. 
valgrind-3.5.0.SVN.


Ciao,
Dscho

  reply	other threads:[~2009-01-27 21:53 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-19  9:13 What's cooking in git.git (Jan 2009, #04; Mon, 19) Junio C Hamano
2009-01-19 11:54 ` Kjetil Barvik
2009-01-19 13:09   ` Johannes Schindelin
2009-01-19 13:08 ` Johannes Schindelin
2009-01-20  4:44   ` Jeff King
2009-01-20 13:51     ` valgrind patches, was " Johannes Schindelin
2009-01-20 14:19       ` Jeff King
2009-01-20 14:50         ` Johannes Schindelin
2009-01-20 15:04           ` [PATCH 1/2] Add valgrind support in test scripts Johannes Schindelin
2009-01-20 15:05             ` [PATCH 2/2] valgrind: ignore ldso errors Johannes Schindelin
2009-01-21  0:12             ` [PATCH 1/2] Add valgrind support in test scripts Jeff King
2009-01-21  0:41               ` Johannes Schindelin
2009-01-21  1:10               ` [PATCH 1/2 v2] " Johannes Schindelin
2009-01-21  1:11                 ` [INTERDIFF of PATCH " Johannes Schindelin
2009-01-21  8:48                 ` [PATCH " Junio C Hamano
2009-01-21 12:21                   ` Johannes Schindelin
2009-01-21 19:02                 ` Jeff King
2009-01-21 20:49                   ` Johannes Schindelin
2009-01-21 21:53                     ` Jeff King
2009-01-21 22:38                       ` Johannes Schindelin
2009-01-25 23:18                         ` [PATCH 0/3] Valgrind support Johannes Schindelin
2009-01-25 23:18                           ` [PATCH v3 1/3] Add valgrind support in test scripts Johannes Schindelin
2009-01-25 23:29                             ` Jeff King
2009-01-25 23:35                               ` Johannes Schindelin
2009-01-25 23:42                                 ` Jeff King
2009-01-25 23:19                           ` [PATCH v3 2/3] valgrind: ignore ldso and more libz errors Johannes Schindelin
2009-01-25 23:32                             ` Jeff King
2009-01-26  0:02                               ` Johannes Schindelin
2009-01-26  0:14                                 ` Jeff King
2009-01-25 23:20                           ` [PATCH 3/3] Valgrind support: check for more than just programming errors Johannes Schindelin
2009-01-25 23:42                             ` Jeff King
2009-01-26  0:43                               ` Johannes Schindelin
2009-01-21 22:31                     ` [PATCH] valgrind tests: be super-super paranoid when creating symlinks Johannes Schindelin
2009-01-20 23:24           ` valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19) Jeff King
2009-01-21  0:10             ` Johannes Schindelin
2009-01-21  0:15               ` Jeff King
2009-01-21  0:28                 ` Johannes Schindelin
2009-01-21  0:37                   ` Jeff King
2009-01-21  1:26                     ` Johannes Schindelin
2009-01-21  1:36                       ` [PATCH 2/2 v2] valgrind: ignore ldso errors Johannes Schindelin
2009-01-21 19:09                         ` Jeff King
2009-01-21 20:51                           ` Johannes Schindelin
2009-01-21 19:07                       ` valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19) Jeff King
2009-01-21 22:17                         ` Johannes Schindelin
2009-01-21 23:57                           ` Jeff King
2009-01-22  0:42                           ` Junio C Hamano
2009-01-22  0:59                             ` Jeff King
2009-01-22  5:02                               ` Johannes Schindelin
2009-01-22  5:39                                 ` Jeff King
2009-01-27  2:50                           ` Valgrind updates Johannes Schindelin
2009-01-27  3:38                             ` Linus Torvalds
2009-01-27  4:26                               ` Johannes Schindelin
2009-01-27  4:46                                 ` Johannes Schindelin
2009-01-27 13:14                                 ` Mark Brown
2009-01-27 16:54                                   ` Johannes Schindelin
2009-01-27 18:55                                     ` Linus Torvalds
2009-01-27 21:52                                       ` Johannes Schindelin [this message]
2009-01-29  1:56                                         ` Linus Torvalds
2009-01-29 14:22                                           ` Johannes Schindelin
2009-01-28 23:06                                       ` Mark Adler
2009-01-28 23:27                                         ` Johannes Schindelin
2009-01-29  0:15                                           ` Mark Adler
2009-01-29 14:14                                             ` Johannes Schindelin
2009-01-29 14:54                                               ` Johannes Schindelin
2009-01-27  4:48                               ` Jeff King
2009-01-27  9:31                                 ` Johannes Schindelin
2009-01-20  4:30 ` What's cooking in git.git (Jan 2009, #04; Mon, 19) Jeff King
2009-01-20  4:40 ` Jeff King
2009-01-20  7:04   ` Junio C Hamano
2009-01-20  7:55   ` Johannes Sixt
2009-01-20 14:18     ` Jeff King
2009-01-20  5:17 ` Boyd Stephen Smith Jr.
2009-01-20  8:57   ` Thomas Rast

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.1.00.0901272241250.14855@racer \
    --to=johannes.schindelin@gmx.de \
    --cc=broonie@sirena.org.uk \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=torvalds@linux-foundation.org \
    --cc=valgrind-users@lists.sourceforge.net \
    --cc=zlib@gzip.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox