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

Memory leaks after upgrading bindings to 3.3.0 #393

Open
EclesioMeloJunior opened this issue May 16, 2023 · 0 comments
Open

Memory leaks after upgrading bindings to 3.3.0 #393

EclesioMeloJunior opened this issue May 16, 2023 · 0 comments
Labels
🐞 bug Something isn't working

Comments

@EclesioMeloJunior
Copy link

EclesioMeloJunior commented May 16, 2023

Describe the bug

Hello! In our project (https://github.com/ChainSafe/gossamer) we have recently upgraded (ChainSafe/gossamer#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 #322 (comment), 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
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

1 participant