gh-111798: Use lower Py_C_RECURSION_LIMIT in debug mode #112124
Conversation
884e823 to
fa13914
Compare
|
@hroncok: I'm working on a fix for test_call.test_super_deep(). Once GitHub Action jobs validate this PR, I plan to test it on WASI on s390x buildbots. |
|
!buildbot s390x |
|
🤖 New build scheduled with the buildbot fleet by @vstinner for commit 5e343d7 🤖 The command will test the builders whose names match following regular expression: The builders matched are:
|
|
!buildbot wasm32 |
|
🤖 New build scheduled with the buildbot fleet by @vstinner for commit 5e343d7 🤖 The command will test the builders whose names match following regular expression: The builders matched are:
|
FYI all the WASI buildbots are non-pydebug builds, so this won't validate it fixes that scenario (I have been doing that manually so that once things work I can switch the WASI buildbot over to doing pydebug builds). I had to get |
I wrote this PR to fix the test_call crash on Linux when Python is built with This change should not impact WASI, since it sets Py_C_RECURSION_LIMIT to 500 in debug mode. Before, Py_C_RECURSION_LIMIT was always set to 500 on WASI. Same this constant value is not changed by my PR on WASI. I suppose that a following change is needed to adjust limits for WASI built in debug mode. |
|
Mmmh. Builders have a long queue of jobs but do nothing:
I restarted to the buildbot server. It seems like it was blocked. By the way, when I stopped it, it said that it was "already shutting down" which remains me a Twisted/Buildbot bug. Sometimes, when I tried to stop the server, it moves to a broken state where it still runs but does nothing, and it doesn't stop. |
|
Not good: test_call fails on s390x RHEL7 LTO PR on s390x RHEL7 LTO PR buildbots :-( There are also many buildbots which fail for unrelated reasons, like Git clone failure, disk full, known build failure, known test failures, etc. Not sure why buildbot |
Oh, s390x RHEL7 LTO + PGO PR builds Python in release mode ("release LTO+PGO") and s390x RHEL7 LTO PR is also built in release mode ("release LTO"). This change only affects Python built in debug mode if the Py_DEBUG macro is defined. |
* Run again test_ast_recursion_limit() on WASI platform. * Add _testinternalcapi.get_c_recursion_remaining(). * Fix test_ast and test_sys_settrace: test_ast_recursion_limit() and test_trace_unpack_long_sequence() now adjust the maximum recursion depth depending on the the remaining C recursion.
5e343d7 to
c98644b
Compare
|
I don't have the bandwidth to investigate the s390x failure right now, so I just kept the s390x skip for now sadly. |
…#112124) * Run again test_ast_recursion_limit() on WASI platform. * Add _testinternalcapi.get_c_recursion_remaining(). * Fix test_ast and test_sys_settrace: test_ast_recursion_limit() and test_trace_unpack_long_sequence() now adjust the maximum recursion depth depending on the the remaining C recursion.
…#112124) * Run again test_ast_recursion_limit() on WASI platform. * Add _testinternalcapi.get_c_recursion_remaining(). * Fix test_ast and test_sys_settrace: test_ast_recursion_limit() and test_trace_unpack_long_sequence() now adjust the maximum recursion depth depending on the the remaining C recursion.
Reenable test_call.test_super_deep() on the s390x architecture.
test_super_deep()fortest_calltriggers a stack overflow protection under a debug build for WASI #111798