> So we should keep an eye open for reports of segfaults running tests as originally reported in Issue18075.

Now there are such reports for 3.7.4rc1, at least. Release builds seem to be OK but at least four tests now fail on macOS 10.14.5 when built --with-pydebug: test_exceptions test_json test_logging test_sys test_traceback.  Plus, changing the interpreters stack size can inhibit use of dtrace.

There are really two attempts at dealing with macOS's small default stack size.  The original workaround, dating back to 2002-12-02 (bb48465273d2aa98fc7669e99b0d5fb1c57962de !!) added the runtime calls in regrtest to change RLIMIT_STACK. Years later, a different approach was taken in the original change for Issue18075 (335ab5b66f432ae3713840ed2403a11c368f5406) by increasing the default stack size when building the interpreter rather than at runtime.  So, I *think* that means that the original regrtest runtime workaround is really no longer needed.  So I think we should take the opposite approach to what I originally merged back in April, that is, we should go back to building the interpreter with the increased stack size and remove the ancient regrtest workaround attempt: that's what was failing here anyway.  The only place in the source base that resource.RLIMIT_STACK is used, outside of its functional test, is the old regrtest workaround.  It's still a bit of a mystery as what has changed in 3.8 that seems to not hit the stack size limit but these kind of test failures on macOS have always been dependent on other factors, including compiler version and options.  I'd like to get this into 3.8.0b2 and 3.7.4rc2 ao I'm temporarily making it a "release blocker"; the PR will follow momentarily.