Repository navigation
Race condition leads to AttributeError from BaseEventLoop.__del__ #158903
Description
Activity
- changed the title
[-]Race condition leads to AttributeError from BaseEventLoop.__del__[/-][+]Race condition leads to AttributeError from `BaseEventLoop.__del__`[/+]on Oct 6, 2026 @bmerry, can I work on this issue? I am able to reproduce the same bug in Windows 11 Version: 23H2, with the following output:
Exception ignored while calling deallocator <function BaseEventLoop.__del__ at 0x0000019DB6734EB0>: Traceback (most recent call last): File "C:\Users\user1\AppData\Local\Python\pythoncore-3.14-64\Lib\asyncio\base_events.py", line 760, in __del__ self.close() File "C:\Users\user1\AppData\Local\Python\pythoncore-3.14-64\Lib\asyncio\proactor_events.py", line 696, in close self._close_self_pipe() File "C:\Users\user1\AppData\Local\Python\pythoncore-3.14-64\Lib\asyncio\proactor_events.py", line 778, in _close_self_pipe self._ssock.close() AttributeError: 'ProactorEventLoop' object has no attribute '_ssock' Running on Python 3.14.3 with default event loop policies...Based on my analysis of this bug the issue is that, in rare cases a
KeyBoardInterruptcan blockasyncio.run()loop's__init__method before attributes ( such asself.sockin the above bug ), can be fully initialized. At the end during garbage collection the, these attributes aren't there so Python raisesAttributeErrorfor them.
Making the cleanup process of the loop a bit more conservative would be able to resolve this I believe.@bmerry, can I work on this issue?
I'm not a CPython committer, so it's not up to me. But note that @JohnnyWilson16 seems to have provided a fix already.
Reacted by Uttam BhadauriyaI don't think it's a valid issue. This event is rare and suppressing the exception just for a clean traceback is honestly not worth it. If you interrupt the event loop during initialization, we can just leave it as is. And looking at the PR this adds un-necessary churn.
I don't think it's a valid issue. This event is rare and suppressing the exception just for a clean traceback is honestly not worth it. If you interrupt the event loop during initialization, we can just leave it as is. And looking at the PR this adds un-necessary churn.
I think you might be right. I was thinking in terms of https://docs.python.org/3/library/asyncio-runner.html#handling-keyboard-interruption, where Python 3.11 made changes specifically to ensure that SIGINT leads to a clean shutdown, but with the code I provided I'm guessing the SIGINT is being delivered before that signal handler is even installed.
I still think it's best practice for
__del__not to assume that__init__ran to completion (it could fail for a variety of reasons such as OSError or MemoryError, not just SIGINT), but maybe not worth the churn as you say. Feel free to close.I'm leaving it open until Kumar comes back and then we can advise. But looking at the PR I really don't think having a bunch of ifs everywhere is really the best we can do. If there are better and cleaner alternatives I'm open to the change but otherwise I would advise against as it complicates the code.
I don't think we need anything to do here. The AttributeError is a benign exception and it's ignored anyway. And I don't think there is anything to do just in
__init__.py. The problem is whenclose()is called by__del__and where we are lacking attributes. What we can do is trying to free the resources in the reverse order they are declared so that if__init__is interrupted somewhere, as soon as an AttributeError is rasied, it means the "rest" of the attributes don't need real cleanup. But we would still have AttributeErrors.Now, if Kumar wants to avoid any exception during cleanups like that, it's ok, but I'd like his input first.
Reacted by Uttam Bhadauriya
Bug report
The following program will rarely (maybe 0.1% of the time) print a stack trace:
Output:
Tested on Ubuntu 24.04 with CPython 3.15.0rc3 from deadsnakes. I've also observed this with 3.14.6.
CPython versions tested on:
3.15
Operating systems tested on:
Linux
Linked PRs