You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(qasync) mdickinson@mirzakhani Desktop % python ~/Desktop/qasync_leak.py
number of event loop objects: 1
number of event loop objects: 2
number of event loop objects: 3
number of event loop objects: 4
number of event loop objects: 5
number of event loop objects: 6
number of event loop objects: 7
number of event loop objects: 8
number of event loop objects: 9
number of event loop objects: 10
The expectation / hope was that the number of event loops would be stable.
Diagnosis
Here's a graph showing all the ancestors of one of the leaked QSelectorEventLoop objects.
Those two lambda objects at the top have no referrers (in the sense of gc.get_referrers); they're apparently being kept alive by PySide6. Those lambdas correspond to these two lines:
I believe that if we add the corresponding signal disconnects at event loop close time, then this will fix the above issue.
System details
Python 3.10 venv
qasync 0.23.0 installed from PyPI (via pip)
PySide6 6.4.2 installed from PyPI (via pip)
macOS 12.6.2 on an Intel MacBook Pro
Context
In case you're wondering why anyone would be creating QEventLoops repeatedly, the answer is unit testing. We're using qasync to provide an asyncio event loop for an embedded IPython kernel to use within a Qt-based application. In our test suite we have many tests that create and then tear down that asyncio event loop, and we were observing test interactions as a result of not being able to cleanly clean up all the resources associated to the event loop. (The Qt application itself is a singleton, of course, so we don't try to clean that up between tests.)
The text was updated successfully, but these errors were encountered:
On a similar note QEventLoop does not clean up asyncio.events._set_running_loop which can cause issue when multiple different event loops are used over time (I have a testing situation where this arises).
Hi @mdickinson, thank you for a detailed repro and analysis. I will try to address this issue in the coming weeks. @MatthieuDartiailh this has been fixed in #71 and present in 0.24.0
We're seeing an issue where the
close
method of aQSelectorEventLoop
doesn't completely clean up resources associated to that event loop.Reproducer
The following code should reproduce:
When I run the above on my machine, I get:
The expectation / hope was that the number of event loops would be stable.
Diagnosis
Here's a graph showing all the ancestors of one of the leaked
QSelectorEventLoop
objects.Those two
lambda
objects at the top have no referrers (in the sense ofgc.get_referrers
); they're apparently being kept alive by PySide6. Thoselambda
s correspond to these two lines:qasync/qasync/__init__.py
Line 347 in 88b64c7
qasync/qasync/__init__.py
Lines 508 to 512 in 88b64c7
I believe that if we add the corresponding signal
disconnect
s at event loop close time, then this will fix the above issue.System details
pip
)pip
)Context
In case you're wondering why anyone would be creating
QEventLoop
s repeatedly, the answer is unit testing. We're usingqasync
to provide an asyncio event loop for an embedded IPython kernel to use within a Qt-based application. In our test suite we have many tests that create and then tear down that asyncio event loop, and we were observing test interactions as a result of not being able to cleanly clean up all the resources associated to the event loop. (The Qt application itself is a singleton, of course, so we don't try to clean that up between tests.)The text was updated successfully, but these errors were encountered: