gh-140936: Fix JIT assertion crash at finalization if some generator is alive #140969
Conversation
efimov-mikhail
requested review from
ZeroIntensity and
ericsnowcurrently
as code owners
|
Hmm I think this isn't the problem. The problem might be that JUMP_BACKWARD is specialized to JUMP_BACKWARD_JIT. Following that, finalization happens, turning the JIT off. However, some of the JUMP_BACKWARD still remains as JUMP_BACKWARD_JIT. This causes optimizer to be triggered on JUMP_BACKWARD_JIT. The real fix should be to check if |
|
CC @brandtbucher as author of #129194 |
Ok, I've provided this fix. |
|
@efimov-mikhail thanks. Just checking: does it pass the test on your system? I didn't test it but I think it should. |
|
On my system new test passes with this fix and fails without it on debug build. |
Lib/test/test_capi/test_opt.py
Outdated
| tmp = tempfile.NamedTemporaryFile(delete=False, suffix='.py') | ||
| tmp.write(code.encode('utf-8')) | ||
| tmp.close() | ||
| try: | ||
| p = subprocess.Popen([sys.executable, tmp.name], stdout=subprocess.PIPE, stderr=subprocess.STDOUT) | ||
| p.wait() | ||
| out = p.stdout.read() | ||
| finally: | ||
| os.remove(tmp.name) | ||
| p.stdout.close() | ||
| self.assertEqual(b"finished", out) |
There was a problem hiding this comment.
Why not just use assert_python_ok?
There was a problem hiding this comment.
Oh, thanks! Of course, we can use it here. I've provided this change.
3 participants
I've removed setting
interp->jittofalseat finalization.Because in rare case it may be a problem when some optimized code is used after
finalize_modules.New test needs subprocess since we have assertion crash only at the finalization stage.
On release builds there was no real problem, and test passed with this fix and without it.