|
From: Tom H. <to...@co...> - 2005-11-21 09:55:26
|
In message <ee2...@ma...>
Neal Norwitz <nno...@gm...> wrote:
> 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.
Unimplemented ioctls shouldn't generally cause a failure of
valgrind - they don't raise SIGILL like a missing system call
will. The worst that usually happens is that some result is not
marked as defined and you get warnings from memcheck as a result.
I'd be interested to know more about these ioctl related problems.
> 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.
That doesn't sound good either - it would be good to investigate
that a bit further.
> 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:
> http://svn.python.org/projects/python/trunk/Misc/valgrind-python.supp
You can use wildcards in the suppression call chain - the default
suppression files use * quite a lot for example.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|