@stlite/browser multipage apps crash with pyodide error on PC

[nic-iqmo]

OS Version: Windows 11 Home, Version 24H2, Build 26100.4351.
Chrome Version: 137.0.7151.69

Issue Description:
After 10-20 minutes of running a multipage app, the entire app crashes with the error below. On PC this seems to happen on @stlite/browser >= 0.77.0. I've tested a number of different versions ranging from 76.0 to 83.0 and I'm seeing the bug on every version I've tested >= 0.77.0. I've also tested on both chrome and edge and the result is the same. On mac I can't reproduce the error.

Pyodide has suffered a fatal error. Please report this to the Pyodide maintainers.
   API.fatal_error                                      @ pyodide.asm.js:10
   callPyObjectKwargsPromising                          @ pyodide.asm.js:10
   await in callPyObjectKwargsPromising   
   Module.callPyObjectMaybePromising                    @ pyodide.asm.js:10
   wrapper                                              @ pyodide.asm.js:10
   e.port1.onmessage                                    @ pyodide.asm.js:10

The cause of the fatal error was:
   API.fatal_error                                      @ pyodide.asm.js:10
   callPyObjectKwargsPromising                          @ pyodide.asm.js:10
   await in callPyObjectKwargsPromising   
   Module.callPyObjectMaybePromising                    @ pyodide.asm.js:10
   wrapper                                              @ pyodide.asm.js:10
   e.port1.onmessage                                    @ pyodide.asm.js:10

RuntimeError: table index is out of bounds
      at cdn.jsdelivr.net/pyodide/v0.27.3/full/pyodide.asm.wasm
      at cdn.jsdelivr.net/pyodide/v0.27.3/full/pyodide.asm.wasm
      at cdn.jsdelivr.net/pyodide/v0.27.3/full/pyodide.asm.wasm
      at cdn.jsdelivr.net/pyodide/v0.27.3/full/pyodide.asm.wasm
      at cdn.jsdelivr.net/pyodide/v0.27.3/full/pyodide.asm.wasm
      at cdn.jsdelivr.net/pyodide/v0.27.3/full/pyodide.asm.wasm
      at cdn.jsdelivr.net/pyodide/v0.27.3/full/pyodide.asm.wasm
      at cdn.jsdelivr.net/pyodide/v0.27.3/full/pyodide.asm.wasm
      at cdn.jsdelivr.net/pyodide/v0.27.3/full/pyodide.asm.wasm
      at cdn.jsdelivr.net/pyodide/v0.27.3/full/pyodide.asm.wasm
   API.fatal_error                                      @ pyodide.asm.js:10
   callPyObjectKwargsPromising                          @ pyodide.asm.js:10
   await in callPyObjectKwargsPromising   
   Module.callPyObjectMaybePromising                    @ pyodide.asm.js:10
   wrapper                                              @ pyodide.asm.js:10
   e.port1.onmessage                                    @ pyodide.asm.js:10

Stack (most recent call first):
  File "/lib/python312.zip/pyodide/webloop.py", line 286 in call_soon                 pyodide.asm.js:10 
  File "/lib/python312.zip/asyncio/events.py", line 88 in _run                        pyodide.asm.js:10 
  File "/lib/python312.zip/pyodide/webloop.py", line 332 in run_handle                pyodide.asm.js:10 

I created an MRE to demonstrate. The MRE consists of a barebones flask server that serves a multipage Streamlit app where each app has a title and thats it.

Steps to Reproduce:

1. cd into stlite_browser_broken_multipage_app_crashes
2. Launch the flask server
3. When the app had loaded, click on a page (e.g. page2)
4. Let it sit until it fails

Link to MRE: https://github.com/NicholasGingrich/stliteTesting/tree/main/stlite_browser_broken_multipage_app_crashes

[lukefullard]

Same issue on https://edit.share.stlite.net/ since 0.83

[whitphx]

Thank you both for the report! I will investigate the problem.

[nic-iqmo]

Update: After turning off the JSPI (Java script promise integration) flag in Chrome, it seems that the bug no longer occurs.

To turn off the flag:

1. Navigate to chrome://flags
2. Find the flag entitled Experimental WebAssembly JavaScript Promise Integration (JSPI) and set the option to disabled

[LukeAFullard]

Looks to be related to this:
pyodide/pyodide#5702

[DarkGoldBar]

This config works for me.

mount(
  {
    requirements: req,
    entrypoint: "app.py",
    files: files,
    streamlitConfig: {
      "server.fileWatcherType": "none",
    }
  },
  document.getElementById("root")
);

Since this error is triggered by a large number of Python async function calls, turning off the file watcher delays the crash significantly.