-
-
Notifications
You must be signed in to change notification settings - Fork 30.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GH-107263: Increase C stack limit for most functions, except _PyEval_EvalFrameDefault()
#107535
GH-107263: Increase C stack limit for most functions, except _PyEval_EvalFrameDefault()
#107535
Conversation
…and compiler mutliply to 2.
With From this, it seems that the estimate of |
The new C recursion limit is used the same way as the old (generic) recursion limit, which defaulted to 1000, right? Or are there things that use the C recursion limit that now count recursion differently? 2000 doesn't sound unreasonable, but if Python's own tests overrun the stack at 2400, maybe it's better to put it closer to the old limit to avoid causing problems with large stack frames in user (C) code. |
Misc/NEWS.d/next/Core and Builtins/2023-07-30-05-20-16.gh-issue-107263.q0IU2M.rst
Outdated
Show resolved
Hide resolved
I had thought that a limit of 2000 and A limit of 1500, counting |
🤖 New build scheduled with the buildbot fleet by @markshannon for commit a8c72d0 🤖 If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
@@ -222,7 +222,8 @@ struct _ts { | |||
# ifdef __wasi__ | |||
# define C_RECURSION_LIMIT 500 | |||
# else | |||
# define C_RECURSION_LIMIT 800 | |||
// This value is duplicated in Lib/test/support/__init__.py | |||
# define C_RECURSION_LIMIT 1500 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the WASI conditional will have to be duplicated in test.support as well, for the WASI ast recursion test (https://buildbot.python.org/all/#/builders/1061/builds/526).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already skip a few tests for WASI due to the limited stack use, so I'll just add another skip.
We can remove all of those for 3.13.
!buildbot s390 |
🤖 New build scheduled with the buildbot fleet by @markshannon for commit 0e8c992 🤖 The command will test the builders whose names match following regular expression: The builders matched are:
|
I think all the buildbot failures are pre-existing ones (some of which have already been fixed in main), so is this good to check in? |
Yes. |
Thanks @markshannon for the PR 🌮🎉.. I'm working now to backport this PR to: 3.12. |
GH-107618 is a backport of this pull request to the 3.12 branch. |
…PyEval_EvalFrameDefault()` (pythonGH-107535) * Set C recursion limit to 1500, set cost of eval loop to 2 frames, and compiler mutliply to 2. (cherry picked from commit fa45958) Co-authored-by: Mark Shannon <mark@hotpy.org>
…_PyEval_EvalFrameDefault()` (GH-107535) (#107618) GH-107263: Increase C stack limit for most functions, except `_PyEval_EvalFrameDefault()` (GH-107535) * Set C recursion limit to 1500, set cost of eval loop to 2 frames, and compiler mutliply to 2. (cherry picked from commit fa45958) Co-authored-by: Mark Shannon <mark@hotpy.org>
# condition. Windows doesn't have os.uname() but it doesn't support s390x. | ||
skip_on_s390x = unittest.skipIf(hasattr(os, 'uname') and os.uname().machine == 's390x', | ||
'skipped on s390x') | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For reference: this moved skip_on_s390x
away from its comment. #125041 fixes that.
This should fix almost all cases of the new C recursion limit preventing code that worked for 3.11 working for 3.12.
The original recursion limit of 1000 was to protect the C stack and to provide a meaningful error in case of runaway recursion.
Since calls to Python functions no longer consume C stack, protection of the C stack is independent of the depth of the Python stack. So we decoupled the two operations. The default Python recursion limit is unchanged at 1000 and can be modified by
sys.setrecursionlimit()
. However, the C recursion limit is set to 800, as the limit of 1000 was too large for some platforms, especially debug builds.Historically it has been
_PyEval_EvalFrameDefault()
that consumes the most stack space, so that sets the (quite low) limit of 800 for C recursion.We can allow deeper recursion of C code and preserve safety by increasing the C recursion counting a call to
_PyEval_EvalFrameDefault()
as several normal calls.This PR raises the C recursion limit from 800 to
25001500 and counts each call to_PyEval_EvalFrameDefault()
asthreetwo normal calls.If this is deemed insufficient, we could expose the means to modify the C recursion limit, but that might be too large a change for 3.12.
@Yhg1s
@gpshead