Repository navigation
atexit module breaks refleak check #139289
Description
Bug report
Bug description:
If the test registers a callback with atexit module, refleak test will consider it a leak.
def test_refleak(self):
atexit.register(lambda: None)This is the root cause of the buildbot failure of #139185. It's a couple of coincidences that caused the seemingly unrelated issue. Basically, clearing the module cache in test_zipimport made the module-level code in rlcompleter, which includes a register to atexit, run more than once.
There are a few possible approaches to fix this, but I did not find the solution that I'm immediately happy with.
I consider this a test framework bug as this should be a valid behavior. The ideal solution is to keep the atexit callbacks before running test in a loop and restore it after. However, atexit does not provide such an interface, public or private. You can either clear it or run it. The callbacks are stored in a state of the interpreter and we don't have any access to it.
Without that, we either need to somehow calculate the allocated memory by atexit, or hope that no one writes a test that writes to atexit. Of course there might be other ways that I did not think of.
CPython versions tested on:
CPython main branch
Operating systems tested on:
macOS
Activity
encukou commentedon Sep 24, 2025
This is intended behaviour: tests aren't supposed to “modify the environment” (affect other tests). IMO, the top-level code in
rlcompleteris the anomaly. (It was written in 1997; who knew it would interfere with tests in 2025.)Maybe we could put
Completerin another module, so you could use it without the side effects?gaogaotiantian commentedon Sep 24, 2025
I agree the top-level code in
rlcompleteris not ideal. I was worried that changing it would break backward compatibility. Moving theCompleterclass to another module is a decent way to fix the issue, but that also requires some work - creating a new module in CPython is not the most trivial thing to do I think (docs, etc.).However, that seems like the most ideal solution we have for now and I'm happy if that can be done.
ericsnowcurrently commentedon Sep 24, 2025
FWIW, we can put
Completerin a private module, to avoid the extra work of a new public stdlib module.gh-139289: Lazy import rlcompleter to fix the refleak (#139305)
[3.13] gh-139289: Lazy import rlcompleter to fix the refleak (GH-139305…
pythongh-139289: Lazy import rlcompleter to fix the refleak (python#1…
[3.14] gh-138860: Lazy import rlcompleter in pdb to avoid deadlock in…
hugovk commentedon Oct 10, 2025
Triage: ready to close this issue?
encukou commentedon Oct 10, 2025
Unfortunately, the merged patch only fixed a symptom. Making Completer importable without side effects is still up for grabs.