wasmerio/wasmer · error

Internal error: module {resolved_from:?} not loaded by this

Error message

Internal error: module {resolved_from:?} not loaded by this group

What it means

apply_resolved_function looks up the instance for the module a symbol was resolved from (try_instance) and panics if the group has no such instance. A resolution record says a symbol comes from module X, but module X was never instantiated (or was dropped) in this instance group, so its exports cannot be read to place the function in the table.

Source

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

        Ok(())
    }

    pub(super) fn apply_resolved_function(
        &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> {

View on GitHub (pinned to 8c4b9ee9d3)

Solutions

1. Load (instantiate) the module that provides the symbol before applying requested symbols from the linker
2. Check the load order in your dynamic-loading flow so dependency modules are instantiated first
3. Rebuild LinkerState resolutions in the same instance group that owns the producing instances
4. Verify no unload/remove operation ran before apply_dl_operation finished

Example fix

// before: applying symbols resolved from a module never loaded
group.apply_requested_symbols_from_linker(store, &linker_state)?;
// after: ensure the provider module is instantiated first
group.apply_dl_operation(store, &linker_state, DlOperation::Load { handle: provider, .. })?;
group.apply_requested_symbols_from_linker(store, &linker_state)?;

fn provider_loaded(group: &InstanceGroup, from: &ModuleHandle) -> bool {
    group.try_instance(from).is_some()
}
// before apply_requested_symbols_from_linker:
// ensure every resolution's resolved_from is in the group
for r in state.resolutions() {
    assert!(provider_loaded(&group, r.resolved_from()), "load provider first");
}

fn has_instance(group: &InstanceGroup, h: &ModuleHandle) -> bool {
    group.try_instance(h).is_some()
}

When it happens

Trigger: apply_requested_symbols_from_linker or apply_dl_operation applying resolutions where resolved_from names a module not present in the group's instances/side_instances; the producing module failed to instantiate earlier but its symbols were still recorded as resolutions.

Common situations: dlopen of module B whose symbols resolve into module A that was never loaded; removing/unloading a module while resolutions pointing to it are still pending; resolution records shared from a different instance group.

Related errors

• Internal error: resolution record for symbol {name} indicate
• Internal error: function table index {index} already occupie
• Internal error: table base out of sync with linker state
• Internal error: allocated index {allocated_index} does not m
• Internal error: unexpected symbol resolution {r:?} for reque

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