I'm working on a project that uses the Go bindings for wasmtime, and if I create two instances from the same store, wasi instance, and module I get a call stack exhausted panic when I try to call the entrypoint func. I also tried to construct a new wasi instance for each module instance, but no difference. Am I misunderstanding something?
@Alex Vidal hm what does the stack trace look like?
wasm backtrace: 0: 0xffffffff - <unknown>!_start
In my specific case my wasm program calls out to the host, and the host sleeps for 1s. I can try to repro by sleeping inside the wasm program instead.
(the sleep isn't normal operation, just for my reproduction)
hm is that the only stack frame?
oh you know that actually looks like a segfault
rather than a stack exhausted panic
do you have some code I could poke at?
i can try to reproduce it without all my nonsense
ok i can repro it easily
sending up a branch
https://github.com/avidal/wasmtime-go/blob/concurrent-segfault/repro_test.go
the wasi stuff is a red herring it's not necessary for the reproduction
run it with go test -v -run Repro
and all but the first subtest will fail
ah I see, so currently nothing in Store
can be used concurrently
so believe this is segfaulting due to data races
everything within a Store
must be locked to the same goroutine
hm, but i can't get a compiled module without a store..
My program currently instantiates for each incoming http request to avoid the setup costs. I suppose I'll need to use a pool instead and pre-fill it with a handful of stores.
@Alex Vidal ah yeah currently it's a limitation that you need to compile once-per-thread
we very much want to lift that limitation soon
ok cool. I'll setup a pool for now then. Is there a tracking issue I can subscribe to?
https://github.com/bytecodealliance/wasmtime/issues/793 is probably the closest equivalent
Last updated: Nov 22 2024 at 16:03 UTC