GeezerVison is showing github.com — Inconsistencies in error propagation after calling `_PyFrame_GetFrameObject` · Issue #144693 · python/cpython
Inconsistencies in error propagation after calling _PyFrame_GetFrameObject #144693Labels interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error DescriptionBug report
Bug description:
There are 3 callers of _PyFrame_GetFrameObject which explicitly clear error when it returns NULL.
take_ownership
|
PyFrameObject *back = _PyFrame_GetFrameObject(prev); |
|
if (back == NULL) { |
|
/* Memory error here. */ |
|
assert(PyErr_ExceptionMatches(PyExc_MemoryError)); |
|
/* Nothing we can do about it */ |
|
PyErr_Clear(); |
PyEval_GetFrame
|
PyFrameObject *f = _PyFrame_GetFrameObject(frame); |
|
if (f == NULL) { |
|
PyErr_Clear(); |
PyThreadState_GetFrame
|
PyFrameObject *frame = _PyFrame_GetFrameObject(f); |
|
if (frame == NULL) { |
|
PyErr_Clear(); |
PyEval_GetFrame and PyThreadState_GetFrame docs say that NULL is returned when "no frame is currently executing", and doesn't say anything about any error (probably as they explicitly clear it?).
I wonder whether PyFrame_GetBack also would want to clear error
|
if (prev) { |
|
back = _PyFrame_GetFrameObject(prev); |
|
} |
PyFrame_GetBack's documentation doesn't say anything about MemoryError which can be set by its internal API calls https://docs.python.org/3.15/c-api/frame.html#c.PyFrame_GetBack
The rest of the _PyFrame_GetFrameObject callers that don't clear error including PyFrame_GetBack are
And PyEval_GetLocals and PyFrame_GetBack are public C APIs that don't check for NULL and don't clear the error. I guess the internals are ok to propagate the errors?
Can someone explain whether PyFrame_GetBack not clearing error on null is ok/intended or it's a discrepancy/bug?
I would prefer PyFrame_GetBack to not propagate an error given that its documentation doesn't say anything about MemoryError.
CPython versions tested on:
CPython main branch
Operating systems tested on:
No response
Linked PRs
Activitysergey-miryanov commented on Feb 11, 2026 _PyFrame_GetFrameObject is not setting an exception (but preserves it if it exists). PyFrame_GetBack can return NULL and this is handled by frame_back_get_impl, for example. In this case frame.f_back will have None value.
From Python point of view, frame.f_back and PyFrame_GetBack can't be called with exception set.
From C-API point of view, it is responsibility of the user to handle exceptions that can exist before calling a PyFrame_GetBack.
Maybe it is worth to update a documentation that API preserves existing exceptions. sergey-miryanov commented on Feb 11, 2026 It seems that _PyFrame_GetLocals potentially can be called with frame == NULL, maybe it is worth to add checks there.
Would you like open PRs? If so please open two separate PRs, one for documentation update, one for _PyFrame_GetLocals. sergey-miryanov commented on Feb 11, 2026 I believe _gen_getframe, PyEval_GetLocals should have NULL checks or at least asserts.
sys__getframe_impl, _PyThread_CurrentFrames, _Py_call_instrumentation_line should set an exception if _PyFrame_GetFrameObject returns NULL.
_PyEval_ExceptionGroupMatch seems OK.
sergey-miryanov commented on Feb 11, 2026 taegyunkim commented on Feb 11, 2026 ContributorAuthor More actions
Would you like open PRs? If so please open two separate PRs, one for documentation update, one for _PyFrame_GetLocals.
Sure will do shortly encukou commented on Feb 16, 2026
From C-API point of view, it is responsibility of the user to handle exceptions that can exist before calling a PyFrame_GetBack.
Yes, that's the general expectation for public C API functions. The behaviour is undefined if called with an active exception. If preserving the exception isn't documented, it's an implementation detail that can change in future versions.
I'm not sure if the frame experts want to turn it into a documented guarantee.
MetadataMetadatainterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error DevelopmentNo branches or pull requestsIssue actions
|