Closed Bug 1204445 Opened 10 years ago Closed 10 years ago

50MB memory leak per reload, Google Chart/SVG

Categories

(Firefox :: Untriaged, defect)

40 Branch
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: remid0d0s0, Unassigned)

Details

Attachments

(1 file)

Attached file output.html
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0 Build ID: 20150826023504 Steps to reproduce: The following file, which contains a few thousands of data points and some straightforward Google Charts calls, seems to cause profoundly large memory leaks in my current version of Firefox (40.0.3/Win 8/64) Actual results: Load file. Reload it. Reload it. Watch working set grow by about 50MB each iteration. I have AdBlock Plus installed, which of course causes hideous JS performance problems with Facebook etc. but I doubt it is the culprit here. But then, it may be. But either way it seems like reloading the page shouldn't just be deleting 50MB of RAM from my computer. Expected results: Firefox shouldn't leak enormous quantities of memory.
Summary: 50MB memory leak per reload, Google Chart/SGV → 50MB memory leak per reload, Google Chart/SVG
Suggestion: You should try trimming the data sets inside the file and seeing if that changes the severity or the character of the behavior. I had this file reloading itself every 30 sec when it was a fraction this size and didn't notice it bloating, at least not in a way that got my attention. I am used to Firefox hanging and hogging memory and whatnot and generally keep an eye on it with Resource Monitor. Although I have no real insight into the problem, I wonder, is there a threshold beyond which the garbage collection breaks down? A counter wrapping around or array overflowing or something like that, where GC works until there is "too many/much X" and then it doesn't work? Just a thought.
I turned my addons off, loaded the file in question (along with a couple other pages), saved about:memory, reloaded the file about 30 times while clicking "Minimize Memory Usage" every 10 reloads, saved about:memory again. The only thing happening between the graphs below is a bunch of reloads and 3 "Minimize Memory Usage." Is "decommitted" memory, memory that can be reused for new allocations/objects and/or returned to the OS (if the OS allows you to do that)? If so, why does decommitted memory continue to grow steadily even though there is nothing going on other than reload/re-render of a single page, even when I click the explicit "let go of all memory please" button? Before: 57.81 MB (100.0%) -- decommitted ├──56.14 MB (97.10%) -- js-non-window │ ├──56.14 MB (97.10%) ── gc-heap/decommitted-arenas │ └───0.00 MB (00.00%) ── runtime/gc/nursery-decommitted └───1.68 MB (02.90%) -- workers/workers(chrome) ├──1.01 MB (01.74%) ++ (2 tiny) └──0.67 MB (01.16%) -- worker(resource://gre/modules/PageThumbsWorker.js, 0x25595000) ├──0.67 MB (01.16%) ── gc-heap/decommitted-arenas └──0.00 MB (00.00%) ── runtime/gc/nursery-decommitted After: 377.69 MB (100.0%) -- decommitted ├──376.01 MB (99.56%) -- js-non-window │ ├──376.01 MB (99.56%) ── gc-heap/decommitted-arenas │ └────0.00 MB (00.00%) ── runtime/gc/nursery-decommitted └────1.68 MB (00.44%) ++ workers/workers(chrome)
It also appears that if you just leave https://developers.google.com/chart/interactive/docs/gallery/linechart sitting around, it manages to accumulate/leak/hoard/??? a ton of memory. After an hour or three of "sitting around" (this is essentially unchanged by manual GC/Minimize): │ ├────588.01 MB (31.03%) -- top(https://developers.google.com/chart/interactive/docs/gallery/linechart, id=202) │ │ ├──563.34 MB (29.73%) -- active │ │ │ ├──509.96 MB (26.91%) -- window(https://google-developers.appspot.com/chart/interactive/docs/gallery/linechart_e5ea964fb09dfd9289df352a399c2de2.frame?hl=en&redesign=true) │ │ │ │ ├──366.63 MB (19.35%) -- js-compartment(https://google-developers.appspot.com/chart/interactive/docs/gallery/linechart_e5ea964fb09dfd9289df352a399c2de2.frame?hl=en&redesign=true) │ │ │ │ │ ├──365.08 MB (19.27%) -- classes │ │ │ │ │ │ ├──242.21 MB (12.78%) -- class(Object) │ │ │ │ │ │ │ ├──228.38 MB (12.05%) -- objects │ │ │ │ │ │ │ │ ├──128.10 MB (06.76%) ── gc-heap │ │ │ │ │ │ │ │ └──100.28 MB (05.29%) -- malloc-heap │ │ │ │ │ │ │ │ ├───97.79 MB (05.16%) ── slots │ │ │ │ │ │ │ │ └────2.49 MB (00.13%) ── elements/non-asm.js │ │ │ │ │ │ │ └───13.83 MB (00.73%) ++ shapes │ │ │ │ │ │ ├───79.65 MB (04.20%) -- class(Array) │ │ │ │ │ │ │ ├──79.65 MB (04.20%) -- objects │ │ │ │ │ │ │ │ ├──63.21 MB (03.34%) ── gc-heap │ │ │ │ │ │ │ │ └──16.43 MB (00.87%) ++ malloc-heap │ │ │ │ │ │ │ └───0.00 MB (00.00%) ++ shapes │ │ │ │ │ │ ├───38.03 MB (02.01%) -- class(Function) │ │ │ │ │ │ │ ├──21.20 MB (01.12%) ++ objects │ │ │ │ │ │ │ └──16.83 MB (00.89%) ++ shapes │ │ │ │ │ │ └────5.19 MB (00.27%) ++ (12 tiny) │ │ │ │ │ └────1.56 MB (00.08%) ++ (6 tiny) │ │ │ │ ├──139.92 MB (07.38%) -- dom │ │ │ │ │ ├──139.69 MB (07.37%) ── orphan-nodes │ │ │ │ │ └────0.23 MB (00.01%) ++ (5 tiny) │ │ │ │ └────3.41 MB (00.18%) ++ (3 tiny) │ │ │ └───53.38 MB (02.82%) ++ (9 tiny) │ │ └───24.67 MB (01.30%) ++ js-zone(0x1547fc00) Did a shift reload of that page, now it's magically 500MB smaller! │ ├───78.27 MB (05.16%) -- top(https://developers.google.com/chart/interactive/docs/gallery/linechart, id=202) │ │ ├──62.80 MB (04.14%) ++ active │ │ └──15.47 MB (01.02%) ++ js-zone(0x1547fc00)
Hi Joseph, I've tested your scenario on the latest release(42.0) and latest Nightly(45.0a1). When reloading the page, you can see inside task manager that Firefox's memory consumption goes up, but comes back down once the page is reloaded. This behavior is reproduced by Chrome and IE as well. I'm not sure about what your issue is here. Do you refer that after reload, Firefox keeps adding on 50 MB on memory consumption and eventually is using too much memory? Or are you referring to the exact behavior as encountered on my environment ? User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Build ID: 20151029151421 User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 Build ID: 20151203030226 Could you please try to reproduce this on the latest release(42.0) and latest Nightly(45.0a1) and provide the results? Maybe test this with a new Firefox profile or even in safe-mode. This could help to exclude some custom settings or extensions that could cause something like this (https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems). Thanks, Paul.
Flags: needinfo?(remid0d0s0)
Since the reporter didn't provide the requested information, I will mark this issue as RESOLVED INCOMPLETE. If you still encounter this problem, please feel free to reopen this bug, or file a new one.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Flags: needinfo?(remid0d0s0)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: