4

If you've used Memcheck (from Valgrind) you'll probably be familiar with this message...

Conditional jump or move depends on uninitialized value(s)

I've read about this and it simply occurs when you use an uninitialized value.

MyClass s;
s.DoStuff();

This will work because s is automatically initialized... So if this is the case, and it works, why does Memcheck tell me that it's uninitialized? Should the message be ignored?

Perhaps I misunderstood where the error was directing me. From the Valgrind manual, the actual erroneous snippet is...

int main()
{
  int x;
  printf ("x = %d\n", x);
}

However, in my code, I can't see anything like that. I have noticed however that the function at the top of the stack trace Memcheck shows me is a virtual function; could this be something to do with it?

==14446== Conditional jump or move depends on uninitialised value(s)
==14446==    at 0x414164: vimrid::glut::GlutApplication::FinishRender() (GlutApplication.cpp:120)
==14446==    by 0x422434: vimrid::demos::filterdemos::FilterDemo3::Render() (FilterDemo3.cpp:260)
==14446==    by 0x412D3D: vimrid::VimridApplication::UpdateAndRender() (VimridApplication.cpp:93)
==14446==    by 0x4144BA: vimrid::glut::GlutApplication::glutHandleDisplay() (GlutApplication.cpp:201)
==14446==    by 0x41486A: vimrid::glut::GlutApplication::glutCallbackDisplay() (GlutApplication.cpp:277)
==14446==    by 0x54D9FAA: (within /usr/lib64/libglut.so.3.8.0)
==14446==    by 0x54DDA4A: fgEnumWindows (in /usr/lib64/libglut.so.3.8.0)
==14446==    by 0x54DA4A3: glutMainLoopEvent (in /usr/lib64/libglut.so.3.8.0)
==14446==    by 0x54DAEB5: glutMainLoop (in /usr/lib64/libglut.so.3.8.0)
==14446==    by 0x413FF8: vimrid::glut::GlutApplication::Run() (GlutApplication.cpp:112)
==14446==    by 0x41249D: vimrid::Launcher::runDemo(vimrid::VimridSettings&) (Launcher.cpp:150)
==14446==    by 0x412767: vimrid::Launcher::Launch(int, char**) (Launcher.cpp:62)

Update 1:

I took a look at GlutApplication.cpp:120, and it looks like the uninitialized variable was being passed in to a function on that line. Simple!

Nick Bolton
  • 38,276
  • 70
  • 174
  • 242

6 Answers6

17

You can add the flag --track-origins=yes to valgrind and it will give you information on the sources of uninitialised data. It runs slower, but can be helpful.

Source: Valgrind User Manual

rocarvaj
  • 546
  • 4
  • 19
6

Can you post a more complete sample? It's hard to see how there would be that particular error with out some form of goto or flow changing statement.

I most commonly see this error in code like the following

MyClass s1;
...
if ( someCondition ) { 
  goto Foo:
}
MyClass s2;
Foo:
cout << s2.GetName();

This code is fundamentally incorrect. The reason why is that even though s2 has a constructor, it's not executed if someCondition is true. The goto statement will jump over the initialization and at the last line of the program s2 will be uninitialized and essentially point to garbage.

EDIT

You may also want to check out this page which gives hints on how to decipher this particular valgrind error

https://computing.llnl.gov/code/memcheck/#deciphering4

Addendum

Another common cause for this I've just found is when you pass over some integer constants to a variadic function, which are put on the stack as ints, but when the callee gets it as longs, you've got a problem on 64-bit machines.

I was almost about to give up and just consider valgrind being stupid, then I've realised that simply casting it to long fixes it.

So my upshot is: take this messages seriously.

Flavius
  • 13,566
  • 13
  • 80
  • 126
JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
  • Agreed, it is incorrect, to the extent that it is not legal C++. The compiler should chuck this out before valgrind gets its paws on it. –  Apr 19 '09 at 19:15
  • ...assuming MyClass has a user-defined constructor, of course. –  Apr 19 '09 at 19:22
  • It may be legal C++ - if MyClass is a POD type then it's legal C++ (even if it's bad form). – Michael Burr Apr 19 '09 at 19:28
  • @michael - yes, you are right it's PODness that is the issue rather than what I said about a constructor –  Apr 19 '09 at 19:33
3

If Valgrind states that a value is not initialised, then in 99.5% it is really not initialised. Normally, when compiler reports use of an uninitialised value (-Wuninitialized in GCC), you check for inline unrolls, as your uninitialised value can be declared (and not initialised) for example 10 levels of inline function "calls" (or template unrolls) higher, than actual GCC report. Valgrind does the same, but in runtime. So you should check whole path in which uninitialised value travelled from place of being declared (and not initialised), to the place where it's actually used. The path can be for example: cascade of function calls, where each function passes its arguments (and possibly uninitialised value) to next function. Valgrind will report in last function, when the value is actually used.

Generally you should not ignore what Valgrind states. Valgrind is not a simple trace program. It can be seen as a virtual machine:

Valgrind is in essence a virtual machine using just-in-time (JIT) compilation techniques, including dynamic recompilation. Nothing from the original program ever gets run directly on the host processor. Instead, Valgrind first translates the program into a temporary, simpler form called Intermediate Representation (IR), which is a processor-neutral, SSA-based form. After the conversion, a tool (see below) is free to do whatever transformations it would like on the IR, before Valgrind translates the IR back into machine code and lets the host processor run it. Even though it could use dynamic translation (that is, the host and target processors are from different architectures), it doesn't. Valgrind recompiles binary code to run on host and target (or simulated) CPUs of the same architecture. (Wikipedia)

1

In 64-bits machine. Usually, int takes 4 bytes in memory. But long will take 8 bytes in memory. So simply refer an int value as long format will cause totally incorrect result. An convert is needed in this situation.

wuxianyun
  • 11
  • 1
1

It would be very helpful if you can post more code, especially from the part where valgrind thinks the error is.

If this happens every time you instantiate the class, you probably forgot to initialize one of the members in the constructor.

And yes: You should worry about this error, those guys can really bite you.

bayer
  • 6,854
  • 24
  • 35
-1

The error does not seem to come from your code, but a library you are using.

Valgrind comes with some default error suppression, but that probably does not cover the library you are using.

The error-checking tools detect numerous problems in the base libraries, such as the GNU C library, and the X11 client libraries, which come pre-installed on your GNU/Linux system. You can't easily fix these, but you don't want to see these errors (and yes, there are many!) So Valgrind reads a list of errors to suppress at startup. A default suppression file is created by the ./configure script when the system is built.

You can create your own error suppressions that you know are irrelevant to your code.

See the similar SO question Why does Valgrind not like my usage of glutCreateWindow?

Community
  • 1
  • 1
lothar
  • 19,853
  • 5
  • 45
  • 59