Common causes of memory leaks in extensions

  • Revision slug: Extensions/Common_causes_of_memory_leaks_in_extensions
  • Revision title: Common causes of memory leaks in extensions
  • Revision id: 49895
  • Created:
  • Creator: Nmaier
  • Is current revision? No
  • Comment 26 words added, 20 words removed

Revision Content

This page explains coding patterns that cause extension to cause memory leaks.

Causes of zombie compartments

Zombie compartments are a particular kind of memory leak.  All zombie compartments in extensions are caused by a failure to release resources appropriately in a certain circumstances, such as when a window is closed, a page unloads, or an extension is disabled or removed.

Storing references to window objects and DOM nodes

The most common problem is extensions holding onto references to content windows for too long.

For example, in XUL overlay code:

var contentWindows = [];
function inBrowserXulOverlay(contentWindow) {
  // forgetting or failing to pop the content window thing again
  contentWindows.push(contentWindow);
}

This will keep the content window compartments alive until the browser window is closed. Users often only open a single browser window per session and use tabs, in which case the leaked compartments will live for the whole life of the session.

A similar problem is holding onto window objects or DOM nodes (such as window.document) for too long by storing them in a JavaScript module.  For example:

var windows = [];
function inJavascriptCodeModule(window) {
  // forgetting or failing to pop the window again
  windows.push(window);
}

Both of these cases can happen if you forget to prefix local variables with var, which means they end up belonging to the global scope.  For example:

function implicitDeclarationLeak(window) {
  // Implicit variable declaration in the js global, holding a strong ref to the document
  doc = window.document;
}

Implicitly declared variables can be avoided by using ECMAScript 5's strict mode.  Strict mode also excludes several other error-prone code patterns.

For some examples found in real-world add-ons, see bug 712733, bug 725875, and bug 727552.

Problems in bootstrapped (restartless) add-ons

Bootstrapped extensions use a bootstrap.js compartment. If you put a reference to anything within this compartment into a long-lived window object (such as browser.xul), JavaScript module or XPCOM component, the bootstrap.js compartment will become a zombie.  For example:

function leakref() {}

function modifyDocument(document) {
  var a = document.createElement("a");
  document.body.appendChild(a);

  // the new DOM node holding a reference to leakref
  // will prevent that function object from being garbage collected and hence
  // will leak the whole bootstrap compartment
  a.someProperty = leakref;
}

See also Kris Maglione's guide to cleaning up bootstrapped extensions.

Failing to clean up event listeners

Extensions can be disabled and removed by user actions, but it also happens when an add-on is updated. If a bootstrapped (restartless) extension fails to clean up event listeners when disabled/removed, the listeners will still reference the enclosing scope — usually the bootstrap.js Sandbox — and therefore keep that scope (and its enclosing compartment) alive until the window is unloaded. If the window in question is browser.xul or some long-lived web app such as Gmail, the leaked compartment might survive for quite some time.

function leakref() {}

function main(window) {
  // This is a potential leak, as the window (e.g. browser.xul) will hold on to
  // the leakref function and the enclosing compartment via the listener.
  window.addEventListener("leaky", leakref, true);

  // The following line still fails to avoid the leak, as useCapture differs
  // and removeEventListener will not remove anything.
  // This kind of subtle bug is very common.
  // unload(function() window.removeEventListener("leaky", leakref, false), window);

  // This is the right way to do it remove the listener.
  unload(function() window.removeEventListener("leaky", leakref, true), window);
}
Note: The unload() function is an external function which can be added in your add-on to easily provide a way to undo changes upon unloading of your add-on or a specific part/object. It is part of Edward Lee's restartless boilerplate.

Causes of other kinds of leaks

Other than Javascript compartments, add-ons may also leak "things" which do not get a dedicated compartment, most commonly chrome DOM windows and Javascript code modules.

Forgetting to unregister observers

Holding onto event observers for too long is another problem.  Observers that use strong references are a common cause of leaking whole chrome windows or Javascript code modules; it is possible to leak content windows, too, but that is less common.

Consider the following example:

Services.obs.addObserver({
  observe: function(s, t, d) {
    window.document.documentElement.setAttribute(
      "pbm", (d == "enter") ? "private" : "normal");
  }
}, "private-browsing", /* ownsWeak */ false);

