-
-
Notifications
You must be signed in to change notification settings - Fork 32k
IsolatedAsyncioTestCase __del__
could be dangerous
#96021
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
Comments
Apart from a reproducer it would be nice if your issue description was more clearly stating the problem. Quoting from the middle of another discussion is just confusing. |
I had a go at undrafting the issue, I still need to make a reproducer |
Hm... I had sort of assumed that debug() was intentionally not cleaning anything up on failure -- TestCase.debug() doesn't either (it has a special case for PS. There is no such thing as a draft issue. |
…n tests Tests for IsolatedAsyncioTestCase.debug() rely on the runner be closed in __del__. It makes tests depending on the GC an unreliable on other implementations. It is better to close the runner explicitly even if currently there is no a public API for this.
GH-96135) Tests for IsolatedAsyncioTestCase.debug() rely on the runner be closed in __del__. It makes tests depending on the GC an unreliable on other implementations. It is better to close the runner explicitly even if currently there is no a public API for this.
…n tests (pythonGH-96135) Tests for IsolatedAsyncioTestCase.debug() rely on the runner be closed in __del__. It makes tests depending on the GC an unreliable on other implementations. It is better to close the runner explicitly even if currently there is no a public API for this. (cherry picked from commit 4de06e3) Co-authored-by: Serhiy Storchaka <[email protected]>
…n tests (pythonGH-96135) Tests for IsolatedAsyncioTestCase.debug() rely on the runner be closed in __del__. It makes tests depending on the GC an unreliable on other implementations. It is better to close the runner explicitly even if currently there is no a public API for this. (cherry picked from commit 4de06e3) Co-authored-by: Serhiy Storchaka <[email protected]>
…n tests (pythonGH-96135) Tests for IsolatedAsyncioTestCase.debug() rely on the runner be closed in __del__. It makes tests depending on the GC an unreliable on other implementations. It is better to close the runner explicitly even if currently there is no a public API for this.
GH-96135) Tests for IsolatedAsyncioTestCase.debug() rely on the runner be closed in __del__. It makes tests depending on the GC an unreliable on other implementations. It is better to close the runner explicitly even if currently there is no a public API for this. (cherry picked from commit 4de06e3) Co-authored-by: Serhiy Storchaka <[email protected]>
… in tests (pythonGH-96135) Tests for IsolatedAsyncioTestCase.debug() rely on the runner be closed in __del__. It makes tests depending on the GC an unreliable on other implementations. It is better to tear down the loop explicitly even if currently there is no a public API for this. (cherry picked from commit 4de06e3) Co-authored-by: Serhiy Storchaka <[email protected]>
…sts (GH-96135) (GH-96235) Tests for IsolatedAsyncioTestCase.debug() rely on the runner be closed in __del__. It makes tests depending on the GC an unreliable on other implementations. It is better to tear down the loop explicitly even if currently there is no a public API for this. (cherry picked from commit 4de06e3) Co-authored-by: Serhiy Storchaka <[email protected]>
What's the status of this? @graingert Do you have a reproducer? |
Nothing changed. #96135 solved some potential problems in our tests of It is not even clear what solution should be. |
It looks like in IsolatedAsyncioTestCase when
debug()
crashes it doesn't teardown the event loop, in addition it seems that if the loop isn't torn down it will happen in__del__
which means thread local sensitive functions likeset_event_loop
get called via the GC from potentially the wrong threadOriginally posted by @graingert in #95898 (comment)
The text was updated successfully, but these errors were encountered: