-
Notifications
You must be signed in to change notification settings - Fork 694
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
Comments
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. |
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. |
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 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:
These issues have to be handled on a case-by-case basis. |
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?
The text was updated successfully, but these errors were encountered: