Signal handling improvements

[mikevoronov]

Motivation

In Fluence we decided to move to Wasmer :). And since our node is written in Scala, we intend to use Wasmer as a JNI module. But almost all Java VMs actively use signals for various tasks (such as asymmetric Dekker synchronization). It turned out that it is incompatible with the signal handling scheme in the clif backend since it just calls abort() functions if a signal doesn't belong to the Wasm side.

Also, it could hurt other environments if you try to embed Wasmer.

Proposed solution

The most straightforward improvement is just calling the previous handler instead of abort() like this one (I've already tested it in our network). Ideally, it needs a more complex algo taking into account layouts of Wasm heap allocation, stack and so on to determine the exact destination of a signal.

P.S. Really, we don't depend much on this feature to switch to Wasmer, because there is a nice libjsig mechanism in Hotspot. But it would be more convenient for us to rely only on proper signal handling scheme inside Wasmer.

[syrusakbary]

Thanks for creating the issue!

We are reviewing it internally and will follow here once we have the strategy a bit more clear

[mikevoronov]

Hmm, It seems that the signal management related to managed singlepass context should be refactored to be embeddable... It doesn't even work with libjsig.

[mikevoronov]

And also, one desired design point: in Fluence, we are dealing with multi modules backends. Each module has its memory, and in terms of Wasmer, they have different instances. And we will have some predefined trusted modules such as Redis, SQLite that each developer could easily integrate as a component in his backend. It will be known for sure that these modules don't have any compiler/jit bombs, and it is possible to use the fastest llvm backend for them safely (It could even be precompiled in llvm ir). But untrusted user modules should still use the singlepass compiler.

At now, each backend compiler in Wasmer uses its signal scheme, and it seems that they aren't compatible with each other (to be honest, I haven't checked, but clif and singlepass have different trap handlers without the ability to call previously registered handlers). So, it would be nice to have such a possibility after signal handler refactoring.

[zackangelo]

I'm trying to call Wasmer from a Rust JNI module and I believe I'm bumping into this issue. The first JNI invocation succeeds, but subsequent ones result in the process crashing with error code 134.

When running with -Xcheck:jni, Java complains that the signal handlers have been remapped. I tried linking in libjsig at startup and it didn't have any effect.

Are there any known workarounds for this?

[mikevoronov]

It is interesting, for me libjsig with cranelift works fine. What compiler backend do you use? It seems that with singlepass it doesn't actually work.

Also you could try straightforward approach from this branch (it works only with the cranelift compiler backend). In Fluence we are currently using Wasmer on this branch as a JNI module that is calling from the Scala part.

[zackangelo]

@michaelvoronov I tried your branch and it works! (without libjsig)

I was also running wasmer 0.6.0, so I'll do some more testing with newer versions.

[mikevoronov]

@zackangelo and how do you exactly use libjsig?

[zackangelo]

@michaelvoronov actually, I tried re-enabling it with these env vars:

DYLD_FORCE_FLAT_NAMESPACE=0
DYLD_INSERT_LIBRARIES=$JAVA_HOME/jre/lib/libjsig.dylib

But I'm not seeing the jsig log message anymore at startup. Interesting. 🤔

[mikevoronov]

If you start it through bash, it won't work because it is a security feature. You can read more here and here.

For me, it worked with LD_PRELOAD like LD_PRELOAD= java-locator --file libjsig* java -jar .... java_locator here is this app.

[syrusakbary]

In the refactor we improved a lot the signal handlers, allowing custom handlers and non-handling of issues when the exception didn't happen in the Wasm code.