wasmerio / wasmer-go

🐹🕸️ WebAssembly runtime for Go
https://pkg.go.dev/github.com/wasmerio/wasmer-go
MIT License
2.82k stars 161 forks source link

Memory leaks after upgrading bindings to 3.3.0 #393

Open EclesioMeloJunior opened 1 year ago

EclesioMeloJunior commented 1 year ago

Describe the bug

Hello! In our project (https://github.com/ChainSafe/gossamer) we have recently upgraded (https://github.com/ChainSafe/gossamer/pull/3168) from github.com/wasmerio/go-ext-wasm/wasmer to github.com/wasmerio/wasmer-go/wasmer v1.0.4 and after this upgrade, we notice our application running out of memory.

After some profiling, we notice that the inuse_memory was around 300MB - 500MB

Screenshot 2023-05-16 at 09 38 03

As this monitor shows the gossamer process is using around more than 1GB

Screenshot 2023-05-16 at 09 38 27

So we found this issue https://github.com/wasmerio/wasmer-go/issues/322#issuecomment-1006494534, where it reports some memory leak and then a comment that says:

This is fixed in Wasmer 2.1, but the Go bindings have not yet been updated to use that version.

So I forked this repository here -> https://github.com/EclesioMeloJunior/wasmer-go and tried to upgrade the bindings to the most recent version of wasmer-c-api which is v3.3.0, which mitigates the leak but does not resolve it since the instance stills running out of memory, below I provide a print of the instance memory usage after upgrading the bindings

image

How do we instantiate the runtime

I've extracted the Gossamer process of instantiating a runtime to another repository https://github.com/EclesioMeloJunior/gossamer-runtime-leak. Basically, the provided runtime requires the host to provide the memory.

We have an allocator that manages the memory provided by the host to the runtime, additional information about the runtime specification we're trying to support: https://spec.polkadot.network/chap-host-api#sect-allocator-api

Steps to reproduce

  1. Go to https://github.com/EclesioMeloJunior/gossamer-runtime-leak
  2. Choose a version
  3. Run: docker-compose up
  4. See the container memory usage continues to increase