Re: [matplotlib-devel] memory leaks

[Eric F. <ef...@ha...>]

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 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 messages, such as one by Dylan Passmore in January.
> 
> 2) There is a recent thread "Re: Memory leak in basemap or matplotlib" 
> showing that even with a non-interactive backend, a seemingly-pointless 
> call to cla() is needed to prevent a leak.
> 
> I would like to suggest that we try harder to solve these problems ASAP. 
>   This kind of malfunctioning at the core of mpl worries me.
> 
> I have spent quite a bit of time trying to figure out (1), and I have 
> tracked it down to the NavigationToolbar2.  Eliminate the toolbar by 
> putting None in the rc slot, and the memory leak vanishes.  It looks to 
> me like some explicit call to a destroy method may be needed to 
> dismantle the toolbar when a figure is closed and/or deleted.  I suspect 
> that each gui toolkit is keeping references to components, and the 
> toolbar is not getting the word when the window is destroyed. 
> gc.garbage verifies that the toolbar components are what get left behind.
> 
> So, I hope a gui toolkit backend wizard can step forward and say, "Of 
> course, we just need to put a __del__ method here with a call to 
> destroy()", or something like that.
> 
> I have spent much less time on (2), and made no progress.
> 
> We are relying very heavily on the gc--mpl has cyclic references all 
> over the place.  Is anyone sure that we don't need explicit gc support 
> in any of the extension code?  Can *everything* in the extension code be 
> handled correctly with reference counting?  Is this independent of how 
> things defined in extension code are used at the python level?
> 
> It is not clear to me that gc debugging methods even allow one to see 
> problems in extension code that do not have some degree of gc support. 
> The standard documentation of the gc module and the gc C API is minimal.
> 
> Eric
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel