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
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
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
prevents data from being cleaned up.
--Michiel
--- On Mon, 1/19
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,
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
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
27 matches
Mail list logo
