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.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
assignee=Noneclosed_at=Nonecreated_at=<Date2021-09-22.08:32:26.699>labels= ['3.9', 'type-crash', 'expert-asyncio']
title='crash if asyncio is used before and after re-initialization if using python embedded in an application'updated_at=<Date2021-10-08.08:55:45.466>user='https://bugs.python.org/benjamin-sch'
We have embedded Python in our application and we deinitialize/initialize the interpreter at some point of time. If a simple script with a thread that sleeps with asyncio.sleep is loaded before and after the re-initialization, then we get the following assertion in the second run of the python module:
"Assertion failed: Py_IS_TYPE(rl, &PyRunningLoopHolder_Type), file D:\a\1\s\Modules_asynciomodule.c, line 261"
We were hitting the same issue in kodi, which uses embedded sub-interpreters to run python addons, after one of the addons was switched to asyncio.
The immediate cause of the assertion failure is a use-after-free issue from the running loop holder cache:
When the running loop holder is deallocated (which happens eg on interpreter shutdown) cached_running_holder holds a dangling pointer.
A subsequent call to get_running_loop() may then pick that up and boom.
While probably not a full fix for this issue I think it would be good to fix the use-after-free problem - there could be other code paths that lead to this situation. I've created a github pull request for that