Skip to content
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

bpo-34602: Avoid failures setting macOS stack resource limit #14546

Merged
merged 1 commit into from Jul 2, 2019

Conversation

@ned-deily
Copy link
Member

ned-deily commented Jul 2, 2019

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. See the discussion on the bug tracker for
more details.

https://bugs.python.org/issue34602

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.
@ned-deily ned-deily merged commit 5bbbc73 into python:master Jul 2, 2019
4 of 5 checks passed
4 of 5 checks passed
Azure Pipelines PR in progress
Details
bedevere/issue-number Issue number 34602 found
Details
bedevere/news News entry found in Misc/NEWS.d
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@miss-islington

This comment has been minimized.

Copy link

miss-islington commented Jul 2, 2019

Thanks @ned-deily for the PR 🌮🎉.. I'm working now to backport this PR to: 3.6, 3.7, 3.8.
🐍🍒🤖

@ned-deily ned-deily deleted the ned-deily:bpo-34602_take2_master branch Jul 2, 2019
@bedevere-bot

This comment has been minimized.

Copy link

bedevere-bot commented Jul 2, 2019

GH-14547 is a backport of this pull request to the 3.8 branch.

miss-islington added a commit to miss-islington/cpython that referenced this pull request Jul 2, 2019
…H-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.
(cherry picked from commit 5bbbc73)

Co-authored-by: Ned Deily <nad@python.org>
@bedevere-bot

This comment has been minimized.

Copy link

bedevere-bot commented Jul 2, 2019

GH-14548 is a backport of this pull request to the 3.7 branch.

miss-islington added a commit to miss-islington/cpython that referenced this pull request Jul 2, 2019
…H-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.
(cherry picked from commit 5bbbc73)

Co-authored-by: Ned Deily <nad@python.org>
@bedevere-bot

This comment has been minimized.

Copy link

bedevere-bot commented Jul 2, 2019

GH-14549 is a backport of this pull request to the 3.6 branch.

miss-islington added a commit to miss-islington/cpython that referenced this pull request Jul 2, 2019
…H-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.
(cherry picked from commit 5bbbc73)

Co-authored-by: Ned Deily <nad@python.org>
miss-islington added a commit that referenced this pull request Jul 2, 2019
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.
(cherry picked from commit 5bbbc73)

Co-authored-by: Ned Deily <nad@python.org>
miss-islington added a commit that referenced this pull request Jul 2, 2019
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.
(cherry picked from commit 5bbbc73)

Co-authored-by: Ned Deily <nad@python.org>
ned-deily added a commit to ned-deily/cpython that referenced this pull request Jul 2, 2019
…H-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.
(cherry picked from commit 5bbbc73)

Co-authored-by: Ned Deily <nad@python.org>
ned-deily added a commit that referenced this pull request Jul 2, 2019
… (GH-14549)

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.
(cherry picked from commit 5bbbc73)

Co-authored-by: Ned Deily <nad@python.org>
LorenzMende added a commit to LorenzMende/cpython that referenced this pull request Aug 11, 2019
…H-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.
lisroach added a commit to lisroach/cpython that referenced this pull request Sep 10, 2019
…H-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.
DinoV added a commit to DinoV/cpython that referenced this pull request Jan 14, 2020
…H-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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.