Kyle Stanley <aeros...@gmail.com> added the comment:
> Sorry I haven't gotten back to you sooner, Kyle. Thanks for working on this. > I'm looking at your PR right now. > BTW, Kyle, your problem-solving approach on this is on-track. Don't get > discouraged. This stuff is tricky. :) No problem at all, and thank you for the words of encouragement. (: > 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. Hmm, that's an interesting point that I hadn't considered. > @aeros, feel free too keep investigating. I'd be glad to help you out. > Otherwise I'll dive into this probably next week. Sounds good, I'll do some further digging around, particularly anywhere that interacts with PyFrameObject's `f_executing` field. I think it's possible that there's a non-obvious issue with `_is_running()`, where it works correctly 99% of the time. That seems to be a significant commonality between the different areas where the intermittent failures are occurring, they all directly or indirectly call `_is_running()`. Also, thanks again Eric for the PR review. Looking back it after Eric's analysis and having a couple of months to think it over, I don't think that GH-16293 is the correct solution. It seems unlikely that this is being caused by a lack of proper GIL acquisition, as that would likely be causing far more consistent build failures. I'm thinking that it's more likely to be an issue with either: 1) Subinterpreters occasionally disappearing due to premature cleanup (as Eric suggested) 2) _is_running() being incorrect a small percentage of the time ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue37224> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
