Are there known false positives issues with Valgrind?

views:

720

answers:

+4 Q:

Are there known false positives issues with Valgrind?

Hello, Are there any known false positives with Valgrind?

(myself I get a 'Conditional jump or move depends on uninitialised value(s)' with the 'fmemopen' function, writing in 'c' and 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..

+6 A:

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 2009-04-28 07:29:46

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

Liran Orevi 2009-04-28 08:12:47

I have added some pointers to my answer, hopefully it helps.

Laurynas Biveinis 2009-04-28 09:15:20

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...

Dan 2009-04-28 13:16:20

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

Laurynas Biveinis 2009-04-28 13:18:01

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

Liran Orevi 2009-04-29 14:24:22

So do Valgrind version numbers track glibc version numbers?

2009-04-30 13:29:21

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

Laurynas Biveinis 2009-04-30 16:16:32

+2 A:

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 2009-04-28 23:05:07

+1 A:

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

jldugger 2009-04-30 13:17:41

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 2010-02-02 21:13:15

ansaurus

tags:

views:

answers:

Are there known false positives issues with Valgrind?

related questions