-
Notifications
You must be signed in to change notification settings - Fork 59
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
Possible Memory Leak #216
Comments
Thank you for your feedback, I've been very busy lately. I expect to have time to look at this issue in April. Until then, you can try using the wasm version and see what happens? https://github.com/yisibl/resvg-js/tree/main/wasm |
I did try the wasm version and although I have problems getting it to render images and text, it revealed something significant. It seems quite a bit slower and at fist it did the same thing; grew memory indefinitely. I noticed that RenderedImage has a "free()" method attached to it. When I used that, all was good, memory remained pretty much stable.
// do something with png, e.g. save to file... I don't see free() referenced in any of the examples, so I'm not sure about its intended usage, but it seems important if it releases memory. I would like to continue using resvg-js for its speed, so I look forward to your findings in a couple weeks. Thanks! |
I can reproduce this and can observe a continuous memory growth(MacBook Pro M1). This does not happen in [email protected].
|
For answer seekers: https://rustwasm.github.io/wasm-bindgen/reference/weak-references.html |
I still see memory growth using 1.4.0. Its not as much but well over 1G by the end of the run. From zimond's comment it looks like this has something to do with how the rust library is integrated with the js code? |
@DSalman The simple answer is that rust code needs an integration framework which So is calling |
I had the same problem when processing a large number of files. Tried Node v16.16.0 and v20.5.1 |
@iKBAHT |
我也遇到了内存不断增长的问题,看起来像内存泄漏 |
I have also faced this problem when using The cause seems to be that diff --git a/node_modules/@vercel/og/dist/index.node.js b/node_modules/@vercel/og/dist/index.node.js
index c92983c..a516f4f 100644
--- a/node_modules/@vercel/og/dist/index.node.js
+++ b/node_modules/@vercel/og/dist/index.node.js
@@ -18786,7 +18786,11 @@ async function render(satori2, resvg, opts, defaultFonts, element) {
value: options.width
}
});
- return resvgJS.render().asPng();
+ const pngData = resvgJS.render();
+ const pngBuffer = pngData.asPng();
+ pngData.free();
+ resvgJS.free();
+ return pngBuffer;
}
// src/figma/index.tsx |
Is it feasible to provide api like |
Not sure it's related but I'm opened an issue due to memory usage #343 |
@tyutjohn You can use the resvg-wasm as wasm is supported by nodejs |
I spent some time researching the memory leak problem in node. I now have reason to suspect that the memory is not released due to the integration of rapi-rs with rust. I created the following test code
It returns nothing, I created 10000 instances, then I manually triggered the drop and called node gc, rss no changes |
Wanted to add/confirm my understanding here
With that in mind is it advisable to use the WASM "runtime" if memory is of concern? |
Hi. I'm using with Node.js and I need to loop through many svg frames and convert them to a png sequence. I'm seeing memory usage continually increase and stay very high even after the job is complete. The heap is not increasing, only the rss. I found that Node users experiencing similar issues usually trace it back to a leak in native code. I've reduced the script down to the simplest possible code where all I do is create a new Resvg and call render().asPng() on it. The demo script includes an http server to run the test, but the result is the same if you call it directly. The service set values from the console match my activity monitor for the node process and show a memory usage close to 3G at the end of the loop. This was also confirmed when running on the server where we have limited memory, about 1G. This will reliably trigger an out of memory termination.
leak-test.zip
The text was updated successfully, but these errors were encountered: