[subinterpreters] Refleaks on Windows Under Specific Conditions
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 77.2k
- Forks
- 35.9k
- PR merge metrics
- PR metrics pending
Description
Bug report
Bug description:
One of my recent PRs, gh-117662, led to one of the Windows refleak buildbots failing^1. 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
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the Windows leak with the provided _interpreters legacy-config snippet, then start in Python/import.c around _PyImport_CheckSubinterpIncompatibleExtensionAllowed(). Compare module cleanup for test.support.os_helper and _ctypes, using the verbose import output described in the report. Done means the reproducer no longer leaks objects and the relevant Windows behavior is covered by an appropriate regression test.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100