The ownsWeak = false parameter causes the observer service to use a strong reference to the observer object, which will cause it to hold onto the whole window.

To avoid this problem explicitly call removeObserver in an unload event listener. You may also specify ownsWeak = true in the call to addObserver, but that might require you to properly implement weak references as well.

Finally, a lot of services other than nsIObserverService accept nsIObserver parameters or other interfaces and will keep strong references around. Please see the corresponding documentation of these services on how to properly unregister/remove your observers and components during unload.

Forgetting to unload Javascript modules in restartless add-ons

Another common cause of leaks is forgetting to unload JavaScript code modules in bootstrapped add-ons.  These leaks cannot be detected by looking at about:compartments or about:memory because such modules live within the main System compartment.

Also, when your add-on gets updated and re-enabled, the previous module version that is still loaded will be used, which might break your add-on entirely.

Other information

Also see Using XPCOM in JavaScript without leaking (though that page could use some updating).

Revision Source

<p>This page explains coding patterns that cause extension to cause memory leaks.</p>
<h2>Causes of zombie compartments</h2>
<p><a href="/en/Zombie_compartments" title="Zombie compartments">Zombie compartments</a> are a particular kind of memory leak.  All zombie compartments in extensions are caused by a failure to release resources appropriately in a certain circumstances, such as when a window is closed, a page unloads, or an extension is disabled or removed.</p>
<h3>Storing references to <code>window</code> objects and DOM nodes</h3>
<p>The most common problem is extensions holding onto references to content windows for too long.</p>
<p>For example, in XUL overlay code:</p>
<pre class="brush: js">var contentWindows = [];
function inBrowserXulOverlay(contentWindow) {
  // forgetting or failing to pop the content window thing again
  contentWindows.push(contentWindow);
}
</pre>
<p id="comment_text_7">This will keep the content window compartments alive until the browser window is closed. Users often only open a single browser window per session and use tabs, in which case the leaked compartments will live for the whole life of the session.</p>
<p>A similar problem is holding onto<code> window</code> objects or DOM nodes (such as <code>window.document</code>) for too long by storing them in a JavaScript module.  For example:</p>
<pre class="brush: js">var windows = [];
function inJavascriptCodeModule(window) {
  // forgetting or failing to pop the window again
  windows.push(window);
}
</pre>
<p>Both of these cases can happen if you forget to prefix local variables with <code>var</code>, which means they end up belonging to the global scope.  For example:</p>
<pre class="brush: js">function implicitDeclarationLeak(window) {
  // Implicit variable declaration in the js global, holding a strong ref to the document
  doc = window.document;
}
</pre>
<p>Implicitly declared variables can be avoided by using <a href="/en/JavaScript/Reference/Functions_and_function_scope/Strict_mode" title="en/JavaScript/Strict_mode">ECMAScript 5's strict mode</a>.  Strict mode also excludes several other error-prone code patterns.</p>
<p>For some examples found in real-world add-ons, see <a class="link-https" href="https://bugzilla.mozilla.org/show_bug.cgi?id=712733#c17" title="https://bugzilla.mozilla.org/show_bug.cgi?id=712733#c17">bug 712733</a>, <a class="link-https" href="https://bugzilla.mozilla.org/show_bug.cgi?id=725875" title="https://bugzilla.mozilla.org/show_bug.cgi?id=725875">bug 725875</a>, and <a class="link-https" href="https://bugzilla.mozilla.org/show_bug.cgi?id=727552#c3" title="https://bugzilla.mozilla.org/show_bug.cgi?id=727552#c3">bug 727552</a>.</p><h3>Problems in bootstrapped (restartless) add-ons</h3>
<p id="comment_text_7">Bootstrapped extensions use a <code>bootstrap.js</code> compartment. If you put a reference to anything within this compartment into a long-lived window object (such as <code>browser.xul</code>), JavaScript module or XPCOM component, the <code>bootstrap.js</code> compartment will become a zombie.  For example:</p>
<pre class="brush: js">function leakref() {}

function modifyDocument(document) {
  var a = document.createElement("a");
  document.body.appendChild(a);

  // the new DOM node holding a reference to leakref
  // will prevent that function object from being garbage collected and hence
  // will leak the whole bootstrap compartment
  a.someProperty = leakref;
}
</pre>
<p>See also Kris Maglione's <a class="external" href="http://maglione-k.users.sourceforge.net/bootstrapped.xhtml" title="http://maglione-k.users.sourceforge.net/bootstrapped.xhtml">guide to cleaning up bootstrapped extensions</a>.</p>
<h3>Failing to clean up event listeners</h3>
<p>Extensions can be disabled and removed by user actions, but it also happens when an add-on is updated. If a bootstrapped (restartless) extension fails to clean up event listeners when disabled/removed, the listeners will still reference the enclosing scope — usually the <code>bootstrap.js</code> Sandbox — and therefore keep that scope (and its enclosing compartment) alive until the window is unloaded. If the window in question is <code>browser.xul</code> or some long-lived web app such as Gmail, the leaked compartment might survive for quite some time.</p>
<pre class="brush: js">function leakref() {}

function main(window) {
  // This is a potential leak, as the window (e.g. browser.xul) will hold on to
  // the leakref function and the enclosing compartment via the listener.
  window.addEventListener("leaky", leakref, true);

  // The following line still fails to avoid the leak, as useCapture differs
  // and removeEventListener will not remove anything.
  // This kind of subtle bug is very common.
  // unload(function() window.removeEventListener("leaky", leakref, false), window);

  // This is the right way to do it remove the listener.
  unload(function() window.removeEventListener("leaky", leakref, true), window);
}
</pre>
<div class="note"><strong>Note:</strong> The <em>unload()</em> function is an <a class="link-https" href="https://github.com/Mardak/restartless/blob/unload/bootstrap.js" title="unload() boilerplate">external function</a> which can be added in your add-on to easily provide a way to undo changes upon unloading of your add-on or a specific part/object. It is part of <a class="link-https" href="https://github.com/Mardak/restartless/">Edward Lee's restartless boilerplate</a>.</div>
<h2>Causes of other kinds of leaks</h2>
<p>Other than Javascript compartments, add-ons may also leak "things" which do not get a dedicated compartment, most commonly chrome DOM windows and Javascript code modules.</p>
<h3>Forgetting to unregister observers</h3>
<p>Holding onto event observers for too long is another problem.  Observers that use strong references are a common cause of leaking whole chrome windows or Javascript code modules; it is possible to leak content windows, too, but that is less common.</p>
<p>Consider the following example:</p>
<pre class="brush: js">Services.obs.addObserver({
  observe: function(s, t, d) {
    window.document.documentElement.setAttribute(
      "pbm", (d == "enter") ? "private" : "normal");
  }
}, "private-browsing", /* ownsWeak */ false);
</pre>
<p>The <code>ownsWeak = false</code> parameter causes the observer service to use a strong reference to the observer object, which will cause it to hold onto the whole window.</p>
<p>To avoid this problem explicitly call <a href="/en/XPCOM_Interface_Reference/nsIObserverService/removeObserver" title="removeObserver"><code>removeObserver</code></a> in an unload event listener. You may also specify <code>ownsWeak = true</code> in the call to <a href="/en/XPCOM_Interface_Reference/nsIObserverService/addObserver" title="addObserver"><code>addObserver</code></a>, but that might require you to properly implement weak references as well.</p>
<p>Finally, a lot of services other than <a href="/ja/XPCOM_Interface_Reference/nsIObserverService" title="nsIObserverService"><code>nsIObserverService</code></a> accept <a href="/en/XPCOM_Interface_Reference/nsIObserver" title="nsIObserver"><code>nsIObserver</code></a> parameters or other interfaces and will keep strong references around. Please see the corresponding documentation of these services on how to properly unregister/remove your observers and components during unload.</p><h3>Forgetting to unload Javascript modules in restartless add-ons</h3>
<p>Another common cause of leaks is forgetting to <a href="/en/Components.utils.unload" title="Components.utils.unload">unload</a> JavaScript code modules in bootstrapped add-ons.  These leaks cannot be detected by looking at about:compartments or about:memory because such modules live within the main System compartment.</p>
<p>Also, when your add-on gets updated and re-enabled, the previous module version that is still loaded will be used, which might break your add-on entirely.</p>
<h2>Other information</h2>
<p>Also see <a href="/en/Using_XPCOM_in_JavaScript_without_leaking" title="Using XPCOM in JavaScript without leaking">Using XPCOM in JavaScript without leaking</a> (though that page could use some updating).</p>
Revert to this revision