-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wasi threads mpsc channel hang on sched_yield only on debug rust build #117440
Comments
@rustbot label T-libs O-wasi |
I had a thought that it might be due to the child thread panicking, it not being handled, and then deadlocking on the channel recv function on main thread. However, I replaced with this snippet and it's ending the program on debug and release, which is what I would have expected.
Output
However, running this on x86 native is leading to a main thread deadlock on debug and release:
Where shell control isn't returned |
If I comment out
Output
|
Gathered some logs through WAMR during execution. I added backtraces to all the atomic wait and notify calls:
The main thread is stuck on atomic wait on address
There isn't a corresponding notify for that address, which is the reason for the deadlock. I've built the standard library to include some extra logging, however printing changes the behaviour of the program. For example, running this example without any of the prints causes both threads to stuck on the futex wait. |
Integrated this change into wasi-libc locally and added some checking to WAMR to print when the stack limit is exceeded WebAssembly/wasi-libc@41da013. I can see in debug build only that it stack overflows in the thread
For the release this doesn't happen and program exits without the overflow error. I increased the |
It' possible to set env variable to increase the thread stack size
Setting it larger for the debug build resolves the issue. Will check with WASI threads maintainers what's the process of setting the minimum stack size. There could be a static check that estimates the required thread stack size in rust compiler. For handling overflows at runtime, discussed with @loganek that this can be handled by adding an LLVM pass that adds runtime checks comparing the thread stack size to the thread stack pointer in WASM. See WebAssembly/wasi-threads#12 |
@cimacmillan thanks for finding the root cause and a solution. I think it would make sense to increase the default value at least for |
There is an issue with rust wasi threads where using mpsc channel can hang / deadlock only when compiled in debug mode
With this code, with
wasm32-wasi-preview1-threads
target:I've created this repository, which provides an easy way of reproducing the bug:
https://github.com/cimacmillan/WasiThreadsSchedYieldBug
I expected to see this happen:
Instead, this happened:
I've reproduced this on wasmtime and wamr.
Notes
If vec is placed in a box, it succeeds on both debug and release
Using a stack allocated array, it succeeds on release but crashes on debug
Tracing using wasm-micro-runtime wasm debugger shows both threads paused on exception
Main thread
Spawned thread
Meta
rustc --version --verbose
:The text was updated successfully, but these errors were encountered: