|
From: Johannes S. <Joh...@gm...> - 2009-01-29 15:04:40
|
Hi, On Wed, 28 Jan 2009, Julian Seward wrote: > > > 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. > > I understand. But -- whilst we're on the subject of the Conditional thing: > I thought I'd suppressed all those zlib FAQ#36 complaints, but apparently > not. Could you try the following and see if it helps? > > Index: xfree-4.supp > =================================================================== > --- xfree-4.supp (revision 9082) > +++ xfree-4.supp (working copy) > @@ -315,6 +315,7 @@ > zlib-1.2.x trickyness (1a): See http://www.zlib.net/zlib_faq.html#faq36 > Memcheck:Cond > obj:/*lib*/libz.so.1.2.* > + ... > obj:/*lib*/libz.so.1.2.* > fun:deflate > } > @@ -329,6 +330,7 @@ > zlib-1.2.x trickyness (2a): See http://www.zlib.net/zlib_faq.html#faq36 > Memcheck:Value8 > obj:/*lib*/libz.so.1.2.* > + ... > obj:/*lib*/libz.so.1.2.* > fun:deflate > } > @@ -343,6 +345,7 @@ > zlib-1.2.x trickyness (3a): See http://www.zlib.net/zlib_faq.html#faq36 > Memcheck:Value4 > obj:/*lib*/libz.so.1.2.* > + ... > obj:/*lib*/libz.so.1.2.* > fun:deflate > } I had something similar in the suppressions file already. > Now to your real question. I believe this is either a bug in Valgrind > or some strangeness with libc. I don't think it has anything to do with > zlib. Actually, after much more painful research, it turns out that I cannot investigate the issue further. Your hint with VALGRIND_CHECK_MEM_IS_DEFINED() showed indeed that valgrind thinks that the single byte at offset 51 (in a buffer of 58) is undefined. So I wanted to use the same macro/function in the source of zlib to find out where the responsible code is. But the issue disappeared then. No matter if I link to zlib-1.2.3, 1.2.3.3.dfsg-5ubuntu1 (the version that is installed on the system I had the issue with) or the dynamic library thereof, the error was no longer reproducible. This is very frustrating, but at least I have a system now where the valgrind tests pass. > Program as modified w/ patch runs Memcheck-clean for me. For me, it did not. > That said, I don't have any concrete offerings as to what the problem > really is, or even whether there is a problem. I do know that zlib's > handwritten assembly inner loops tend to cause Memcheck's definedness > tracking to have problems. If you want to chase this further, I suggest > you build zlib from source, with -g -O0, and make sure you use the > generic C versions of deflate et al. Then you might be in with a > fighting chance of getting to the bottom of this. > > Please lmk what the outcome is, so I know if it's a bug in Memcheck. I could still imagine that there is some obscure insn that is not caught properly, but without a reproducible testcase that I can compile myself... > A final comment - you should make friends with --track-origins=yes. It > doesn't help much here, but in general it makes finding the sources of > uninitialised values a whole lot easier. Thank you! That is indeed very helpful. Sorry to pass my frustration to you... Will keep an eye open, maybe I'll find the time to do more fine-grained research into the assembler-level code. Thanks, Dscho |