Message357350
Thus far these are the failures we've seen:
* not running when we expect it to be running:
* interpreters.is_running(interp)
* interpreters.run_string(interp, ...)
* interpreters.destroy(interp)
* can't find the interpreter even though we expect it to exist
* interpreters.run_string(interp, ...)
* finds it running when we expect it to not be running
* interpreters.run_string(interp, ...)
Except for the last one (which might be a separate issue), they all look like they could be explained by the same thing: the subinterpreter stopped (or went away) prematurely. That could be related to the code in _xxsubinterpretersmodule.c or it could be the cleanup code that makes sure interpreters get cleaned up at the end of tests (e.g. running too soon). Either way I expect the fix will be in the module code and not the tests.
Regarding "is_running()", notice that it relies almost entirely on "frame->f_executing". That might not be enough (or maybe the behavior there changed). That would be worth checking out.
@aeros, feel free too keep investigating. I'd be glad to help you out. Otherwise I'll dive into this probably next week. |
|
Date |
User |
Action |
Args |
2019-11-23 00:30:36 | eric.snow | set | recipients:
+ eric.snow, vstinner, aeros |
2019-11-23 00:30:36 | eric.snow | set | messageid: <1574469036.15.0.121608665969.issue37224@roundup.psfhosted.org> |
2019-11-23 00:30:36 | eric.snow | link | issue37224 messages |
2019-11-23 00:30:35 | eric.snow | create | |
|