Common causes of memory leaks in extensions

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 certain circumstances, such as when a window is closed, a page unloads, or an extension is disabled or removed. While bug 695480 should prevent most of these compartment leaks, add-ons still need to be aware of the practices that caused these leaks, as the fix causes many add-ons which would have otherwise caused a leak to instead throw errors when attempting to access nodes from documents which no longer exist.

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 declare local variables with var or let, 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.

To avoid these issues, references to DOM nodes in foreign document should instead be stored in an object which is specific to that document, and cleaned up when the document is unloaded, or stored as weak references.

Be careful with setInterval/setTimeout

Using window.setInterval() or window.setTimeout() can be problematic, too, when it comes to zombie compartments. Consider the following example code that could be part of your browser.xul overlay:

gBrowser.addEventListener("DOMContentLoaded", function(evt) {
  var contentDoc = evt.originalTarget;
  var i = 0;
  // Refresh the title once each second
  setInterval(function() {
    contentDoc.title = ++i;
  }, 1000);
}, false);

One would normally expect that the interval (or timer) would be destroyed as soon as the document unloads, in the same way that event listeners are automatically destroyed. However, while this is still true, the window.setInterval() in the example originates from the outer chrome window (browser.xul) and not from the content window. Hence the interval will only be destroyed when the outer window is unloaded (i.e. when the user closes the whole browser window) but not when the content window unloads (i.e. when the user closes the tab). The interval function in the example would still hold a reference to contentDoc, therefore leaking the content document and the associated window and compartment.

If your add-on makes use of long-lived timeouts or uses window.setInterval(), you need to take special care to ensure your code won't accidentally leak content windows. Therefore, your add-on should clean up such intervals and timeouts when the corresponding content document is unloaded, by adding an unload event listener or by similar means. Another solution would be to use the setInterval()/setTimeout() instances content windows provide, but there is a big drawback with this idea: If the user disables JavaScript globally or locally (such as by using an add-on like NoScript), then using the content window functions won't work.

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, the following code snippets — part of a bootstrap.js — will leak:

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;
}
function modifyDocument2(document) {
  // The "body" DOM node holding a reference to leakref will prevent
  // that function object from being garbage collected and hence
  // will leak the whole bootstrap compartment.
  document.body.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 or 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);
}

Causes of other kinds of leaks

Other than JavaScript compartments, add-ons may also leak entities that 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:

var myObserver = {
  observe: function(subject, topic, data) {
    window.document.documentElement.setAttribute(
      "pbm", (data == "enter") ? "private" : "normal");
  }
};
Services.obs.addObserver(myObserver, "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 nsIObserverService.removeObserver() in an unload event listener. You may also specify ownsWeak = true in the call to nsIObserverService.addObserver(), but that might require you to properly implement weak references as well.

In overlay code you may use an unload event listener:

addEventListener("unload", function() {
  Services.obs.removeObserver(myObserver, "private-browsing");
}, false);

In bootstrap.js (restartless add-ons) unregister your observer in your shutdown function:

function shutdown() {
  // ...
  Services.obs.removeObserver(myObserver, "private-browsing");
}

In JavaScript code modules it recommended to also observe the xpcom-shutdown or quit-application notifications and unregister your observers from that topic:

var myObserver = {
  observe: function(subject, topic, data) {
    if (topic == "xpcom-shutdown") {      
      Services.obs.removeObserver(myObserver, "private-browsing");
      Services.obs.removeObserver(myObserver, "xpcom-shutdown");
    }
    else {
      // do something with "private-browsing"
    }
  }
};
Services.obs.addObserver(myObserver, "private-browsing", false);
Services.obs.addObserver(myObserver, "xpcom-shutdown", false);

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. 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.

The following example shows how to unload your modules again (bootstrap.js):

Components.utils.import("resource://gre/modules/Services.jsm");
function startup(data, reason) {
  // This assumes your add-on did register some chrome
  Components.utils.import("chrome://myaddon/content/mymodule.jsm");
}
function shutdown(data, reason) {
  // No need to do regular clean up when the application is closed
  // unless you need to break circular references that might negatively
  // impact the shutdown process.
  if (reason == APP_SHUTDOWN) return;
  // Your add-on needs to unload all modules it ships and imported!
  Components.utils.unload("chrome://myaddon/content/mymodule.jsm");
}

Other information

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