Question: Preventing stack overflows / increasing effective stack size

[hoodmane]

I am using Pyodide and running into difficulties with recursion errors, particularly in Chrome. I am wondering whether there are any ways to increase the effective size of the wasm stack.

The compilation variable TOTAL_STACK looks potentially relevant. However, the RangeError is presumably a result of overflowing the VM stack. I found the following quote describing TOTAL_STACK:

The stack defined by TOTAL_STACK etc. is the "C stack", which is just for variables whose address is taken etc., otherwise the call stack and local variables and so forth are handled by the VM automatically. So the size of the stack emscripten allocates can usually be much smaller than the stack a native program would.

If I know that the program is likely to overflow the VM stack, is it possible to encourage Emscripten to allocate things on the "C stack" defensively in order to conserve the limited VM stack? Is it possible to allocate stack traces on the "C stack" or only stack-allocated variables?

If only variables can be on the "C stack", is there any way to instrument a build to audit what is taking up space on the VM stack when there is a stack overflow? If most of the VM stack is occupied by the call stack and cannot be moved to the "C stack" then this strategy wouldn't work very well...

[kripken]

Yes, RangeError would be a wasm VM error, so TOTAL_STACK wouldn't help.

There's not much you can do to try to reduce VM stack usage. Even if you tried to allocate more on the C stack in linear memory, the VM would still use stack space to store temporary variables etc.

However, this should be very rare, as VM stack sizes are quite big. If you see this then it's probably worth investigating more. As a starting point, the RangeError should have a stack trace that shows exactly what has been called all the way up. Might be something obviously wrong there, like an infinite recursion (that's usually why I see that error).

[hoodmane]

Unfortunately this is a recursion that is deep but finite. The same code works okay in Firefox, which has a native stack that is three times larger. A big part of the problem is that running CPython in the browser we have a VM in a VM.

Forcing a stack overflow in both Firefox and Chrome, I see that Chrome has a stack size of about ~10,000 zero-argument javascript function calls and Firefox has a stack size of about ~30,000 zero-argument js calls. One stack frame in the C Python VM takes up about as much space on the stack as about 70 zero-argument function calls so in Chrome the recursion limit for Python is around 140, and in Firefox the recursion limit is around 420. The Python code I'm running typically uses a recursion depth of around 100-200 causing frequent RangeErrors in Chrome, rare stack overflows in Firefox, and never any issue on a native CPython VM which typically has a recursion limit set around 1000.

[kripken]

I see, thanks @hoodmane As this is a VM-specific limitation harming a real-world use case, I think we should file a bug on V8 - perhaps the limit can be raised.

You can do that here: https://bugs.chromium.org/p/v8/issues/entry (or, if you'd prefer, I can file one for you if you don't have an account there or some other reason, let me know)

[hoodmane]

Okay I opened an issue on v8. Thanks @kripken!
V8 issue is here:
https://bugs.chromium.org/p/v8/issues/detail?id=11269

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

[hoodmane]

Closed as resolved cf https://blog.pyodide.org/posts/function-pointer-cast-handling/