Repository navigation
BINARY_OP_SUBSCR_GETITEM constituent uops are invalid #140277
Description
Bug report
Bug description:
The current JIT doesn't expose this bug as it doesn't project calls through BINARY_OP_SUBSCR_GETITEM. However, the problem is that the uop puts 3 things on the stack:
op(_BINARY_OP_SUBSCR_CHECK_FUNC, (container, unused -- container, unused, getitem)) {
However, BINARY_OP is only expected to have at most 2 items on the stack.
On my branch with recording the BINARY_OP_CHECK_FUNC, this causes a segfault due to stack overflow.
We should really re-add the code that calculates the maximum stack size from constituent uops. This is also blocking work on decref elimination in the JIT.
Example repro on my branch with trace recording:
class Get:
def __getitem__(self, i):
return i
g = Get()
def foo():
for _ in range(4099):
g[1]
foo()
@mpage (as author of the original PR to sum up uop stack effect) @markshannon
CPython versions tested on:
CPython main branch
Operating systems tested on:
No response
Activity
markshannon commentedon Oct 19, 2025
We should be rejecting this pattern in the code generator. Even we add some headroom to the stack, the code generator should check that the code is within the headroom.
As for adding headroom, both for this case and for decref elimination, maybe we should just merge #135465
gh-139109: A new tracing JIT compiler frontend for CPython (GH-140310)
pythongh-139109: A new tracing JIT compiler frontend for CPython (pyt…
markshannon commentedon Dec 19, 2025
We now have TOS caching, so
BINARY_OP_SUBSCR_GETITEMis fine.