Repository navigation
stateLoadFile on a missing path aborts the Wasm core #116
Description
After a model loads, stateLoadFile on a path that does not exist aborts the Wasm core instead of rejecting:
await bridge.stateLoadFile('/does_not_exist.bin', 512);
// main thread: RuntimeError: Aborted(undefined). Build with -sASSERTIONS for more info.
// worker: Error with the same text, and the bridge moves to the main thread for the sessionIt behaves the same on v0.1.44 and v0.1.47, in main-thread and worker modes, on wasm32 and wasm64.
llamadart_webgpu_state_load_file (src/llama_webgpu_core.cpp:1652 at 64ba825) passes the path straight to llama_state_load_file. Its own failure branch, which returns -5 with "Failed to load llama.cpp state file…", is never reached.
This matters because Web state paths are virtual and do not survive a page reload. So loading a path saved before a reload hits this.
Expected: a missing file rejects with an error, for example by checking that it exists first and returning a new code, and leaves the runtime usable.
Found while validating the bridge pin bump in leehack/llamadart#620.
Activity
leehack commentedon Sep 24, 2026
A note for whoever fixes this: #119 changes the worker
createCompletionfallback so that it moves to the main thread only when the worker itself is unusable. That means a crash, a timeout or stall, or anAborted(…)/trap error. It no longer does so for every error.The state APIs don't fall back. After
stateLoadFileaborts the worker's core, the bridge keeps that dead worker. Until now, the next completion error of any kind then moved the session to the main thread. After #119, only errors recognised as worker failures do.Returning an error instead of aborting, as this issue proposes, avoids the dead worker entirely. A more general guard would be for the runtime's
onAbortto set a flag that stays set, sent back with the worker's error state, so the facade can see the core is dead whatever the error text says.leehack commentedon Oct 21, 2026
2026-10-21 publication evidence: this repair is included in immutable assets v0.1.67, bridge source
8992121b4b533a4444ad6de93d855ea3c99644c6. Qualification 39531423431 and publication 39533748707 succeeded. The manifest verifies SHA-256d596304c609034afc37280bf86b8231a941bf3a7f3a3e584acd084f646a472ba; bridge JS and both WASMs changed from v0.1.66, while bundled llama.cpp remains620d2225cc436ab0b001e3200e590e3b286ef9ab.Consumer delivery is still pending: published llamadart 0.15.5 and current main pin v0.1.66; repin core #1260 is inside open batch #1282. No source closure→consumer-delivery inference. Separate snapshot issue #169 / draft #170 is not included in v0.1.67 and retains its load-latency decision. Issue state/priority are unchanged.
leehack commentedon Oct 22, 2026
2026-10-22 consumer delivery: the repair previously published in immutable v0.1.67 is now consumed by core 0.15.6, which pins assets v0.1.69 through core#1301. This supersedes yesterday's pending-v0.1.66 consumer snapshot. Manifest SHA-256 is
994e798389d440a256f103f3789a1f56da2ab00dd6bb6e52f334ed4e58867c46; upstream remains620d2225cc436ab0b001e3200e590e3b286ef9ab. Closed state/priority are unchanged; no additional runtime/API support is inferred.