Skip to content
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

[subinterpreters] Refleaks on Windows Under Specific Conditions #117936

Open
ericsnowcurrently opened this issue Apr 16, 2024 · 2 comments
Open
Labels
OS-windows pending The issue will be closed if no feedback is provided topic-subinterpreters type-bug An unexpected behavior, bug, or error

Comments

@ericsnowcurrently
Copy link
Member

ericsnowcurrently commented Apr 16, 2024

Bug report

Bug description:

One of my recent PRs, gh-117662, led to one of the Windows refleak buildbots failing1. I'm fairly confident the PR revealed an existing source of refleaks (albeit an unlikely one), rather that introducing new leaks. I have resolved the failures with gh-117913, but the underlying potential source of refleaks remains.

I've been able to reproduce the leak conditions, but only on Windows (for now?). The following conditions are necessary:

  • interpreter created using a config with check_multi_interp_extensions=False (e.g. "legacy")
  • interpreter imports test.support.os_helper
try:
    import _interpreters
except ModuleNotFoundError:
    import _xxsubinterpreters as _interpreters
config = _interpreters.new_config('legacy')  # critically, check_multi_interp_extensions=False
interpid = _interpreters.create(config)
_interpreters.exec(interpid, 'import test.support.os_helper')
_interpreters.destroy(interpid)
# leaks a bunch of objects

When the bug is triggered, around 190 objects are leaked. At first I thought this was interpreter finalization failing silently, but now I think it is something else.

I suspect the underlying problem relates to legacy extension modules. In the specific example above, I'm pretty sure the _ctypes module is leaking and ~190 is how many objects it holds, directly or indirectly. The main clue there is that, when I run ./python -v ..., the _ctypes module is never noted as destroyed, whereas all other modules are. As to test.support.os_helper, _ctypes is one of the modules that gets indirectly imported. All that said, I haven't been able to reproduce the leak if the subinterpreter above imports _ctypes instead.

Why did we only see this on Windows? The only clue I can think of is that on Windows stdlib extension modules are all turned into builtin modules, IIRC. The logic of the check_multi_interp_extensions check (via _PyImport_CheckSubinterpIncompatibleExtensionAllowed() in Python/import.c) is specific to extension modules, not builtin modules.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Windows

Footnotes

  1. https://buildbot.python.org/all/#/builders/920/builds/733

@ericsnowcurrently
Copy link
Member Author

FYI, gh-117487 (or something like it) may help.

@neonene
Copy link
Contributor

neonene commented Apr 17, 2024

The _ctypes module has switched to the multi-phase initialization, and I can confirm the leaks above disappear on Windows with a patch like #117181 (comment). I think we are on #117181 (comment) at this point.

@ericsnowcurrently ericsnowcurrently added the pending The issue will be closed if no feedback is provided label Jul 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
OS-windows pending The issue will be closed if no feedback is provided topic-subinterpreters type-bug An unexpected behavior, bug, or error
Projects
Status: Todo
Development

No branches or pull requests

2 participants