Question

I’ve just started learning to use valgrind and the –tool=memcheck

But what I am having trouble with is actually finding the problems.

e.g.

One such problem is this.

==12561== Conditional jump or move depends on uninitialised value(s)
==12561==    at 0x425779: Server::HandleReceiveFrom(boost::system::error_code const&, unsigned long) (mUUID.h:63)
==12561==    by 0x428EC4: boost::asio::detail::reactive_socket_recvfrom_op<boost::asio::mutable_buffers_1, boost::asio::ip::basic_endpoint<boost::asio::ip::udp>, boost::_bi::bind_t<void, boost::_mfi::mf2<void, Server, boost::system::error_code const&, unsigned long>, boost::_bi::list3<boost::_bi::value<Server*>, boost::arg<1> (*)(), boost::arg<2> (*)()> > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code, unsigned long) (mem_fn_template.hpp:280)
==12561==    by 0x42E589: boost::asio::detail::task_io_service::run(boost::system::error_code&) (task_io_service_operation.hpp:35)
==12561==    by 0x42720C: Server::Run() (io_service.ipp:57)
==12561==    by 0x42FB00: main (obbs.cpp:198)

and another is this

== Use of uninitialised value of size 8
==12561==    at 0x5E56091: _itoa_word (_itoa.c:196)
==12561==    by 0x5E573D8: vfprintf (vfprintf.c:1613)
==12561==    by 0x5F0EA6F: __vsnprintf_chk (vsnprintf_chk.c:65)

I’m after some hints on how to most effectively trace these types of problems. (Conditional jumps and uninitialised values.)

EDIT

Is this anything to worry about? Seems to disappear with the option --run-libc-freeres=no.
Does that mean I have a buggy C library?

==14754== Invalid free() / delete / delete[]
==14754==    at 0x4C27D71: free (vg_replace_malloc.c:366)
==14754==    by 0x5F43A0A: free_mem (in /lib/libc-2.12.1.so)
==14754==    by 0x5F435A1: __libc_freeres (in /lib/libc-2.12.1.so)
==14754==    by 0x4A2366B: _vgnU_freeres (vg_preloaded.c:62)
==14754==    by 0x5E4A4A4: exit (exit.c:93)
==14754==    by 0x5E2FD94: (below main) (libc-start.c:258)
==14754==  Address 0x4046bb8 is not stack'd, malloc'd or (recently) free'd

Answer 1

Basically, each Valgrind error displays a stack trace. The higher portions of the stack trace might not be very useful to you, since they refer to library code. However, ultimately these problems stem from issues in your code. Start by scanning for the first part of the stack trace which refers to a line of code in your application (as opposed to a library function.) If you examine the stack trace, you’ll see that line 198 of obbs.cpp is the point in your application leading to the cause of your first problem. Further up the stack, you can see that line 63 of mUUID.h is ultimately where the uninitialized variable is evaluated, either via an if statement, or a loop.

The error “Conditional jump or move depends on uninitialised value(s)” means you have an uninitialized variable that is being used to affect the flow of your program. In your case, it looks like you’re passing an uninitialized variable to a Boost library function, and the library function is calling your handler class which evaluates the uninitialized variable in a conditional statement. This means your program is exhibiting undefined behavior.

A trivial example that would cause this problem would be something like:

int i; // uninitialized value
if (i == 10) { /* ... do something */ }

Start by checking line 198 of obbs.cpp and move up the stack trace until you realize the problem.

I’ll also add that errors like this can sometimes be caught by the compiler, if you compile with all warnings. (In GCC, for example, make sure you compile with the -Wall flag)