Repository navigation
Closed
Labels
Description
22:39 $ python unit/memleak.py Qt5Agg 50 out.png
0: pymalloc 17627699, rss 116760576, nobjs 55869, garbage 0, files: 2
1: pymalloc 17634545, rss 117694464, nobjs 55872, garbage 0, files: 2
2: pymalloc 17635196, rss 118116352, nobjs 55875, garbage 0, files: 2
3: pymalloc 17635615, rss 118386688, nobjs 55878, garbage 0, files: 2
4: pymalloc 17636002, rss 118386688, nobjs 55881, garbage 0, files: 2
5: pymalloc 17636389, rss 118386688, nobjs 55884, garbage 0, files: 2
6: pymalloc 17636776, rss 118386688, nobjs 55887, garbage 0, files: 2
7: pymalloc 17637176, rss 118386688, nobjs 55890, garbage 0, files: 2
8: pymalloc 17637579, rss 118386688, nobjs 55893, garbage 0, files: 2
9: pymalloc 17637985, rss 118386688, nobjs 55896, garbage 0, files: 2
10: pymalloc 17638340, rss 118386688, nobjs 55899, garbage 0, files: 2
11: pymalloc 17638791, rss 118386688, nobjs 55902, garbage 0, files: 2
12: pymalloc 17639162, rss 118386688, nobjs 55905, garbage 0, files: 2
13: pymalloc 17639533, rss 118386688, nobjs 55908, garbage 0, files: 2
14: pymalloc 17639920, rss 118386688, nobjs 55911, garbage 0, files: 2
15: pymalloc 17640307, rss 118386688, nobjs 55914, garbage 0, files: 2
16: pymalloc 17640694, rss 118386688, nobjs 55917, garbage 0, files: 2
17: pymalloc 17641081, rss 118386688, nobjs 55920, garbage 0, files: 2
18: pymalloc 17641468, rss 118386688, nobjs 55923, garbage 0, files: 2
19: pymalloc 17641902, rss 118386688, nobjs 55926, garbage 0, files: 2
20: pymalloc 17642323, rss 118386688, nobjs 55929, garbage 0, files: 2
21: pymalloc 17642573, rss 118386688, nobjs 55932, garbage 0, files: 2
22: pymalloc 17643421, rss 118386688, nobjs 55935, garbage 0, files: 2
23: pymalloc 17643987, rss 118386688, nobjs 55938, garbage 0, files: 2
24: pymalloc 17644342, rss 118386688, nobjs 55941, garbage 0, files: 2
25: pymalloc 17644745, rss 118386688, nobjs 55944, garbage 0, files: 2
26: pymalloc 17645132, rss 118386688, nobjs 55947, garbage 0, files: 2
27: pymalloc 17645519, rss 118386688, nobjs 55950, garbage 0, files: 2
28: pymalloc 17645906, rss 118386688, nobjs 55953, garbage 0, files: 2
29: pymalloc 17646340, rss 118386688, nobjs 55956, garbage 0, files: 2
30: pymalloc 17646816, rss 118386688, nobjs 55959, garbage 0, files: 2
31: pymalloc 17647075, rss 118386688, nobjs 55962, garbage 0, files: 2
32: pymalloc 17647470, rss 118386688, nobjs 55965, garbage 0, files: 2
33: pymalloc 17647857, rss 118386688, nobjs 55968, garbage 0, files: 2
34: pymalloc 17648244, rss 118386688, nobjs 55971, garbage 0, files: 2
35: pymalloc 17648631, rss 118386688, nobjs 55974, garbage 0, files: 2
36: pymalloc 17649049, rss 118386688, nobjs 55977, garbage 0, files: 2
37: pymalloc 17649461, rss 118386688, nobjs 55980, garbage 0, files: 2
38: pymalloc 17649784, rss 118386688, nobjs 55983, garbage 0, files: 2
39: pymalloc 17650115, rss 118386688, nobjs 55986, garbage 0, files: 2
40: pymalloc 17650531, rss 118386688, nobjs 55989, garbage 0, files: 2
41: pymalloc 17651001, rss 118386688, nobjs 55992, garbage 0, files: 2
42: pymalloc 17651260, rss 118386688, nobjs 55995, garbage 0, files: 2
43: pymalloc 17651727, rss 118386688, nobjs 55998, garbage 0, files: 2
44: pymalloc 17652114, rss 118386688, nobjs 56001, garbage 0, files: 2
45: pymalloc 17652501, rss 118386688, nobjs 56004, garbage 0, files: 2
46: pymalloc 17652888, rss 118386688, nobjs 56007, garbage 0, files: 2
47: pymalloc 17653195, rss 118386688, nobjs 56010, garbage 0, files: 2
48: pymalloc 17653611, rss 118386688, nobjs 56013, garbage 0, files: 2
49: pymalloc 17654065, rss 118657024, nobjs 56016, garbage 0, files: 2
Average memory consumed per loop: 10813.4400 bytes
Activity
QuLogic commentedon Sep 1, 2017
Also, I get this at the end:
Also, pretty sure that sum is redundant and could just bedoesn't seem to work that way.(rss_peaks[-1] - rss_peaks[starti]).tacaswell commentedon Sep 1, 2017
See #9142 for a fix to that.
anntzer commentedon Sep 1, 2017
This bisects to earlier than 1.5.0 (#6854 needs to be manually applied for testing early commits, and I copied unit/memleak.py out of the source tree for the bisection).
I can't test 1.4.3 because trying to build it crashes gcc :-)
Given how long the issue has been around I would suggest that this issue, while important, should not be considered as release critical.
Edit: looks like we're leaking dead weakrefs (found by comparing
Counter(map(type, gc.get_objects()))between iterations), which is quite funny in a sense :-)QuLogic commentedon Sep 1, 2017
Every time I bisect, I get a different commit, so this seems a bit random. We probably need to figure out a faster&stabler test to really get to the bottom of this.
anntzer commentedon Sep 1, 2017
is sufficient to show the leak, so we can in fact just run the loop two or three times and fail if the len's are different.
Specifically, tkagg always returns the same number, whereas qt5agg sees a jump of 158 objects between the first and second iteration, and 3 objects per iteration after that. The test always fails even as far back as 1.5.0 + qt4agg.
tacaswell commentedon Sep 1, 2017
I wonder if this due to a change in qt/pyqt not necessarily on our side?
anntzer commentedon Sep 7, 2017
I think it's a bug in pyqt. PySide(2) also leaks, but appears to leak only one object per iteration.
I find that the leaked dead weakrefs started as pointing respectively to a FigureManagerQT, a FigureCanvasQTAgg, and a NavigationToolbar2QT.
https://pypi.python.org/pypi/objgraph is useful for this kind of exploration...
dopplershift commentedon Sep 7, 2017
If both are leaking, I'm skeptical that matplotlib is doing the right thing.
tacaswell commentedon Sep 20, 2017
We are not doing any of the c-work with pyqt which is the easiest way leak references.
The big jump between 1 and 2 does not bother me, that seems like qt starting it's self up.
2 of those classes are things we subclass from qt objects, but all of then are things that I think we have in circular references with Qt objects.
tacaswell commentedon May 22, 2020
Going to optimistically close this as fixed by #17468
anntzer commentedon May 22, 2020
is is actually fixed, or are you just "optimistically" hoping it is?
tacaswell commentedon May 22, 2020
I was going on #17385 (comment)
Going on @QuLogic 's comment in this thread, I think the problem may be worse than it bisecting badly, the leak seems to be non-deterministic:
all 3 run with in a few minutes of each other in the env at v3.2.1-2585-ga1c51a0a1.
If you let it run longer you get:
qt5.pdf
I will open a PR with slight tweaks to the memleak script. We are never spinning the event loop so I think a bunch of the "leaked" memory is Qt objects that we have discarded but need the event loop to spin to finish their end-of-life process.