Non-deterministic fatal go runtime crashes on macOS #60
Comments
|
Thanks for the report! I've also been seeing this on CI for some time now, I just unfortunately haven't had the time to investigate yet :( |
|
After digging a bit further I opened up golang/go#44501 so I'll watch that and see how it goes. |
|
Ok after some discussion on the linked issue I think this should be fixed by bytecodealliance/wasmtime#2676 |
|
I haven't seen this in a while now, and we've reintroduced our |
|
Ok! |
|
😢 I'm afraid I was wrong. Running @tsandall's example code still reliably ends with a SIGILL: |
|
I've been stumbling upon this in some work related to use interrupting the VM. It turns out that those suffer a similar fate to what Torin initially reported here, presumably interrupt traps and unreachable traps have something in common. This is my package main
import (
"log"
"time"
"github.com/bytecodealliance/wasmtime-go"
_ "github.com/bytecodealliance/wasmtime-go/build/include" // to include the C headers.
_ "github.com/bytecodealliance/wasmtime-go/build/linux-x86_64" // to include the static lib for linking.
_ "github.com/bytecodealliance/wasmtime-go/build/macos-x86_64" // to include the static lib for linking.
_ "github.com/bytecodealliance/wasmtime-go/build/windows-x86_64" // to include the static lib for linking.
)
func main() {
bs, err := wasmtime.Wat2Wasm(`
(func (export "loop")
(loop br 0))
`)
check(err)
for i := 0; ; i++ {
config := wasmtime.NewConfig()
config.SetInterruptable(true)
store := wasmtime.NewStore(wasmtime.NewEngineWithConfig(config))
module, err := wasmtime.NewModule(store.Engine, bs)
check(err)
instance, err := wasmtime.NewInstance(store, module, nil)
check(err)
errc := make(chan error)
go func() {
_, err = instance.GetExport("loop").Func().Call()
errc <- err
}()
time.Sleep(100*time.Millisecond)
handle, err := store.InterruptHandle()
check(err)
handle.Interrupt()
err = <-errc
if err == nil {
panic("expected error")
}
if t, ok := err.(*wasmtime.Trap); ok {
log.Printf("%d: trap: %s", i, t.Message())
}
}
}
func check(e error) {
if e != nil {
panic(e)
}
}and this is a run that ends in a 💥: |
|
@srenatus the bug you're running into is you're concurrently using a This is what works for me -- https://gist.github.com/alexcrichton/1be9a044be50e95e0584f70170a6d55d |
💡 Thanks, that's helpful. 😃 |
|
@alexcrichton So just for clarification, the interrupt handle can be used from another goroutine, correct? Also, I see the same thing happening with your code: |
|
Hm yes I think I've seen that too from time to time and is likely related to the Go runtime, I'll need to dig in further to see what's going on though. |
|
Sorry, to indeed clarify, the Otherwise, though, @srenatus what Go version are you using? I'm using 1.16 and I'm unable to get that to produce any issues using wasmtime 0.26 |
|
Hrmm I've upgaded to go 1.16 ( |
|
Hm ok I've tried poking and haven't been successful. Can you open a new issue with the full details? |
|
☝️ Done! I'd love to join you poking, but I have no idea how. What's your approach debugging something like this? 🤔 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi there!
I'm running into some non-deterministic go runtime crashes on macOS w/ v0.23.0. Here's an example:
If you run this program on macOS, it should crash eventually (the last couple runs on my laptop took about 150 iterations, but it's not consistent).
It seems like something nasty is happening in the runtime when the unreachable instruction is executed.
Here's the output from the last run:
I'm running go1.15.8 after I found the other issues related to older versions (<1.14.11, I think).
One other data point/question...
I've found that if a Go-defined function is called and panics before the unreachable instruction is executed, I still run into the same crash. For example, here's the WAT:
In this case, the Go-defined function "f2" just calls panic().
I'm on macOS 10.15.7 in case that helps.
Would rewriting my Go-defined functions to use Traps instead of panicking help at all?
The text was updated successfully, but these errors were encountered: