Ian Smith (May 05 2023 at 17:26): Ian Smith (May 05 2023 at 17:26):I have a wasmtime embedded in a go program. I am seeing some weird things when I try to start a program. The program's entry point is called from go and for this program:
func main(){
log.Printf("a\n")
log.Printf("b\n")
}
One would receive the output "a" but nothing else and, according to the return value returned to the go level, the program exited and returned no value.
Seems to me that the.problem is something in the WASM world, probably in the go/wasmtime interface. Is there a way to turn off the JIT in crane lift? I'm on a Mac with AARCH64 architecture. Is there any way to get a trace from wasmtime so I can see exactly where the program exit is coming from?
thanks
Ian
Alex Crichton (May 05 2023 at 17:32):Could you perhaps clarify a bit? You say that Wasmtime is embedded in a Go program, does that mean you're using the wasmtime-go bindings? You mention another Go program, but that one doesn't mention Wasmtime. Is that a program compile to wasm and running in the aforementioned embedding? If so how did you compile the Go program here?
If you can run the program in the wasmtime CLI then you can set RUST_LOG=wasi_common to get a strace-sort-of-output for all syscalls. That doesn't have backtraces on it, though, which it sounds like that's what you want. Traps, which proc_exit in WASI corresponds to, should have backtraces on them so if you're using wasmtime-go you should be able to inspect a trap for its backtrace.
Given all that, though, I'm not sure why you're also asking about turning off the JIT? You cannot do that with the C API (which wasmtime-go uses), but additionally if you turn off the JIT there's no way to run wasm unless you have a precompiled module, but at that point you're not really turning anything off, hence my confusion of why turning off the JIT is mentioned here.
Ian Smith (May 05 2023 at 17:34):Yes, I am using wasmtime-go and the go program I gave is one that I compiled to WASM that I was attempted to run via getting a Func that points to the start symbol and calling it.
Alex Crichton (May 05 2023 at 17:35):I'd recommend reproducing that in the wasmtime CLI then as that should be a bit more of a controlled environment
Ian Smith (May 05 2023 at 17:37):How can I run in the CLI when I have a bunch of functions that are in the "environment" that are called by the wasm (guest) program???
Alex Crichton (May 05 2023 at 17:39):One option is --default-values-unknown-imports. Another is --trap-unknown-imports. If neither of those works then the CLI won't work, yes
Ian Smith (May 05 2023 at 17:46):Yeah, well, I'm doing some shenanigans with linking to allow go programs to run in wasmtime. Have there been changes to the way wasi is "used" by wasmtime? I don't actually support wasi (I have my own implementation of the functions that just print something and return.)
Ian Smith (May 05 2023 at 17:51):The fact that it gets to main and then seems to return mysteriously makes me think it's something about the fact this is running on AARCH64. I mean I don't see how the example can get to main() and then execute ONE LINE and not the second before returning. I am wondering if wasmtime is crashing in some way that gets trapped and then it gets returned to me in the go world as a "returned with no value."
?
Alex Crichton (May 05 2023 at 17:57):ah well once something executes surprisingly there's quite a lot that could be going wrong, but I think it'll be difficult to help you remotely debug without a reproduction
Ian Smith (May 05 2023 at 18:30):some messing with debuggers produced this
thread '<unnamed>' panicked at 'assertion failed: range_start < range_end', crates/cranelift/src/debug/transform/expression.rs:689:13
Ian Smith (May 05 2023 at 18:31):so it appears wasmtime itself has an assertion failure
Alex Crichton (May 05 2023 at 18:36):oh yes there are known issues with Wasmtime's dwarf implementation, so it's not recommended to enable that
Ian Smith (May 05 2023 at 18:43):ok, can you slap with a link about the issue and/or how to turn off dwarf?
Ian Smith (May 05 2023 at 18:45):sorry, stupid question. I found the config switch for it.
Alex Crichton (May 05 2023 at 18:48):The issue in question is https://github.com/bytecodealliance/wasmtime/issues/3999
Chris Fallin (May 05 2023 at 19:54):The fact that it gets to main and then seems to return mysteriously makes me think it's something about the fact this is running on AARCH64
FWIW, we've had good support for aarch64 for about three years now, and it's regularly fuzzed; I understand the impulse to suspect the complex codegen under the hood but I'd be very very surprised if a compiler bug were responsible for your program exiting early. Or at the very least, there's no reason to think aarch64 is any more suspect than other architectures -- it's actually a slightly older backend than our current x86 one.
Re: "turning off JIT", as Alex notes you'll need a precompiled module then, and the compiler that produces that precompiled module is exactly the same compiler that produces the JIT'd code. The only difference is when the compiler runs. I suspect you're wanting an interpreter instead; unfortunately Wasmtime doesn't have a Wasm interpreter, it must compile to native.
Ian Smith (May 06 2023 at 12:49):@Chris Fallin I'm frankly not one to jump to the conclusion it's the infrastructure (wasmtime) because I was once told by a wise engineer, "ALWAYS assume it's YOUR code that is broken." However, after about 3 days of studying this and experimenting with it, the fact that the first line of code runs and later ones don't is VERY hard to explain with _some_ kind of error coming in from out of band. I'm going to do some other experiments today and if I figure it out I'll advise.
Ian Smith (May 06 2023 at 12:50):PS: It also might be a problem with wasmtime-go and its use of cgo to call into the infrastructure that is rust based. Frankly, I think cgo is a bit rickety.
Last updated: Dec 23 2024 at 13:07 UTC