gh-94438: in frameobject's mark_stacks switch, the PUSH_EXC_INFO and POP_EXCEPT cases...

diff --git a/Objects/frameobject.c b/Objects/frameobject.c
index 34a6c46c6b57f2a70e986aaaa68523f6f977d6f5..6f4de65cc7c0d0f77b572b8ea58825c8f6681fd8 100644 (file)
--- a/Objects/frameobject.c
+++ b/Objects/frameobject.c
@@ -256,10 +256,6 @@ mark_stacks(PyCodeObject *code_obj, int len)
                     stacks[i+1] = next_stack;
                     break;
                 }
-                case POP_EXCEPT:
-                    next_stack = pop_value(pop_value(pop_value(next_stack)));
-                    stacks[i+1] = next_stack;
-                    break;
                 case SEND:
                     j = get_arg(code, i) + i + 1;
                     assert(j < len);
@@ -304,10 +300,16 @@ mark_stacks(PyCodeObject *code_obj, int len)
                     stacks[i+1] = next_stack;
                     break;
                 case PUSH_EXC_INFO:
-                    next_stack = push_value(next_stack, Except);
-                    next_stack = push_value(next_stack, Except);
-                    next_stack = push_value(next_stack, Except);
-                    stacks[i+1] = next_stack;
+                case POP_EXCEPT:
+                    /* These instructions only appear in exception handlers, which
+                     * skip this switch ever since the move to zero-cost exceptions
+                     * (their stack remains UNINITIALIZED because nothing sets it).
+                     *
+                     * Note that explain_incompatible_stack interprets an
+                     * UNINITIALIZED stack as belonging to an exception handler.
+                     */
+                    Py_UNREACHABLE();
+                    break;
                 case RETURN_VALUE:
                 case RAISE_VARARGS:
                 case RERAISE: