psbrandtP
Deno•3y ago•
3 replies
psbrandt

Tracking Down Lost Memory

Hi,

I have a long running service that creates many JsRuntimes over time and I have found that I am slowly leaking memory. While trying to figure out what's going on, I found that the following simple piece of code seems to leak memory:

fn main() {
  deno_core::JsRuntime::new(deno_core::RuntimeOptions::default());
}


I am using valgrind to check for memory leaks and this is what I'm getting with DHAT*:

$ valgrind --tool=dhat target/debug/rusty-v8-memtest
==1505== Total:     2,766,643 bytes in 3,129 blocks
==1505== At t-gmax: 664,059 bytes in 1,134 blocks
==1505== At t-end:  36,733 bytes in 659 blocks


This is what I'm getting with memcheck*:

$ valgrind --tool=memcheck target/debug/rusty-v8-memtest
==1499== HEAP SUMMARY:
==1499==     in use at exit: 36,733 bytes in 659 blocks
==1499==   total heap usage: 3,129 allocs, 2,470 frees, 2,766,643 bytes allocated
==1499==
==1499== LEAK SUMMARY:
==1499==    definitely lost: 1,953 bytes in 14 blocks
==1499==    indirectly lost: 1,443 bytes in 23 blocks
==1499==      possibly lost: 1,440 bytes in 5 blocks
==1499==    still reachable: 31,897 bytes in 617 blocks
==1499==         suppressed: 0 bytes in 0 blocks
==1499== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)


My memory leak could still absolutely be in my own code, but are the leaks above expected? The DHAT viewer output can be seen here: https://github.com/psbrandt/rusty-v8-memtest/blob/master/dhat-output/master/dhat-master.pdf. I also compiled a custom V8 without WASM (which seems to be one source of the leaks) and I the leaked memory is reduced, but not to zero.

Am I doing something wrong or is there something I can do to clean up after a JsRuntime (besides dispose and/or dispose_platform)?

Any ideas on how I could debug further?

*Some output deleted to meet post length limit restriction.
Was this page helpful?