Deno needs better memory leaks debugging tools
Hello Deno team! From a few weeks I am facing a big memory leak issue in my Deno app. I used the chrome dev tools to figure out the source of memory leak but I found no clue! There is just a big ArrayBuffer on top with a retained size, when I open it to see the details it has some strange objects with circular references. There are no variable names or source paths of this data that can allow me to find the origin of the memory leak!
I have double checked all of my code to find any clue, but nothing found!
I am writing this to know if there are any tools that I can use with Deno to debug this issue? Is there any plan to develop some more lower-level tools that can allow debugging these kind of anonymous memory leaks?
I have attached a heapsnapshot of my app below. May be you can find the root cause of the memory leak:
https://limewire.com/d/b2169988-af1a-4537-a1a5-fd1b3774cca9#iqHBTOHQi6cJiG9a0CITzTK2uK0XJl6xrefAlDvcugg
Looking forward for a faster solution for this issue
Regards
6 Replies
Create an issue on their gh and put that snapshot on a image and/or gist, so people can see it more reliably
And about memory leaks, don't except much, you're still writing js, not c
I have double checked all of my code to find any clue, but nothing found!Have you checked inside your dependencies as well?
I am writing this to know if there are any tools that I can use with Deno to debug this issue?I know that
Deno.test() is able to detect some leaks.
Is there any plan to develop some more lower-level tools that can allow debugging these kind of anonymous memory leaks?AFAIK, no.
Also is there any ffi in the project/deps?
limewire???
Yeah I will do that for sure
Yes I did wrote the tests for my app using Deno.test, but no leaks detected! This is another reason why I am so confused!
I did check some of the dependencies (not all), but found nothing!
Not sure about that, I will check again
Hi there, I have successfully found the root cause of the memory leak in my app! It was too hard to find it but I'm glad that I did it!
The leak was caused by the oak middleware called oak_compress which is used to gzip the api response. I removed the middleware and boom! The graph went straight line!
https://github.com/jiawei397/oak_compress/issues/1
GitHub
This library has a memory leak · Issue #1 · jiawei397/oak_compress
This library wasted a whole month of mine in just debugging the memory leak! I thought the leak was in my code but I didn't knew that it was caused by this library!