On 7/9/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
> I am about to update the memory leak question in the FAQ, but I thought I'd
> run it by the list first. I removed language that talked about much earlier
> releases of mpl, and the paragraph about leaks in older versions of Numeric
> an
I am about to update the memory leak question in the FAQ, but I thought
I'd run it by the list first. I removed language that talked about much
earlier releases of mpl, and the paragraph about leaks in older versions
of Numeric and numarray. It seems like we should recommend numpy when
the us
On 7/9/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> ...however, there are only about 40 patches between 2.12.3 and 2.13.2.
> Two of them are very crucial memory leak patches:
> When I patched 2.12.3 against these patches, the Python object leaks go
> away. There may be workarounds matplot
Eric,
It turns out that the key difference is in pygobject. I was using
2.13.2 (from source) here at work, and Ubuntu Feisty currently ships
2.12.3. 2.13.x is an unstable branch, of course, (gnome-related
packages follow the even/odd versioning scheme), so I shouldn't have
been using it to t
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 a
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
retu
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 PROTECTE
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 t
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
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
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?
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 w
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 backen
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 iss
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
pylab.close(fig)
File "/usr/l
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 PROTECTED]:~/p
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 h
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
3.5k
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 col
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.)
Gre
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 stompi
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 displa
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 t
John Hunter wrote:
> 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.
mdboom
> Vis-a-vis the gtk question, I agree that we should encourage pe
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 f
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 2.2
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 rende
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
> PyMall
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, thos
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?
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 Chapli
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
it is very important that Mike's patches be checked out and applied ASAP
if
I've been looking into the memory leaks exercised by the memleak_gui.py
unit test. I've searched through the mailing list for information, but
I'm new to the party here, so forgive me if I'm not fully current.
Eric Firing wrote:
"I think we have a similar problem with all interactive backends
Tom Holroyd (NIH/NIMH) [E] wrote:
> More info on the memory leaks. It has to do with GtkToolbar.insert().
> For example, in the function _init_toolbar2_4() in backend_gtk.py,
> commenting out any of the self.insert() calls will change how much it
> leaks. Comment them all out, plus the self.file
More info on the memory leaks. It has to do with GtkToolbar.insert(). For
example, in the function _init_toolbar2_4() in backend_gtk.py, commenting out
any of the self.insert() calls will change how much it leaks. Comment them all
out, plus the self.fileselect assignment (which is very slow, by
In fact, the following loop leaks:
for i in range(indEnd):
fig = pylab.figure()
about 2k per on my box _even_ with toolbar set to None.
With it set to toolbar2, it is very noticably slower, and leaks 120k per.
--
Tom Holroyd, Ph.D.
We experience the world not as it is, but as we expect it t
You used gnuplot to plot MPL memory use?
for shame, for shame!
;-)
-Chris
Tom Holroyd (NIH/NIMH) [E] wrote:
> as shown in the graph, then stabilizes.
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 voice
7600 Sand Point Way NE
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()
>>
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 = fig.add_axes([0.1,0.1,0.7,0.7])
ax.plot([1,2,3]
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 t
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 unit dir as well?
John Hunter wrote:
> 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 i
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
h
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 a
In 2007, two different major memory leaks have been identified:
1) Eric Pellegrini showed that a loop over figure(); close() leaks. I
have verified that this occurs with any interactive backend, but not
with non-interactive backends. This may be the same problem that was
reported in other mes
Aalok kapoor wrote:
> 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
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
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
515
Hi,
Thanks for this direction. I am using Numpy-1.1. Do I not supposed to use this
version? I will try to use older version and see what happens. I hope this will
solve the problem.
thanks
-Aalok
Jeff Whitaker <[EMAIL PROTECTED]> wrote: Aalok kapoor wrote:
> Thanks for reply,
>
> This was just
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 gen
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 generation it gives memory error t
Aalok kapoor wrote:
> Hi all,
>
> I am using matplotlib-0.87.7, Basemap-0.9.3, Numpy-1.1 and agg backend.
> I am facing memory leak problems after running following script -
>
>
> import os, sys, time
> import cStringIO
> import Image
> import matplotlib
> matplotlib.use('Agg')
>
> import matplotli
Hi all,
I am using matplotlib-0.87.7, Basemap-0.9.3, Numpy-1.1 and agg backend.
I am facing memory leak problems after running following script -
import os, sys, time
import cStringIO
import Image
import matplotlib
matplotlib.use('Agg')
import matplotlib.pylab as p
import matplotlib.numerix as
54 matches
Mail list logo
