unix::StoreExt no longer available on MacOS

[ulan]

We are using unix::StoreExt::set_signal_handler() to install a custom signal handler. That no longer compiles on MacOS after PR #2632.

If I understand correctly, trap handling works internally in wasmtime, but is no longer exposed via the unix::StoreExt API. Is it due to some fundamental restriction of mach ports or could it be implemented?

cc @alexcrichton, @bnjbvr

[ulan]

A workaround would be to introduce a cargo feature flag to select between signals and mach ports on MacOS. Would you accept such a patch for upstreaming?

[bjorn3]

Why do you want to use signals on macOS? The switch happened to prevent conflicts with crash reporters that use mach ports and thus would get a benign SIGSEGV before the wasmtime signal handler could handle it.

[alexcrichton]

Mach ports are such a different mechanism from signals that I ended up removing the signal-handler-registration code for macOS since it didn't really make sense any more. Mach ports catch exceptions on a separate thread while signals always run on the same thread.

That, coupled with the fact that you can always install and manage your own signal handler, is why I ended up removing this from macOS without replacement. It's always been the case that even for Unix you can install your own signal handler as well.

Could you describe your use case a bit more? Does your use case require Wasmtime to handle traps first and then your application's handler runs next? Can your application register its own signal handler and does that work?

[ulan]

Thanks @bjorn3 and @alexcrichton! The motivation for PR #2632 makes a lot of sense to me.

Our use case is the motivation behind PR #620: we use a custom signal handler to keep track of accessed Wasm memory pages. The handler runs before the Wasmtime handler, but we need to run the Wasmtime handler afterwards. What makes it more complex is that there are multiple handlers (one per Wasm instance) and multiple Wasm instances can be running on multiple threads.

Registering our own signal handler is probably possible in theory, but it is very difficult to get the handler chaining, registration ordering, and Wasm instance tracking per thread right. We would need to mirror what Wasmtime already does internally.

It would be great if we could find a workaround to unblock updating to the current version of Wasmtime. It's worth mentioning that we don't use Breakpad, so the signal-based trap handling would work well for us on MacOS.

[alexcrichton]

Oh oops sorry I was aware of that original use case but didn't realize y'all were working with it on macOS as well, sorry about that!

I think that having a compile-time feature for using signal handlers instead of mach exceptions makes sense to me, afaik it should be a pretty small switch. We can then conditionally define the StoreExt trait on macOS depending on this feature being enabled.

If you're up for sending a PR, that'd be great!

[ulan]

Thanks a lot @alexcrichton! And no worries at all about the breakage. I'll try to get the PR ready :)

[ulan]

Thanks for merging the fix @alexcrichton! Would it be possible to cherry-pick the fix to the stable branch stable-v0.26 and release it?

FWIW, I prepared PR #3079 that applies cleanly to that branch and passes our tests locally.

[ulan]

@alexcrichton and I discussed backporting of the fix to 0.26 in PR #3079.

The summary:

• Currently only security fixes are backported.
• Newer versions wasmtime are as suitable for production as 0.26.
• Instead of backporting, it is better to update to the current main of wasmtime.

I will start working on updating and will also investigate if it is possible to float the patch on our end to make updating more incremental.

Closing the issue as fixed. Thanks all for helping!