Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
borjatelladotecnalia opened this issue Apr 16, 2025 · 3 comments

Comments

@borjatelladotecnalia
Copy link

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

lum1n0us commented May 6, 2025

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.

@lum1n0us lum1n0us linked a pull request May 12, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants