Repository navigation
Type propagation does not account for the setting local variables via frame.f_locals in a debugger or similar. #115709
Description
Bug report
Bug description:
Consider
def testfunc(loops):
for _ in range(loops):
a = 1
a + a
a + a
change_a()
a + aand suppose that change_a manages to change the value of the local a to "a".
Specialization will have converted the subsequent a + a to integer addition, and type propagation will have stripped the guard, resulting in a crash.
This is incredibly unlikely, and very hard to come up with a test for but it is theoretically possible.
It may be become more likely (and easier to test for) if PEP 667 is accepted.
Activity
markshannon commentedon Feb 20, 2024
The fix is relatively straightforward:
Invalidate all executors depending on a code object should any locals associated with that code object get changed via
frame.f_localsencukou commentedon Feb 27, 2024
Is this on track for 3.13.0a5 (on 2024-03-12), or should I look into it?
markshannon commentedon Feb 27, 2024
It's on track for the release, but probably not for 3.13.0a5.
The fix will be easier with PEP 667, so I'm waiting to see if that is accepted first.
Identifying if a local variable has changed is currently awkward with
PyFrame_LocalsToFastandPyFrame_FastToLocals, but with PEP 667 it is almost trivial.Yhg1s commentedon May 5, 2024
Since PEP 667 was accepted, is this on track to be finished before beta 1 (next Tuesday)?
GH-115709: Invalidate executors when a local variable is changed via …
gvanrossum commentedon May 7, 2024
I believe this is fixed now by gh-118639 and definitely no longer blocking the release. Waiting for @markshannon to close it.
pythonGH-115709: Invalidate executors when a local variable is change…