Valgrind errors when linked with -static — Why?

Question

I have a test driver linked to a library I wrote. The library uses autotools so it produces both an archive (.a file) and a dynamic library (.so).

When I link my driver with 'g++ -static', presumably linking to the .a, valgrind lights up complaining repeatedly 'Conditional jump or move depends on uninitialised value(s)'. The first failure occurs before main in __pthread_initialize_minimal.

When I link without -static, presumably linking with the .so, I don't get any valgrind complaints.

Does anyone know why? Does valgrind just not work with -static?

UPDATE: I can't post even a pared down version of my driver because it links to a very large library that I couldn't possible pare down, but I notice that simplest of all programs

int main()
{
  return 0;
}

gives an error when linked with -static and run from valgrind:

==15449== Use of uninitialised value of size 8
==15449==    at 0x40B0F3: exit (in /home/jdgordo/src/t)

I should have included that I'm running on 64-bit Redhat 5.5.

Answer 1

Does valgrind just not work with -static?

It does. The problem is not in Valgrind, it's in glibc, which is not Valgrind clean. The glibc developers refused to fix these problems (because the problems are of a "don't care" nature, and fixing them costs (a few) cycles).

When you link dynamically, these errors come from libc.so.6, and can be easily suppressed, which is what Valgrind does by default.

But when you link statically, these errors come from your executable (which now includes code from libc.a), and so the default Valgrind suppressions don't suppress them.

You could write new suppressions (see Valgrind --gen-suppressions=yes documentation).

Or you could install and use glibc-audit.

Answer 2

If the library causes problems in valgrind, you can only ignore those problems by writing suppression files.

One of problems I encountered is alocating something on the heap, like this :

// library
int * some = new int;

// main links the library
int main()
{
}

This example would report an error about leak.

EDIT : if you have the library's source, you can fix the error (use of uninitialized variable), and recompile it.