David Bolen <db3l....@gmail.com> added the comment:
Steve, where is that configured? If reducing that further would resolve the crashes while retaining ceval debugging, maybe that's a reasonable trade-off, though based on my testing, reverting still seems simpler. Right now the debug build on the buildbot appears use the standard recursion limit of 1000, and some quick grep-fu didn't find a clear spot (either internally or just for the tests) where it would be reduced. Could perhaps how it's done be something that doesn't influence buildbot builds? The failing tests do all appear to be recursion tests of one form or another. Based on further testing, we'd need to have a recursion limit of 290 or below to get most of the test suite to pass. Presumably something like 250 for a bit of head room. However, lowering the limit appears to cover only most of the failures, not all. Some tests directly play with the limits (like test_exceptions.test_recursion_in_except_handler and test_sys.test_recursionlimit_recovery) and still get into trouble, aborting the process, no matter how low the default recursion limit is. so those tests also need changes to pass. In addition, lowering to 290 created one new failure - test_compile.test_extended_arg now fails with a recursion error. It seems to need a limit of about 900 to pass; I guess the test could temporarily reset or something but that seems especially kludgy. Out of curiousity, are these these failures not occurring elsewhere? It seems like something that would be happening in general (at least for anyone compiling debug builds). I thought of checking CI builds, but they appear to use release mode, so would be unaffected. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue43271> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
