Stream: git-wasmtime

Topic: wasmtime / issue #3256 aarch64-darwin: crash when unwinding

Wasmtime GitHub notifications bot (Sep 01 2021 at 09:35):

bnjbvr edited issue #3256:

Our internal wasmtime testing on aarch64-darwin shows that something broke around July 17th: https://buildkite.com/embark-studios/wasmtime-aarch64-apple-darwin/builds?branch=main&page=5

When running cargo test -p wasmtime-cli --test all, I see a segfault. LLDB shows libunwind in the backtrace, then the backtrace crate, then wasmtime::trap::Trap::new as the first wasmtime function. It seems that it happens when we're creating to create a backtrace after resuming a fiber from another thread.

Unfortunately, I've been trying to chase down a commit that would have introduced this failure, with no success: I can get back to wasmtime as of June 1st (last time I remember manually running tests on this machine), and reproduce that crash. So it could be that the system, distributed version of libunwind has changed after an upgrade of MacOS, and that it is now not working with our unwinding methods anymore.

I'll try to investigate a bit more, and report about what I've found, and if there are workarounds.

Wasmtime GitHub notifications bot (Sep 01 2021 at 09:39):

bnjbvr commented on issue #3256:

One test that triggers a crash 100% of the time is async_functions::iloop_with_fuel. I managed to retrieve the latest version of libunwind present on https://opensource.apple.com/, build it locally and link it statically in wasmtime + backtrace.rs. Luckily, with this I can reproduce the crash with something that looks like the same crash backtrace (so it might be the same crash!). Debug symbols for the debug build of libunwind don't appear in lldb, yet I thought they would appear (everything has been built in debug mode).

Wasmtime GitHub notifications bot (Sep 02 2021 at 16:49):

cfallin closed issue #3256:

Our internal wasmtime testing on aarch64-darwin shows that something broke around July 17th: https://buildkite.com/embark-studios/wasmtime-aarch64-apple-darwin/builds?branch=main&page=5

When running cargo test -p wasmtime-cli --test all, I see a segfault. LLDB shows libunwind in the backtrace, then the backtrace crate, then wasmtime::trap::Trap::new as the first wasmtime function. It seems that it happens when we're creating to create a backtrace after resuming a fiber from another thread.

Unfortunately, I've been trying to chase down a commit that would have introduced this failure, with no success: I can get back to wasmtime as of June 1st (last time I remember manually running tests on this machine), and reproduce that crash. So it could be that the system, distributed version of libunwind has changed after an upgrade of MacOS, and that it is now not working with our unwinding methods anymore.

I'll try to investigate a bit more, and report about what I've found, and if there are workarounds.

Last updated: Dec 23 2024 at 13:07 UTC