[#64] Q & A continue about memlab HOT 3 CLOSED

It's important to understand what the output from MemLab means to debug memory leaks.

MemLab prints the retainer trace of the leaked objects. A retainer trace is a reference chain from the GC root (at the top of the trace) to the leaked object (at the bottom of the trace). It explains why and how a leaked object is still kept alive in memory.

To give a simple example, the following trace means A keeps B alive (with a reference named c). B keeps C alive (with a reference named d). Therefore C cannot be garbage collected.

[A] 
--c--> [B] 
--d--> [C]

Now let's take a look at the leak trace from the tutorial:

[window](object) -> leakedObjects(property) -> [Array](object)
  -> 0(element) -> [Detached HTMLDIVElement](native)

It means the window object has a property named leakedObjects pointing to an Array in the web site under test in the tutorial. It is a contrived example just to demonstrate a leak example and what its leak trace looks like.

Therefore, unless your application contains a variable or object property named leakedObjects, the leak trace detected from your web app will not include the leakedObjects reference.

from memlab.

The traces from your web site do have some numbers, but they are not random numbers.

For instance, let's take a look at the first trace from your reports:

[] (synthetic) @1 [5.3MB]
--2 (shortcut)---> [Window / http://localhost:8000] (object) @9823 [48.6KB]
--require (property)---> [requirejs] (closure) @69911 [3.1KB]
--s (property)---> [Object] (object) @69913 [212 bytes]
--contexts (property)---> [Object] (object) @54171 [96 bytes]
--_ (property)---> [Object] (object) @54173 [2.3KB]
--defined (property)---> [Object] (object) @53929 [37.8KB]
--preact/compat (property)---> [Object] (object) @54089 [9.3KB]
--useTransition (property)---> [K] (closure) @137041 [68 bytes]
--context (internal)---> [] (object) @122325 [116.3KB]
--U (variable)---> [p] (object) @227695 [107.6KB]
--__P (property)---> [Detached HTMLElement] (native) @212991 [105.4KB]
--11 (element)---> [Detached InternalNode] (native) @262836032 [228 bytes]
--2 (element)---> [Detached DOMTokenList] (native) @213075 [84 bytes]

[] (synthetic) @1 [5.3MB] --2 (shortcut)---> [Window / http://localhost:8000] means the GC root has a native shortcut reference (with index 2) pointing to the Window object.

However, most of the time you don't need to fully understand the entire trace to debug memory leaks. You only need to find the top-most detached DOM element and start working backwards:

The part that is particular interesting is this:

--_ (property)---> [Object] (object) @54173 [2.3KB]
--defined (property)---> [Object] (object) @53929 [37.8KB]
--preact/compat (property)---> [Object] (object) @54089 [9.3KB]
--useTransition (property)---> [K] (closure) @137041 [68 bytes]
--context (internal)---> [] (object) @122325 [116.3KB]
--U (variable)---> [p] (object) @227695 [107.6KB]
--__P (property)---> [Detached HTMLElement] (native) @212991 [105.4KB]

It seems that your code uses preact. This module uses a hook called useTransition, which includes a callback that keeps a variable (@122325) alive within its surrounding closure context.

Notice that I'm thinking out loud on how we debug memory leak traces without using the code links. In this case, however, it appears the website under test is minified; so investigating the code related to the leak based on the minified names are difficult.

To determine the actual function name of K, the real variable name of U, and the real constructor name of p, you should run memlab on the un-minified version of your website. Once you have those actual names in your code, it's easy to search and narrow down to the code and files that generates this reference chain.

PS: If your website is un-minified but you are using a minfied preact library, it is likely that preact may have a memory leak.

from memlab.

The reason why Chrome DevTools can provide the code link but MemLab cannot is because each closure instance in the heap snapshot contains a scriptId number, which is just a reference number for the JS source code loaded in Chrome's memory. Chrome DevTools can use this scriptId key to map and query source code. However, Chrome does not save the information mapped by the scriptId to disk, which means MemLab cannot query the mapped information based on scriptId.

from memlab.