wasmerio/wasmer · error

Internal error: failed to resolve exported function

Error message

Internal error: failed to resolve exported function {name}: {e:?}

What it means

apply_resolved_function found the instance for resolved_from, but querying instance.exports.get_function(name) failed; the module does not actually export a function with that name (or it is exported with a different kind). The panic surfaces the underlying lookup error e. This means the resolution table and the module's real export surface disagree.

Solutions

1. Rebuild the consuming module and the shared library together so resolved symbol names match actual exports (nm/wasm-objdump the exports)
2. Check that the symbol is exported as a function (not a global) in the provider module
3. Clear stale linker/resolution state and re-run the link after replacing a module build
4. If the export exists with the right kind yet the panic persists, report as a linker bug with the module and symbol name

Example fix

// before: lib rebuilt without the export
//   resolution says libfoo exports 'callback', but new build exports 'cb'
group.apply_resolved_function(store, libfoo_handle, "callback", idx);
// after: keep ABI stable or re-resolve against new names
//   export 'callback' in the rebuilt lib, or update the resolution for 'cb'

fn exports_function(inst: &Instance, name: &str) -> bool {
    inst.exports.get_function(name).is_ok()
}
// before apply_resolved_function:
assert!(exports_function(&group.try_instance(handle).unwrap(), "callback"));

fn is_exported_function(inst: &Instance, name: &str) -> bool {
    inst.exports.get_function(name).is_ok()
}

When it happens

Trigger: apply_requested_symbols_from_linker / apply_dl_operation resolving symbol {name} to module X, then X's exports contain no function named {name}; export kind mismatch (name exported as a global/memory instead of a function).

Common situations: Version skew: a shared library was rebuilt and dropped/renamed an exported symbol; symbol name mangling or version-script changes; resolution state built against a different build of the module than the one instantiated.

Related errors

• Internal error: unexpected symbol resolution
• Internal error: allocated index
• Internal error: bad in-progress symbol resolution
• Internal error: failed to resolve function
• Internal error: function table index

AI-assisted analysis of wasmerio/wasmer@8c4b9ee9d3 (2026-09-01). Data as JSON: /api/errors/b1b53bd50af0a87e. Report an issue: GitHub.

Appendix: source

Thrown at lib/wasix/src/state/linker/instance_group/table.rs:151

        &self,
        store: &mut impl AsStoreMut,
        name: &str,
        resolved_from: ModuleHandle,
        function_table_index: u32,
    ) -> Result<(), LinkError> {
        trace!(
            ?name,
            ?resolved_from,
            function_table_index,
            "Applying resolved function"
        );

        let instance = &self.try_instance(resolved_from).unwrap_or_else(|| {
            panic!("Internal error: module {resolved_from:?} not loaded by this group")
        });

        let func = instance.exports.get_function(name).unwrap_or_else(|e| {
            panic!("Internal error: failed to resolve exported function {name}: {e:?}")
        });

        self.place_in_function_table_at(store, func.clone(), function_table_index)
            .map_err(LinkError::TableAllocationError)?;

        Ok(())
    }

    pub(super) fn apply_function_table_allocation(
        &mut self,
        store: &mut impl AsStoreMut,
        index: u32,
        size: u32,
    ) -> Result<(), LinkError> {
        trace!(index, "Applying function table allocation");
        let allocated_index = self
            .allocate_function_table(store, size, 0)
            .map_err(LinkError::TableAllocationError)? as u32;

View on GitHub (pinned to 8c4b9ee9d3)