Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 35.2k
JIT error stubs don't account for peeks #126222
Copy link
Copy link
Closed
Labels
3.13bugs and security fixesbugs and security fixes3.14bugs and security fixesbugs and security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)topic-JITtype-crashA hard crash of the interpreter, possibly with a core dumpA hard crash of the interpreter, possibly with a core dump
Description
Metadata
Metadata
Assignees
Labels
3.13bugs and security fixesbugs and security fixes3.14bugs and security fixesbugs and security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)topic-JITtype-crashA hard crash of the interpreter, possibly with a core dumpA hard crash of the interpreter, possibly with a core dump
Crash report
When deciding how many stack items to pop in an
_ERROR_POP_Nstub, we use_PyUop_num_popped. However, for opcodes with "peeked" items that never get popped, this is incorrect.For example, consider
SET_ADD(2). It has three inputs and two outputs. However, both of the bottom inputs are the same as the outputs, and are never really popped. When compiling an error stub for the JIT, using_PyUop_num_poppedwill create_ERROR_POP_N(3), which leaks both references and shrinks the stack too far:The compiled trace for the comprehension is:
@markshannon, does this make sense to generate new tables for in the cases generator? Not sure what the best option is.
Linked PRs
_PyUop_num_popped#126507