Repository navigation
Stack overflow collecting PGO data on Windows #113655
Description
Activity
Trying to repro, I can't even manage to complete a PGO build (first step above).
It sounds like you are repro'ing (I probably wasn't clear enough). It fails during the PGO build while running the tests that generate PGO data.
git bisecttells me the first bad commit is: 45e09f9 (which increased the recursion limit, which at least seems related).Ah, you're right, the output similar to yours scrolled off my screen. :-(
You should be able to experiment with some of the numbers changed by the PR to see which one affects the Windows PGO build. The stack limit is definitely an ongoing discussion.
Windows release buildbots are similarly failing: https://buildbot.python.org/all/#/builders/914/builds/3274/steps/4/logs/stdio
So it is crashing in this addition to
test_functools.py:@support.skip_on_s390x @unittest.skipIf(support.is_wasi, "WASI has limited C stack") def test_lru_recursion(self): @self.module.lru_cache def fib(n): if n <= 1: return n return fib(n-1) + fib(n-2) if not support.Py_DEBUG: with support.infinite_recursion(): fib(2500)My conclusion is that the increased default C recursion limit is too large for the platform and we hit a stack overflow. Maybe try setting Py_C_RECURSION_LIMIT to something smaller than 8000? (I am trying now with 4000.)
My conclusion is that the increased default C recursion limit is too large for the platform and we hit a stack overflow. Maybe try setting Py_C_RECURSION_LIMIT to something smaller than 8000? (I am trying now with 4000.)
Yes -- my experimentation arrived at that too. 5,000 is too large, but 4,000 seems to work. See #113668.
Also, this docstring (deleted by that PR) suggests a possible cause:
"""Set a lower limit for tests that interact with infinite recursions (e.g test_ast.ASTHelpers_Test.test_recursion_direct) since on some debug windows builds, due to not enough functions being inlined the stack size might not handle the default recursion limit (1000). See bpo-11105 for details."""Maybe we are running into the inlining problem even in non-debug mode?
60 remaining items
- moved this from Todo to Done in Release and Deferred blockers 🚫
on Feb 19, 2025 Is there a plan to backport the fix to 3.12 and 3.13? Or do we need to keep the resource overallocation in those versions?
I'd prefer to backport. Or at least trim the hardcoded limit to avoid crashing.
- moved this from Done to In Progress in Release and Deferred blockers 🚫
on Feb 19, 2025 The fix uncovered unrelated issues. I don't think backporting it would be appropriate; definitely not for all platforms. It needs the full alpha/beta period.
This has had the full 3.14 alpha/beta period plus RC and half a dozen bugfixes.
Do we want to backport this, close it, or remove
deferred-blocker?I don't remember if the all the issues were resolved (I think it broke some Boost stuff?).
As far as I'm aware, Python 3.12 and 3.13 will forever require 3-4x memory usage because of the temporary patch we put in to keep releasing. Since we've made it this far into their lifespans without major complaint, I guess it's fine to leave them patched that way.
Python 3.12 and 3.13 will forever require 3-4x memory usage
I think only 3.12 is affected, since Revert extra stack reserve (commit 665b8f3) is tagged since v3.13.0a4?
Reacted by Steve DowerRemoving the
deferred-blockerlabel as this hasn't delayed any releases, and 3.12 and 3.13 are both security-fix only with no Windows installers.3.12 and 3.13 are both security-fix only
That means a fix wouldn't be accepted to the remaining affected branches. I'll close.
Bug report
Bug description:
During a PGO build on Windows on main (471aa75), a test in
test_functoolsfails with a stack overflow.Full log of build
CPython versions tested on:
CPython main branch
Operating systems tested on:
Windows
Linked PRs