-
Notifications
You must be signed in to change notification settings - Fork 906
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 leak #4070
Comments
Here's the output of running it with wasi and wasmtime on my machine
|
I'll try to take a look at this and see where the leak is coming from. |
FWIW the leak reproduces on all platforms, not just wasm, if that makes debugging easier |
I looked into this; it doesn't happen for me on native, which leads me to believe that it's just the a problem of a conservative garbage collector working with a 32-bit address space accidentally pinning large allocations. I'll leave this open for now incase I want to take another look at this. |
I think I am encountering the same problem developing https://github.com/goui-org/goui, which runs with wasm (-gc=conservative) in the browser. After updating the dom millions of times, I get this:
|
@twharmon You are probably encountering memory fragmentation. |
@dgryski What is the solution? I added some logging in gc_* src, and it does free bytes regularly, but still must call I also logged runtime memory stats to confirm HeapInuse always increases and never decreases. Does this rule out fragmentation? I already tried |
To avoid pinned allocations, we need more type information for the garbage collector. Specifically, something like #4479 would address this and not cause confusion with sequences of bytes that "look like" pointers, keeping the strings alive. |
|
|
The following program never frees memory, even with
-gc=conservative
.Build it via
tinygo build -scheduler=none foo.go
BigGo seems to handle freeing memory fine based on the ReadMemStats call, but in TinyGo the memory just grows unbounded until the program exits or OOMs.
An easy way to test is via wasmtime and capping memory usage:
The text was updated successfully, but these errors were encountered: