python / python/cpython

`dict` item-iterator: `_PyObject_GC_UNTRACK` on never-tracked iterator under OOM (`dictobject.c`)

未關閉
#152,107 1 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

interpreter-core type-crash
主要語言
Python
星號
77.2k
分支
35.9k
PR 合併指標
PR 指標待擷取

描述

Creating a dict item-iterator (iter(d.items()) or reversed(d.items())) while
allocations are failing aborts a debug build with:

Objects/dictobject.c:5532: _PyObject_GC_UNTRACK:
    Assertion "_PyObject_GC_IS_TRACKED(op)" failed:
    object not tracked by the garbage collector
object type name: dict_itemiterator
Fatal Python error: _PyObject_AssertFailed

dictiter_new() allocates the iterator with PyObject_GC_New() but only calls
_PyObject_GC_TRACK(di) at the very end. For item iterators it first allocates
di->di_result via _PyTuple_FromPairSteal(). If that allocation fails (OOM), the
error path runs Py_DECREF(di) on the still-untracked iterator, and
dictiter_dealloc() unconditionally calls _PyObject_GC_UNTRACK(di).

  • Debug build: the _PyObject_GC_IS_TRACKED assertion fires → Py_FatalError / abort.
  • Release build (NDEBUG): the assert is compiled out and untracking a never-tracked
    object corrupts the GC list, leading to a later segfault in _Py_Dealloc.

Only item iterators are affected (dict_itemiterator / dict_reverseitemiterator) —
they are the only dict iterators whose di_result requires an allocation between
PyObject_GC_New and _PyObject_GC_TRACK.

This was found via allocation-failure fuzzing as OOM-0006 in the umbrella issue
#151763. Filing a focused issue per that issue's process.

Reproducer

Minimal, stdlib-only, deterministic (requires a --with-pydebug interpreter so
_testcapi.set_nomemory is available):

import faulthandler, _strptime
faulthandler.enable()
from _testcapi import set_nomemory
for start in range(60):
    set_nomemory(start)
    try:
        _strptime._strptime("", "")
    except BaseException:
        pass
print("done, no crash")

_strptime._strptime("", "") performs an iter(d.items()) once the size-2 tuple
freelist is drained, so _PyTuple_FromPairSteal() reaches the failing allocator and
drives the dictiter_new() OOM error path. (Reducer by @devdanzin; gist:
https://gist.github.com/devdanzin/c809eb4072c0c787c0c890f54ba1c843)

Backtrace (abbreviated)
_PyObject_AssertFailed                       Objects/object.c
_PyObject_GC_UNTRACK                          Include/internal/pycore_gc.h:254
dictiter_dealloc (self=dict_itemiterator)     Objects/dictobject.c:5532
_Py_Dealloc                                   Objects/object.c
Py_DECREF                                     Include/refcount.h
dictiter_new (itertype=PyDictIterItem_Type)   Objects/dictobject.c   <- Py_DECREF(di) after di_result alloc fails
PyObject_GetIter                              Objects/abstract.c
Suggested fix

Either guard the untracked against the never-tracked error path:

if (_PyObject_GC_IS_TRACKED(di)) {
    _PyObject_GC_UNTRACK(di);
}

or move _PyObject_GC_TRACK(di) ahead of the fallible di_result allocation (after
initializing di->di_result = NULL so traverse/dealloc stay safe). A PR with the first
approach and a regression test is ready.

CPython versions tested on:

CPython main branch

Operating systems tested on:

macOS

Output from running 'python -VV' on the command line:

No response

Linked PRs
  • gh-152110

貢獻指南

開啟貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

研究方向

從 Objects/dictobject.c 中的 dictiter_new() 和 dictiter_dealloc() 開始,然後在 --with-pydebug 建置上執行提供的 _strptime 和 _testcapi.set_nomemory reproducer。檢查連結的 PR,了解已經在進行的工作。當 item-iterator 的 OOM 路徑不再導致中止或損壞 GC,並且有一個涵蓋該故障的回歸測試時,即視為完成。

由索引模型根據 Issue 內容生成。

評估

技術堆疊
c, python
領域
backend
Issue 類型
缺陷
難度
3/5
預估耗時
1-2 天
活躍度
停滯
描述清晰度
描述清楚
新手友好度
25/100

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。