20

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.

Keith Pinson
  • 7,835
  • 7
  • 61
  • 104
Liran Orevi
  • 4,755
  • 7
  • 47
  • 64

3 Answers3

20

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.

Laurynas Biveinis
  • 10,547
  • 4
  • 53
  • 66
  • 1
    How can I really find out if it's a false positive? – Liran Orevi Apr 28 '09 at 08:12
  • 1
    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... –  Apr 28 '09 at 13:16
  • Yes, definitely. Assume it is your bug unless you can prove otherwise :) – Laurynas Biveinis Apr 28 '09 at 13:18
  • Thanks for the --track-origins=yes , had to upgrade version to use it. – Liran Orevi Apr 29 '09 at 14:24
  • So do Valgrind version numbers track glibc version numbers? – chrism1 Apr 30 '09 at 13:29
  • Not that they track version numbers, but each valgrind release has a list of supported gcc/glibc/... versions. – Laurynas Biveinis Apr 30 '09 at 16:16
3

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.

lothar
  • 19,853
  • 5
  • 45
  • 59
1

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

jldugger
  • 2,339
  • 6
  • 22
  • 24
  • 2
    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). – Baffe Boyois Feb 02 '10 at 21:13
  • 5
    @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. – R.. GitHub STOP HELPING ICE Apr 16 '12 at 10:52
  • 2
    @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. – Baffe Boyois Apr 16 '12 at 13:02