Wasmtime GitHub notifications bot (Feb 28 2022 at 15:00): Wasmtime GitHub notifications bot (Feb 28 2022 at 15:00):alexcrichton opened issue #3857:
This past Friday some tests were done on CI - https://github.com/bytecodealliance/wasmtime/pull/3853 - to figure out what was going wrong and the culprit ended up being the stack overflow tests on Windows. Our testing efforts were thwarted by the fact that if the test harness is run with
--test-threads 1then stack overflow tests will all legitimately stack overflow on Windows, presumably because we're by default giving too much stack space to WebAssembly.This can be reproduced locally on Windows with:
$ cargo test --test all -- --test-threads 1The best fix for this is likely to decrease the default amount of stack given to WebAssembly (specified here), perhaps only on Windows.
Wasmtime GitHub notifications bot (Feb 28 2022 at 15:22):alexcrichton commented on issue #3857:
I'm performing a test run at https://github.com/alexcrichton/wasmtime/actions/runs/1911049688 to see what happens when we limit the stack size of wasm for the entire test suite, and then run the tests on windows with
--test-threads 1
Wasmtime GitHub notifications bot (Feb 28 2022 at 15:32):alexcrichton edited a comment on issue #3857:
I'm performing a test run at
https://github.com/alexcrichton/wasmtime/actions/runs/1911049688https://github.com/alexcrichton/wasmtime/actions/runs/1911091901 to see what happens when we limit the stack size of wasm for the entire test suite, and then run the tests on windows with--test-threads 1
Wasmtime GitHub notifications bot (Feb 28 2022 at 15:54):alexcrichton commented on issue #3857:
Learnings so far:
- According to https://github.com/alexcrichton/wasmtime/runs/5361838714?check_suite_focus=true the test suite works as-is (as of b57dc5e3346747824dcb512cc99f94c14763cbab) with 64k to 256k, of wasm stack.
- At 512k and above of wasm stack this test fails as the host tries to probe that it has 512k of stack.
- At 16-32k of wasm stack this test fails because it's intermingling host/wasm stack and the wasm stack's allocation starts at the first recursive call, it's not per-call.
- At 8k and below of wasm stack we start seeing lots of various failures in the test suite
- According to https://github.com/alexcrichton/wasmtime/runs/5361992788?check_suite_focus=true if we probe for 128k bytes of stack in this test then the test suite passes with 512k of wasm stack.
Wasmtime GitHub notifications bot (Feb 28 2022 at 18:18):alexcrichton closed issue #3857:
This past Friday some tests were done on CI - https://github.com/bytecodealliance/wasmtime/pull/3853 - to figure out what was going wrong and the culprit ended up being the stack overflow tests on Windows. Our testing efforts were thwarted by the fact that if the test harness is run with
--test-threads 1then stack overflow tests will all legitimately stack overflow on Windows, presumably because we're by default giving too much stack space to WebAssembly.This can be reproduced locally on Windows with:
$ cargo test --test all -- --test-threads 1The best fix for this is likely to decrease the default amount of stack given to WebAssembly (specified here), perhaps only on Windows.
Last updated: Nov 22 2024 at 16:03 UTC