WebAssembly New Added 26 September 2026

wasm-bindgen: closure invoked after being dropped

A Rust closure handed to JavaScript lives only as long as its Closure value, and letting that fall out of scope frees it while the event listener or timer still points at it. The panic therefore arrives when the callback first fires rather than where the mistake was made, which is normally a setup function that registered it and returned.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix

use wasm_bindgen::prelude::*;
use wasm_bindgen::closure::Closure;

// Panics on the first tick: cb is dropped when setup() returns
// let cb = Closure::wrap(Box::new(|| log("tick")) as Box<dyn FnMut()>);
// window.set_interval_with_callback_and_timeout_and_arguments_0(
//     cb.as_ref().unchecked_ref(), 1000)?;

// For something that lives as long as the page, hand ownership to JS
let cb = Closure::wrap(Box::new(|| log("tick")) as Box<dyn FnMut()>);
window.set_interval_with_callback_and_timeout_and_arguments_0(
    cb.as_ref().unchecked_ref(), 1000)?;
cb.forget();            // deliberate leak, correct for app lifetime callbacks

// When it must be removable, keep the closure beside the handle
struct Timer { _cb: Closure<dyn FnMut()>, id: i32 }
// dropping Timer clears the interval and frees the closure together

# The panic names a Rust file only in a debug build
wasm-pack build --dev

How to diagnose WebAssembly errors

WebAssembly errors are precise about the layer that failed. A CompileError means the bytes are not a valid module: most often the file was served with the wrong MIME type, or an HTML error page was fetched instead of the .wasm file. A RuntimeError: memory access out of bounds means the module read or wrote outside its linear memory, which in a language like C or Rust is a genuine memory-safety bug caught by the sandbox.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

Check what the server actually returned. The wasm file must be served as application/wasm for streaming compilation, and a 404 HTML page produces a misleading magic-number error.
Validate the module offline with wasm-validate and inspect it with wasm-objdump -x from the WABT toolkit.
For out-of-bounds errors, rebuild with sanitizers or debug assertions in the source language. The wasm runtime cannot tell you which source line was responsible without DWARF info.
Confirm imports match: every function the module imports must be supplied by the host with the exact name and signature, or instantiation fails.
Build with debug symbols and use the browser's DWARF support to step through original source rather than raw wasm.

Tools worth reaching for

wasm-validate / wasm-objdump (WABT)
browser DWARF debugging
wasmtime --invoke
curl -I (check MIME type)

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

rustwasm.github.io rustwasm.github.io

Related WebAssembly errors

See all 17 WebAssembly errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.