-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
RangeError: Maximum call stack size exceeded #9283
Comments
This error message is typically caused by a bug in pyright's logic that leads to infinite recursion. In this case, it's not infinite recursion but rather very deep recursion that occurs when analyzing code with a very long chain of dependent function calls. In particular, the problem occurs when pyright attempts to infer the return type for the I don't recall ever seeing this limit reached before. I'll need to think about whether there are ways to detect and mitigate the problem before it results in a crash. I suspect the reason that we haven't seen this before is that code typically isn't written with "unrolled" function calls in this manner. More typically, this would be done with a loop that acts upon some iterable data structure. |
After further investigation, I don't see a great solution here. There's no good way for pyright's logic to detect this case prior to the crash. It would involve manually tracking the call depth during analysis or use introspection routines to determine the depth of the stack. And even if this condition could be detected in a reasonable way, there's no good way to handle the condition. It would result in inconsistent and nondeterministic type evaluation behaviors, which we try to avoid. It would allow us to give the user a more meaningful error message, but it wouldn't solve the problem they're encountering. I don't see a way to detect this situation in the binder, where we currently detect functions with high cyclomatic complexity. This condition doesn't involve cycles or complex code flow graphs, so we can't use the trick where we refrain from performing code flow analysis on complex functions. This condition can be detected only at code flow analysis time. Each stacked call to One solution is to increase node's max stack size. If I double the default from 1MB to 2MB, this crash no longer occurs. It is still theoretically possible to create a source file that exhausts the stack, but it makes this condition less likely. This solution consumes an additional 1MB of memory for all pyright and pylance users, so we'd need to decide whether that's a good tradeoff. @debonte, @rchiodo, are you seeing signal from pylance telemetry that this is a common source of crashes? What do you think about increasing the default stack size? I can easily make this change in the pyright language client (in the |
Hello!
I am getting a
Maximum call stack size exceeded
when using rather a simple script withxlsxwriter
.Here is reproducible minimal example (
callstack-error.py
)Running
pyright callstack-error.py
in terminal yieldsAn internal error occurred while type checking file "[...]/callstack-error.py": RangeError: Maximum call stack size exceeded
.I am running Python v3.12.7 under MacOS Sequoia 15.0.1, on M1 Pro
My venv (
uv pip freeze
output):I have tried to run pyright directly on xlsxwriter (by copying it from .venv and running
pyright xlsxwriter
), which yields expected results with errors, warnings etc. and leads me to believe error does not lie in xlsxwriter itself.Full traceback
The text was updated successfully, but these errors were encountered: