Victor Adossi (Jul 22 2025 at 08:36): Victor Adossi (Jul 22 2025 at 08:36):Ran into a problem on the JS side of things and wanted to run a quick check by anyone that recognizes this issue.
I am seemingly running into this excellently-commented condition:
Here's the stack (w/ debug) from the JS component in question:
> wasmtime serve -Scli dist/fetch-server.wasm
Serving HTTP on http://0.0.0.0:8080/
2025-07-22T08:14:40.664758Z ERROR wasmtime_cli::commands::serve: [0] :: error while executing at wasm backtrace:
0: 0xe6ee26 - wit-component:adapter:wasi_snapshot_preview1!wasi_snapshot_preview1::descriptors::Descriptors::new::h33060ed6fe1110fb
1: 0xe6e140 - wit-component:adapter:wasi_snapshot_preview1!wasi_snapshot_preview1::State::descriptors::hf646fa16f2768d61
2: 0xe6e453 - wit-component:adapter:wasi_snapshot_preview1!fd_write
3: 0xe7153f - wit-component:shim!adapt-wasi_snapshot_preview1-fd_write
4: 0x86db89 - <unknown>!__wasi_fd_write
5: 0x872d8d - <unknown>!writev
6: 0x872e0d - <unknown>!__stdio_write
7: 0x873f3e - <unknown>!vfprintf
8: 0x87324f - <unknown>!fprintf
9: 0x1d59a2 - <unknown>!cabi_realloc
10: 0xe713f3 - wit-component:shim!indirect-wasi:http/types@0.2.3-[method]incoming-request.authority
11: 0x886f00 - <unknown>!host_api::HttpRequestResponseBase::url()
12: 0x8d9a4c - <unknown>!builtins::web::fetch::fetch_event::handle_incoming_request(host_api::HttpIncomingRequest*)
13: 0x88a8ce - <unknown>!__wasm_export_exports_wasi_http_incoming_handler_handle
Caused by:
cannot leave component instance
error: guest never invoked `response-outparam::set` method
Caused by:
0: error while executing at wasm backtrace:
0: 0xe6ee26 - wit-component:adapter:wasi_snapshot_preview1!wasi_snapshot_preview1::descriptors::Descriptors::new::h33060ed6fe1110fb
1: 0xe6e140 - wit-component:adapter:wasi_snapshot_preview1!wasi_snapshot_preview1::State::descriptors::hf646fa16f2768d61
2: 0xe6e453 - wit-component:adapter:wasi_snapshot_preview1!fd_write
3: 0xe7153f - wit-component:shim!adapt-wasi_snapshot_preview1-fd_write
4: 0x86db89 - <unknown>!__wasi_fd_write
5: 0x872d8d - <unknown>!writev
6: 0x872e0d - <unknown>!__stdio_write
7: 0x873f3e - <unknown>!vfprintf
8: 0x87324f - <unknown>!fprintf
9: 0x1d59a2 - <unknown>!cabi_realloc
10: 0xe713f3 - wit-component:shim!indirect-wasi:http/types@0.2.3-[method]incoming-request.authority
11: 0x886f00 - <unknown>!host_api::HttpRequestResponseBase::url()
12: 0x8d9a4c - <unknown>!builtins::web::fetch::fetch_event::handle_incoming_request(host_api::HttpIncomingRequest*)
13: 0x88a8ce - <unknown>!__wasm_export_exports_wasi_http_incoming_handler_handle
1: cannot leave component instance
The actual code in question is in componentize-js -- a LOG macro we use to take advantage of when wizer debugging is enabled.
Here's the real question:
The error above happens during a wasi:http/incoming-handler#handle call but does not happen during a simple interface call (ex. export run: func() -> string;) call.
So the "simple" interface essentially runs to completion properly despite as far as I can tell doing the same thing:
➜ wasmtime run -Scli --invoke 'run()' dist/fetch-server.wasm
(call) Function [0] - () -> *i32
(call) setting args
(call) setting retptr at arg 0
(call) JS lowering call
(call) getting promise return
(call) adding promise reactions
(call) driving event loop to promise completion
(cabi_realloc) [0 0 5] 3140416
(call) call then handler
(call) retrieving promise result
(call) end
"DONE!"
What am I missing here about the difference between a "simple" interface call (you can see the cabi_realloc log line in question there in the output), and a more complex call like wasi:http/incoming-handler.handle.
If I remove the log line in cabi_realloc, the problem is fixed -- the call works finishes as expected.
Alex Crichton (Jul 22 2025 at 14:07):You might be running into different signatures having different runtime/allocation behavior? It's true though that at this time once you're in cabi_realloc it's not valid to call out to the host meaning (regrettably) even logging isn't allowed
Last updated: Dec 06 2025 at 06:05 UTC