diff options
author | Ned Deily <nad@python.org> | 2019-07-02 07:12:18 (GMT) |
---|---|---|
committer | GitHub <noreply@github.com> | 2019-07-02 07:12:18 (GMT) |
commit | 5bbbc733e6cc0804f19b071944af8d4719e26ae6 (patch) | |
tree | 2951928176f131ca7b67f947ef77f1ed9c78b222 /Objects/call.c | |
parent | 2cd07920bb7d2d319999394092190f37935dc421 (diff) | |
download | cpython-5bbbc733e6cc0804f19b071944af8d4719e26ae6.zip cpython-5bbbc733e6cc0804f19b071944af8d4719e26ae6.tar.gz cpython-5bbbc733e6cc0804f19b071944af8d4719e26ae6.tar.bz2 |
bpo-34602: Avoid failures setting macOS stack resource limit (GH-14546)
Under some conditions the earlier fix for bpo-18075, "Infinite recursion
tests triggering a segfault on Mac OS X", now causes failures on macOS
when attempting to change stack limit with resource.setrlimit
resource.RLIMIT_STACK, like regrtest does when running the test suite.
The reverted change had specified a non-default stack size when linking
the python executable on macOS. As of macOS 10.14.4, the previous
code causes a hard failure when running tests, although similar
failures had been seen under some conditions under some earlier
systems. Reverting the change to the interpreter stack size at link
time helped for release builds but caused some tests to fail when
built --with-pydebug. Try the opposite approach: continue to build
the interpreter with an increased stack size on macOS and remove
the failing setrlimit call in regrtest initialization. This will
definitely avoid the resource.RLIMIT_STACK error and should have
no, or fewer, side effects.
Diffstat (limited to 'Objects/call.c')
0 files changed, 0 insertions, 0 deletions