Are there known false positives issues with Valgrind?

Question

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.

Satyr

Answer 1

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.

Every

How can I really find out if it's a false positive? – Satyr

I would say assume that all reported issues actually are issues until you have verified undoubtedly that it is. Its easy to dismiss something as a false positive or a bug in another library or whatever when the issue is, in fact, a real issue in your own code. Remember: select is probably not broken ;-) Of course, there will be cases when it really is a false positive... – Pirtle

Yes, definitely. Assume it is your bug unless you can prove otherwise :) – Every

Thanks for the --track-origins=yes , had to upgrade version to use it. – Satyr

So do Valgrind version numbers track glibc version numbers? – Volotta

Not that they track version numbers, but each valgrind release has a list of supported gcc/glibc/... versions. – Every

@Volotta it used to but glibc has been fairly stable for a long time now so there is an X version number with configure time modification. – Tejada

Answer 2

Valgrind comes with some default error suppression, but they are by no means covering all libraries.

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.

Sonja

Answer 3

Wasn't the Debian SSL thing motivated by fixing some false positives with Valgrind?

Alben

Depends on what you mean by "false positive". It was a deliberate usage of uninitialized memory in OpenSSL, as one of many sources of randomness. Valgrind was entirely correct in warning about it (even though it was harmless). – Chimaera

@BaffeBoyois: It wasn't harmless, as Debian's infamous bugs proves. If Debian memsetting the buffer to zero broke secure key generation, a compiler change in how stack memory is allocated (or a library change in malloc, if it was from the heap) could just as easily result in the memory being all-zero and breaking secure key generation. Use of uninitialized memory for any purpose, including obtaining entropy, is a serious bug. – Alburnum

@R: The Debian bug wasn't that they had too little entropy left once they stopped using uninitialized memory as a source. It was that, when they tried to stop using uninitialized memory, they patched the wrong thing and accidentaly also stopped using most of the other sources of entropy. Just removing the uninitialized memory would have been fine. – Chimaera

Answer 4

I’m answering this as a Valgrind developer.

I keep seeing comments here and on Reddit that memcheck produces false positives. 99.9% of the time that is because the developer is ignorant of the real cause and has confirmation bias and wants to believe that their code is correct.

That said, memcheck will produce some false positives

1. There are a couple of bugzilla items open for errors resulting from the compiler optimization of logical ‘and’ operations where the compiler can swap the order of the operands. If the right operand is a pointer to stack memory that is uninitialized that can cause a false positive. This seems to occur when using C++ std::optional.
2. Syscall parameter validation. If structs are used that have holes or padding that can generate errors. It’s a bit of a grey area. We can’t tell a hole from a field so it’s possible that the error is harmless. Valgrind does suppress some common cases of this. You need to know your code and decide whether to suppress or memset the memory to zero.
3. Virtualization environments. If you are using Docker or WSL they present a less than perfect representation of a real computer which can generate errors. My advice is to avoid WSL. VMware and VirtualBox are OK but still not perfect. Docker is better than WSL but less good than vbox and VMware.
4. Bugs. Valgrind is not perfect and the only constant is change (at least in Linux and FreeBSD). If you encounter a real bug please report it to https://bugs.kde.org (you will need an account). A small reproducer would be a great help. And for the brave providing a patch is always appreciated. Be patient, there are orders of magnitude more bugs than Valgrind developers.

Tejada