Re: Valgrind updates

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 27, 2009, 16:54 UTC
Message-ID: <alpine.DEB.1.00.0901271742430.3586@pacific.mpi-cbg.de>
In-Reply-To: <20090127131404.GA11870@sirena.org.uk>

Hi,

On Tue, 27 Jan 2009, Mark Brown wrote:

Show 12 quoted lines

> On Tue, Jan 27, 2009 at 05:26:34AM +0100, Johannes Schindelin wrote:
> 
> > 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.
> 
> I don't recall anything along those lines in zlib but it does generate 
> warnings with valgrind which require overrides - it has at least one 
> unrolled loop which roll on beyond initialised memory (but keep within 
> memory that zlib knows it has allocated).  It rolls back the results of 
> the loop before producing output, but it's possible that some unused 
> bits in the stream may be derived from the results.

That is what I suspected, but the data contradict this:

- accesses to all offsets between 0 and 50 and 52 and 58 (one _more_ than 
  indicated as valid by stream.total_count!) do not trigger any message in 
  valgrind.

- access to offset 51, which is well _within_ the boundaries, and even 
  well outside the range of a stray alignment issue, _does_ trigger a 
  valgrind message.

So either valgrind gets it wrong (which I find rather unlikely), or zlib really does not write to that offset.

Or, and I think that makes most sense so far, valgrind has not really ignored the initialization of byte number 52 in that buffer which partly depended on an uninitialized value (but does not matter, maybe due to Huffman cutoff or something similar).

Come to think of it, the word "suppression" is probably a good indicator that valgrind never claimed it would mark the zlib buffer as properly initialized.

Sorry for the noise, then, Dscho