Type propagation does not account for the setting local variables via frame.f_locals in a debugger or similar.

[markshannon]

Bug report

Bug description:

Consider

def testfunc(loops):
    for _ in range(loops):
        a = 1
        a + a
        a + a
        change_a()
        a + a

and 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.

Linked PRs

• GH-115709: Invalidate executors when a local variable is changed via frame.f_locals #118639

[markshannon]

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_locals

[encukou]

Is this on track for 3.13.0a5 (on 2024-03-12), or should I look into it?

[markshannon]

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_LocalsToFast and PyFrame_FastToLocals, but with PEP 667 it is almost trivial.

[Yhg1s]

Since PEP 667 was accepted, is this on track to be finished before beta 1 (next Tuesday)?

[gvanrossum]

I believe this is fixed now by gh-118639 and definitely no longer blocking the release. Waiting for @markshannon to close it.