-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Memory leak in version 2.0 #922
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
Comments
Thanks for the nice repro case. I can try to look at this within the next week, but if anyone else gets to this before me, go ahead please! |
zbjornson
added a commit
to zbjornson/node-canvas
that referenced
this issue
Jun 20, 2017
zbjornson
added a commit
to zbjornson/node-canvas
that referenced
this issue
Jun 20, 2017
zbjornson
added a commit
to zbjornson/node-canvas
that referenced
this issue
Jun 27, 2017
Don't recreate the cairo surface when the canvas is constructed. Fixes Automattic#922
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hi!
I have come across what seems to be a memory leak in
node-canvas
version 2. I've put together a very basic repro case that you can find in this repo.Briefly, the problem manifests like this:
rss
portion ofprocess.memoryUsage
is quickly increasing despite garbage collection.For example, in my repro case, the memory usage that started with:
rose after a 1000 requests to:
(notice the rise in
rss
).This memory leak is not present in the 1.x branch of
node-canvas
.I tried both
.pngStream()
and.toBuffer()
methods in my repro case (since there is an issue regarding memory leaks withpngStream
). None of this helped.If you could suggest the place in the version 2 branch that is free from this leak, I would be super grateful. I've used the master branch of
node-canvas
in production this winter, and it seems like there was no such bug then.My environment:
MacOS v. 10.11.6
node v6.7.0
P.S.: I have not bisected the git history to find the exact commit that has introduced the leak, but at least at the time of this March commit memory seems to be managed fine.
The text was updated successfully, but these errors were encountered: