12

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.

John Gordon
  • 2,576
  • 3
  • 24
  • 29
  • try to narrow down problem to as few lines os code as possible and post here. – fazo Sep 21 '11 at 20:25
  • 4
    There are plenty of lapses and shortcuts in the various system libraries so that it's not unusual to see those come up in valgrind. You could try to ignore them systematically, I suppose, or just do your testing with the shared version. – Kerrek SB Sep 21 '11 at 20:34
  • I'm not seeing this on my system. @KerrekSB - is right though, it's not really something to worry about and valgrind ships with a large file that suppresses most of these. It's probably slightly mis-matched to your libc/compiler version on your system somehow. – Flexo Sep 21 '11 at 20:54

2 Answers2

18

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.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
1

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.

BЈовић
  • 62,405
  • 41
  • 173
  • 273