Eric Firing wrote:
Attached are runs with gtk, wx, qtagg, and tkagg. Quite a variety of
results: tkagg is best, with only slow memory growth and a constant
number of python objects; qtagg grows by 2.2k per loop, with no
increase in python object count; wx (which is built on gtk) consumes
Yes -- the global wxapp variable was removed (a very good thing). I
just committed a patch to fix this crash (r3460)
Cheers,
Mike
Christopher Barker wrote:
Eric Firing wrote:
I just updated from svn and tried to rerun the wx test, but ran into an
error:
[EMAIL
Eric Firing wrote:
I just updated from svn and tried to rerun the wx test, but ran into an
error:
[EMAIL PROTECTED]:~/programs/py/mpl/tests$ python
wxapp.Yield()
NameError: global name 'wxapp' is not defined
I think I just saw a note that Ken had committed a patch that a user had
Mike,
New exception:
[EMAIL PROTECTED]:~/programs/py/mpl/tests$ python
../matplotlib_units/unit/memleak_gui.py -dwx -s1000 -e2000
~/temp/memleak_wx_0705.asc
Traceback (most recent call last):
File ../matplotlib_units/unit/memleak_gui.py, line 58, in module
pylab.close(fig)
File
Interesting. I don't get that, but I do get some random segfaults (I
got lucky the first time I tested).
I'm awfully surprised that wx.GetApp() would return an iterator, as you
are getting, so maybe it's corruption of some sort?
Reverting to revision 3441 on backend_wx.py does resolve this
Michael Droettboom wrote:
Interesting. I don't get that, but I do get some random segfaults (I
got lucky the first time I tested).
I'm awfully surprised that wx.GetApp() would return an iterator, as you
are getting, so maybe it's corruption of some sort?
Reverting to revision 3441 on
Interesting...
When you get a chance, would you mind running the attached script? This
is how I was finding object leaks before. It takes a single commandline
argument that is the number of iterations. Can you send me the outputs
from 1 and 2 iterations? That way we should be able to see
Michael Droettboom wrote:
Interesting...
When you get a chance, would you mind running the attached script? This
is how I was finding object leaks before. It takes a single commandline
argument that is the number of iterations. Can you send me the outputs
from 1 and 2 iterations?
Michael Droettboom wrote:
Interesting...
When you get a chance, would you mind running the attached script? This
is how I was finding object leaks before. It takes a single commandline
argument that is the number of iterations. Can you send me the outputs
from 1 and 2 iterations?
On Jul 5, 2007, at 2:13 PM, Michael Droettboom wrote:
Interesting. I don't get that, but I do get some random segfaults (I
got lucky the first time I tested).
It looks like wxPython doesn't retain a reference to the wxApp PyObj
for you:
[EMAIL PROTECTED]:~/Projects/matplotlib-svn$
Yep. Nothing obvious. I'll have to have a look on Ubuntu and see if
that makes a difference.
Cheers,
Mike
Eric Firing wrote:
Michael Droettboom wrote:
Interesting...
When you get a chance, would you mind running the attached script?
This is how I was finding object leaks before. It
That is at least something to go by. ;)
Thanks,
Mike
Eric Firing wrote:
Michael Droettboom wrote:
Interesting...
When you get a chance, would you mind running the attached script?
This is how I was finding object leaks before. It takes a single
commandline argument that is the number
Ken McIvor wrote:
On Jul 5, 2007, at 2:13 PM, Michael Droettboom wrote:
Interesting. I don't get that, but I do get some random segfaults (I
got lucky the first time I tested).
It looks like wxPython doesn't retain a reference to the wxApp PyObj for
you:
[EMAIL
On Jul 5, 2007, at 3:48 PM, Eric Firing wrote:
This qualifies as a wx bug, doesn't it?
I believe so. I'll file it.
If wx doesn't retain the reference, then instead of a segfault
shouldn't it raise an exception?
I'd expect wx.GetApp() to work like the rest of wxPython and always
return
Ken McIvor wrote:
This qualifies as a wx bug, doesn't it?
I believe so. I'll file it.
I agree - a segfault is ALWAYS a bug.
If wx doesn't retain the reference, then instead of a segfault
shouldn't it raise an exception?
I'd expect wx.GetApp() to work like the rest of wxPython and
Eric Firing wrote:
I also made memleak_gui.py more flexible with arguments. For example,
here are tests with three backends, a generous number of loops, and
suppression of intermediate output:
Those changes are really helpful. I just added code to display the
total number of objects in the
Michael Droettboom wrote:
Eric Firing wrote:
I also made memleak_gui.py more flexible with arguments. For example,
here are tests with three backends, a generous number of loops, and
suppression of intermediate output:
Those changes are really helpful. I just added code to display the
Eric Firing wrote:
I just committed a change to the output formatting of memleak_gui so
that if you redirect it to a file, that file can be loaded with
pylab.load() in case you want to plot the columns. (At least this is
true if you don't use the -c option.)
Great. Sorry for stomping on
Michael Droettboom wrote:
Eric Firing wrote:
I just committed a change to the output formatting of memleak_gui so
that if you redirect it to a file, that file can be loaded with
pylab.load() in case you want to plot the columns. (At least this is
true if you don't use the -c option.)
On Tuesday 03 July 2007 04:33:46 pm Eric Firing wrote:
Michael Droettboom wrote:
Eric Firing wrote:
I just committed a change to the output formatting of memleak_gui so
that if you redirect it to a file, that file can be loaded with
pylab.load() in case you want to plot the columns. (At
Eric Firing wrote:
So, this test is still showing problems, with similar memory
consumption in these three backends.
Not necessarily. By default, Python allocates large pools from the
operating system and then manages those pools itself (though its
PyMalloc call). Prior to Python 2.5, those
Michael Droettboom wrote:
Eric Firing wrote:
So, this test is still showing problems, with similar memory
consumption in these three backends.
Not necessarily. By default, Python allocates large pools from the
operating system and then manages those pools itself (though its
PyMalloc
More results:
I've built and tested a more recent pygtk+ stack. (glib-2.12,
gtk+-2.10.9, librsvg-2.16.1, libxml2-2.6.29, pygobject-2.13.1,
pygtk-2.10.4...). The good news is that the C-level leaks I was seeing
in pygtk 2.2 and 2.4 are resolved. In particular, using an SVG icon and
Gdk
Forgot to attach the patches.
Oops,
Mike
Michael Droettboom wrote:
More results:
I've built and tested a more recent pygtk+ stack. (glib-2.12,
gtk+-2.10.9, librsvg-2.16.1, libxml2-2.6.29, pygobject-2.13.1,
pygtk-2.10.4...). The good news is that the C-level leaks I was seeing
in pygtk
On 7/2/07, Michael Droettboom [EMAIL PROTECTED] wrote:
Forgot to attach the patches.
Michael -- if you send me your sf ID I'll add you to the committers
list and you can check these in directly.
Vis-a-vis the gtk question, I agree that we should encourage people to
upgrade who are suffering
On 6/30/07, Eric Firing [EMAIL PROTECTED] wrote:
Mike,
All this sounds like great progress--thanks! I particularly appreciate
the descriptions of what problems you found and how you found them.
John et al.: is there a maintainer for each of these backends? I think
gtk: Steve Chaplin or me
John Hunter wrote:
On 6/30/07, Eric Firing [EMAIL PROTECTED] wrote:
Mike,
All this sounds like great progress--thanks! I particularly appreciate
the descriptions of what problems you found and how you found them.
John et al.: is there a maintainer for each of these backends? I think
On 3/27/07, Eric Firing [EMAIL PROTECTED] wrote:
I can add a couple of things to item (1) below. First, the problem
occurs only with toolbar2, not with classic or None. Second, a script
that illustrates it is attached.
I defintely agree that this is important -- and it is a big help to
have
John Hunter wrote:
On 3/28/07, Jeff Whitaker [EMAIL PROTECTED] wrote:
John: I just added macos x support in the report_memory function.
Regarding Eric's memory leak #2 (which occurs even for non-gui
backends), here's a simple script to trigger it:
Thanks Jeff, could you add this to the
Tom Holroyd (NIH/NIMH) [E] wrote:
import os,matplotlib
matplotlib.use('Agg')
from matplotlib.figure import Figure
from matplotlib.cbook import report_memory
def plot():
fig = Figure()
i = 0
while True:
print report_memory(i)
fig.clf()
ax =
I can add a couple of things to item (1) below. First, the problem
occurs only with toolbar2, not with classic or None. Second, a script
that illustrates it is attached.
Eric
Eric Firing wrote:
In 2007, two different major memory leaks have been identified:
1) Eric Pellegrini showed that
Aalok kapoor wrote:
Thanks for reply,
This was just an example for mem leak in my application. Actually i
want maps with different data to be loaded each time and the map
objects taken once changees after ploting so i have to take different
object each time. After around 20 maps
After using numpy-1.0 the results are more bad. After 15 maps it is reaching to
71% memory usage. I am working on freeBSD box.
python memory_leak_map.py
rss vsz%mem
047940 50636 9.8
175080 77700 15.4
294636 97380 19.4
3114156 116776 23.4
4133672 136416 27.4
5
Jeff and Aalok,
I am in central MO and it doesn't bother me but, for some unknown reason I'm
recieving correspondense between you two. You might want to start a new email
instead of replying to each other. Have a nice day. Curt Bridges
Aalok kapoor [EMAIL PROTECTED] wrote:
After using
34 matches
Mail list logo
