Karl Fogel <kfogel@newton.ch.collab.net> writes:
> Blair Zajac <blair@orcaware.com> writes:
> > Maybe we should add valgrind to make check if configure finds it on
> > the system so we catch these earlier than waiting for a user to
> > stumble across a bug.
>
> What's involved in a valgrind run? Does it take a really long time,
> or is it just a special environment in which the usual tests would
> run?
First off, valgrind works on Linux ELF x86 executables. I don't know
if it works on other ELF x86 platforms. It simulates an x86 processor
and interprets the x86 code, allowing it to track every read/write to
memory, for both stack and heap.
Instead of invoking
% executable arguments
one uses
% valgrind executable arguments
and the valgrind report is printed on stderr. There are valgrind
options to print memory leak summaries, or to attach gdb when an error
is detected. Invoking valgrind on a libtool wrapper script isn't
useful, so one needs to use a static build or an installed shared
build.
Runtime increases are substantial (think orders of magnitude):
% time svn st ../svn/tools/
real 0m0.140s
user 0m0.110s
sys 0m0.030s
% time valgrind svn st ../svn/tools/
real 0m5.962s
user 0m5.790s
sys 0m0.170s
Memory usage also increases dramatically.
The really tricky bit is that lots of the valgrind checks are defeated
by the standard APR pools. Things like using uninitialised memory,
using free'd memory, etc., won't be detected if the APR pools reuse
memory rather than free'ing it. Building Subversion with
APR_POOL_DEBUG makes valgrind much more useful.
I had to patch the 20020511 valgrind snapshot to make it work with
Subversion (to support pread/pwrite). I sent the patch upstream and I
think it has been incorporated, but I haven't tried any of the later
snapshots. valgrind is under active development.
Running valgrind on the ELF binary test executables is quite
straightforward, I think I've done most of them manually over the past
couple of weeks. Lots of our tests involve Python invoking the svn
client. Getting these to run with valgrind would involve getting
Python to invoke valgrind svn instead of svn, that's probably quite
simple. However they would also need to handle the valgrind output and
separate it from the svn output, that's more complex. valgrind has a
--logfile-fd option that may help, but I've never used it. Finally
the valgrind output would need to be interpreted.
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 1 14:24:39 2002