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
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
togithub.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 - 500MBAs this monitor shows the gossamer process is using around more than 1GB
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:
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 isv3.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 bindingsHow 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
docker-compose up