[Bug]: plt.figure(), plt.close() leaks memory #23701

Activity

1. nschloe commented on Aug 22, 2022

   

   nschloe

   on Aug 22, 2022

   ContributorAuthor

   More actions

   The following is with

   matplotlib.use('GTK3Agg')

   
2. timhoffm commented on Aug 22, 2022

   

   timhoffm

   on Aug 22, 2022

   Last edited by timhoffm

   Member

   More actions

   Have you tried other backends? Is this GTK and/or AGG specific? Interesting would be "qtagg", "Tkagg", "agg" and "gtk4cairo".
3. tacaswell commented on Aug 22, 2022

   

   tacaswell

   on Aug 22, 2022

   Member

   More actions

   The issue is that you are never letting the GUI event loop run so there are a growing number of GUI windows just hanging out in the background waiting for the event loop to run so they can finish their tear down cycle (because most UI frameworks have a way to notify that things are being destroyed etc).

   If you need to run tight loops like this either use a non-interactive backend (like 'agg' or 'svg') which will never create the GUI objects or call plt.pause(.1) every so often to let the GUI clean up.
4. nschloe commented on Aug 22, 2022

   

   nschloe

   on Aug 22, 2022

   Last edited by nschloe

   ContributorAuthor

   More actions

   I've tried the suggestion. Outcome: All backends have the problem, but 'agg' and 'svg' run a lot faster than the rest. I've tried

   • 'agg'
   • 'gtk3agg'
   • 'gtk3cairo'
   • 'gtk4agg'
   • 'gtk4cairo'
   • 'qtagg'
   • 'qtcairo'
   • 'svg'

   When adding plt.pause(1.0) (a full second), no clean-up appears to happen. This is with 'agg'; observe the plateaus:

   

   Code:

   import matplotlib
   import matplotlib.pyplot as plt
   
   matplotlib.use("GTK4Agg")
   
   # [
   #     "GTK3Agg",
   #     "GTK3Cairo",
   #     "GTK4Agg",
   #     "GTK4Cairo",
   #     "MacOSX",
   #     "nbAgg",
   #     "QtAgg",
   #     "QtCairo",
   #     "Qt5Agg",
   #     "Qt5Cairo",
   #     "TkAgg",
   #     "TkCairo",
   #     "WebAgg",
   #     "WX",
   #     "WXAgg",
   #     "WXCairo",
   #     "agg",
   #     "cairo",
   #     "pdf",
   #     "pgf",
   #     "ps",
   #     "svg",
   #     "template",
   # ]
   
   for k in range(4000):  # higher numbers for agg, svg
       plt.figure()
       plt.close()
       if k % 1000 == 0:
           plt.pause(1.0)
5. tacaswell commented on Aug 22, 2022

   

   tacaswell

   on Aug 22, 2022

   Member

   More actions

   Can you please try adding gc.collect() (to clean up an reference cycles) and put the pause before the close (some of the backends do not actually run the event loop if the all of the managers are gone).

   Can you also try with https://github.com/matplotlib/matplotlib/blob/main/tools/memleak.py on your system?

   import gc
   import matplotlib.pyplot as plt
   import matplotlib as mpl
   mpl.use('agg')
   
   while True:
       plt.figure()
       plt.close()
       gc.collect()

   This stays under 90MB for me (where as with out the gc.collect() it did indeed start to run away).

   👍React with 👍1Reacted by Nico Schlömer
6. tacaswell commented on Aug 22, 2022

   

   tacaswell

   on Aug 22, 2022

   Member

   More actions

   import matplotlib.figure as mfigure
   
   
   while True:
       mfigure.Figure()

   Also seems to work so likely something in the Manager class
7. nschloe commented on Aug 22, 2022

   

   nschloe

   on Aug 22, 2022

   ContributorAuthor

   More actions

   • agg without gc (100k iterations):

     

   • agg with gc (100k iterations, gc after every 1000 its):

     
