| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Original report at SourceForge, opened Wed Dec 1 19:00:17 2010
The attached minimal strip chart widget shows a serious memory leak, at least on Mac OS X 10.5 and 10.6. I'm using matplotlib 1.0.0 (from the binary installer), Python 2.6 from python.org, numpy 1.5.0 and ActiveState Aqua Tcl/Tk 8.4.19 (the example uses TkAgg).
Michael Droettboom tested the same example using Fedora 14/Python 2.7/Numpy 1.5.1/Tkinter with both matplotlib 1.0 and
matplotlib SVN head and found no leak. Thus it may be specific to Mac OS X or Tcl/Tk 8.4.19.
More information on linux: if I build matplotlib svn trunk rev8840 from source and then run the example it starts out with a slow memory leak (as shown in the last comment) and then grows. However, if I run the example again it starts out leaking at a higher rate and it's not clear if the rate grows with time. For example:
bash-3.2$ python matplotlibMemoryLeak.py
matplotlib.file= /astro/users/rowen/build/matplotlib-trunk/build/lib.linux-x86_64-2.6/matplotlib/init.pyc
time rss memory mem/sec
(sec) (kb) (kb/sec)
0.0 34164 nan
5.0 34440 nan
10.0 34464 4.8
15.1 34492 5.2
20.1 34508 4.5
25.1 34544 5.2
30.2 34556 4.6
35.2 34576 4.5
40.2 34600 4.6
45.2 34616 4.4
50.2 34632 4.2
55.2 34652 4.2
60.3 34664 4.1
65.3 34684 4.0
70.3 34700 4.0
...
346.7 35688 3.7
351.7 35712 3.7
356.7 35724 3.7
361.8 35748 3.7
366.8 35760 3.6
371.8 35784 3.7
376.8 35796 3.6
381.9 35820 3.7
386.9 35832 3.6
391.9 35932 3.9
396.9 35960 3.9
401.9 35976 3.9
407.0 35988 3.9
412.0 36012 3.9
417.0 36024 3.8
422.0 36048 3.9
427.1 36060 3.8
432.1 36084 3.8
437.1 36096 3.8
442.1 36120 3.8
447.1 36132 3.8
452.1 36156 3.8
457.2 36168 3.8
...
572.8 36588 3.8
577.8 36604 3.8
582.8 36624 3.8
587.8 36640 3.8
592.8 36660 3.8
597.9 36672 3.8
602.9 36692 3.8
It appears something is being cached (otherwise why is the leakage in the first run different than all subsequent runs) but it's not in ~/.matplotlib since deleting that makes no difference.
I tried the test script on linux using matplotlib svn trunk rev8840
(which appears to include your patch) and found a leak that starts out
small but gets systematically larger. This is with Python 2.6.5 and
Tkinter built against Tcl/Tk 8.4.13.
time rss memory mem/sec
(sec) (kb) (kb/sec)
0.0 36816 nan
5.0 36860 nan
10.0 36860 0.0
15.1 36860 0.0
20.1 36860 0.0
25.1 36896 1.8
...
326.5 36896 0.1
331.6 36972 0.3
...
401.9 36972 0.3
406.9 36980 0.3
411.9 37004 0.4
417.0 37016 0.4
422.0 37040 0.4
427.0 37052 0.5
432.0 37076 0.5
437.1 37088 0.5
442.1 37112 0.6
447.1 37124 0.6
452.1 37148 0.6
457.2 37160 0.7
462.2 37184 0.7
467.2 37196 0.7
472.2 37220 0.8
477.3 37232 0.8
482.3 37256 0.8
487.3 37268 0.8
492.3 37292 0.9
497.3 37304 0.9
502.3 37328 0.9
507.4 37340 1.0
512.4 37360 1.0
517.4 37376 1.0
522.4 37396 1.0
527.5 37412 1.1
532.5 37432 1.1
537.5 37448 1.1
542.5 37472 1.1
547.6 37488 1.2
552.6 37504 1.2
557.6 37516 1.2
562.6 37540 1.2
567.6 37556 1.2
572.7 37576 1.3
577.7 37592 1.3
582.7 37612 1.3
587.7 37628 1.3
592.7 37648 1.3
597.8 37664 1.4
602.8 37684 1.4
607.8 37700 1.4
This is different behavior than on Mac OS X (where it starts out large and stays about the same), but still alarming.
It is actually the call to canvas.draw that does the leak. Is it not supposed to be called multiple times?
The leak shows up on unix as well. It seems to occur whenever the X axes limits are changed (something that happens frequently for a strip chart). See the new attached script which is much simpler than the first one and reports memory usage. The leak rate is at least roughly proportional to how frequently the x axes are changed (the value of updateInterval).
| Back | FazBrowse Home | New Git URL |
Activity
efiring commented on Jun 21, 2011
Two substantive comments were added to the Sourceforge tracker after the contents of the tracker were captured for transfer to github. The upshot is that the problem does not seem to appear with current mpl and TclTk 8.5, but we are not sure whether there is still a problem with 8.4. I'm going to close this because it seems unlikely that the problem, if any remains, is in current mpl, and hence is anything we can fix.