Re: [Valgrind-users] Spurious warnings and missing source/line number information

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

On Tue, Jul 14, 2009 at 12:27 PM, Colin Miller<col...@pi...> wrote:
> Zachary Turner wrote:
>> Hello,
>>
>> I'm somewhat a valgrind noob, so apologies if this is a RTFM question.
>>  I did search around however and did not see anything definitive about
>> this.  I ran valgrind on an app I have and it generated thousands of
>> spurious warnings. I know I can create a .supp file to suppress these,
>> but my question is how do I know which ones are spurious and which
>> ones are not?  I found one website that mentioned that there was a
>> .supp file somewhere in the valgrind code repository, but for some
>> reason I cannot access the SVN repository.  I'm using the correct SVN
>> url (svn://svn.valgrind.org/valgrind/trunk), shown on the website at
>> (http://www.valgrind.org/downloads/repository.html) but it just says
>> the server timed out or did not respond appropriately.  I've never had
>> any problem accessing other svn repositories.
>>
>> Is there a way to tell which warnings are spurious to easily disable
>> them, or is this .supp file which I can't seem to currently access the
>> correct approach?  95% of the errors I get are either "Use of
>> uninitialised value of size 4"  (usually in _int_malloc, memcpy, or
>> malloc_consolidate), and "Conditional jump or move depends on
>> uninitialized value" (in anything have to do with static variable
>> initialization / cleanup, etc).
>>
>>
> The short answer is *ALL* Valgrind reports are errors, and should be
> fixed.
> (with the possible exception of leaked reachable memory).
>
> Suppressions are there for reports inside third-party code that you
> can't fix.
>
> Valgrind comes with a set of suppressions for some standard libraries
> with are known to be buggy.
>
> Running
> valgrind -v /bin/true
> should print out the default suppressions  that valgrind is using
>
>
> The lack of line numbers means the library does not have debug
> information with it.
> For Debian, try installing
> libstdc++*-dbg  and libc6-dbg
>
>
> HTH,
> Colin S. Miller

Hi, thanks for the info about the debug libraries.  Regarding your
point about fixing all errors, I get thousands of errors that happen
during process initialization.  Just to give a couple examples:

==7373== Syscall param set_robust_list(head) points to uninitialised byte(s)
==7373==    at 0x82A8C61: __pthread_initialize_minimal (in
/usr/sbin/snip/bin/snip)
==7373==    by 0x82A8FCC: (below main) (in /usr/sbin/snip/bin/snip)
==7373==  Address 0x83FC898 is not stack'd, malloc'd or (recently) free'd

==7373== Conditional jump or move depends on uninitialised value(s)
==7373==    at 0x82EA155: __register_atfork (in /usr/sbin/snip/bin/snip)
==7373==    by 0x82EA26A: __libc_pthread_init (in /usr/sbin/snip/bin/snip)
==7373==    by 0x82A8E19: __pthread_initialize_minimal (in
/usr/sbin/snip/bin/snip)
==7373==    by 0x82A8FCC: (below main) (in /usr/sbin/snip/bin/snip)

==7373== Conditional jump or move depends on uninitialised value(s)
==7373==    at 0x82D4E22: malloc (in /usr/sbin/snip/bin/snip)
==7373==    by 0x82D4DE7: malloc (in /usr/sbin/snip/bin/snip)
==7373==    by 0x830A5DB: _dl_init_paths (in /usr/sbin/snip/bin/snip)
==7373==    by 0x82ED78B: _dl_non_dynamic_init (in /usr/sbin/snip/bin/snip)
==7373==    by 0x82EE065: __libc_init_first (in /usr/sbin/snip/bin/snip)
==7373==    by 0x82A9050: (below main) (in /usr/sbin/snip/bin/snip)

==7439== Use of uninitialised value of size 4
==7439==    at 0x82D32D6: _int_malloc (in /usr/sbin/snip/bin/snip)
==7439==    by 0x82D4E3A: malloc (in /usr/sbin/snip/bin/snip)
==7439==    by 0x82992E6: operator new(unsigned) (in /usr/snip/snip/bin/snip)
==7439==    by 0x827945A: std::string::_Rep::_S_create(unsigned,
unsigned, std::allocator<char> const&) (in /usr/sbin/snip/bin/snip)
==7439==    by 0x8279D5C:
std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned) (in
/usr/snip/snip/snip/snip)
==7439==    by 0x827A659: std::string::reserve(unsigned) (in
/usr/sbin/snip/bin/snip)
==7439==    by 0x827A77C: std::string::append(unsigned, char) (in
/usr/sbin/snip/bin/snip)
==7439==    by 0x827B80F: std::string::resize(unsigned) (in
/usr/sbin/snip/bin/snip)
==7439==    by 0x80D8153: Foo::Foo(x&, y const&) (Foo.cpp:147)
==7439==    by 0x80D4C96: Foo::foi(x&, y const&) (Foo.cpp:234)
==7439==    by 0x80D7006: Foo::foj(RsaKeyInfo&) (Foo.cpp:60)
==7439==    by 0x80CF313: Bar::Baz() (Bar.cpp:141)

The first few all have their roots in libc, and the last one, while it
does at least have my code on the callstack, is really nothing
special.  For example, Foo::Foo (Foo.cpp:147) listed above is
basically just the following:

class Foo
{
   Foo(x&, const y)
   {
      std::stringstream input_buf;
      //initialize input_buf using whatever method

      unsigned short length;
      input_buf.read((char*)&length, sizeof(length));
      length = ntohs(length);
      str_.resize(length);
   }
private:
   std::string str_;
};

So unless libstdc++ has some kind of error in it, I'm not sure what
else I can do.  Could it be that that there's some switch I can
compile my program with, or some switch I can run valgrind with to
make the results more accurate?  Or do these still look like
legitimate errors that should be fixed somehow (even if "fixed" turns
out to mean "you built your libraries incorrectly, rebuild them" )?