On Tue, 22 Nov 2005, Fredrik Lundh wrote:
[...]
> http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Misc/README.valgrind?view=markup
The up-to-date version of that (from SVN instead of old CVS repository) is
here:
http://svn.python.org/view/python/trunk/Misc/README.valgrind?view=markup
Gustavo Sverzut Barbieri wrote:
> At least with gentoo's Python 2.4.2, I get a bunch of errors from
> invalid reads and jumps/moves that depends on unitialized values in
> PyObject_Free().
>
> Running:
>
> valgrind --leak-check=full --leak-resolution=high --show-reachable=yes
> python -c "pass" 2
On 11/20/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> Thanks I was going to look into the resizing and forgot about it.
> Running without pymalloc confirmed that there weren't more serious
> problems.
At least with gentoo's Python 2.4.2, I get a bunch of errors from
invalid reads and jumps/moves
On 11/22/05, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Purify is not so difficult to use: just run and learn to read the output ;-)
Amaury,
Thank you for running Purify.
> 1 - Memory error in test_coding, while importing bad_coding.py :
> IPR: Invalid pointer read in tok_nextc
Hello,
Purify is not so difficult to use: just run and learn to read the output ;-)
My config: Win2k using VC6sp5, and only 512Mb RAM.
I downloaded the snapshot dated 2005/11/21 05:01,
commented out #define WITH_PYMALLOC,
built in debug mode,
modified the rt.bat file to use purify,
and ran "rt -d"
On 11/21/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
> I don't think there's a shortage of Windows boxes among the python-dev
> crowd (I have plenty). Does anyone knows that kind of box you need to
> run purify these days ?
Dunno, but it would probably be fine on a reasonably new box with at
l
Neal Norwitz wrote:
> I think a bigger bang for the buck would be to buy a Windows box with
> Purify. Rational was a real pain to deal with, maybe it's better now
> that IBM bought them. Parasoft (Insure++) was even worse to deal
> with. There would be many other benefits for someone to do more
Neal Norwitz:
> I think a bigger bang for the buck would be to buy a Windows box with
> Purify. Rational was a real pain to deal with, maybe it's better now
> that IBM bought them. Parasoft (Insure++) was even worse to deal
> with.
My experience with the other Windows option, BoundsChecker,
On 11/21/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
> sounds like the PSF should buy you some more RAM.
I think I still have some allocation from the PSF. Wanna have a party. ;-)
Seriously, I don't know that more RAM would help too much. I didn't
notice much swapping, but maybe if I had run
Neal Norwitz wrote:
> The big benefit of running with pymalloc is that it only takes about
> 1.25 to 1.50 hours to run on my box. When running without pymalloc, I
> estimate it takes about 5 times longer. Plus it requires a lot of
> extra work since I need to run the tests in batches. I only ha
Neal Norwitz wrote:
> I still think the total references at the end of a test run are high,
> 342291. I don't have anything to base this number on. Some strategic
> interning should help this number go down a bit. I suppose I
> shouldn't worry much since these references don't seem to become
> a
Neal Norwitz wrote:
[...]
> To give you an example, I ran the entire regression suite through
> Valgrind after configuring --without-pymalloc. I only found 3
> additional problems in new code. There was also one problem in older
> code (Python/modsupport.c).
>
> The big benefit of running with
I would really like it if someone could run Purify (or another memory
tool) on Windows. Purify on any another (unix) platform would be
nice, but I doubt it will show much more. By using different tools,
problems not found by one tool may be found by the other. Plus there
is windows specific code
On 11/20/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Can somebody please give a quick explanation how valgrind can give
> *any* reasonable leak analysis when obmalloc is used? In the current
> implementation, obmalloc never ever calls free(3), so all pool memory
> should appear to have lea
Neal Norwitz wrote:
> There are still 2 memory leaks while running the regression tests.
> They show up when running test_fork1 and test_pty. There may be more,
> valgrind crashed on me the last run which was also before I fixed some
> of the reference leaks. It would be great if people could lo
I lied a bit in my previous status. I said that the refs used at the
end of a regression test run from a clean state (*) were down to 380k.
Well if I had remembered to remove all the .pyc's this would have
been true. Here's the numbers now:
Before AST: r39757 [362766 refs]
Before AST: svn up [3
There's still more clean up work to go, but the current AST is
hopefully much closer to the behaviour before it was checked in.
There are still a few small memory leaks.
After running the test suite, the total references were around 380k
(down from over 1,000k). I'm not sure exactly what the tot
17 matches
Mail list logo
