Help interpreting an Emscripten 4.0.9 Wasm imported-call control-flow contradiction

[mebbeh]

Edited to clarify that pycore_interp_init is a locally added diagnostic caller, not part of the official Pyodide 0.29.4 artefact.

Hello,

I’m investigating a defensive compatibility issue involving Pyodide 0.29.4, Emscripten 4.0.9, and AndroidX JavaScriptSandbox.

The goal is to run Pyodide locally and offline inside AndroidX JavaScriptSandbox as a constrained runtime for untrusted scripts. No browser APIs, filesystem, network access, Android bridge, or direct hardware authority are exposed.

I would appreciate guidance on an imported-call control-flow result from a locally rebuilt diagnostic variant of Pyodide.

Important provenance clarification

The official Pyodide 0.29.4 Wasm distributed through jsDelivr contains the three upstream callers of env.emscripten_asm_const_int:

trigger_fatal_error
init_pyodide_proxy
jsproxy_init

The fourth caller described below, in pycore_interp_init, is not present in the official Pyodide artefact.

It was introduced by a small source-level diagnostic patch in our local build. The build otherwise retains the Pyodide 0.29.4, CPython 3.13.2, and Emscripten 4.0.9 lineage.

The original failure also reproduces without this diagnostic caller. The custom caller was added only to investigate the state leading to that failure.

Environment

• Pyodide 0.29.4 source lineage
• CPython 3.13.2
• Emscripten 4.0.9
• MAIN_MODULE=1
• imported memory and table
• memory growth enabled
• Wasm exceptions
• SUPPORT_LONGJMP=wasm
• modularised Emscripten runtime
• Android WebView and AndroidX JavaScriptSandbox comparison hosts

Original upstream-baseline failure

The original Pyodide failure occurs during the first:

API.rawRun("import _pyodide_core")

before _pyodide_core side-module loading begins.

CPython first obtains __main__, and the observed failing path is:

PyImport_AddModuleRef("__main__")
→ PyMapping_GetOptionalItem()
→ PyDict_CheckExact()
→ WebAssembly memory access out of bounds

The object-header slot derived from interp->imports.modules is outside the current Wasm linear-memory range. This reproduces on two physical Android devices.

Local diagnostic caller

To investigate an earlier point in the failing path, we added one source-level diagnostic call during interpreter import-state initialisation.

The diagnostic callback returns only:

1 → take a native unreachable path
2 → perform a native byte load at exactly memory.size

Any other return preserves compiler-visible fallthrough.

Static WABT inspection of the locally rebuilt Wasm finds four callers of emscripten_asm_const_int:

trigger_fatal_error
init_pyodide_proxy
jsproxy_init
pycore_interp_init       // locally added diagnostic caller

The three upstream callers pass an empty signature. Only the locally added pycore_interp_init caller passes a single-integer signature.

Its verified native control flow is:

imported callback returns 1
→ native unreachable

imported callback returns 2
→ native load at exactly memory.size

otherwise
→ fallthrough

Dynamic observation

We wrapped the actual imported emscripten_asm_const_int function in trusted host code.

The wrapper:

• calls the original import exactly once;
• preserves its arguments and this binding;
• returns the original value unchanged;
• rethrows any exception unchanged;
• emits only bounded categorical evidence.

On Android WebView, using the same locally rebuilt JavaScript/Wasm pair, we observe:

caller signature: single-i
original imported return: 1
runtime initialization later completes
main later completes
finalizeBootstrap later starts

Static caller attribution establishes that the single-integer signature uniquely identifies the locally added pycore_interp_init caller.

The callback event and subsequent lifecycle events have also been bound to the same recorded runtime generation and instance lineage.

Our present interpretation is therefore:

local pycore_interp_init diagnostic calls emscripten_asm_const_int
→ JavaScript callback returns 1
→ native Wasm should execute unreachable
→ later lifecycle execution nevertheless appears to continue

We are trying to determine which assumption in that interpretation is wrong.

Reduction results

Smaller probes do not reproduce the anomaly:

1. A hand-written Wasm imported-call and terminal ladder behaves correctly.
2. A minimal Emscripten 4.0.9 MAIN_MODULE=1 probe with imported memory/table, memory growth, Wasm exceptions, and Wasm longjmp behaves correctly.
3. A minimal EM_ASM_INT probe using the same return/unreachable/boundary-load pattern behaves correctly in AndroidX JavaScriptSandbox.

This suggests the behaviour requires an additional condition present in the full Pyodide-derived runtime.

Questions

1. Can an emscripten_asm_const_int wrapper observe and return JavaScript numeric 1, while the Wasm caller receives a different effective i32 value?

2. Can Wasm exception handling, Wasm longjmp, or generated Emscripten control flow redirect execution before an adjacent native unreachable?

3. Is there any MAIN_MODULE, relocation, exception-handling, or runtime-generation mechanism that could make the statically inspected caller differ from the effective executing path despite matched Wasm identity and recorded instance lineage?

4. Is there a known Emscripten 4.0.9 issue involving EM_ASM_INT, MAIN_MODULE, Wasm exceptions, or SUPPORT_LONGJMP=wasm that could be relevant?

5. What source-level instrumentation would you recommend to prove the value consumed by the Wasm caller without modifying generated JavaScript or editing the Wasm binary?

6. Is there a later Emscripten version that would provide a particularly meaningful controlled comparison?

We can provide:

• the exact small source patch that adds the diagnostic caller;
• the complete compile flags;
• the minimal A1/A2/A3 probe sources;
• the static four-call-site attribution table;
• the locally generated JavaScript/Wasm pair;
• bounded comparison results from Node, Android WebView, AndroidX JavaScriptSandbox, physical devices, and an API 35 emulator;
• a minimal Android host project if useful.

We are not trying to suppress the original memory trap or patch around corrupted CPython state. The goal is to understand the source-level mechanism and determine whether a narrow, upstream-compatible correction is possible.

Thank you for any guidance.

[hoodmane]

Where are you getting Pyodide from? In https://cdn.jsdelivr.net/pyodide/v0.29.4/full/pyodide.asm.wasm I only see three calls to env.emscripten_asm_const_int:

• jsproxy_init
• init_pyodide_proxy
• trigger_fatal_error

No such call occurs in pycore_interp_init. pycore_interp_init sounds like it would be for _PyEM_InitTrampoline_js but that is called in a C constructor:

__attribute__((constructor)) void _PyEM_InitTrampoline() {
  _PyEM_InitTrampoline_js();
 }

and uses EM_JS not EM_ASM.

[mebbeh]

You are correct. I should have made the provenance of that fourth call explicit.

The jsDelivr Pyodide 0.29.4 Wasm is the upstream baseline and contains the three call sites you listed. The pycore_interp_init call was added by our local defensive diagnostic build; it is not part of upstream Pyodide 0.29.4.

The diagnostic build retains the Pyodide 0.29.4 / CPython 3.13.2 / Emscripten 4.0.9 lineage, but includes a small source-level checkpoint in CPython import/interpreter initialisation intended to classify an earlier out-of-range import-state pointer before the existing bootstrap trap.

So the puzzling observation is specifically:

• our custom diagnostic caller invokes emscripten_asm_const_int;
• the wrapped JavaScript import reports returning 1;
• static inspection of that custom caller shows 1 selecting unreachable;
• later same-generation lifecycle evidence nevertheless appears.

I did not mean to imply that pycore_interp_init or that fourth call exists in the official CDN artefact. I will update the issue description to distinguish the untouched upstream baseline from the custom diagnostic build.

The original unmodified failure that motivated the diagnostic build is still a synchronous memory access out of bounds during the first rawRun("import _pyodide_core"), before side-module loading begins.

I can provide the exact small source patch and build flags so the diagnostic caller can be reviewed independently. Would that be the most useful next artefact?