Improve traceability of assertion errors in common functions
還沒有人認領這個 Issue。
- 主要語言
- Python
- 星號
- 77.2k
- 分支
- 35.9k
- PR 合併指標
- PR 指標待擷取
描述
Feature request
(By @picnizx)
While the C API docs explicitly state that functions should usually not be called with an exception set, else some assertion errors may occur and/or the thread state may be invalid, this means that assert(!PyErr_Occurred()) in common macros / functions such as _PyType_LookupRef would just crash. However, in a CI scenario, without a debugger, it's extremely hard to pinpoint the actual cause.
Related: https://github.com/python/cpython/pull/128159 would give the possibility to show the C stack trace with -X faulthandler.
A crude idea: add assert(!PyErr_Occurred()) inside public common C API functions to be sure that the assertion is checked as well, making debugging a bit easier.
Toy Scenario (original request):
I was working on freethread support for pygame-ce, and I finally need to use a python build with debug symbols, and our atexit-registered quit function was causing SIGABRT to be thrown. This took me a while to figure out. Here's all the code you need to run (or just run python -c "import pygame" since pygame.quit() is atexit-registered).
import pygame
pygame.quit()
Here's the guilty block of code in our codebase:
funcobj = PyObject_GetAttrString(module, "_internal_mod_quit");
/* If we could not load _internal_mod_quit, load quit function */
if (!funcobj)
funcobj = PyObject_GetAttrString(module, "quit");
/* Silence errors */
if (PyErr_Occurred())
PyErr_Clear();
In the 3.12 docs for PyObject_GetAttrString and PyObject_GetAttr. there's no mention at all that there shouldn't be any exceptions set before calling this function, and it works on release versions of python, so nobody has ever questioned this structure. I'll be making a pull request on our end to clear any exceptions between the first call and second call if needed (or use PyObject_GetOptionalAttrString in 3.13+).
The reason for this issue is that I'm not sure throwing a SIGABRT is the best option here.
gdb backtrace on a debug python 3.13t
[gdb.txt](https://github.com/user-attachments/files/18922524/gdb.txt)
CPython versions tested on:
3.12, 3.13, 3.14
Operating systems tested on:
Linux
貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
研究方向
首先檢視圍繞 PyObject_GetAttrString、PyObject_GetAttr、PyErr_Occurred 和 _PyType_LookupRef 的 C API 行為,以及相關的 faulthandler pull request。將文件中記載的前置條件與 pygame 情境中顯示的判斷失敗進行比較。當已確立一個經協議的方案,以改善判斷的可追蹤性及其預期行為時,即視為完成。
由索引模型根據 Issue 內容生成。
評估
- 技術堆疊
- c, python
- 領域
- api
- Issue 類型
- 功能
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 活躍度
- 停滯
- 描述清晰度
- 基本清楚
- 新手友好度
- 45/100