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
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
15 matches
Mail list logo
