Properly deleting a matplotlib figure embedded in a child window in PySide to free memory

[jnsebgosselin]

Introduction

This issue comes from a question I asked on StackOverflow about how to properly delete a matplotlib figure embedded in a child window in PySide to free memory. Since then, I've worked numerous hours trying to understand the problem by testing and studying the codebase of matplotlib. User tcaswell suggested that I should probably escalate this issue here. Therefore, below I present a reformulated and updated problem description based on my original StackOverflow question.

Problematic

I have an application, from which I open a modless child window by clicking on a button. Within this child window, I produce a matplotlib figure with the object oriented API using the non-GUI backend FigureCanvasAgg. I then convert the figure into a QPixmap, which is then displayed on the child window using a QLabel.

The problem is that, once the figure has been converted into a QPixmap, or after a child window has been closed, the garbage collector seems unable to fully clean the matplotlib figure and a certain amount of memory is not deallocated from the process.

A Minimal Working Example

This is a simple application I've produced while trying to isolate the problem. When clicking on the "Show Figure" button:

• if the number in the spin box equals 1, the child window will contain a QLabel displaying a QPixmap produced from an external image. This was to verify this was not a problem with the way I was destroying the child window in qt.
• if the number in the spin box equals 2, the child window will contain a QLabel displaying a QPixmap produced from a matplotlib figure, using only the non-GUI backend FigureCanvasAgg.

import sys
import numpy as np
from PySide import QtGui, QtCore
import matplotlib as mpl
import gc
from matplotlib.backends.backend_agg import FigureCanvasAgg

class MyApp(QtGui.QWidget):
    def __init__(self):
        super(MyApp, self).__init__()

        btn_open = QtGui.QPushButton('Show Figure')
        btn_open.clicked.connect(self.show_a_figure)

        btn_call4gc = QtGui.QPushButton('Garbage Collect')
        btn_call4gc.clicked.connect(self.collect)

        self.mode = QtGui.QSpinBox()
        self.mode.setRange (1, 2)
        self.mode.setValue(2)

        layout = QtGui.QGridLayout()
        layout.addWidget(btn_open, 1, 1)
        layout.addWidget(self.mode, 1, 2)
        layout.addWidget(btn_call4gc, 2, 1)
        self.setLayout(layout)

    def show_a_figure(self):        
        MyFigureManager(mode=self.mode.value(), parent=self).show()

    def collect(self):
        num = gc.collect()
        print(num)

class MyFigureManager(QtGui.QWidget):    
    def __init__(self, mode, parent=None):
        super(MyFigureManager, self).__init__(parent)

        self.setWindowFlags(QtCore.Qt.Window)
        self.setAttribute(QtCore.Qt.WA_DeleteOnClose)

        layout = QtGui.QGridLayout()
        layout.addWidget(MyFigureCanvas(mode=mode, parent=self), 0, 0)
        self.setLayout(layout)

class MyFigureCanvas(QtGui.QLabel):               
    def __init__(self, mode, parent=None):        
        super(MyFigureCanvas, self).__init__()
        self.setAttribute(QtCore.Qt.WA_DeleteOnClose)
        self.setMaximumSize(1000, 650)

        if mode == 1:

            #-- import a large image from hardisk --

            qpix = QtGui.QPixmap('aLargeImg.jpg')

        elif mode == 2:

            #-- plot some data with mpl --

            canvas = FigureCanvasAgg(mpl.figure.Figure())
            renderer = canvas.get_renderer()

            ax = canvas.figure.add_axes([0.1, 0.1, 0.85, 0.85])
            ax.axis([0, 1, 0, 1])

            N = 10**6
            x = np.random.rand(N)
            y = np.random.rand(N)

            colors = np.random.rand(N)
            area = np.pi * (5 * np.random.rand(N)) ** 2

            ax.scatter(x, y, s=area, c=colors, alpha=0.5)

            #-- convert mpl imag to pixmap --

            canvas.draw()
            imgbuf = canvas.figure.canvas.buffer_rgba()
            imgwidth = int(renderer.width)
            imgheight =int(renderer.height)
            qimg = QtGui.QImage(imgbuf, imgwidth, imgheight,
                                QtGui.QImage.Format_ARGB32)
            qimg = QtGui.QImage.rgbSwapped(qimg)
            qpix = QtGui.QPixmap(qimg)

        self.setPixmap(qpix)

        num = gc.collect()
        print(num)

if __name__ == '__main__':

    app = QtGui.QApplication(sys.argv)

    w = MyApp()
    w.show()

    sys.exit(app.exec_())

I tested the above application in Ubuntu 15.04 + Python 2.7.9 + Matplotlib 1.4.2 + PySide 1.2.2. A similar behaviour also occurs in Python 3.4.3. When opened from the terminal, the memory used by the application on startup is around 50 MiB. Then if, in mode 2:

• I, several times, open a single child window and close it, the memory used by the application will gradually rise from around 200 MiB and will stabilize at around 300 MiB after about 5 cycles.
• I, several times, open a single child window, close it, and explicitly call a gc.collect(), the memory used by the application will vary between 70 and 90 MiB. I've had a run where it got stuck at around 150 MiB for no apparent reason.
• I do the same process as the above but by opening multiple child windows at the same time and then closing them, the "problem" seems to be worse.

I've just dive recently in the memory-management aspect of Python, so I'm not very knowledgeable in this area. Is it an expected behaviour that I should just get on with or is it worth investigating further or is there something wrong in my approach?

[WeatherGod]

I wonder if you might get a different result if you explicitly set your
backend to "agg" at the very beginning. While it looks like it is avoiding
any of the automatic backend selection stuff, I wonder if our codebase
might not be a clean as we would like. Try adding:

import matplotlib as mpl
mpl.use('agg')

This would guarantee that everything stays as AGG-based all the way through.

On Thu, Sep 3, 2015 at 12:35 PM, Jean-Sébastien Gosselin <
notifications@github.com> wrote:

Introduction

This issue comes from a question I asked on StackOverflow
http://stackoverflow.com/questions/32318643/how-to-properly-delete-a-matplotlib-figure-embedded-in-a-child-window-in-pyside
about how to properly delete a matplotlib figure embedded in a child window
in PySide to free memory. Since then, I've worked numerous hours trying to
understand the problem by testing and studying the codebase of matplotlib.
User tcaswell suggested that I should probably escalate this issue here.
Therefore, below I present a reformulated and updated problem description
from my original StackOverflow question.
Problematic

I have an application, from which I open a modless child window by
clicking on a button. Within this child window, I produce a matplotlib
figure with the object oriented API using the non-GUI backend
FigureCanvasAgg. I then convert the figure into a QPixmap
https://srinikom.github.io/pyside-docs/PySide/QtGui/QPixmap.html, which
is then displayed on the child window using a QLabel
https://srinikom.github.io/pyside-docs/PySide/QtGui/QLabel.html.

The problem is that, once the figure has been converted into a QPixmap, or
after a child window has been closed, the garbage collector seems unable to
fully clean the matplotlib figure and a certain amount of memory is not
deallocated from the process.
A Minimal Working Example

This is a simple application I've produced while trying to isolate the
problem. When clicking on the "Show Figure" button:

• if the number in the spin box equals 1, the child window will
  contain a QLabel displaying a QPixmap produced from an external image. This
  was to verify this was not a problem with the way I was destroying the
  child window in qt.
• if the number in the spin box equals 2, the child window will
  contain a QLabel displaying a QPixmap produced from a matplotlib figure,
  using only the non-GUI backend FigureCanvasAgg.

[image: mpl_pyside_memory_rel_qlabel_test py_006]
https://cloud.githubusercontent.com/assets/10170372/9663506/d1e94142-5232-11e5-95be-bbb816beb99a.png

import sys
import numpy as np
from PySide import QtGui, QtCore
import matplotlib as mpl
import gc
from matplotlib.backends.backend_agg import FigureCanvasAgg

class MyApp(QtGui.QWidget):
def init(self):
super(MyApp, self).init()

    btn_open = QtGui.QPushButton('Show Figure')
    btn_open.clicked.connect(self.show_a_figure)

    btn_call4gc = QtGui.QPushButton('Garbage Collect')
    btn_call4gc.clicked.connect(self.collect)

    self.mode = QtGui.QSpinBox()
    self.mode.setRange (1, 2)
    self.mode.setValue(2)

    layout = QtGui.QGridLayout()
    layout.addWidget(btn_open, 1, 1)
    layout.addWidget(self.mode, 1, 2)
    layout.addWidget(btn_call4gc, 2, 1)
    self.setLayout(layout)

def show_a_figure(self):
    MyFigureManager(mode=self.mode.value(), parent=self).show()

def collect(self):
    num = gc.collect()
    print(num)

class MyFigureManager(QtGui.QWidget):
def init(self, mode, parent=None):
super(MyFigureManager, self).init(parent)

    self.setWindowFlags(QtCore.Qt.Window)
    self.setAttribute(QtCore.Qt.WA_DeleteOnClose)

    layout = QtGui.QGridLayout()
    layout.addWidget(MyFigureCanvas(mode=mode, parent=self), 0, 0)
    self.setLayout(layout)

class MyFigureCanvas(QtGui.QLabel):
def init(self, mode, parent=None):
super(MyFigureCanvas, self).init()
self.setAttribute(QtCore.Qt.WA_DeleteOnClose)
self.setMaximumSize(1000, 650)

    if mode == 1:

        #-- import a large image from hardisk --

        qpix = QtGui.QPixmap('aLargeImg.jpg')

    elif mode == 2:

        #-- plot some data with mpl --

        canvas = FigureCanvasAgg(mpl.figure.Figure())
        renderer = canvas.get_renderer()

        ax = canvas.figure.add_axes([0.1, 0.1, 0.85, 0.85])
        ax.axis([0, 1, 0, 1])

        N = 10**6
        x = np.random.rand(N)
        y = np.random.rand(N)

        colors = np.random.rand(N)
        area = np.pi * (5 * np.random.rand(N)) ** 2

        ax.scatter(x, y, s=area, c=colors, alpha=0.5)

        #-- convert mpl imag to pixmap --

        canvas.draw()
        imgbuf = canvas.figure.canvas.buffer_rgba()
        imgwidth = int(renderer.width)
        imgheight =int(renderer.height)
        qimg = QtGui.QImage(imgbuf, imgwidth, imgheight,
                            QtGui.QImage.Format_ARGB32)
        qimg = QtGui.QImage.rgbSwapped(qimg)
        qpix = QtGui.QPixmap(qimg)

    self.setPixmap(qpix)

    num = gc.collect()
    print(num)

if name == 'main':

app = QtGui.QApplication(sys.argv)

w = MyApp()
w.show()

sys.exit(app.exec_())

I tested the above application in Ubuntu 15.04 + Python 2.7.9 + Matplotlib
1.4.2 + PySide 1.2.2. A similar behaviour also occurs in Python 3.4.3. When
opened from the terminal, the memory used by the application on startup is
around 50 MiB. Then if, in mode 2:

• I, several times, open a single child window and close it, the
  memory used by the application will gradually rise from around 200 MiB and
  will stabilize at around 300 MiB after about 5 cycles.
• I, several times, open a single child window, close it, and
  explicitly call a gc.collect(), the memory used by the application
  will vary between 70 and 90 MiB. I've had a run where it got stuck at
  around 150 MiB for no apparent reason.
• I do the same process as the above but by opening multiple child
  windows at the same time and then closing them, the "problem" seems to be
  worse.

I've just dive recently in the memory-management aspect of Python, so I'm
not very knowledgeable in this area.
Is it an expected behaviour that I should just get on with it or is it
worth investigating further or is there something wrong in my approach?

—
Reply to this email directly or view it on GitHub
#5022.

[jnsebgosselin]

@WeatherGod
I've tried to explicitly set the 'agg' backend in mpl with the same results. I managed to partially solve the "Issue" by removing manually the circular references between the mpl artists, but I don't understand yet everything that is going on.

I don't mind investigating this further for the sake of contributing and learning the codebase of matplotlib, but I would like to be sure that I'm not on a wild-goose chase here. Is it even theoretically possible or expected to have all the memory taken up by a mpl figure deallocated once it is deleted? Also what about the garbage collector. Should it be empty once the mpl figure is properly deleted? Actually, there seems to remain about 3k items in it when I call gc.collect() if I don't clean up stuff manually. When I generate a pixmap from an external image (mode 1), all the memory is deallocated and the gc collector is empty once the child window is deleted. I guess that this process is simpler than creating a mpl figure, thus easier to clean-up.

I will test the same code on a Windows 7 OS to be sure that this is not related to my particular setup. Will report the results when its done.

[leycec]

This open issue concerns me.

I'm contemplating a similar workflow to that described by jnsebgosselin above, albeit with the nascent PySide2 rather than increasingly obsolete PySide framework.

Is it even theoretically possible or expected to have all the memory taken up by a mpl figure deallocated once it is deleted?

From my admittedly novice understanding, absolutely.

The low-level matplotlib._pylab_helpers.Gcf.destroy() and matplotlib._pylab_helpers.Gcf.destroy_fig() methods go to excruciating lengths to garbage collect the currently registered Figure instance with the passed index and the passed Figure instance, respectively. The higher-level matplotlib.pyplot.close() function then defers to these methods to garbage collect the desired figures; likewise, most interactive backends (e.g., backend_qt5, backend_tkagg) register a callback on the window close event deferring to these methods as well.

The issue here may be your use of the non-interactive FigureCanvasAgg backend. Since you fail to explicitly call matplotlib.pyplot.close() in the above example, it seems conceivable that circular artist references (as you astutely note above) prevent the instantiated figures from being released after their parent canvas instances go out of scope.

Would you mind adding an explicit call to matplotlib.pyplot.close() at the tail end of your MyFigureCanvas.__init__() method and giving this another go? If figures still aren't being released for some or all backends or operating systems, "Houston, we have a problem."

[leycec]

On further investigation, my prior comment probably doesn't apply. Since you bypass use of the pyplot and hence Gcf API altogether, neither can help you – or me, when I similarly implement this!

While the matplotlib.backend_bases.FigureCanvasBase.__init__() method does establish a circular reference between a canvas and its associate figure, the garbage collector exists to detect and break these references. You explicitly call gc.collect(). Even if you didn't, however, the garbage collector should still be doing its job.

Of course, the garbage collector refuses to break circular references amongst objects defining the __del__() method. Of course, your example doesn't appear to leverage any such objects (e.g., TimerBase). I'm a flummoxed Canadian brown bear as to what's going on here. 🐻

I do wonder, however, why the Figure.set_canvas() method uses a strong rather than weak reference (i.e., weakref). The latter would circumvent the creation of any circular references to begin with, at seemingly no cost that I can see. Or am I missing something? I am probably missing something.

I suppose I'll just have to bite the ugly bullet and profile this myself when I hit that milestone.

[jnsebgosselin]

I haven't worked on this issue for a while. If i recall correctly, by deleting some circular references and explicitly calling the garbage collector, I was able to free up most of the memory taken up by my embedded matplotlib figures.

For the remaining memory that was not released by my program, my best guess is that it is related to what is called "free lists", which cannot be collected by the gc as discussed here for instance:

http://effbot.org/pyfaq/why-doesnt-python-release-the-memory-when-i-delete-a-large-object.htm

I haven't had time to investigate this hypothesis further though.

[efiring]

From everything described above, it is not clear to me that there is a problem at all. First, remember that automatic garbage collection happens only occasionally, so when it is not called explicitly one must expect some buildup and potentially big fluctuations. Second, memory management is a messy business, with discrete sizes of chunks, fragmentation, different levels at which allocation/deallocation can occur (e.g., python has its own allocation/deallocation functions, and I wouldn't be surprised if Qt does also.) Third, there are different ways of measuring how much memory is in use, and the answer can change depending on exactly when the measurement is made. With a simple script that repeatedly makes a plot, it is normal for the memory usage to climb over many iterations before it eventually stabilizes, with further changes occurring in a relatively small range.
We use the mpl.cbook.report_memory() utility when checking for memory leakage.

[jnsebgosselin]

Thanks for your comment @efiring, that is mostly what I wanted to hear.

After much testing, I also came to the conclusion that there was probably no problem and that the residual memory was normal business. The "free lists" explanation fitted the behavior I was experiencing, I was quite ok with that, and I stopped investigating the issue.

[leycec]

@efiring Excellence incarnate. In light of your succinct breakdown, this non-issue can probably be safely closed.

It's a bit oddball that the original example showed memory overhead of ~250MB without explicit garbage collection, but that's unlikely to be Matplotlib's problem. I suspect today's lesson is that long-lived Matplotlib-based applications should consider performing explicit garbage collection on a routine basis.

One final thought on this blustery winter's day: would there by any tangible benefit to replacing circular with weak references in the Matplotlib codebase (e.g., between figures and figure canvases, between figure canvases and figure managers)? Doing so could reduce the severity of these sorts of issues for applications not performing explicit garbage collection.

Snowflakes for all! ❄️

[tacaswell]

If the user only has a hard reference to the Figure or Canvas object we do not want the other to get gc'd as it would render the object the user did hold on to (presumably because they wanted to do something with it) useless (we do use weakrefs other places in the library, such as in the callback registry which leads to it's own set of issues).

There are also circular references between fig <-> axes and axes <-> artists which again I think it is a feature, not a bug, that the hard cycles exist.

[leycec]

Yes, that quite makes sense. The public API is as it is, and there's little use crying over spilled memory this late in the game. To improve memory churn, I suspect we'll probably end up implementing a similar "fix" as jnsebgosselin. Specifically, immediately before a figure goes out of scope:

1. Explicitly break as many circular references for that figure as we can find.
2. Explicitly nullify that figure.
3. Explicitly garbage collect.

There are also circular references between fig <-> axes and axes <-> artists which again I think it is a feature, not a bug, that the hard cycles exist.

For any of the obvious reasons, circular references are generally something to be avoided. Circular references between objects defining __del__() methods will never be garbage collected, for example. Do Matplotlib objects define __del__() methods?

Yes. Yes, they do. TimerBase.__del__() is probably the most obvious example. Which directly implies that there may already exist edge cases of unbreakable circular references in the Matplotlib codebase. Which would be bad.

This is one among many reasons that hard cycles are considered harmful, even moreso than the über-harmful goto statement. goto only promotes unmaintainable control flow. Hard cycles promote memory leaks and preclude usage of __del__() methods, an essential control flow construct for which there exists no good alternative.

Of course, Matplotlib may have valid use cases for employing hard cycles... like, everywhere throughout the public API. In the end, though, it doesn't particularly matter. The damage (if any) has long been done. There's no unwinding that decision process now.

Thanks for the clarifying comments, all! This has been most instructive. 👍

[github-actions]

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!