-
Notifications
You must be signed in to change notification settings - Fork 824
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
Run Wasm code on a separate stack #2807
Conversation
f1262fb
to
3d83d55
Compare
void wasmer_unwind(void *JmpBuf) { | ||
platform_jmp_buf *buf = (platform_jmp_buf*) JmpBuf; | ||
platform_longjmp(*buf, 1); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work removing the dependency on this c file!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That C file had some hack to allow correct debugging on mac. It would be nice if that hack culd be put somewhere else, as a comment or something optionnal?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can use an LLDB command to mask signals:
process handle SIGBUS --notify false --stop false
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, that's not the issue. It's not about signal trapping.
that line of code
task_set_exception_ports(mach_task_self(), EXC_MASK_BAD_ACCESS, MACH_PORT_NULL, EXCEPTION_DEFAULT, 0);
allow EXC_BAD_ACCESS exception to be routed and trigger segfault. Without it, you get stuck at the exception and can debug anything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason why this line is hidden behind an #if 0
by default? It seems that mono always does this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No specific reason, I just let it disabled unless activated for debug to avoid changing previous behaviour. But I suppose it can just be enabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we eliminate vm/probestack.rs
along with the PROBESTACK
const, wasmer_vm_probestack
, and LibCall::Probestack
(in vm/libcalls.rs
) ?
They seem to not be used any longer (although I'm not really sure)
Cranelift still uses it for stack probing. |
ef38f0d
to
290c84e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need to remember to add some workaround for the macOS task_set_exception_ports(mach_task_self(), EXC_MASK_BAD_ACCESS, MACH_PORT_NULL, EXCEPTION_DEFAULT, 0);
debuggin issue...
a747bdd
to
bee530b
Compare
bors r+ |
2807: Run Wasm code on a separate stack r=syrusakbary a=Amanieu This uses the [corosensei](https://crates.io/crates/corosensei) crate to run Wasm code on a separate stack from the main thread stack. In trap handlers for stack overflows and memory out of bounds accesses, we can now check whether we are executing on the Wasm stack and reset execution back to the main thread stack when returning from the trap handler. When Wasm code needs to perform an operation which may modify internal data structures (e.g. growing a memory) then execution must switch back to the main thread stack using on_host_stack. This is necessary to avoid leaving internal data structure in an inconsistent state when a stack overflow happens. In the future, this can also be used to suspend execution of a Wasm module (#1127) by modeling it as an async function call. Fixes #2757 Fixes #2562 Co-authored-by: Amanieu d'Antras <[email protected]>
bors r- |
Canceled. |
Some context on why we did cancel:
Once that's addressed we should be good to merge |
Stack probes must be done before the stack pointer is adjusted. This ensures that the stack pointer is still within the bounds of the stack when inspected by the signal handler.
This uses the [corosensei](https://crates.io/crates/corosensei) crate to run Wasm code on a separate stack from the main thread stack. In trap handlers for stack overflows and memory out of bounds accesses, we can now check whether we are executing on the Wasm stack and reset execution back to the main thread stack when returning from the trap handler. When Wasm code needs to perform an operation which may modify internal data structures (e.g. growing a memory) then execution must switch back to the main thread stack using on_host_stack. This is necessary to avoid leaving internal data structure in an inconsistent state when a stack overflow happens. In the future, this can also be used to suspend execution of a Wasm module (#1127) by modeling it as an async function call. Fixes #2757 Fixes #2562
This is now handled by the generic trampoline code in the engine.
bors r+ |
This uses the corosensei crate to
run Wasm code on a separate stack from the main thread stack.
In trap handlers for stack overflows and memory out of bounds accesses,
we can now check whether we are executing on the Wasm stack and reset
execution back to the main thread stack when returning from the trap
handler.
When Wasm code needs to perform an operation which may modify internal
data structures (e.g. growing a memory) then execution must switch back
to the main thread stack using on_host_stack. This is necessary to avoid
leaving internal data structure in an inconsistent state when a stack
overflow happens.
In the future, this can also be used to suspend execution of a Wasm
module (#1127) by modeling it as an async function call.
Fixes #2757
Fixes #2562