|
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
|
|
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/
|
|
From: Tom H. <to...@co...> - 2005-11-21 11:30:41
|
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.
I've built the SVN trunk of Python now and started having a look at
these tests. So far I have:
tets_gdbm - hits unhandled system calls which I will look at
test_ioctl - this passes for me
test_mmap - this fails because it tries to mremap a file mapping
and Julian's do_mremap is only allowing Anon segments
to be remapped for some reason - Julian?
test_posix - this is hitting unhandled system calls on amd64
which I will look at - do you want fixes for those
to go in before 3.1 Julian?
test_subprocess - this passes for me
test_whichdb - hits unhandled system calls which I will look at
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-11-21 12:50:13
|
> test_mmap - this fails because it tries to mremap a file mapping > and Julian's do_mremap is only allowing Anon segments > to be remapped for some reason - Julian? Um .. idiocy on my part probably. I'll have a look at it, but not until tomorrow. > test_posix - this is hitting unhandled system calls on amd64 > which I will look at - do you want fixes for those > to go in before 3.1 Julian? Yes; presumably these are low-risk fixes. J |
|
From: Julian S. <js...@ac...> - 2005-11-21 12:50:14
|
> > 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. I've noticed some hangs at exit of OOo too. As you say it would be good to track these down. Is it possible to derive a small test case from the Python suite? J |
|
From: Tom H. <to...@co...> - 2005-11-21 14:01:54
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>> > 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.
>
> I've noticed some hangs at exit of OOo too. As you say it would be
> good to track these down. Is it possible to derive a small test
> case from the Python suite?
Well "valgrind ./python Lib/test/test_subprocess.py" in a Python
tree should do it, but it isn't failing for me.
Obviously once we know what the problem is we can try and devise
a small standalone test for it.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-11-21 14:00:00
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>> test_mmap - this fails because it tries to mremap a file mapping
>> and Julian's do_mremap is only allowing Anon segments
>> to be remapped for some reason - Julian?
>
> Um .. idiocy on my part probably. I'll have a look at it, but not
> until tomorrow.
Even more bizarre is that it is allowing AnonV segments to be
remapped and the client shouldn't be touching those... Fortunately
there is an earlier check that would have blocked them.
>> test_posix - this is hitting unhandled system calls on amd64
>> which I will look at - do you want fixes for those
>> to go in before 3.1 Julian?
>
> Yes; presumably these are low-risk fixes.
Just enabling three system calls on amd64 using the existing handlers.
I've committed that now and test_gdbm, test_posix and test_whichdb now
pass for me.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-11-23 02:23:56
|
On Monday 21 November 2005 13:59, Tom Hughes wrote:
> In message <200...@ac...>
>
> Julian Seward <js...@ac...> wrote:
> >> test_mmap - this fails because it tries to mremap a file mapping
> >> and Julian's do_mremap is only allowing Anon segments
> >> to be remapped for some reason - Julian?
> >
> > Um .. idiocy on my part probably. I'll have a look at it, but not
> > until tomorrow.
>
> Even more bizarre is that it is allowing AnonV segments to be
> remapped and the client shouldn't be touching those...
How did you infer that? I can't see it. VG_(am_relocate_nooverlap_client)
has this:
if (nsegments[iLo].kind != SkFileC && nsegments[iLo].kind != SkAnonC)
return False;
Do you know what is supposed to happen with the file offset at remap?
eg, if old_addr corresponds to offset X then what offset is new_addr at
afterwards? Is is X or (X + new_addr-old_addr) ?
J
|
|
From: Julian S. <js...@ac...> - 2005-11-23 03:40:25
|
> > Even more bizarre is that it is allowing AnonV segments to be > > remapped and the client shouldn't be touching those... > > How did you infer that? Ignore that ... I figured it out and fixed it. That Python test now passes on V. J |
|
From: Nicholas N. <nj...@cs...> - 2005-11-21 16:58:57
|
On Sun, 20 Nov 2005, Neal Norwitz wrote: > 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. :-) Yes. That's why I wrote this in the detailed notes on question 9: - This question doesn't tell us as much as it might seem. For example, if Valgrind were available for Windows I'm sure that would account for most usage, but because most Linux developers don't do much development on Windows, Windows doesn't get mentioned very much. For this reason I think our main target platform of PPC32/MacOS X is still a good one; I think that will expose Valgrind to a large group of new users. Thanks for the testing results, it's good when people report this sort of thing. Often the fixes are easy, as in this case (at least for some of them), but we can't fix problems if we don't know about them :) Nick |
|
From: Nicholas N. <nj...@cs...> - 2005-11-21 16:59:54
|
On Mon, 21 Nov 2005, Tom Hughes wrote:
> You can use wildcards in the suppression call chain - the default
> suppression files use * quite a lot for example.
Perhaps Neal meant wildcards not in individual call stack elements, but in
the chain itself, eg:
foo
bar
... // match multiple entries
baz
Nick
|
|
From: Ashley P. <as...@qu...> - 2005-11-23 11:28:04
|
On Mon, 2005-11-21 at 10:59 -0600, Nicholas Nethercote wrote: > On Mon, 21 Nov 2005, Tom Hughes wrote: > > > You can use wildcards in the suppression call chain - the default > > suppression files use * quite a lot for example. > > Perhaps Neal meant wildcards not in individual call stack elements, but in > the chain itself, eg: > > foo > bar > ... // match multiple entries > baz That would be a very useful improvement. Most of my suppressions have to be repeated three or four times which could be avoided with this. Often the wildcard needs to be at the bottom of the stack (top when you look at it this way round). Ashley, |