Skip to content

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

Open
graingert opened this issue Aug 16, 2022 · 5 comments · Fixed by #96135
Open

IsolatedAsyncioTestCase __del__ could be dangerous #96021

graingert opened this issue Aug 16, 2022 · 5 comments · Fixed by #96135
Labels
stdlib Python modules in the Lib dir

Comments

@graingert
Copy link
Contributor

graingert commented Aug 16, 2022

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 like set_event_loop get called via the GC from potentially the wrong thread

Originally posted by @graingert in #95898 (comment)

@gvanrossum
Copy link
Member

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.

@graingert
Copy link
Contributor Author

graingert commented Aug 16, 2022

I had a go at undrafting the issue, I still need to make a reproducer

@gvanrossum
Copy link
Member

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 @skip though).

PS. There is no such thing as a draft issue.

serhiy-storchaka added a commit to serhiy-storchaka/cpython that referenced this issue Aug 20, 2022
…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.
Repository owner moved this from Todo to Done in Unittest issues Aug 24, 2022
serhiy-storchaka added a commit that referenced this issue Aug 24, 2022
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.
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Aug 24, 2022
…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]>
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Aug 24, 2022
…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]>
mdboom pushed a commit to mdboom/cpython that referenced this issue Aug 24, 2022
…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.
Repository owner moved this from Done to In Progress in Unittest issues Aug 25, 2022
miss-islington added a commit that referenced this issue Aug 25, 2022
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]>
serhiy-storchaka added a commit to miss-islington/cpython that referenced this issue Aug 27, 2022
… 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]>
serhiy-storchaka added a commit that referenced this issue Aug 28, 2022
…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]>
@kumaraditya303 kumaraditya303 removed the pending The issue will be closed if no feedback is provided label Sep 6, 2022
@kumaraditya303
Copy link
Contributor

What's the status of this? @graingert Do you have a reproducer?

@serhiy-storchaka
Copy link
Member

Nothing changed. #96135 solved some potential problems in our tests of unittest by using a private method, but the original problem still exists.

It is not even clear what solution should be.

@github-project-automation github-project-automation bot moved this to Todo in asyncio Jan 24, 2025
@encukou encukou added stdlib Python modules in the Lib dir and removed tests Tests in the Lib/test dir topic-asyncio labels Jan 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stdlib Python modules in the Lib dir
Projects
Status: In Progress
Status: Todo
Development

Successfully merging a pull request may close this issue.

6 participants