8. nschloe commented on Aug 22, 2022

   

   nschloe

   on Aug 22, 2022

   ContributorAuthor

   More actions

   python3 memleak.py agg 100 out.pdf
   

   
9. nschloe commented on Aug 22, 2022

   

   nschloe

   on Aug 22, 2022

   ContributorAuthor

   More actions

   mfigure Also seems to work so likely something in the Manager class

   Indeed:

   import gc
   import matplotlib.pyplot as plt
   import matplotlib as mpl
   import matplotlib.figure as mfigure
   
   mpl.use('agg')
   
   for k in range(100000):
       mfigure.Figure()
       plt.close()

   gives

   

   -- no explicit gc.
10. tacaswell commented on Aug 23, 2022

    

    tacaswell

    on Aug 23, 2022

    Member

    More actions

    That long delay at the end is probably GC finally running on the way out

    plt.close() is no effect in that second example because the Figure was never registered with

    ---

    I understand the problem, TL;DR either use manual gc.collect() or set gc.set_threshold(100) because we internally use gc.collect(1) which breaks CPyhons garbage collection (I'll be opening up a PR soon).

    1. https://devguide.python.org/internals/garbage-collector/index.html is the best write of the GC out there
    2. a details that is not included is that the logic to sort out which generation to run is only run if the threshold for the lowest generation is met (cpython source)
    3. we have a gc.collect(1) in

       matplotlib/lib/matplotlib/_pylab_helpers.py

       Lines 69 to 72 in 5773bf9

       	# Full cyclic garbage collection may be too expensive to do on every
       	# figure destruction, so we collect only the youngest two generations.
       	# see: https://github.com/matplotlib/matplotlib/pull/3045
       	gc.collect(1)

       which is sweeping out lower generations
    4. if we do not have a code path between the plt.close() that does not make 700 objects then we never pass that first test and CPython never tries to run its "what generation to run?" logic (cpython source) and we have this run-away "leak"

    ---

    You can reproduce this issue with:

    import gc
    import matplotlib.figure as mfigure
    
    
    print("about to start")
    for j in range(100_000):
        fig = mfigure.Figure()
        gc.collect(1)
        print(gc.get_count())

    A way to "fix" this is

    from itertools import count
    import gc
    import matplotlib.pyplot as plt
    import matplotlib as mpl
    mpl.use('agg')
    
    
    class MyObject:
        ...
        
    gc.collect()
    print("about to start")
    for j in range(100):
        print(gc.get_count())
        plt.figure()
        print(gc.get_count())
        plt.close()
        print(gc.get_count())
        c = [MyObject() for j in range(700)]

    which will force enough generation 0 objects to be created that it will cause a full gc eventually.

    👍React with 👍1Reacted by Nico Schlömer
11. tacaswell

    added this to the v3.5.4 milestone on Aug 23, 2022
12. tacaswell

    added a commit that references this issue on Aug 23, 2022

    FIX: do not try to help CPython with garbage collection

    ...

    This issue will close once commit 9f3861f is merged into the 'main' branch.

    9f3861f
13. greglucas

    closed this as completedin #23712on Aug 25, 2022
14. tacaswell

    modified the milestones: v3.5.4, v3.6.0 on Aug 25, 2022
15. QuLogic

    added

    Performance

    on Aug 25, 2022
16. melissawm

    added a commit that references this issue on Dec 19, 2022

    FIX: do not try to help CPython with garbage collection

    ...

    This issue will close once commit 03ff3b0 is merged into the 'main' branch.

    03ff3b0
17. imgbot

    added 2 commits that reference this issue on Apr 19, 2026

    FIX: do not try to help CPython with garbage collection

    ...

    This issue will close once commit db8ad3a is merged into the 'main' branch.

    db8ad3a

    FIX: do not try to help CPython with garbage collection

    ...

    This issue will close once commit bf50e9f is merged into the 'main' branch.

    bf50e9f