-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
wasmtime should have more options for debugging errors in early program startup #783
wasmtime should have more options for debugging errors in early program startup #783
Comments
My coworkers cannot appear to reproduce the issue. I will assume that this happens to be something on my end, and will continue investigating as I find time. |
I'm also unable to reproduce this with current out of master. What's the environment you're reproducing this in? |
Hi @peterhuene! Here's what I know so far:
This was with a fresh linux .tar.xz build from the dev release channel. My terminal is plain ol' Running with After much debugging, I'm assuming there's something on my end interfering with the terminal output. Trying to isolate the issue in a linux container to reproduce the issue. |
Yep. Couldn't reproduce the issue from within a linux container. Closing as there's nothing actionable here on wasmtime's end. I'll update the ticket if I find anything more concrete for others. Thanks for reaching out! |
Is it actually running anything? You can put in a infinite loop to see if it completes. You can also check if stderr has same issue - and print in infinite loop to see if there is a flush issue. |
Good call @rene-fonseca. I just checked with another sample that runs in an infinite loop. The program exits immediately, so it appears that nothing is being executed.
Output:
|
What's the exit status? Perhaps it's signaling? Can you run it under gdb/lldb? |
exit code 71.
a document on linux system errors indicates this would be a protocol error: EPROTO. |
From
|
In this case it's a process exit status, so it's not an errno value. 71 is sometimes It might be wasm's startup code, which uses Beyond that, we should consider giving wasmtime verbose messages, which could be used to indicate things like "I just failed a |
I happened to hit this as well, and it turned out to be a bug in wasi-libc -- see WebAssembly/wasi-libc#159. Keeping this issue open because we still should add better ways to debug these kinds of errors. |
This implements the semantics in WebAssembly/WASI#235. Fixes bytecodealliance#783. Fixes bytecodealliance#993.
This implements the semantics in WebAssembly/WASI#235. Fixes bytecodealliance#783. Fixes bytecodealliance#993.
This implements the semantics in WebAssembly/WASI#235. Fixes bytecodealliance#783. Fixes bytecodealliance#993.
This implements the semantics in WebAssembly/WASI#235. Fixes bytecodealliance#783. Fixes bytecodealliance#993.
This implements the semantics in WebAssembly/WASI#235. Fixes bytecodealliance#783. Fixes bytecodealliance#993.
This implements the semantics in WebAssembly/WASI#235. Fixes bytecodealliance#783. Fixes bytecodealliance#993.
…rocess. (#1646) * Remove Cranelift's OutOfBounds trap, which is no longer used. * Change proc_exit to unwind instead of exit the host process. This implements the semantics in WebAssembly/WASI#235. Fixes #783. Fixes #993. * Fix exit-status tests on Windows. * Revert the wiggle changes and re-introduce the wasi-common implementations. * Move `wasi_proc_exit` into the wasmtime-wasi crate. * Revert the spec_testsuite change. * Remove the old proc_exit implementations. * Make `TrapReason` an implementation detail. * Allow exit status 2 on Windows too. * Fix a documentation link. * Really fix a documentation link.
given an example that displays output on stdout - like a "hello world" application -
wasmtime --env
appears to drop stdout entirely.Tested with both 0.8.0 and the development release available on the releases page. Both demonstrate the same issue.
The text was updated successfully, but these errors were encountered: