Repository navigation
JIT global-to-constant promotion doesn't properly validate the globals dictionary at runtime #136154
Description
Bug report
This code raises a NameError with the JIT disabled, and succeeds with the JIT enabled:
import types
GLOBAL = 42
def make_f():
def f():
return GLOBAL
return f
make_f_with_bad_globals = types.FunctionType(make_f.__code__, {})
def jitted(funcs):
for func in funcs:
func()
def main():
# Make a "good" f:
f = make_f()
# Compile jitted for the "good" f:
jitted([f] * 4096)
# This "bad" f has different globals, but the *same* code/function versions:
f_with_bad_globals = make_f_with_bad_globals()
# A "good" f to enter the JIT code, and a "bad" f to trigger the bug:
jitted([f, f_with_bad_globals])
main()We're relying on the function version to guarantee the correct globals. Functions that are created from the same code object share the same function version, but don't necessarily share the same globals.
The fix is probably to insert runtime checks for the identity of the globals dictionary (instead of the function version) in remove_globals. An identity check is safe, since if the original globals dict is deallocated then the trace will be invalidated anyways.
Activity
Zheaoli commentedon Jul 4, 2025
I'm a little bit confuse why happend in JIT disabled(
Zheaoli commentedon Jul 8, 2025
OK, I think I got the case here. We make a special func share with the original function. but the scope/object is totally different.
Make sense here. But I think maybe we need a benchmark here. The identity check may get extra overhead?(nor sure for now.
Do you have a plan to do this? I would like to take a try if this is not in your plan. (X
markshannon commentedon Jul 19, 2025
Also, see #117086 which is closely related
Add test for python#136154
markshannon commentedon Sep 18, 2025
I don't think it is worth backporting the fix to 3.14 or 3.13. It is quite intrusive and the JIT is experimental in those versions.