My recommendation still stands to use the Agg backend for long-running offline batch processes, just for having fewer moving parts if nothing else.
Cheers, Mike D2Hitman wrote:
Mike, Yes i'm using a more complicated program to batch produce images. Through more investigation i think it's not just the close function, any repeat call of pylab seems to have similar problem. Thanks for looking into it, i will try the Agg backend and see if that works out. Cheers, Jon. Michael Droettboom-3 wrote:I'm not at the bottom of this yet, but thought I'd share my progress so far -->It is leaking actual Python references (meaning len(gc.get_objects()) is increasing). So it's not a malloc/free pair.Seems to be Gtk-specific. (Both GtkAgg and Gtk). Other backends are unaffected (Qt4 has some sort of leak of a much smaller magnitude).The proper way to destroy pygtk objects appears to be a little bit of a black art. What's there now was pretty much arrived at by experimentation and seems very brittle.I know at one point it was working better than it is now. My next step will be to try to revert to a state where the leak wasn't so bad. Given the architecture of pygtk, I'm not sure it's possible to not leak at all when creating/destroying windows like this, but we should at least be able to reduce the leakage.If your use case is just generating a bunch of images in batch, I'd recommend using the Agg backend, rather than Gtk. That doesn't leak for me. If you really need to be opening and closing this many windows in succession, then we still don't have a good solution.Mike Michael Droettboom wrote:Ok. Thanks, I'll look into it. Just wanted to rule out that this wasn't the known Gtk memory leak with old versions of Gtk before devoting time to it.Cheers, Mike Eric Firing wrote:Michael Droettboom wrote:Can you provide more information about the platform and backend that you are using?Mike,I was able to reproduce this with my ubuntu 8.10, gtkagg backend. I ran the code via cut and paste with the stock python interpreter, not ipython. I did not measure the memory use carefully, but used the system monitor to observe memory for that process climbing, maybe 500k per cycle.Our usual memleak tester shows no problem, however. EricD2Hitman wrote:I am getting a memory leak when i am using the pylab.close() function. I amrunning matplotlib-0.98.3. It happens in a very simple script such as: #!/usr/bin/python import time import pylab while True: time.sleep(1) print 'calling pylab' pylab.box() pylab.close()Every close seems to store megabytes in physical memory. Any idea why thishappens? Cheers.-- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
<<inline: gtk_memleak1108.png>>
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users