Closed tjanczuk closed 11 years ago
Useful resource: http://www.codeproject.com/Articles/19490/Memory-Leak-Detection-in-NET
It appears the ClrFuncInvokeContext associated with a call from V8 to CLR is never collected, which also contains other objects in its closure:
!dumpheap -stat
...
03be0f14 77629 2173612 ClrFuncInvokeContext
64112b0c 77629 2484128 System.Action
6411acc0 78354 120662376 System.String
Root cause: ClrFuncInvokeContext remained GC-rooted when CLR function completed synchronously on V8 thread. This prevented ClrFuncInvokeContext along with its closure (which includes payload passed from CLR to JS) from being reclaimed by the GC.
The fix is to refactor code such the ClrFuncInvokeContext is being GC-rooted only when the CLR function does not complete synchronously.
For future reference: here is a guide to native leak investigation with windbg: http://www.codeproject.com/Articles/31382/Memory-Leak-Detection-Using-Windbg
The following code generates a managed memory leak (managed heap ever increasing). Ultimately (~10min on my box) the process fails with out of memory exception: