I'm hitting this assertion.
I ran into this while working on a branch that uses wit_bindgen::block_on to drive stream I/O synchronously from within an async export.
With some LLM help I was able to reduce it to: https://github.com/badeend/wasmtime/blob/waitable-panic-repro/crates/test-programs/src/bin/p3_tls_sample_application.rs
Noet that the assertion only fires if the two write futures are allocated at different heap addresses. If the allocator happens to reuse the same slot (ptr == prev) then the assert passes by coincidence, possibly causing memory corruption (?)
I have no idea what the correct behavior should be here. On the surface I'd expect this to work. Or, if block_on is not intended to be used like this, I don't think comparing memory addresses is the correct line of defense.
Stack trace:
thread '<unnamed>' (1) panicked at /home/dave/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wit-bindgen-0.57.0/src/rt/async_support/waitable.rs:201:17:
assertion `left == right` failed
left: 0x104fd0
right: 0x104e50
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
test p3::rustls::p3_tls_sample_application ... FAILED
failures:
---- p3::rustls::p3_tls_sample_application stdout ----
Error: error while executing at wasm backtrace:
0: 0x1a3c7 - p3_tls_sample_application-57673490efd69ec5.wasm!abort
1: 0x155ed - p3_tls_sample_application-57673490efd69ec5.wasm!_ZN3std3sys3pal6wasip17helpers14abort_internal17h74119267dbd11beeE
2: 0x140af - p3_tls_sample_application-57673490efd69ec5.wasm!_ZN3std7process5abort17h49844fb4bec76201E
3: 0x1412b - p3_tls_sample_application-57673490efd69ec5.wasm!_RNvCsdBezzDwma51_7___rustc12___rust_abort
4: 0x13ecf - p3_tls_sample_application-57673490efd69ec5.wasm!_RNvCsdBezzDwma51_7___rustc18___rust_start_panic
5: 0x13ef2 - p3_tls_sample_application-57673490efd69ec5.wasm!_RNvCsdBezzDwma51_7___rustc10rust_panic
6: 0x163c1 - p3_tls_sample_application-57673490efd69ec5.wasm!_ZN3std9panicking15panic_with_hook17h7a3e5eaee7fad80cE
7: 0x158b9 - p3_tls_sample_application-57673490efd69ec5.wasm!_ZN3std9panicking13panic_handler28_$u7b$$u7b$closure$u7d$$u7d$17h36465fe3c8c216bdE
8: 0x1421a - p3_tls_sample_application-57673490efd69ec5.wasm!_ZN3std3sys9backtrace26__rust_end_short_backtrace17hfc6d834ad5c88707E
9: 0x1420e - p3_tls_sample_application-57673490efd69ec5.wasm!_RNvCsdBezzDwma51_7___rustc17rust_begin_unwind
10: 0x1ba41 - p3_tls_sample_application-57673490efd69ec5.wasm!_ZN4core9panicking9panic_fmt17h2b55671c70ea4e21E
11: 0x1d0ce - p3_tls_sample_application-57673490efd69ec5.wasm!_ZN4core9panicking19assert_failed_inner17h413a92926c49224dE
12: 0x731a - p3_tls_sample_application-57673490efd69ec5.wasm!_ZN4core9panicking13assert_failed17ha9e7c539c84bc32eE
13: 0xb3a7 - p3_tls_sample_application-57673490efd69ec5.wasm!_ZN11wit_bindgen2rt13async_support8waitable26WaitableOperation$LT$S$GT$14register_waker17h24054f043d98c2e5E
14: 0xa812 - p3_tls_sample_application-57673490efd69ec5.wasm!_ZN11wit_bindgen2rt13async_support8waitable26WaitableOperation$LT$S$GT$23poll_complete_with_code17h52b4388adf3a6c5fE
15: 0xa35f - p3_tls_sample_application-57673490efd69ec5.wasm!_ZN11wit_bindgen2rt13async_support8waitable26WaitableOperation$LT$S$GT$13poll_complete17h574be3c29c8fe313E
16: 0x85a7 - p3_tls_sample_application-57673490efd69ec5.wasm!_ZN120_$LT$wit_bindgen..rt..async_support..stream_support..RawStreamWrite$LT$O$GT$$u20$as$u20$core..future..future..Future$GT$4poll17hdff73afdb24c0bbdE
17: 0x2123 - p3_tls_sample_application-57673490efd69ec5.wasm!_ZN106_$LT$p3_tls_sample_application..Component$u20$as$u20$test_programs..p3..exports..wasi..cli..run..Guest$GT$3run28_$u7b$$u7b$closure$u7d$$u7d$28_$u7b$$u7b$closure$u7d$$u7d$17h458754691bc5ca2bE
18: 0x1b4f - p3_tls_sample_application-57673490efd69ec5.wasm!_ZN106_$LT$p3_tls_sample_application..Component$u20$as$u20$test_programs..p3..exports..wasi..cli..run..Guest$GT$3run28_$u7b$$u7b$closure$u7d$$u7d$17h6c6098462d6d7272E
19: 0x349d - p3_tls_sample_application-57673490efd69ec5.wasm!_ZN13test_programs2p37exports4wasi3cli3run16_export_run_cabi28_$u7b$$u7b$closure$u7d$$u7d$17h808d1ee9b878ecc9E
Caused by:
wasm trap: wasm `unreachable` instruction executed
I'm hitting this assertion.
I ran into this while working on a branch that uses
wit_bindgen::block_onto drive stream I/O synchronously from within an async export.With some LLM help I was able to reduce it to: https://github.com/badeend/wasmtime/blob/waitable-panic-repro/crates/test-programs/src/bin/p3_tls_sample_application.rs
Noet that the assertion only fires if the two write futures are allocated at different heap addresses. If the allocator happens to reuse the same slot (
ptr == prev) then the assert passes by coincidence, possibly causing memory corruption (?)I have no idea what the correct behavior should be here. On the surface I'd expect this to work. Or, if
block_onis not intended to be used like this, I don't think comparing memory addresses is the correct line of defense.Stack trace: