So I’ve been getting some mysterious uninitialized values message from valgrind and it’s been quite the mystery as of where the bad value originated from.
Seems that valgrind shows the place where the unitialised value ends up being used, but not the origin of the uninitialised value.
==11366== Conditional jump or move depends on uninitialised value(s)
==11366== at 0x43CAE4F: __printf_fp (in /lib/tls/i686/cmov/libc-2.7.so)
==11366== by 0x43C6563: vfprintf (in /lib/tls/i686/cmov/libc-2.7.so)
==11366== by 0x43EAC03: vsnprintf (in /lib/tls/i686/cmov/libc-2.7.so)
==11366== by 0x42D475B: (within /usr/lib/libstdc++.so.6.0.9)
==11366== by 0x42E2C9B: std::ostreambuf_iterator<char, std::char_traits<char> > std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::_M_insert_float<double>(std::ostreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, char, char, double) const (in /usr/lib/libstdc++.so.6.0.9)
==11366== by 0x42E31B4: std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::do_put(std::ostreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, char, double) const (in /usr/lib/libstdc++.so.6.0.9)
==11366== by 0x42EE56F: std::ostream& std::ostream::_M_insert<double>(double) (in /usr/lib/libstdc++.so.6.0.9)
==11366== by 0x81109ED: Snake::SnakeBody::syncBodyPos() (ostream:221)
==11366== by 0x810B9F1: Snake::Snake::update() (snake.cpp:257)
==11366== by 0x81113C1: SnakeApp::updateState() (snakeapp.cpp:224)
==11366== by 0x8120351: RoenGL::updateState() (roengl.cpp:1180)
==11366== by 0x81E87D9: Roensachs::update() (rs.cpp:321)
As can be seen, it gets quite cryptic.. especially because when it’s saying by Class::MethodX, it sometimes points straight to ostream etc. Perhaps this is due to optimization?
==11366== by 0x81109ED: Snake::SnakeBody::syncBodyPos() (ostream:221)
Just like that. Is there something I’m missing? What is the best way to catch bad values without having to resort to super-long printf detective work?
Update:
I found out what was wrong, but the strange thing is, valgrind did not report it when the bad value was first used. It was used in a multiplication function:
movespeed = stat.speedfactor * speedfac * currentbendfactor.val;
Where speedfac was an unitialised float. However, at that time it was not reported and not until the value is to be printed that I get the error.. Is there a setting for valgrind to change this behavior?