Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiled Module not loaded properly in v1.8.2 but works in v1.6.0 #2358

Open
davidmdm opened this issue Jan 8, 2025 · 5 comments
Open

Compiled Module not loaded properly in v1.8.2 but works in v1.6.0 #2358

davidmdm opened this issue Jan 8, 2025 · 5 comments
Labels
bug Something isn't working

Comments

@davidmdm
Copy link

davidmdm commented Jan 8, 2025

Describe the bug
Instantiating compiled module results in nil pointer dereference in v1.8.2 but not v1.6.0

To Reproduce

Clone the example repository, checkout the set-exitcode-deref-panic branch and run the tests:

git clone https://github.com/davidmdm/wzbug.git
cd wzbug
git checkout set-exitcode-deref-panic
./test.sh

Expected behavior

The module should instantiate and run properly as it did with v1.6.0 without panic.

Screenshots

Using: github.com/tetratelabs/wazero v1.6.0

---

Using: github.com/tetratelabs/wazero v1.8.2

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x0 pc=0x1042fcbd0]

goroutine 1 [running]:
github.com/tetratelabs/wazero/internal/wasm.(*ModuleInstance).setExitCode(...)
	/Users/davidmdm/go/pkg/mod/github.com/tetratelabs/[email protected]/internal/wasm/module_instance.go:142
github.com/tetratelabs/wazero/internal/wasm.(*ModuleInstance).CloseWithExitCode(0x10449b5d8?, {0x10449c5f0?, 0x104661c00?}, 0x22e6f00?)
	/Users/davidmdm/go/pkg/mod/github.com/tetratelabs/[email protected]/internal/wasm/module_instance.go:101 +0x20
github.com/tetratelabs/wazero/internal/wasm.(*ModuleInstance).Close(0x14000074120?, {0x10449c5f0?, 0x104661c00?})
	/Users/davidmdm/go/pkg/mod/github.com/tetratelabs/[email protected]/internal/wasm/module_instance.go:96 +0x28
github.com/davidmdm/wzbug/wasi.Execute.func2()
	/Users/davidmdm/Documents/coding/exp/wazerobug/wasi/wasi.go:85 +0x34
github.com/davidmdm/wzbug/wasi.Execute({0x10449c5f0, 0x104661c00}, {{0x0, 0x0, 0x0}, {0x10449e400, 0x1400002e140}, {0x1043c3b05, 0x3}, {0x10449b538, ...}, ...})
	/Users/davidmdm/Documents/coding/exp/wazerobug/wasi/wasi.go:93 +0xd58
main.run()
	/Users/davidmdm/Documents/coding/exp/wazerobug/main.go:52 +0x428
main.main()
	/Users/davidmdm/Documents/coding/exp/wazerobug/main.go:15 +0x1c
exit status 2

Environment (please complete the relevant information):

  • Go version: 1.23.4
  • wazero Version: v1.6.0 & v1.8.2
  • Host architecture: arm64
  • Runtime mode: compiler
@davidmdm davidmdm added the bug Something isn't working label Jan 8, 2025
@davidmdm
Copy link
Author

davidmdm commented Jan 8, 2025

Note this also fails using v1.7.0

This occurs when using a compiled module with a cache directory.

@faddat
Copy link

faddat commented Jan 12, 2025

David, I'm not hitting this, which is kind of interesting to me. I don't know if it will be helpful, bug have a look at this:

Maybe helpful?

@davidmdm
Copy link
Author

@faddat ? Did you try the example repo?

The steps to reproduce on your own:

  • Generate a WASM Binary
  • Compile it using wazero
    • use a compilation-cache
  • Execute it

@davidmdm
Copy link
Author

I have played around with the code, and noticed that this panic was from calling module.Close.

This is because in wazero 1.7+ instantiating returns this error:

source module must be compiled before instantiation

Somehow it is not using or finding the compilation cache?

@davidmdm davidmdm changed the title Instantiating compiled module results in nil pointer dereference in v1.8.2 but not v1.6.0 Compiled Module not loaded properly in v1.8.2 but works in v1.6.0 Jan 13, 2025
@davidmdm
Copy link
Author

It seems to be the case that when we create the wazevo Engine, it only looks up the CompiledModule from Memory and does not use the cache:

func (e *engine) NewModuleEngine(m *wasm.Module, mi *wasm.ModuleInstance) (wasm.ModuleEngine, error) {
me := &moduleEngine{}
// Note: imported functions are resolved in moduleEngine.ResolveImportedFunction.
me.importedFunctions = make([]importedFunction, m.ImportFunctionCount)
compiled, ok := e.getCompiledModuleFromMemory(m)
if !ok {
return nil, errors.New("source module must be compiled before instantiation")
}

Naively trying to lookup using cache works ~almost.

	compiled, ok := e.getCompiledModuleFromMemory(m)
	if !ok {
		var err error
		compiled, ok, err = e.getCompiledModuleFromCache(m)
		if err != nil {
			return nil, fmt.Errorf("could not lookup module in cache: %w", err)
		}
		if !ok {
			return nil, errors.New("source module must be compiled before instantiation")
		}
	}

It does managed to find the compiled module by ID but results in a panic resolving imported functions:

panic: runtime error: index out of range [7] with length 0

goroutine 1 [running]:
encoding/binary.littleEndian.PutUint64(...)
        /opt/homebrew/Cellar/go/1.23.4/libexec/src/encoding/binary/binary.go:115
github.com/tetratelabs/wazero/internal/engine/wazevo.(*moduleEngine).ResolveImportedFunction(0x14000128300?, 0xe6b0?, 0x140?, 0xb?, {0x104c8f030?, 0x14000126180?})
        /Users/davidmdm/Documents/coding/exp/wazerobug/vendor/github.com/tetratelabs/wazero/internal/engine/wazevo/module_engine.go:256 +0x210
github.com/tetratelabs/wazero/internal/wasm.(*ModuleInstance).resolveImports(0x14000128400, {0x104c8c090?, 0x104e51bc0?}, 0x140001024e0)
        /Users/davidmdm/Documents/coding/exp/wazerobug/vendor/github.com/tetratelabs/wazero/internal/wasm/store.go:449 +0x464

My debugging abilities are ok, but my understanding of the wazero/wazevo internals are a little bit put the test.
Would appreciate an expert's point of view.

@mathetake @evacchi ???

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants