Closed Bug 376476 Opened 14 years ago Closed 10 years ago
.open/window .close cause high JS heap fragmentation
After some more searching if found two other issues similair to mine. The issues ids are 333978 and 334225. Note that i can still use all the features of firefox/extentions. The only problem is the memory usage.
I definitely see the memory usage not being released, but I think that's expected as part of bfcache/caching of session history. Note that it doesn't go up indefinitely, just to a certain point, then it hovers around that point.
Product: Firefox → Core
QA Contact: general → general
(In reply to comment #0) > Build Identifier: (snip) Windows NT 5.1; ... > 2. Click the button and watch memory usage of firefox using the taskmanager. > 4.(snip) memory used by firefox increasing To Dave Mertens : (Q1) Same questions as Bug 320915 Comment #42. (a."Momory Usage" column? How about "Virtual Memory Size"? and so on) (b.If "Momory Usage" column, what happens when config.trim_on_minimize=true?) (Q2) Same asking as 320915 Comment #28. (Extensions are used? Even when new-profile? and so on) Anyway, read thru Bug 320915 first, please.
Bug 320915 Comment #28. Sorry for spam.
Sorry for the late response, but I received this morning the first feedback on this issue. I guess other mails ended up in my spam box. Currently i'm using 220.127.116.11, but the problem still remains. Firefox keeps claiming memory for each window/popup opened, with releasing that memory when it's closed. I've tested it with and without extensions, but it didn't make any difference. Again, the memory is fully released when firefox is closed itself. About the questions on #3: Q1.A: Both Memory and Virtual Memory columns keep increasing. The memory usage goes a bit harder up. Q1.B: In my case, memory usage remains the same. No increase or decrease. Q2: With- or without extensions didn't make any difference. I also want to note that Opera and Safari (for windows, beta) doesn't suffer of this problem. If MSIE is vulnerable, i don't know. (i)Explorer is to much integrated into windows to only look for memory usage of iexplorer.exe. But that keeps steady. IE7 with tabs also didn't visiblebly take more memory. But the memory of other browser keep incresing and decreasing, as where firefox keeps claiming memory. I hope this is of help.
(Q3) What is Firefox's behavior on Virtual Memory Size in next test? Does Virtual Memory Size of Firefox increase rapidly/infinitely? 0. Set startup page to blank (to simplify test case) 1. Start Firefox, and load local HTML which has buttons for "window.open()" and "window.close()" for 10 windows (disabling of POP up blocker is required) => VM_1 2. Open 10 windows => VM_2_A, and close the opened 10 windows => VM_2_B 3. Open 10 windows => VM_3_A, and close the opened 10 windows => VM_3_B 4. Open 10 windows => VM_4_A, and close the opened 10 windows => VM_4_B 5. Repeat open/close of 10 windows several times, and watch VM size How about browser.sessionhistory.max_total_viewers=0 case?
I can replicate a memory leak in the popup blocker with Mozilla Firefox 3 beta 3. Try out the attached test case. When you run the attached test case, a whole bunch of memory is used by the 'pageReport' object which contains references to all of the popups which have been blocked. Because the size of the pageReport object is not limited, the pagereport object can use up a lot of memory. When you close the tab, the memory used by the popup blocker continues to be used. I believe that this leak is due to a circular reference between the popup blocker, the notification bar, the document, and the window.
Haven't tried to reproduce but this has apparently morphed into a trunk/Gecko 1.9 bug and is not going to get resolved for Gecko 1.8.x. Clearing dependency.
No longer blocks: mlk1.8
Version: unspecified → Trunk
is there not a better component for this?
12 years ago
Component: General → DOM
QA Contact: general → general
Not tested this myself - but if it still repros, it sounds bad.
I can still reproduce this with Mozilla Firefox 3.5 Preview (3.5b99). Memory usage rises when I click the "options" button in the example test case in comment #7, and it never goes back down after. If you run the test case enough times, you can make Firefox use arbitrary amounts of memory.
Please re-nom after the bug has been confirmed.
There does seem to be a leak, at least if you bash Firefox with this script. The explicit allocations started out as 26MB, were 268MB after running the inner loop once, and dropped to 49MB after "Minimize Memory Use". The round of the internal loop takes about 30 seconds of CPU time, later rounds take somewhat more. Results from more rounds are listed below. The Explicit Allocation total from memory use (in MB): Initial value: 26MB After Run After "Minimize Memory Use" One round: 268 49 Second round: 314 78 After third: 314 88 Tried ten additional rounds and Firefox crashed. https://crash-stats.mozilla.com/report/index/bp-5b26923f-a15a-40dc-9db6-335c12110902 Restarted Firefox and the web page automatically reloaded and executed. After Run After "Minimize Memory Use" Ten rounds: 415 112 20 rounds: 143 (Contents of about:memory is below) The script doesn't always crash quickly. My first long attempt used over an hour of CPU time, but that experiment didn't finish as I needed to reboot my system. The process was using around 3GB of memory at the end. (Note to self: If one round of a test works, don't assume the next experiment should be 1000 rounds, at least not without measuring CPU time.) User Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:9.0a1) Gecko/20110831 Firefox/9.0a1 Main Process Explicit Allocations 147.52 MB (100.0%) -- explicit ├───90.34 MB (61.24%) -- js │ ├──73.46 MB (49.80%) -- gc-heap-chunk-dirty-unused │ ├───9.99 MB (06.77%) -- compartment([System Principal], 0x4a6a000) │ │ ├──4.74 MB (03.21%) -- gc-heap │ │ │ ├──2.17 MB (01.47%) -- objects │ │ │ ├──1.51 MB (01.02%) -- shapes │ │ │ ├──1.00 MB (00.68%) -- arena-unused │ │ │ └──0.06 MB (00.04%) -- (4 omitted) │ │ ├──1.82 MB (01.23%) -- (9 omitted) │ │ ├──1.75 MB (01.19%) -- mjit-code │ │ └──1.68 MB (01.14%) -- scripts │ ├───1.94 MB (01.32%) -- compartment(https://crash-stats.mozilla.com/report/i...) │ │ ├──1.00 MB (00.68%) -- (8 omitted) │ │ └──0.94 MB (00.64%) -- gc-heap │ │ └──0.94 MB (00.64%) -- (6 omitted) │ ├───1.43 MB (00.97%) -- (7 omitted) │ ├───1.34 MB (00.91%) -- gc-heap-chunk-admin │ ├───1.11 MB (00.75%) -- compartment(https://bugzilla.mozilla.org/show_bug.cg...) │ │ └──1.11 MB (00.75%) -- (9 omitted) │ └───1.07 MB (00.73%) -- compartment(atoms) │ └──1.07 MB (00.73%) -- (3 omitted) ├───31.65 MB (21.45%) -- heap-unclassified ├───21.43 MB (14.53%) -- storage │ └──21.43 MB (14.53%) -- sqlite │ ├──16.49 MB (11.18%) -- urlclassifier3.sqlite │ │ ├──16.41 MB (11.13%) -- cache-used │ │ └───0.08 MB (00.05%) -- (2 omitted) │ ├───2.12 MB (01.43%) -- (11 omitted) │ ├───1.90 MB (01.29%) -- places.sqlite │ │ ├──1.63 MB (01.11%) -- cache-used  │ │ └──0.27 MB (00.18%) -- (2 omitted) │ └───0.92 MB (00.63%) -- other ├────1.75 MB (01.19%) -- layout │ ├──1.30 MB (00.88%) -- arenas │ └──0.45 MB (00.30%) -- (1 omitted) ├────1.02 MB (00.69%) -- dom ├────0.88 MB (00.60%) -- xpti-working-set └────0.44 MB (00.30%) -- (3 omitted) Other Measurements 0.00 MB -- gfx-d2d-surfacecache 0.00 MB -- gfx-d2d-surfacevram 0.00 MB -- gfx-surface-image 0.36 MB -- gfx-surface-win32 143.90 MB -- heap-allocated 241.20 MB -- heap-committed 2.52 MB -- heap-dirty 762.10 MB -- heap-unallocated 2 -- js-compartments-system 6 -- js-compartments-user 82.00 MB -- js-gc-heap 1.57 MB -- js-gc-heap-arena-unused 0.00 MB -- js-gc-heap-chunk-clean-unused 73.46 MB -- js-gc-heap-chunk-dirty-unused 91.50% -- js-gc-heap-unused-fraction 278.05 MB -- private 286.36 MB -- resident 1,076.38 MB -- vsize
73.46 MB (49.80%) -- gc-heap-chunk-dirty-unused This is general js heap fragmentation.
Summary: Memory claimed by window.open function is never released → Many window.open/window.close cause high JS heap fragmentation
Whiteboard: [testday-20110902] → [see comment 13 and after][testday-20110902][MemShrink]
We're tracking something very similar in bug 668809, and that has more up to date information, duping forward.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: MatchStartupMem
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.