|
From: Neal N. <nno...@gm...> - 2005-11-21 02:48:18
|
Warning: there are no complaints, but you have to read the whole mail
(or skip to the bottom) to find the thank yous. :-)
I've been running V a lot recently (on Python) and happened to notice
the RC. I don't know if my platform is common at this point or not:
Linux janus 2.6.8-gentoo-r4 #4 SMP Thu Oct 7 17:40:27 EDT 2004 x86_64
AMD Opteron(tm) Processor 242 AuthenticAMD GNU/Linux
When running w/3.0.1 I think about 10-15 tests failed (could have been
as high as 30+ I don't really remember). Most tests failed due to
running out of memory. With the RC, only 6 tests failed. The RC is
much better than 3.0.1 and there didn't seem to be any regression
problems with the RC. The tests that failed with the RC are:
test_gdbm test_ioctl test_mmap test_posix test_subprocess test_whichdb
From the names, it's not at all surprising these failed. Mostly
unimplemented ioctls. I didn't notice any difference in behaviour
between reported leaks, invalid memory read/writes.
It seemed to take about the same total run time on my box, about 1.5
hours. I have 1 GB RAM. Near the end of the run, here's the ps:
neal 12371 76.8 61.6 2667424 631008 pts/3 R 16:51 67:58
/home/neal/local/bin/valgrind -q
--suppressions=3DMisc/valgrind-python.supp ./python
./Lib/test/regrtest.py
Some of the extra time was in children. There's one slightly annoying
problem in both 3.0.1 and the RC. 2 children from test_subprocess
hangs and I have to kill -9 them.
$ echo $VALGRIND_OPTS
--tool=3Dmemcheck --error-limit=3Dno --trace-children=3Dyes
--leak-resolution=3Dmed --leak-check=3Dyes --num-callers=3D15
On a different note, I noticed the results from the survey (in which I
participated). It's good to see the results. One word of caution
though. Even though most people are saying they want to run on Linux,
that is a self-selected group of users. It could be there are
millions of people who would run on Windows if it was available and
they knew about it. I say this even though I don't personally run a
windows box. :-)
Two things I don't think I mentioned in the survey as far as feature
requests: 1) allow specifying potential leaks separate from leaks, 2)
specify wildcards in the suppression call chain. If you want to
specify a moderate call change, there can be a lot of duplication
because of the lack of #2 if there are several paths. I was going to
point you to the Python suppression file, but it seems I just used the
short common paths, rather than making longer call chains. In case
you care, here is the suppressions file:=20
http://svn.python.org/projects/python/trunk/Misc/valgrind-python.supp
Here are some notes since python uses its own allocator on top of
malloc, so there are some extra hoops for V. I don't know that there
is much V can do to support python's usage. It's pretty easy to work
around so this isn't a complaint, just FYI.
http://svn.python.org/projects/python/trunk/Misc/README.valgrind
As promised, thank you all for a very impressive product. I've been
using V since I heard about (probably 1.0). I'm very happy with it.=20
Keep up the good work.
n
|