Implement Callback for generic excetions/traps as it is for memory enlarge exceptions

[borjatelladotecnalia]

Feature

WAMR allows to define a callback to be triggered whenever a memory enlarge operation happens. I miss the same behaviour with let's call them "generic exceptions" which may include from "wrong version" to "divided by cero" events.

Benefit

Main thread is aware of unexpected events in an asynchronous way

Implementation

As a first approach, replicate structures and logic related to enlarge memory exceptions—originally defined in wam_memory.c/h—within wasm_runtime_common.c/h.

Finally modify wasm_set_exception function to call the configured call back.

Alternatives

Any other approach would be more efficient and practical? Something missing or collateral impact?

[lum1n0us]

I think the callback is intended for logging rather than handling exceptions. Undefined behaviors in WebAssembly will be addressed. For instance, dividing by zero will cause a trap.

[borjatelladotecnalia]

Thanks, @lum1n0us for your inputs. We see that there have been several discussions about this topic.

In our application (AOT build for embedded deployment) the native side creates some threads that indeed are wasm apps running in "background". The native side needs to know if any event that may lead to an unstable environment has happened and consequently terminate and relaunch the environment.

The "exception/unexpected event -> callback" approach is perfect to notify such undefined scenarios. Will the trap mechanism behave in that way?

In principle, the patch to implement "unexpected event -> callback" seems quite straight forward, as the error handling seems quite centralized.

Do you foresee any special consideration that we may have into account? We don't see that it would somehow condition/compromise traps implementation.

[lum1n0us]

At the language level, the WebAssembly Spec can avoid all well-known undefined behavior problems found in the C language, such as integer overflow, division by zero, uninitialized variables, and out-of-bounds access. Overflowing integers will be truncated, division by zero will lead to a trap, uninitialized variables will be rejected by the validator (not at runtime), and out-of-bounds access will be captured by the sandbox and runtime.

All these exceptions can be handled by the Wasm Runtime. If using wasm_runtime_call_wasm(), wasm_runtime_call_wasm_a(), or wasm_runtime_call_wasm_v(), and so on, it will return a false value, and using wasm_runtime_get_exception() can retrieve the exception message.

Here is a PR to clone/dump the call stack when an exception occurs: #4033

However, there are still reasons that can lead to crashes, such as:

• Guest languages, like C or C++, being programmed with undefined behavior.
• Native libraries that the Wasm module depends on not being well programmed.
• AOT not being properly configured.
• Execution of native libraries not following the proper calling convention.

These issues have to be handled on a case-by-case basis.