Repository navigation
_asyncio.Task.__new__(_asyncio.Task).get_context() segfaults #154871
Description
Crash report
What happened?
Calling _asyncio.Task.get_context() on an uninitialized Task created via __new__() crashes the interpreter with a segmentation fault.
Minimal reproducer
import _asyncio
_asyncio.Task.__new__(_asyncio.Task).get_context()A more realistic case is an asyncio.Task subclass that overrides __init__() without calling super().__init__().
import asyncio
class MyTask(asyncio.Task):
def __init__(self, *args, **kwargs):
pass
MyTask.__new__(MyTask).get_context()Actual behavior
The interpreter crashes with a segmentation fault (exit code 139).
Expected behavior
The interpreter should not crash. Accessing get_context() on an uninitialized Task should either return a well-defined value or raise a Python exception.
Analysis
Task instances are allocated using PyType_GenericNew, so fields are initially zero-initialized. The task_context field is initialized only in _asyncio_Task___init__().
However, _asyncio_Task_get_context_impl() currently does:
return Py_NewRef(self->task_context);without checking whether task_context has been initialized. Calling Py_NewRef(NULL) dereferences a null pointer and crashes the interpreter.
For comparison, the adjacent methods _asyncio_Task_get_coro_impl() and _asyncio_Task_get_name_impl() both guard their corresponding fields before returning them, so the same half-initialized object does not crash when calling get_coro() or get_name().
The pure Python implementation also exposes get_context() by returning self._context, so bypassing initialization would result in a normal Python exception rather than a hard interpreter crash.
CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux
Output from running 'python -VV' on the command line:
Python 3.16.0a0 (heads/fix-154835-odict-desync-dirty:8b048eb35eb, Jul 28 2026, 20:03:25) [GCC 13.3.0]
Linked PRs
- gh-154871: Fix
asyncio.Task.get_context()crash #154898 - [3.15] gh-154871: Fix
asyncio.Task.get_context()crash on uninitialized tasks (GH-154898)Â #155019 - [3.14] gh-154871: Fix
asyncio.Task.get_context()crash on uninitialized tasks (GH-154898)Â #155020 - [3.13] gh-154871: Fix
asyncio.Task.get_context()crash on uninitialized tasks (GH-154898)Â #155021
Activity
picnixz commentedon Jul 29, 2026
Messing with C extensions with
__new__and__init__is usually not considered a legitimate issue but if @kumaraditya303 wants to fix this, we can accept the patch.I do not remember whether we fixed similar issues in the past though with missing super() calls.
Please avoid creating such issues in the future though.
johnslavik commentedon Jul 29, 2026
I think in the second example the OP meant to show this:
Asyncio lets you set your own task factories, we do subclass
asyncio.Taskin tests (test_create_taskandtest_set_task_factory), many people subclassasyncio.Task: https://github.com/search?q=%2F%5CS%2B%5C%28asyncio%5C.Task%5C%29%3A%2F&type=code.If I were to throw my two cents, I think this is worth fixing. To me it does look like it could randomly occur.
picnixz commentedon Jul 29, 2026
Oh so if it's like that yes.
pythongh-154871: Address review comments
gh-154871: Fix `asyncio.Task.get_context()` crash on uninitialized taâĶ
[3.13] gh-154871: Fix `asyncio.Task.get_context()` crash on uninitialâĶ
[3.14] gh-154871: Fix `asyncio.Task.get_context()` crash on uninitialâĶ
[3.15] gh-154871: Fix `asyncio.Task.get_context()` crash on uninitialâĶ
pythongh-154871: Fix `asyncio.Task.get_context()` crash on uninitialiâĶ