New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Qt5Agg is leaking #9141
Comments
Also, I get this at the end: 49: pymalloc 17023128, rss 112095232, nobjs 55454, garbage 0, files: 2
Traceback (most recent call last):
File "unit/memleak.py", line 143, in <module>
run_memleak_test(MemleakTest(args.empty), args.iterations[0], args.report[0])
File "unit/memleak.py", line 59, in run_memleak_test
(np.sum(rss_peaks[starti+1:] - rss_peaks[starti:-1]) / float(endi - starti)))
TypeError: slice indices must be integers or None or have an __index__ method
|
See #9142 for a fix to that. |
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 |
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. |
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. |
I wonder if this due to a change in qt/pyqt not necessarily on our side? |
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... |
If both are leaking, I'm skeptical that matplotlib is doing the right thing. |
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. |
Going to optimistically close this as fixed by #17468 |
is is actually fixed, or are you just "optimistically" hoping it is? |
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: 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. |
The text was updated successfully, but these errors were encountered: