Skip to content

Small fixes for the SDK - #6833

Draft
syrusakbary wants to merge 34 commits into
mainfrom
sdk
Draft

Small fixes for the SDK#6833
syrusakbary wants to merge 34 commits into
mainfrom
sdk

Conversation

@syrusakbary

Copy link
Copy Markdown
Member

This PR does many small fixes on Wasmer that allows running properly the SDK on main

Copilot AI review requested due to automatic review settings July 28, 2026 21:16

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR applies several targeted fixes across WASIX, the JS backend, and the C-API imports crate to improve SDK behavior on main, primarily by addressing platform-specific build/runtime issues and re-entrancy/thread-safety edge cases.

Changes:

  • Avoid nested RefCell borrow panics in WASIX signal registration and thread-local handle access by switching some borrows to non-panicking try_* variants.
  • Improve JS/wasm32 compatibility by adjusting time imports (web_time) and selecting WASIX dependency features per target (sys vs js).
  • Extend the JS backend module representation to retain ModuleInfo when wasm-types-polyfill is enabled, and improve the info() failure message otherwise.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file
File Description
lib/wasix/src/syscalls/wasix/callback_signal.rs Switches signal callback registration to a non-panicking inner-mut access path to tolerate re-entrancy.
lib/wasix/src/state/handles/thread_local.rs Replaces a panicking mutable borrow with try_borrow_mut and makes destroy avoid panicking on borrow conflicts.
lib/virtual-fs/src/mount_fs.rs Uses web_time on js builds while retaining std::time elsewhere.
lib/c-api-imports/src/lib.rs Adds an unsafe impl Send for WasmCapiEnv on wasm32 to satisfy FunctionEnv constraints.
lib/c-api-imports/Cargo.toml Selects wasmer-wasix feature set by target arch (sys on native, js on wasm32).
lib/api/src/backend/js/entities/module.rs Stores ModuleInfo behind wasm-types-polyfill and implements info() accordingly.

Comment on lines +44 to 48
let Some(mut env_inner) = ctx.data_mut().try_inner_mut() else {
return Ok(());
};
let inner = env_inner.main_module_instance_handles_mut();
inner.signal = funct;
Comment on lines +141 to +143
if let Ok(mut map) = map.try_borrow_mut() {
map.remove(&id);
}
Comment on lines +381 to +385
// segment runs. wasm-bindgen correctly marks raw JS handles as !Send, but the
// worker scheduler provides the stronger single-owner invariant required by
// `FunctionEnv`.
#[cfg(target_arch = "wasm32")]
unsafe impl Send for WasmCapiEnv {}
Compact-unwind entries encode unsigned 32-bit offsets from the base
returned by the dynamic-unwind callback. Using Wasmer's dylib base is
invalid when JIT code, LSDA data, or the personality GOT slot is mapped
below the dylib.

This caused subtraction panics in debug builds and invalid libunwind
pointers, resulting in SIGBUS during forced guest termination when
Wasmer was loaded as a dynamic library.

Derive the base from the actual JIT image addresses and validate that
the complete address range and personality offset fit in u32.
Compact-unwind entries encode unsigned 32-bit offsets from the base
returned by the dynamic-unwind callback. Using Wasmer's dylib base is
invalid when JIT code, LSDA data, or the personality GOT slot is mapped
below the dylib.

This caused subtraction panics in debug builds and invalid libunwind
pointers, resulting in SIGBUS during forced guest termination when
Wasmer was loaded as a dynamic library.

Derive the base from the actual JIT image addresses and validate that
the complete address range and personality offset fit in u32.

@marxin marxin left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've got some JS CI job - do we know why the particular compilation errors haven't been caught?

wasmer_vm::libcalls::wasmer_eh_personality as *const _,
&mut info as *mut _,
);
let personality = self.maybe_eh_personality_addr_in_got.ok_or_else(|| {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has been reviewed under #6834.

@syrusakbary

Copy link
Copy Markdown
Member Author

We've got some JS CI job - do we know why the particular compilation errors haven't been caught?

Because we are testing only a subset, and not the full amount of things needed to run. If we integrate the wasmer-js SDK codebase here, we would have seen it earlier:

github.com/wasmerio/wasmer-js

Compact-unwind entries encode unsigned 32-bit offsets from the base
returned by the dynamic-unwind callback. Using Wasmer's dylib base is
invalid when JIT code, LSDA data, or the personality GOT slot is mapped
below the dylib.

This caused subtraction panics in debug builds and invalid libunwind
pointers, resulting in SIGBUS during forced guest termination when
Wasmer was loaded as a dynamic library.

Derive the base from the actual JIT image addresses and validate that
the complete address range and personality offset fit in u32.
@marxin

marxin commented Jul 30, 2026

Copy link
Copy Markdown
Collaborator

Based on the discussion with @syrusakbary, it's gonna be split into multiple PRs.

@marxin
marxin marked this pull request as draft July 30, 2026 08:30
Add an optional task-manager hook for terminating the executor that owns a
specific WASM thread. This allows SIGKILL to stop browser workers directly,
while falling back to waking atomic waiters for runtimes without targeted
cancellation.

Keep child-thread exits thread-local: mark killed threads as interrupted,
prevent child threads from performing process-wide cleanup, publish the main
thread result before broadcasting cleanup signals, and avoid tainting the
runtime for non-zero child-thread exits.
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 this pull request may close these issues.

3 participants