aarch64-darwin: crash when unwinding

[bnjbvr]

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.

[alexcrichton]

Digging through those logs it looks like when wasmtime is checked out it doesn't print the revision (would y'all be up for changing it to print this?) but assuming that the dates roughly line up with GitHub's dates I'm seeing I think the range for the regression is probably somewhere in here --

73fd702...f628d06

All of that looks pretty benign though. #3082 and #3074 are arm64 specific but unrelated to unwinding. #3088 is related to async and stack checks but which also makes it suspicious, but I also have a hard time seeing how that would cause something like this...

[bnjbvr]

would y'all be up for changing it to print this?

Good idea, added this 👍

All of that looks pretty benign though.

Yeah, I've tried to git bisect but even the oldest commit I've tried, one I wrote and which I tested manually at the time (and for which I could remember that all the tests were passing), even that commit was failing. Hence my suspicion of a system-wide change. Will try to investigate a bit more this week.

[bnjbvr]

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).