8

I suspect my one-page javascript app contains a memory leak somewhere. Weak devices running Firefox or Chrome seem to crash eventually if the page is left open. I'm trying to determine whether reloading the page would be expected to free the memory or not.

I understand that memory handling is specific to the browser, so the answer may differ in Chrome or Firefox.

NOTE: I recognize that browsers are mentioned a lot in this question (which would be off topic), but the point of this question is about javascript debugging, which I think is very on topic.

emersonthis
  • 32,822
  • 59
  • 210
  • 375
  • can you show any code where you suspect it might be contained? – depperm Jan 22 '16 at 17:32
  • Does this help? http://stackoverflow.com/questions/19621074/finding-javascript-memory-leaks-with-chrome (Otherwise, refreshing would be expected to clear up memory usage, you're usually concerned with memory leaking within a "single page app") – mczepiel Jan 22 '16 at 17:32
  • @mczepiel Thanks that's helpful but doesn't seem to address the specific question about page reload. But your parenthetical does... can you elaborate on that in an answer? – emersonthis Jan 22 '16 at 17:36
  • @depperm I don't yet have the leak isolated to a specific area of code, and the SO rules are pretty strict about posting only "minimal" code samples. Also, although I'd welcome the help, the nature of this question is not about diagnosing my specific memory leak. Rather to determine the effectiveness of page reloads as a diagnostic technique. Make sense? – emersonthis Jan 22 '16 at 17:37

2 Answers2

3

Barring browser/extension bug, browsers free up resources when they are no longer needed; Firefox clears compartments, Chrome kills processes and associated storage.

Firefox does its best but may take some time to clear the memory and may create zombie compartments on occasion:

Compartments are destroyed when they are garbage collected. This happens some time after the last reference to them disappears. This means there can be a delay between a page being closed and its compartments disappearing...

Sometimes, due to bugs in Firefox, the Add-on SDK and/or add-ons, compartments are created that are never destroyed. These are a particular kind of memory leak, and they cause Firefox's memory usage to increase gradually over time, slowing it down and making it more likely to crash.

Chrome uses a process per tab (and really subprocesses for some entities within a tab as well IIRC e.g. plugins, iframes, etc.) to the same effect. Though a quick check against chrome://memory-redirect/ and refreshing a tab looks like the same pid is used. So a refresh is not a completely clean slate.

FWIW Chrome has a "Force Reload" that clears the cache and might be either useful for clearing more memory or a placebo: cmd-shift-r

I'm not really familiar with the internals but I've only seen things not reliably freed up between refreshes when a particular browser is getting too clever and trying to preserve things when you're not changing origins etc. in an effort to boost load performance.

In short, you could be tripping up a browser bug if you're not seeing memory freed as you expect but you'd want to use the various "about:memory" tools to verify that and at that point it would be on you to avoid such behavior and/or report the issue to the browser's dev team.

Otherwise, I think you're best served by addressing your own memory leaks within the page using the various tools available.

Community
  • 1
  • 1
mczepiel
  • 711
  • 3
  • 12
0

A good way to debug the resource usage of JS is to use the Firefox performance monitor within the inspection tool. Firefox Dev Edition has more in-depth tools

Press F12 when on the page and click on the little speedometer icon in the inspect window; this will open the performance monitor. Press the "Start Recording" button and Firefox will begin to benchmark all script timings, CSS activity, user input etc. on the page.

When you feel that it has been running for long enough, stop recording and you will be presented with all the data. At the top will be a chart displaying performance and you can click on any part and examine all the scripts running at that time.

A full tutorial for the performance tools can be found here

Syd Lambert
  • 1,415
  • 14
  • 16