-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
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-91079: Decouple C stack overflow checks from Python recursion checks. #96510
Conversation
markshannon
commented
Sep 2, 2022
•
edited by bedevere-bot
Loading
edited by bedevere-bot
- Issue: Implement stack overflow protection for supported platforms #91079
🤖 New build scheduled with the buildbot fleet by @markshannon for commit e8a1bed 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
🤖 New build scheduled with the buildbot fleet by @markshannon for commit 7e21a74 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
🤖 New build scheduled with the buildbot fleet by @markshannon for commit 65cca7d 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
🤖 New build scheduled with the buildbot fleet by @markshannon for commit d75797c 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
# 1,000 on most systems | ||
limit = sys.getrecursionlimit() | ||
code = "lambda: " + "+".join(f"_number_{i}" for i in range(limit)) | ||
# Need more than 256 variables to use EXTENDED_ARGS |
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.
I assume EXTENDED_ARGS has stack implications? explaining the "why" of this here would be useful.
Lib/test/test_exceptions.py
Outdated
# and is equal to recursion_limit when _gen_throw() calls | ||
# PyErr_NormalizeException(). | ||
recurse(setrecursionlimit(depth + 2) - depth) | ||
recurse(5000) |
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.
There's a constant of 5000
used in all sorts of tests for the same purpose of being "too high" for recursion with this PR. I suggest making this a named test.support
constant and referring to it instead of mystery constants spread throughout the test suite.
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.
(and where other constants are derived from that to be higher or lower scale, use math from the main value?)
Include/cpython/pystate.h
Outdated
/* WASI has limited call stack. Python's recursion limit depends on code | ||
layout, optimization, and WASI runtime. Wasmtime can handle about 700 | ||
recursions, sometimes less. 500 is a more conservative limit. */ | ||
#ifndef Py_DEFAULT_RECURSION_LIMIT |
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.
ifndef C_RECURSION_LIMIT
Include/internal/pycore_ceval.h
Outdated
# define Py_DEFAULT_RECURSION_LIMIT 1000 | ||
# endif | ||
#endif | ||
#define Py_DEFAULT_RECURSION_LIMIT 1000 |
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.
keep the ifndef around this, those exist to allow someone setting their own via CFLAGS.
63f55aa
to
d1abed5
Compare
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.
this tied in nicely with the 3.11 talk :)
This broke compilation of /~https://github.com/python-greenlet/greenlet/
Doing the renames as suggested by the compiler fixes it (although from reading the PR here, maybe Is this an unintended side effect of this change and or does greenlets need to adapt? |
Not being familiar with greenlet much I suspect it wants |
BTW @tacaswell major kudos to you for testing against CPython |
Thanks, I'll get a PR to greenlet done in the next few days (I am also barely familiar with greenlet but it is a dependency of a dependency of something I care about). I have built a whole rube-goldberg machine to test CPython |
E.g. the very basic, really CS101, recursion speedup with cache # fib.py
import sys
sys.setrecursionlimit(2000)
from functools import cache
@cache
def fib(n):
if n<1: return 0
if n==1: return 1
return fib(n-1) + fib(n-2)
print(fib(500)) got broken by this PR. Perhaps needless to say, on the latest main branch, --- a/Include/cpython/pystate.h
+++ b/Include/cpython/pystate.h
@@ -225,7 +225,7 @@ struct _ts {
# define Py_C_RECURSION_LIMIT 500
#else
// This value is duplicated in Lib/test/support/__init__.py
-# define Py_C_RECURSION_LIMIT 1500
+# define Py_C_RECURSION_LIMIT 3000
#endif makes it work (I didn't try to find the minimal needed increase for
|
Please stop using this long merged and closed PR as a forum, nobody liatens here. This is not an issue tracker. If you believe there is a bug, file a new issue. |
These are filed. I also don't understand why this was merged, while not conforming to python/steering-council#102 (they asked for |
On Python 3.12, this provokes a stack overflow in the scheduler. It is not quite clear why that's the case; pure-Python recursion even with generators seems to respond well to setrecursionlimit(): ```py def f(n): if n: yield from f(n-1) else: yield 5 import sys sys.setrecursionlimit(3500) print(list(f(3400))) ``` That said, there have been [behavior](python/cpython#96510) [changes](python/cpython#112215) in Py3.12 in this regard, but it is not clear what exactly about Loopy's behavior makes it fall into the 'bad' case.
On Python 3.12, this provokes a stack overflow in the scheduler. It is not quite clear why that's the case; pure-Python recursion even with generators seems to respond well to setrecursionlimit(): ```py def f(n): if n: yield from f(n-1) else: yield 5 import sys sys.setrecursionlimit(3500) print(list(f(3400))) ``` That said, there have been [behavior](python/cpython#96510) [changes](python/cpython#112215) in Py3.12 in this regard, but it is not clear what exactly about Loopy's behavior makes it fall into the 'bad' case.
On Python 3.12, this provokes a stack overflow in the scheduler. It is not quite clear why that's the case; pure-Python recursion even with generators seems to respond well to setrecursionlimit(): ```py def f(n): if n: yield from f(n-1) else: yield 5 import sys sys.setrecursionlimit(3500) print(list(f(3400))) ``` That said, there have been [behavior](python/cpython#96510) [changes](python/cpython#112215) in Py3.12 in this regard, but it is not clear what exactly about Loopy's behavior makes it fall into the 'bad' case.