RangeError: Maximum call stack size exceeded #2840
Comments
|
Forgot to add installed from brew. In case it helps. |
|
I've just checked this with docker and latest |
|
Can you run the following script and post the results printed (don't need the fatal error traceback part). const {loadPyodide} = require("./pyodide.js");
globalThis.jsdepth = function jsdepth(){
let d = 0;
function jsrec(){ d++; jsrec(); }
try { jsrec(); } catch(e) { return d; }
}
async function main() {
const py = await loadPyodide();
let d = py.runPython(`
from js import jsdepth
jsdepth()
`);
let pyusage = py.runPython(`
from js import jsdepth
from itertools import pairwise
def differences(l):
return [x-y for (x, y) in pairwise(l)]
def f(n):
if n > 0:
return f(n-1)
return jsdepth()
differences([f(x) for x in range(10)])
`).toJs();
const x = [0]
py.globals.set("x", x);
const pyrec = py.runPython(`
import sys; sys.setrecursionlimit(100000)
def pyrec():
x[0] += 1
pyrec()
pyrec
`);
try {
pyrec();
} catch(e){}
console.log("Max JS depth:", d);
console.log("Max Python depth:", x[0]);
console.log("Python usage", pyusage);
console.log("Max JS depth/Python usage:", d/pyusage[0]);
}
main(); |
|
I had to change the first line to With that, output is: |
|
Try For comparison I see: and our most recent CI run showed We used to automatically compute the recursion limit but we removed it because as you can see weird stuff happens in Firefox: We want to compute |
|
Interesting, with that I get Even more, if i set the value as low as |
|
If you set the value to 800 you still get RangeErrors? |
|
yes, happens when pytest is collecting tests, perhaps when it's importing pydantic-core. |
|
I've been playing around, I can get all tests to pass in docker running ubuntu if I use When trying to run tests outside docker I now get |
Well that looks like the wheel was built with the wrong version of Emscripten -- should be |
|
Ok, I had managed to build two wheels, one with With that they both seem to be the same, though I still have the weird situation where pytest sometimes doesn't recognise some plugins. |
|
I've hit a similar issue here, the following html file will hit the Maximum call stack size exceeded error on Chrome but not on FF or Node |
@rtpg Well, that's strange. Your code runs infinite recursion, so it must hit the maximum call stack size error on any platform including native Python. When I ran it on my local Firefox it raises the maximum call stack error as expected. |
Updated version. When I set the recursion limit (via which is fine and great and what I expect. But when running this on Chrome, the following error happens. Here it's not Pyodide raising a Python error, but Pyodide hitting a failure due to stacks in practice even with the default of 1000 I was hitting this error in the system I'm looking at , but am failing to nicely reproduce the error I saw there here. I don't really know what is ideal here, since it's not like we want to be "solving for" the stack height at every Python function call (that generates a variable number of stack frames), and Pyodide is being called within JS, so I think there's a bit of stack budget used up there as well. At the very least it might be worth catching exceptions, checking for if they look like stack overflows, and then re-raising but with an error like "you hit a recursion limit on the WASM. This could be due to an infinite loop, or simply hitting a limit. Lowering the recursion limit in python with |
|
When I was seeing this, the error is more likely to happen when the devtools panel is closed - enabling devtools in chrome obviously changes the way JS is executed to allow introspection, there stopping the error (or making it less likely). |
This sounds reasonable to me. |
|
Another thing I noticed here (though I don't know if it's really solvable at all?) is that after this happens Pyodide is placed in a permanently disabled state. Are there any plans at all to provide a way to basically wipe all of Pyodide and re-initialize it "from scratch" in these sorts of scenarios? I suppose service workers are the way to go for that? I basically want to make this at least somewhat recoverable but maybe this is too big of an ask |
|
@rtpg You can call |
|
To be fair, in ordinary linux it would just say
Well there are a lot of other reasons it might say |
|
To be clear, currently, when hitting the error, Pyodide wraps the error and says to report it upstream. Doing this sort of error filtering would make it obvious that this isn't a Pyodide bug. I was having an issue with trying to re-init with |
🐛 Bug
Trying to run pydantic-core's tests on wasm with node locally, and I'm getting the following crash, tests are working ok on github CI. My local machine is an M1 mac.
To Reproduce
See pydantic/pydantic-core#148 and in particular pydantic/pydantic-core@782b64f
I'm just running those tests locally.
Expected behavior
no crash
Environment
0.21.0-alpha.2v16.13.0The text was updated successfully, but these errors were encountered: