[Valgrind-users] Strange stack traces with libraries not in use

[tom f. <tf...@al...>]

I'm seeing valgrind stack traces that point to errors from libraries
which shouldn't be relevant to the given error messages.  Here's an
example:

   Conditional jump or move depends on uninitialised value(s)
      at 0x4C230A8: strlen (mc_replace_strmem.c:242)
      by 0x402702: std::char_traits<char>::length(char const*) (char_traits.h:262)
      by 0x403054: std::basic_ostream<char, std::char_traits<char> >& std::operator<< <s
  td::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*) (ostre
  am:517)
      by 0x13D65830: avtH5NimrodFileFormat::avtH5NimrodFileFormat(char const*) (avtH5Nim
  rodFileFormat.C:155)
      by 0x13D62A86: H5NimrodCommonPluginInfo::SetupDatabase(char const* const*, int, in
  t) (H5NimrodCommonPluginInfo.C:84)
      by 0x8D5EB95: avtDatabaseFactory::SetupDatabase(CommonDatabasePluginInfo*, char co
  nst* const*, int, int, int, int, bool, bool) (avtDatabaseFactory.C:528)
      by 0x8D5F8B5: avtDatabaseFactory::FileList(DatabasePluginManager*, char const* con
  st*, int, int, std::__debug::vector<std::string, std::allocator<std::string> >&, char const*, b
  ool, bool) (avtDatabaseFactory.C:341)
      by 0x4EECCCF: NetworkManager::GetDBFromCache(std::string const&, int, char const*,
   bool, bool, bool) (NetworkManager.C:634)
      by 0x4EB80A6: RPCExecutor<OpenDatabaseRPC>::Execute(OpenDatabaseRPC*) (Executors.h
  :1271)
      by 0x4EC6E7B: RPCExecutor<OpenDatabaseRPC>::Update(Subject*) (RPCExecutor.h:67)
      by 0x6A749F1: Subject::Notify() (Subject.C:188)
      by 0x6929E10: AttributeSubject::Notify() (AttributeSubject.C:99)
      by 0x6AAEE70: Xfer::Process() (Xfer.C:420)
      by 0x4EB0925: Engine::ProcessInput() (Engine.C:1210)
      by 0x4EB21DB: Engine::EventLoop() (Engine.C:1159)
      by 0x4022CD: main (main.C:312)
    Uninitialised value was created by a heap allocation
      at 0x4C2291E: malloc (vg_replace_malloc.c:207)
      by 0xF5D1196: (within /usr/lib/libGL.so.180.44)
      by 0x7FEFFB8FF: ???
    by 0x13D79F1F: (within /home/tfogal/dev/git-rc/plugins/databases/libEH5NimrodDatabase_ser.so)
    by 0x7FEFFB8FF: ???
    by 0x404BB0C: (within /usr/lib/tls/libnvidia-tls.so.180.44)
    by 0x13D70F92: H5NIMROD_read_string_attrib(int, char const*, char**) (H5utils.C:14

Note that my uninitialized value comes from a malloc that was done
inside my nvidia driver.  I don't see how that memory could have ended
up in this particular module: this code is a file format reader.  We do
end up doing a lot of dlopen/dlsym-ing; *H5Nimrod* symbols come from a
runtime-loaded shared object, IIRC.  I don't see any valgrind messages
from that code though.

I'm using 3.4.1 with a plethora of options:
  vg="--leak-check=no"
  vg="${vg} --smc-check=all"
  vg="${vg} --log-file=vg-eng%p.vg"
  vg="${vg} --track-origins=yes"
  vg="${vg} --suppressions=/home/tfogal/dev/imagevis3d/test/nvidia.supp"
  vg="${vg} --error-limit=no"
  vg="${vg} --num-callers=64"
  # eventually: `valgrind ${vg} ${myprogram} ${myopts}'

The suppression file is what you might expect, but there is a notable
entry given the stack trace above:

  {
    nvid-gl4
    Memcheck:Leak
    fun:malloc
    obj:/usr/lib/libGL.so.180.44
  }

of course, that should only matter for leak checking, which I'm not
currently doing.

Any idea what's going on, or how I might debug this further?

Thanks,

-tom