bpo-36356: Fix memory leak in _asynciomodule.c during "setup.py build_ext"

[btharper]

The module seems to be imported twice during the build process which causes a leak. Since these objects are intended to be global for the life of the import, retain them during the second import.

The double import seems to be an artifact of the build system, and not indicative of normal use.

Multiple PRs for BPO-36356 were largely grouped under a single NEWS entry, should this continue to be skipped, or should a new note be added for the 3.9 branch?

https://bugs.python.org/issue36356

[1st1]

I think you should add a static _asyncio_module_inited and check that once, as there are many other places that could be initialized twice. I also wonder how exactly can it be imported twice...

[btharper]

Turns out I was incorrect about the double import. It's importing itself as part of the import process, once as "_asyncio" that then imports itself as "asyncio" gdb trace (with edited paths) below. The spec is passed in from setup.py line 529, but the _module naming convention doesn't seem out of place compared to others (_sha*, _ctypes, _decimal, etc).

#0 module_init () at cpython/Modules/_asynciomodule.c:3251
#1 0x00007ffff2dca8a7 in PyInit__asyncio () at cpython/Modules/_asynciomodule.c:3352
#2 0x000055555593e5ff in _PyImport_LoadDynamicModuleWithSpec (
spec=spec@entry=<ModuleSpec(name='_asyncio', loader=<ExtensionFileLoader(name='_asyncio', path='cpython/build/lib.linux-x86_64-3.9-pydebug/_asyncio.cpython-39d-x86_64-linux-gnu.so') at remote 0x607000ea0320>, origin='cpython/build/lib.linux-x86_64-3.9-pydebug/_asyncio.cpython-39d-x86_64-linux-gnu.so', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached=None) at remote 0x607000ea0390>, fp=fp@entry=0x0) at ./Python/importdl.c:164
[... trimmed for brevity ...]
#214 0x000055555593d20c in PyImport_ImportModule (name=name@entry=0x7ffff2dcbe80 "asyncio") at Python/import.c:1482
#215 0x00007ffff2dc3c6f in module_init () at cpython/Modules/_asynciomodule.c:3246
#216 0x00007ffff2dca8a7 in PyInit__asyncio () at cpython/Modules/_asynciomodule.c:3352
#217 0x000055555593e5ff in _PyImport_LoadDynamicModuleWithSpec (
spec=spec@entry=<ModuleSpec(name='_asyncio', loader=<ExtensionFileLoader(name='_asyncio', path='build/lib.linux-x86_64-3.9-pydebug/_asyncio.cpython-39d-x86_64-linux-gnu.so') at remote 0x607000cfc9b0>, origin='build/lib.linux-x86_64-3.9-pydebug/_asyncio.cpython-39d-x86_64-linux-gnu.so', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached=None) at remote 0x607000cfca20>, fp=fp@entry=0x0) at ./Python/importdl.c:164

[btharper]

Updated with a static variable to check initialization. left initialization for the inner call and return early for the outside call, although I don't think the difference would be significant.

If everything looks good I can squash the previous commit since the first one is entirely reverted by the second.

[1st1]

LGTM, but please fix the nit I highlighted.

[btharper]

Good catch, I've fixed the one introduced by this changeset, but grep shows 6 more instances. Would it be worth fixing them along with these changes, or leaving it as it is?

[vstinner]

Good catch, I've fixed the one introduced by this changeset, but grep shows 6 more instances. Would it be worth fixing them along with these changes, or leaving it as it is?

@btharper: Which instances? In which file?

[btharper]

Good catch, I've fixed the one introduced by this changeset, but grep shows 6 more instances. Would it be worth fixing them along with these changes, or leaving it as it is?

@btharper: Which instances? In which file?

Sorry for the lack of specificity. 6 more instances of the closing bracket being on the same line as an else/else if in the Modules/_asynciomodule.c file. I wasn't sure if it would be useful to clean up the rest of the file or just correct what was modified in this PR, though I expect not changing unrelated lines is the safest answer. Anything else for bpo-36356 would be under another PR.

[1st1]

Sorry for the lack of specificity. 6 more instances of the closing bracket being on the same line as an else/else if in the Modules/_asynciomodule.c file. I wasn't sure if it would be useful to clean up the rest of the file or just correct what was modified in this PR, though I expect not changing unrelated lines is the safest answer. Anything else for bpo-36356 would be under another PR.

We can fix them in a separate PR.

[1st1]

Could you please generate a NEWS entry with blurb?

[vstinner]

LGTM.

I'm fine with merging it with new NEWS entry. It's uncommon to load a C extension twice.

[miss-islington]

Thanks @btharper for the PR, and @1st1 for merging it 🌮🎉.. I'm working now to backport this PR to: 3.8.
🐍🍒⛏🤖

[1st1]

I'm fine with merging it with new NEWS entry. It's uncommon to load a C extension twice.

Alright!

[bedevere-bot]

GH-16622 is a backport of this pull request to the 3.8 branch.