On Tue, Dec 14, 2010 at 5:26 PM, Russell Owen wrote:
> On Dec 14, 2010, at 2:38 PM, Benjamin Root wrote:
>
> On Tue, Dec 14, 2010 at 4:22 PM, Benjamin Root wrote:
>
>>
>>
>> On Tue, Dec 14, 2010 at 4:06 PM, Russell Owen wrote:
>>
>>> On Dec 14, 2010, at 1:50 PM, Benjamin Root wrote:
>>>
>>> On
On Tue, Dec 14, 2010 at 4:22 PM, Benjamin Root wrote:
>
>
> On Tue, Dec 14, 2010 at 4:06 PM, Russell Owen wrote:
>
>> On Dec 14, 2010, at 1:50 PM, Benjamin Root wrote:
>>
>> On Tue, Dec 14, 2010 at 3:18 PM, Russell E. Owen wrote:
>>
>>> I tried the test script on linux using matplotlib svn trun
On Dec 14, 2010, at 1:50 PM, Benjamin Root wrote:
On Tue, Dec 14, 2010 at 3:18 PM, Russell E. Owen wrote:
I tried the test script on linux using matplotlib svn trunk rev8840
(which appears to include your patch) and found a leak that starts out
small but gets systematically larger. This is with
On Dec 14, 2010, at 2:38 PM, Benjamin Root wrote:
On Tue, Dec 14, 2010 at 4:22 PM, Benjamin Root
wrote:
On Tue, Dec 14, 2010 at 4:06 PM, Russell Owen wrote:
On Dec 14, 2010, at 1:50 PM, Benjamin Root wrote:
On Tue, Dec 14, 2010 at 3:18 PM, Russell E. Owen
wrote:
I tried the test scrip
On Tue, Dec 14, 2010 at 4:06 PM, Russell Owen wrote:
> On Dec 14, 2010, at 1:50 PM, Benjamin Root wrote:
>
> On Tue, Dec 14, 2010 at 3:18 PM, Russell E. Owen wrote:
>
>> I tried the test script on linux using matplotlib svn trunk rev8840
>> (which appears to include your patch) and found a leak
On Tue, Dec 14, 2010 at 3:18 PM, Russell E. Owen wrote:
> I tried the test script on linux using matplotlib svn trunk rev8840
> (which appears to include your patch) and found a leak that starts out
> small but gets systematically larger. This is with Python 2.6.5 and
> Tkinter built against Tcl/
I tried the test script on linux using matplotlib svn trunk rev8840
(which appears to include your patch) and found a leak that starts out
small but gets systematically larger. This is with Python 2.6.5 and
Tkinter built against Tcl/Tk 8.4.13.
Is anyone else seeing this?
time rss memorym
I already posted results using the svn trunk plus the svn trunk with
your patch (as well as the 1.0.0 release). I updated them today with a
few more options (such as your patch without setting the x limit -- it
didn't make any difference) and letting them run longer. Here they are.
All are from
If you're able to try this with the 1.0.x SVN branch or the SVN trunk
(plus my text patch) let me know. I am not able to reproduce any sort
of memory leak with these newer versions, but I am able to with 1.0.0 as
released (with or without my text patch). This is with or without the x
axis lim
I also wanted to say:
- Thank you for the patch. I appreciate the chance to try a fix.
- I doubt the issue is related to text because my scripts shows a memory
leak even if the displayed text is never updated (comment out the line
that modifies the x axis limits to see what I mean; though I confe
I'm afraid your change didn't help (I only applied the patch to
lib/matplotlib/text.py; the cbook.py change appeared to only affect
whitespace).
However, the memory leak is smaller using the svn trunk than in
matplotlib 1.0.0. Also, calling subplot.clear() makes the leak worse in
matplotlib 1.
I think I'm on to something -- it seems that text layout information has
a cyclical reference that prevents the Text object from being freed.
Can you apply the attached patch and let me know if it solves your issue?
Mike
On 12/10/2010 02:19 PM, Russell E. Owen wrote:
You may have already seen
You may have already seen this in the general mailing list, but I've
found what I think is a serious memory leak in matplotlib 1.0.0: it
leaks memory every time canvas.draw() is called, at least when using
TkAgg on unix and Mac.
Admittedly many graphs do not need canvas.draw() to be called repe
Hi all,
I've come across a memory leak when saving multiple figures in a row.
The figure contains a single pcolormesh artist, which I need to
rasterize in my application. However, turning on rasterization causes
a memory leak.The attached script reproduces the problem; swap out the
commented secti
On Mon, Jan 19, 2009 at 6:33 AM, Michiel de Hoon wrote:
> I am also finding the continuing increase in memory usage, but this also
> occurs with other backends (I tried tkagg and pdf) and also without the call
> to savefig. One possibility is a circular reference in the quiver function
> that p
/19/09, Damon McDougall wrote:
> From: Damon McDougall
> Subject: [matplotlib-devel] Memory leak using savefig with MacOSX backend?
> To: "matplotlib development list"
> Date: Monday, January 19, 2009, 6:09 AM
> I'm looping over several files (about 1000) to produce
I'm looping over several files (about 1000) to produce a vector field
plot for each data file I have. Doing this with the MacOSX backend
appears to chew memory. My guess as to the source of the problem is
the 'savefig' function (or possibly the way the MacOSX backend handles
the saving of p
On Fri, Nov 21, 2008 at 8:17 AM, Benoit Zuber <[EMAIL PROTECTED]> wrote:
> Sorry, I did not realise it (I suppose, I did not quite know what backend
> means, now I checked it on wikipedia ;-) . Running the script with
> --verbose-helpful told me that the backend was GTKAgg version 2.10.1
Here is
>
> Well, you are still using some backend, probably a GUI one, even if no
> figure pops up. You can run your script with --verbose-helpful to see
> what is happening.
>
Sorry, I did not realise it (I suppose, I did not quite know what
backend means, now I checked it on wikipedia ;-) . Runni
On Fri, Nov 21, 2008 at 7:53 AM, Benoit Zuber <[EMAIL PROTECTED]> wrote:
>
>> If you comment out agg you are using a gui backend presumably (which
>> one) and most of these are known to have some leaks, some of which are
>> beyond our control.
>
> This leak happened without any gui backend when I r
> If you comment out agg you are using a gui backend presumably (which
> one) and most of these are known to have some leaks, some of which are
> beyond our control.
This leak happened without any gui backend when I ran the script from
the csh prompt like that:
> python script.py
>
> When you
On Fri, Nov 21, 2008 at 7:04 AM, Benoit Zuber <[EMAIL PROTECTED]> wrote:
>
>> > I posted this on maplotlib-users list, but got no reply. I guess that
>> > bugs should rather be reported here...
>>
>> Could you post a *complete* script that demonstrates the leak, eg one
>> that calls the function an
> > I posted this on maplotlib-users list, but got no reply. I guess that
> > bugs should rather be reported here...
>
> Could you post a *complete* script that demonstrates the leak, eg one
> that calls the function and does any other cleanup? Does it help to
> use gc.collect between function c
On Fri, Nov 21, 2008 at 4:24 AM, Benoit Zuber <[EMAIL PROTECTED]> wrote:
> Hi,
> I posted this on maplotlib-users list, but got no reply. I guess that
> bugs should rather be reported here...
Could you post a *complete* script that demonstrates the leak, eg one
that calls the function and does any
Hi,
I posted this on maplotlib-users list, but got no reply. I guess that
bugs should rather be reported here...
I have noticed a memory leak when using pylab.pcolor. Here is the code,
fa() and fb() do the same thing. The difference is the size of the array
which is passed to pcolor. With a large
Hi,
thank you very much! The memory leak disappeared after I updated
pygobject from 2.12 to 2.13.2.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications wit
Agreed. I'm not sure how this bug could be resolved only on the
matplotlib side. See if you can make a standalone (pygtk-only) example
that demonstrates this bug and send it to their mailing list. Also, if
it's possible, try updating pygtk. There was a very similar bug in an
earlier version
Mátyás János wrote:
> Hi,
>
> I'm looking for memory leaks in a python application and found leaks in
> matplotlib. The application is graphic intensive. Each time it updates
> the screen, matplotlib allocates another 5-10 megabytes memory for the
> new gtk.gdk.Pixbuf and gtk.gdk.GCX11 while does
Hi,
I'm looking for memory leaks in a python application and found leaks in
matplotlib. The application is graphic intensive. Each time it updates
the screen, matplotlib allocates another 5-10 megabytes memory for the
new gtk.gdk.Pixbuf and gtk.gdk.GCX11 while does not free up the buffers
allocate
Michael Droettboom wrote:
> Thanks for finding this.
>
> This should be fixed in r4881. It was a simple reference counting bug.
>
> Please let me know if you still see leaks.
That fixed it here. Thank you!
Eric
-
This SF
Thanks for finding this.
This should be fixed in r4881. It was a simple reference counting bug.
Please let me know if you still see leaks.
Cheers,
Mike
Eric Firing wrote:
> Rob Hetland wrote:
>> I am using the new transforms version of MPL (the svn trunk), and
>> found a memory leak in pcolo
Rob Hetland wrote:
> I am using the new transforms version of MPL (the svn trunk), and
> found a memory leak in pcolor and pcolormesh. Be warned, I just
> reported a memory leak in the scikits delaunay package that Robert
> Kern was not able to reproduce, so it might be nice if someone could
I am using the new transforms version of MPL (the svn trunk), and
found a memory leak in pcolor and pcolormesh. Be warned, I just
reported a memory leak in the scikits delaunay package that Robert
Kern was not able to reproduce, so it might be nice if someone could
check this out. I am o
33 matches
Mail list logo
