swc-project/swc · critical

Should able to allocate memory in the plugin

Error message

Should able to allocate memory in the plugin

What it means

For return values the guest cannot pre-size (Vec<Comment> via the comments proxy), the host calls back into the plugin's exported allocator with caller.alloc(len). The expect panics when that guest alloc call traps: the plugin's wasm heap is exhausted (memory.grow failed against wasm memory limits) or the plugin module does not export the allocator ABI the host runtime expects.

Source

Thrown at crates/swc_plugin_runner/src/memory_interop.rs:67

    caller: &mut dyn runtime::Caller<'_>,
    allocated_ret_ptr: u32,
    serialized_bytes: &PluginSerializedBytes,
) {
    let serialized_bytes_len: usize = serialized_bytes.as_slice().len();
    let serialized_bytes_len = serialized_bytes_len
        .try_into()
        .expect("Should be able to convert size");

    // In most cases our host-plugin trampoline works in a way that
    // plugin pre-allocates
    // memory before calling host imported fn. But in case of
    // comments return value is Vec<Comments> which
    // guest cannot predetermine size to allocate, instead
    // let host allocate by calling guest's alloc via attached
    // hostenvironment.
    let guest_memory_ptr = caller
        .alloc(serialized_bytes_len)
        .expect("Should able to allocate memory in the plugin");

    let (allocated_ptr, allocated_ptr_len) =
        write_into_memory_view(caller, serialized_bytes, |_, _| guest_memory_ptr);

    // We cannot use cbor serialization because it is a variable-length encoding.
    let allocated_fatptr = {
        let allocated_ptr = allocated_ptr.to_le_bytes();
        let allocated_ptr_len = allocated_ptr_len.to_le_bytes();
        [
            allocated_ptr[0],
            allocated_ptr[1],
            allocated_ptr[2],
            allocated_ptr[3],
            allocated_ptr_len[0],
            allocated_ptr_len[1],
            allocated_ptr_len[2],
            allocated_ptr_len[3],
        ]

View on GitHub (pinned to 5176682b65)

Solutions

1. Rebuild the plugin with the swc_core version matching the host and the official plugin macro (which exports the required allocator).
2. Lower comment volume or disable the comments proxy for the affected files.
3. Wrap plugin execution in catch_unwind or a worker process so allocation traps are reported per file instead of aborting the build.
4. Update both host and plugin together to a matched release line.

// Guest alloc traps surface as host panics here; isolate and degrade.
let res = std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| {
    compiler.process_js_file(&fm, &handler, &config)
}));
if res.is_err() {
    tracing::error!("plugin allocator trapped (likely guest OOM); skipping plugins for this file");
}

When it happens

Trigger: allocate_return_values_into_guest with comments proxy enabled and a large comment return; plugin built with a swc_core whose allocator export signature differs from the host swc_plugin_runner; guest already near its 4 GiB wasm ceiling.

Common situations: Version mismatch between plugin and host; comment-heavy inputs; plugins that allocate aggressively and fragment the guest heap before returning comments.

Related errors

• Should able to be deserialized into string
• Should be serializable
• Should be serializable
• Should able to deserialize
• Should be serializable

AI-assisted analysis of swc-project/swc@5176682b65 (2026-08-17). Data as JSON: /api/errors/f4fe6096577ddabc. Report an issue: GitHub.