gh-79932: raise exception if frame.clear() is called on a suspended frame

[iritkatriel]

Fixes#79932.

• Issue: traceback.clear_frames manages to deadlock a background task #79932

---

📚 Documentation preview 📚: https://cpython-previews--111792.org.readthedocs.build/

[gvanrossum]

There is already a perfectly general mechanism to turn selected warnings into exceptions, using the warnings module and/or the -W flag. Why do we need a specific flag argument here to accomplish the same thing?

[iritkatriel]

I need to turn it into an exception in a particular call (always). -W wouldn't work for that. Maybe I can use the warnings module locally though?

[gvanrossum]

What’s the use case for this need? Testing? Or something else?

[iritkatriel]

The reported bug was about traceback.clear_frames, which is called from unittest and can cause the program to freeze.

[iritkatriel]

Another option is to expose the frame state to python, so that the caller can avoid calling clear on a suspended frame.

[gvanrossum]

Another option is to expose the frame state to python, so that the caller can avoid calling clear on a suspended frame.

Yeah, given that we have an API here to manipulate the frame, and a reason for not using that API when the frame is suspended, it makes sense to allow the caller to detect the frame is in that state. At least that feels better than having a custom flag to turn the warning into an error.

But: I'm not sure this requires deprecation even. It's just a bug, right? frame_clear() looks like it is intended to clear the locals only after the frame has exited -- if it's still running, we don't want to interfere with it. But a suspended frame, in this context, should be seen as not having exited. The actual state check is just wrong, it incorrectly categorizes "suspended" together with "exited" instead of "running". Since the function is already expected to raise RuntimeError, I don't see why we need to tread so lightly around fixing this (to me) obvious bug.

[iritkatriel]

That was my initial plan, but a couple of test failed. I can just change the tests.

[gvanrossum]

That was my initial plan, but a couple of test failed. I can just change the tests.

Most likely those tests were mindlessly testing that the code did what it did, rather than what it should do.

[gvanrossum]

Thanks, now it makes sense to me.

[gvanrossum]

Is it worth backporting?

[iritkatriel]

I think there are situations where you clear a suspended frame, it closes the generator, and there's no problem because you don't try to use it anymore. Backporting this could break that.

[gvanrossum]

Is that really a feature? Then we need to change what we did here?

[iritkatriel]

I wouldn't go as far as calling it a feature. It's possible that sometimes this bug is not causing an actual problem, and it will if we raise exceptions.

[gvanrossum]

Okay, that's fair. So in 3.13 it will raise, but in 3.12 it might work, or it might cause a deadlock like in the original report. And we recommend that the OP fix their code to stop doing this.