Running into wasm error: indirect call type mismatch when using the compiler backend, but not the interpreter

[zshipko]

Describe the bug
I am running a wasm module that uses call_indirect - when using the interpreter it runs successfully, but when using the compiler it fails with wasm error: indirect call type mismatch - it also runs successfully on wasmtime, so I think this could be a compiler bug.

To Reproduce
I've uploaded the wasm here: wasm.zip

Then using the extism CLI: https://github.com/extism/cli/ (can be installed by cloning the repo and running go install ./extism from the root of the repo)

EXTISM_ENABLE_WASI_OUTPUT=1 extism call ./plugin.wasm req --allow-host '*' --input "https://extism.org" --wasi --link import_module=import_module.wasm --log-level info

Note: the current CLI uses wazero 1.7, but I've also tested using the latest code on main with the same result.

Expected behavior
The call should return successfully instead of throwing the type mismatch error

Environment (please complete the relevant information):

• Go version: 1.22.6
• wazero Version:tested on 1.7 and the latest main (58488880a334e8bda5be0d715a24d8ddeb34c725)
• Host architecture: amd64
• Runtime mode: compiler

Additional context
If I comment out lines 3558-3581 in internal/engine/wazevo/frontend/lower.go it works as expected.

[mathetake]

looks like a bug - do you happen to have arm64 machine and being able to check if this happens on arm64 as well or not?

[zshipko]

I can run this on an arm64 mac later this evening and will let you know how it goes

[mathetake]

sg, thank you!

[zshipko]

Just ran it on arm64 macos and got the same result:

Error: wasm error: indirect call type mismatch
wasm stack trace:
	.$11042(i32,i64) i64
	.$131(i32,i32,i32,i32)
	.$74(i32) i32
	.$130(i32,i32,i32) i32
	.$1576(i32,i32,i32) i32
	.$251(i32,i32,i32,i32) i32
	.$252(i32,i32,i32) i32
	.$2875(i32,i32,i32) i32
	.$816(i32,i32,i32) i32
	.$2872(i32,i32,i32,i32,i32,i32) i32
	.$254(i32,i32,i32,i32) i32
	.$247(i32,i32,i32,i32,i32) i32
	.$251(i32,i32,i32,i32) i32
	.$252(i32,i32,i32) i32
	.$2875(i32,i32,i32) i32
	.$816(i32,i32,i32) i32
	.$2872(i32,i32,i32,i32,i32,i32) i32
	.$254(i32,i32,i32,i32) i32
	.$247(i32,i32,i32,i32,i32) i32
	.$251(i32,i32,i32,i32) i32
	.$252(i32,i32,i32) i32
	.$10591(i32,i32,i32)
	.$11031(i32) i32
	.$11051() i32

[mathetake]

thanks, that helps - meaning i think this is not really a compiler but seems more of a "compiler engine" bug

[evacchi]

investigating a bit, so func 11042 should be:

501347 func[11042] <__invokeHostFunc_1_1>:
 501348: 20 01                      | local.get 1
 50134a: 20 00                      | local.get 0
 50134c: 11 16 01                   | call_indirect 1 (type 22)
 50134f: 0b                         | end

with type 22 being:

 - type[22] (i64) -> i64

with the offset being 0.

(I was suspecting some overflow but I don't think it is the case)

I also tested against v1.6.0 (old compiler) and on arm64 the behavior is correct

[mathetake]

curious about old compiler with amd64...

[evacchi]

looks like it's working there as well (still investigating...)

EDIT: I injected a UDF around the error, just to inspect the registers, apparently it's comparing 0x1 (r10) to 0x2 (r9)

ldr w9, [x8, #0x10]
ldr x10, [x1, #0x630]
ldr w10, [x10, #0x58]
udf
subs wzr, w9, w10

[evacchi]

humm, no luck so far, I turned the UDFs into BRKs, it's definitely loading 0x2, but the offsets seem ok to me, so I wonder if the table has been filled incorrectly.

EDIT, hey wait a minute!

> wasm2wat wasm/import_module.wasm 
...
  (func $import_name (type 2) (param i64) (result i64)
...

it is indeed type 2 in the other module. 🤔

maybe something funky here?

wazero/internal/engine/wazevo/module_engine.go

Lines 264 to 284 in 5848888

	func getTypeIDOf(funcIndex wasm.Index, m *wasm.ModuleInstance) wasm.FunctionTypeID {
	source := m.Source
	var typeIndex wasm.Index
	if funcIndex >= source.ImportFunctionCount {
	funcIndex -= source.ImportFunctionCount
	typeIndex = source.FunctionSection[funcIndex]
	} else {
	var cnt wasm.Index
	for i := range source.ImportSection {
	if source.ImportSection[i].Type == wasm.ExternTypeFunc {
	if cnt == funcIndex {
	typeIndex = source.ImportSection[i].DescFunc
	break
	}
	cnt++
	}
	}
	}
	return m.TypeIDs[typeIndex]
	}

I think we should not copy over the typeID from the imported module, and just use the typeID of the import

[evacchi]

ok I should have a proper PR tomorrow with tests etc., the typeIDs would be propagated from the import signature, after verification

[mathetake]

Good