This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author jquesnelle
Recipients jquesnelle
Date 2020-04-15.17:32:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1586971925.67.0.678462551955.issue40294@roundup.psfhosted.org>
In-reply-to
Content
Starting with Python 3.8 (GH-16598), the `_asyncio` module's C initialization is guarded behind a static variable. If the module is initialized a second time and this variable is set, the resources from the first initialization are used. However, when the module is freed and the corresponding resources released, the static variable is not cleared. If the module is subsequently initialized again, it will incorrectly believe it has already been initialized and use the previously freed resources, resulting in a crash.

This scenario is actually fairly easy to encounter in the presence of multiple interpreters whose lifetime is shorter than that of the whole program. Essentially, if any interpreter loads `asyncio` and then is freed with `Py_EndInterpreter`, any new interpreter that loads `asyncio` will crash. Since `asyncio` is a built-in module, it is loaded as a consequence of a wide variety of libraries.

I ran into this in my project because I use multiple interpreters to isolate user scripts, and I started to encounter crashes when switching to Python 3.8.

I've attached a simple reproduction program. I've personally tested that this runs without crashing in 3.6 and 3.7 (but I suspect it works down to 3.4 when `asyncio` was introduced).
History
Date User Action Args
2020-04-15 17:32:05jquesnellesetrecipients: + jquesnelle
2020-04-15 17:32:05jquesnellesetmessageid: <1586971925.67.0.678462551955.issue40294@roundup.psfhosted.org>
2020-04-15 17:32:05jquesnellelinkissue40294 messages
2020-04-15 17:32:04jquesnellecreate