python / python/cpython

Do Not Allow Static Objects to be Deallocated

未關閉
#101,265 6 則留言 2 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

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

描述

The runtime currently has many objects that are statically defined. See Include/internal/pycore_global_objects.h. For the singletons, all instances of the type are statically defined. Otherwise only some instances are.

(affected types)

The following types are those that have only some statically defined instances (not counting deep-frozen objects):

  • int
  • bytes
  • str
  • tuple

Deepfreeze adds the following:

  • float
  • complex
  • slice [actually not added]
  • code
  • (more bytes, int, tuple, & str objects)

The problem is that if tp_dealloc() for one of the affected types tries to free a static object then it will crash. We've set the refcount for such objects to a really high number to avoid this, but it is still possible. The risk rises a bit for immortal objects (see PEP 683).

For all types with static objects, we need to add a check in tp_dealloc() to either fail or reset the refcount to the really high number. We already have a check like this for the singletons and for str. For the other types we need to identify if the object is static and respond accordingly. The catch is that identifying that can be expensive, which is problematic for types that are deallocated frequently.

貢獻指南

開啟貢獻指南

從這裡開始

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

研究方向

從 Include/internal/pycore_global_objects.h 開始,盤點靜態定義的物件,然後檢查受影響型別的 tp_dealloc 實作。確定每個型別如何在不產生不可接受的釋放負擔下識別靜態物件;完成的標準是靜態物件無法被釋放,也不會導致與 refcount 相關的當機。

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

評估

技術堆疊
c, python
領域
backend
Issue 類型
缺陷
難度
5/5
預估耗時
一週以上
活躍度
停滯
描述清晰度
基本清楚
新手友好度
30/100

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

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