|
From: Nick L. <ni...@io...> - 2005-10-17 14:22:26
|
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 = 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
|