|
From: Yeshurun, M. <mei...@in...> - 2005-10-17 18:43:34
|
I know of a memory checker that never ever gives you a single false
positive, and is included in all Linux distributions. Here is the
usage:
ls <program name>
Seriously now, my experience with Valgrind has been to the contrary.
Sure, its tempting to dismiss error messages as false alarms. But so
far, Valgrind was right about every error that I took the time to
investigate carefully. You can't blame Valgrind for reporting cases of
deliberate use of un-initialized values (and I've seen some of those).
There is one issue though: It looks like Valgrind reports partial loads
as errors by default. I think this shouldn't be the default behavior.
Regards,
Meir
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of Nick
Lindridge
Sent: Monday, October 17, 2005 4:22 PM
To: val...@li...
Subject: [Valgrind-users] User error? - Valgrind 3 failing terribly
compared to purify
Hi all
Looking for any hints on why valgrind may be reporting hundreds of bogus
errors in some C++/C code, compared to purify working and reporting
flawlessly on the same code on the same machine.
The code was tested with both older valgrinds and the latest valgrind 3
on
a code base with openssh, libssh2, and other code, and has been giving
not
only vast numbers of errors, but plenty of errors reports that are
deomonstrably bogus. It took a couple of hours to produce a suppressions
file that would suppress enough to be able to see any possible genuine
errors, but even then, the genuine bugs in libssh2, for example, weren't
caught as far as we could see. Only purify gave the true picture,
finding
the problems in libssh2, and only a few other UMR reports related to
openssh crypto functions that are actually ok.
I know from previous experience that valgrind can be good, so does
anyone
have any ideas why in this case it was so disastrously off base? Files
were optimised -O0 as recommended, and tested both on a 2.2 kernel and
2.95.3 (with an old valgrind), and the latest valgrind with 2.4.20-31.9
and gcc 3.2.2.
One simple failing example was:
n =3D libssh2_channel_read(ch->channel_ptr(), buf, bufsize - 1);
if (n < 0) {
//
}
where n was sometimes reported as being uninitialised on the
conditional.
This was provably incorrect, and verifed both by purify and having a
correct return result, with all code paths inside the function
initialising the return value, and with values that were themselves
always
initialised, so there was no propagation of uninitialised data. Some of
the libssh code was also rewritten to move automatics defined in
innerblocks to the outer most level, just in case overlapping autos were
in anyway a problem, but as expected, this made no difference.
Sorry if I missed something such as valgrind not working with C++
binaries, but I don't believe that there's any problem there.
Any suggestions to try are welcome!
Nick
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads,
discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|