joelpt / sidewise

Persistent sidebar extension for Chrome featuring tree style tabs and tab hibernation.
Creative Commons Zero v1.0 Universal
68 stars 13 forks source link

memory leak in logging.js #39

Open zorael opened 11 years ago

zorael commented 11 years ago

Kubuntu 12.10b, chromium-browser package version 23.0.1271.10~r158896-0ubuntu1, Sidewise 2012.8.14.0.

Interacting with the sidebar makes the extension's memory use soar by a few megabytes per action, in tandem with the GPU process' (as listed in chromium's task manager). Such include hibernating/waking tabs, focusing them, opening new, or simply mouseovering their entries. There is also often a noticeable delay before the tooltip pops up. Spending a minute just moving the mouse up and down, the linux OOM killer eventually kicks in and the extension is terminated. I have some 120 tabs hibernated. Animations are disabled.

Furthermore it also leaks if you don't directly interact with the sidebar, but merely keep it open in the background and letting it react to your normal browser use.

Enabling debug mode and monitoring the console when enabling the extension, there are some 20 error messages like so;

update @ Error (<anonymous>) 
  CallStack
    stack: Array[9]
      0: "Error (<anonymous>)"
      1: "log (/js/util/logging.js:4:245)"
      2: "PageTreeCallbackProxyListener (/js/ui/sidebars/pages.js:227:5)"
      3: "PageTreeCallbackProxy [as callbackProxyFn] (/js/bg/background.js:11:81)"
      4: "PageTree.updateNode (/js/bg/classes/PageTree.js:4:346)"
      5: "associateTabToPageNode (/js/bg/functions/associate.js:13:94)"
      6: "tryAssociateTab (/js/bg/functions/associate.js:6:276)"
      7: "Object.callback (/js/bg/functions/associate.js:4:465)"
      8: "Object.chromeHidden.handleResponse (sendRequest:49:24)"
      length: 9
    __proto__: Array[0]
  __proto__: CallStack
[...]

There are such errors for update, add, focusPage, remove, and probably some more I haven't been able to intentionally reproduce. There is also a related one (but not entirely similar) pertaining to onContextMenuShow yet inevitably ending in logging.js;

Error (<anonymous>) 
  CallStack {stack: Array[7]}
    stack: Array[7]
      0: "Error (<anonymous>)"
      1: "log (/js/util/logging.js:4:245)"
      2: "onContextMenuShow (/js/ui/sidebars/pages.js:406:5)"
      3: "FancyTree.enableContextMenu (/js/ui/classes/FancyTree.contextMenu.js:72:22)"
      4: "HTMLDivElement.FancyTree.onContextMenu (/js/ui/classes/FancyTree.contextMenu.js:36:31)"
      5: "HTMLDocument.f.event.dispatch (/js/jquery/jquery-1.7.2.min.js:3:4816)"
      6: "HTMLDocument.h.handle.i (/js/jquery/jquery-1.7.2.min.js:3:709)"
      length: 7
    __proto__: Array[0]
  __proto__: CallStack
[<li>, prevObject: e.fn.e.init[0], context: undefined]
[...]

I would try wiping the local storage entirely (in the spirit of 'have you tried turning if off and on again'), but for that I'd really want the functionality to flatfile export and import the tab list. Restoring the current table verbatim may well restore the memory leak behavior if the issue stems from errors there.

zorael commented 11 years ago

Example task manager screenshot: http://i.imgur.com/15r4u.png

(kernel memory deduplication is awesome.)

joelpt commented 11 years ago

Freaky. Looks like we're bumping into some kind of GPU related Chromium bug; I can't think of anything unusual that the extension is doing that would cause multi-MB jumps in something like mouseovering a row, which really isn't doing much more than updating a couple of variables and changing the CSS style of the affected row.

If you close the sidebar (either before or after the memory usage starts spiking), does that stop the RAM usage growth or reset it? If you then open some new tabs while the sidebar is closed, how does that affect the memory usage?

My suspicion is that we'll only see the crazy RAM consumption when the sidebar is visible, which would most likely point to a GPU related bug in Chromium.

Also, can you try adding --disable-accelerated-2d-canvas --disable-accelerated-compositing --disable-accelerated-layers to your chrome command line and see if that avoids the problem? You can view the about:gpu page to confirm this actually turns off GPU usage.

I have a feeling this one may wind up as a Chromium bug on crbug.com. While experiencing the problem, try going to chrome://tracing/, record for a few seconds while you do some mouseovering of the sidebar, then look at the results ... do you happen to see any unusually large concentrations of calls being performed? On my system, I saw at most a few thousand instances of any particular function being called in those few seconds.

Lastly, if you inspect the extension's background.html from the Extensions list, go to the Profiles tab, and "take heap snapshot", what is the total memory usage reported? I see about 5 MB used here, with about 30 tabs open.