Open Bug 850456 Opened 11 years ago Updated 2 years ago

Closing initial chrome browser window leaks chrome window

Categories

(Core :: General, defect)

x86
Windows XP
defect

Tracking

()

People

(Reporter: morac, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [MemShrink:P2])

Attachments

(1 file)

I developed a test add-on I used to test my restartless add-ons for memory leaks.  This add-on creates an object containing a very large (circa 26 MB) string and adds it to the chrome window object during the window load event.  Since the add-on loads in the window compartment and doesn't add any observers or eventhandlers, closing the browser window should destroy the object with the string and release the memory.

For all windows, except the initial browser window, that is true. The initial browser chrome window though leaks the object when closed.  I've tested this in new profile with Firefox 19 through the Trunk 22.0a loads as well as the SeaMonkey trunk and in all cases the string is not destroyed when the first browser window is closed.

Test configuration:
- New Firefox profile under Windows XP SP3
- Tested Firefox 19.0.2 and 22.0a1 (2013-03-12) as well as SeaMonkey.
- No add-ons installed (save the leak test add-on).
- All plugins disabled

Steps to reproduce:
1. Install attached add-on and restart.
2. Open new additional browser window and go to about:memory in that window.
3. Close the initial browser window.
4. Click minimize memory usage button on about:memory page a few times.

Expected results:
Under the window-objects entry at the top there should not be a "top(none)/detached/window([system])" entry (or if there is one it should not contain a "strings/normal" entry and it's memory usage should be tiny) and "strings/normal" entries and the Other Measurements section at the bottom should indicate the strings size of about 27 MB:

60.01 MB (100.0%) -- js-main-runtime
├──45.29 MB (75.46%) -- compartments
│  ├──40.63 MB (67.69%) -- gc-heap
│  │  ├──27.40 MB (45.66%) -- strings
│  │  │  ├──27.11 MB (45.18%) ── normal

Actual results:

The windows-object contains a large "top(none)/detached/window([system])" which contains the leaked string object and the Other Measurements section at the bottom should indicate the strings size of about 54 MB, double what it should be.

│   ├──29.52 MB (25.30%) -- top(chrome://browser/content/browser.xul, id=47)/active
│   │  ├──29.39 MB (25.19%) -- window(chrome://browser/content/browser.xul)
│   │  │  ├──28.31 MB (24.27%) -- js/compartment([System Principal], about:blank)
│   │  │  │  ├──27.97 MB (23.98%) -- gc-heap
│   │  │  │  │  ├──26.70 MB (22.89%) ── strings/normal
│   │  │  │  │  └───1.27 MB (01.09%) ++ (6 tiny)
│   │  │  │  └───0.34 MB (00.29%) ++ (5 tiny)
│   │  │  └───1.07 MB (00.92%) ++ (4 tiny)
│   │  └───0.13 MB (00.11%) ++ window(about:blank)
│   ├──28.31 MB (24.26%) -- top(none)/detached/window([system])
│   │  ├──28.31 MB (24.26%) -- js/compartment([System Principal], about:blank)
│   │  │  ├──27.97 MB (23.97%) -- gc-heap
│   │  │  │  ├──26.70 MB (22.89%) ── strings/normal
│   │  │  │  └───1.27 MB (01.08%) ++ (6 tiny)
│   │  │  └───0.34 MB (00.29%) ++ (6 tiny)
│   │  └───0.00 MB (00.00%) ++ dom


88.34 MB (100.0%) -- js-main-runtime
├──73.74 MB (83.48%) -- compartments
│  ├──68.75 MB (77.83%) -- gc-heap
│  │  ├──54.11 MB (61.25%) -- strings
│  │  │  ├──53.82 MB (60.92%) ── normal


Other info:

Basically the memory for the initial chrome window is never released when that window is closed.  This is only true if the initial browser window is closed.  New windows can be opened as many times as wanted and when they are closed all memory used by the inserted giant string object will be released (meaning chrome isn't leaking).
Can you reproduce the leak if you restart browser after installing an addon.
It is a known problem that there are leaks after installing addons.
Whiteboard: [MemShrink:P2] → [MemShrink]
(In reply to Olli Pettay [:smaug] from comment #1)
> Can you reproduce the leak if you restart browser after installing an addon.
> It is a known problem that there are leaks after installing addons.

Yes I can.
Kind of reminds me of bug 353851.
Could this be jetpack related?  I'll try to reproduce and get a CC log.
Assignee: nobody → continuation
Whiteboard: [MemShrink] → [MemShrink:P2]
Assignee: continuation → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: