Menu
Are there any known false positives with Valgrind? I get a 'Conditional jump or move depends on uninitialised value(s)' with the fmemopen function, writing in C and compiling with GCC. Can I be sure it's real?
EDIT: Are there known issues that are not in the suppression files? Are there some things one can do in a program, that are not really errors but Valgrind will say they are? If there are known issues, a list would be nice.
481
Valgrind reports two types of issues: memory errors and memory leaks. When a program dynamically allocates memory and forgets to later free it, it creates a leak. A memory leak generally won't cause a program to misbehave, crash, or give wrong answers, and is not an urgent situation.
Look for function names and line numbersIf you compile your program with the -g flag, Valgrind will show you the function names and line numbers where errors occur.
To run Valgrind, pass the executable as an argument (along with any parameters to the program). The flags are, in short: --leak-check=full : "each individual leak will be shown in detail" --show-leak-kinds=all : Show all of "definite, indirect, possible, reachable" leak kinds in the "full" report.
"indirectly lost" means your program is leaking memory in a pointer-based structure. (E.g. if the root node of a binary tree is "definitely lost", all the children will be "indirectly lost".) If you fix the "definitely lost" leaks, the "indirectly lost" leaks should go away.
Yes, there are false positives with Valgrind, that's why it has suppression files for particular glibc and gcc versions, for example. The false positives may arise if you are using older valgrind with newer gcc and glibc, i.e., valgrind 3.3 with glibc 2.9.
Having said that, you still have to look into issue and find out if it is really a false positive (if that turns out to be the case, you can write a suppression for it yourself) or is it a real bug in your program.
There is no quick and easy way to say what is going on here, but in this case I'd suspect that you are passing uninitialized value from your code to library code. Try Valgrind option --track-origins=yes. It will show where the uninitialized value came from. If it is your code, probably you should initialize it. If it's inside library, it could be the false positive or, still, bad values of library call arguments might be causing it, so check those.
148
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
