C++ – Should I worry about “Conditional jump or move depends on uninitialised value(s)”


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;

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!

Best Solution

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

Related Question