Quiver leaks memory when called multiple times

[markdbenedict]

I have created quite a nice visualization program using Qt as the interface layer and matplotlib to draw much of the content. I use contour and countourf as well as text and lines and never run into problems with releasing objects. I need to draw many plots to create the input for an animation.

As soon as I start calling Axes.quiver I get leaks. With the size of the dataset it adds up quickly. I am unable to use the animation module due to conflicts with other functionality, and the X,Y values and shapes change between frames so quiver.set_UVC() is of no use to me.

The following code demonstrates the problem with the simple for loop replacing the animation code I would use:

from pylab import *
from numpy import ma
import time


X,Y = meshgrid( arange(0,2*pi,.04),arange(0,2*pi,.04) )
U = cos(X)
V = sin(Y)

fig = figure()
ax = fig.add_axes([0.1,0.1,0.8,0.8])
for i in range(90):
    Q = ax.quiver( U, V)
    time.sleep(0.2)

I know this simple snippet isnt drawing to screen (leak becomes worse then).

Q has a sys.getrefcount of 4 so nothing I am able to do seems to get rid of it. Calls to fig and ax clear only reduce the refcount to 2. Telling Q to remove() itself doesnt help.

My code is much more complex than this. I have tried completely replacing the axes objects but that doesnt help. I really am not free to replace the Figure instance.

[efiring]

Confirmed.
It happens even if one merely creates the Quiver object directly.
I think the problem is that each time a Quiver object is created, it registers another instance function in the list of "dpi_changed" callbacks for the figure object.
Git blame shows the callback registration as dating from 2008, commit 9b4ffcc. It looks like the use of a proxy in CallbackRegistry is supposed to prevent this problem; I don't understand it well enough to see what is going wrong here. @pelson? @mdboom?

[tacaswell]

I think the problem really goes back to b66aa38 , the registration in 9b4ffcc is is quiver_key not quiver.

I suspect is what is going on is that the function has a weakref to it from the callback, but the function contains a reference to the Quiver object (and I suspect this is made worse because it was bound by closing over self, not as an honest instance method.

If you search the repo on on_dpi_change you find a whole bunch of places which probably have the same problem.