This same approach would also work on emscripten but instead I think we're going the route of makingpthread_getattr_np work so it can use the usual Linux code path.

CI suggests this isn't enough to fix the issue.

Do we need to manually set the stack size, roll back the stack checking changes that are causing the issue, or something else?

I was just looking into this today and I think a big part of the problem is that_Py_get_machine_stack_pointer(); does not seem to grow very fast at all in the stack overflow tests. I adjusted_Py_ReachedRecursionLimit() to occasionally log the value it got from_Py_get_machine_stack_pointer() and then rantest_ast_recursion_limit to segfault.

Not only does it get nowhere close to exhausting the 5mb of shadow stack, the shadow stack pointer only seems to move up/down by about ~4000. I am not sure if you'll get the same results on WASI, but if this is true and not just some measurement artifact, the whole approach to stack checks might not be workable at all.

         soft_limit: 3807680calls: 62 here_addr: 4305520calls: 63 here_addr: 4305920calls: 64 here_addr: 4305008calls: 65 here_addr: 4303776calls: 66 here_addr: 4302336calls: 67 here_addr: 4301776calls: 68 here_addr: 4302768calls: 69 here_addr: 4303200calls: 70 here_addr: 4303776calls: 71 here_addr: 4305024calls: 72 here_addr: 4305024calls: 73 here_addr: 4305024calls: 74 here_addr: 4305024calls: 75 here_addr: 4305920calls: 76 here_addr: 4305920RangeError: Maximum call stack size exceeded

All commit authors signed the Contributor License Agreement.

Not only does it get nowhere close to exhausting the 5mb of shadow stack, the shadow stack pointer only seems to move up/down by about ~4000. I am not sure if you'll get the same results on WASI, but if this is true and not just some measurement artifact, the whole approach to stack checks might not be workable at all.

Is that a debug build? Those stack frames are surprisingly small.

I think the shadow stack consists of:

1. normal arguments or local variables that we take a pointer to
2. varargs
3. structs that are passed by value and don't get unboxed

I don't have a good sense for how much any of this stuff happens, but it is entirely possible to run out of true stack space without allocating anything on the shadow stack at all.

It's also entirely possible that I was not measuring correctly.

Then maybe we should just turn it off? With all the trouble it's causing right now, it probably isn't worth keeping this mechanism.

Yeah it seems like there is currently no reasonable way to measure the available stack space for wasm runtimes so I'd agree we should turn it off.

At EuroPython we agreed not to worry about blowing the stack for WebAssembly since the hosts will catch that issue and prevent any security concerns.

@FFY00 did you still want to pursue this PR or close it?

At EuroPython we agreed not to worry about blowing the stack for WebAssembly since the hosts will catch that issue and prevent any security concerns.

@FFY00 did you still want to pursue this PR or close it?

No, I just wanted to fix the tests. I'll close it.