Closed Bug 376476 Opened 14 years ago Closed 10 years ago

Many cause high JS heap fragmentation


(Core :: DOM: Core & HTML, defect)

Windows XP
Not set





(Reporter: dmertens-mozilla-bugs, Unassigned)


(Keywords: memory-leak, Whiteboard: [see comment 13 and after][testday-20110902][MemShrink])


(3 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070312 Firefox/
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070312 Firefox/

When the javascript function is used to open a new popup (modal or modeless doesn't matter) memory is claimed to open the new window. When that window is close using the close or window.close() function the memory reserved for that windows is not released. 

Opening the same popup again results in firefox claiming even more memory. The only way to release the memory claimed by firefox is closing firefox fully. 

Reproducible: Always

Steps to Reproduce:
1. Put this code in a webpage:
<input type="button" onclick="'', 'popup', 'width=400,height=200', false);" />

2. Click the button and watch memory usage of firefox using the taskmanager.
3. Close the popup
4. repeat step 2 and 3 several times and you will see that memory used by firefox increasing
5. Close firefox (all windows/tabs)
6. Alle memory claimed by firefox is released
Actual Results:  
As described firefox keeps claiming memory with every popup, but never (until firefox self exits) releases that memory.

Expected Results:  
Memory claimed for opening the popup released or reused for new popups.

This issue also occurs on firefox 2.0.3. I haven't tested it on Linux, but i guess the issue is focussed on the 'gecko' rendering component.

As the memory is released by closing the firefox application I haven't filed this issue as critial, but normal as the impact is limited to memory usage.
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.
Keywords: mlk
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.
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, 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 "" 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?
Component: General → DOM
QA Contact: general → general
Not tested this myself - but if it still repros, it sounds bad.
Flags: blocking1.9.2?
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.
Flags: blocking1.9.2?
Keywords: qawanted
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.

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(
│   │   ├──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(
│   │   └──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 [4]
│      │   └──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
Keywords: qawanted
Whiteboard: [testday-20110902]
Ever confirmed: true
73.46 MB (49.80%) -- gc-heap-chunk-dirty-unused

This is general js heap fragmentation.
Summary: Memory claimed by function is never released → Many 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.
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.