1228730 - Memory leak on report-uri.io

Status: UNCONFIRMED

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

Description

[haarp]

- Go to report-uri.io, log in, navigate to https://report-uri.io/account/hpkp_real_time/
- Wait a couple of hours

Memory usage rises steadily. After 20 hours, Firefox is using 10GB RAM. It normalizes again somewhat after closing the tab.

This was noticed on Firefox 42 under Linux Mint

Comment 1

[:Gijs (he/him)]

Apologies, this report fell through the cracks. Can you still reproduce this issue on a recent version of Firefox with a clean Firefox profile ( https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles ) ? If so, can you use about:memory to post before/after memory logs? Thank you!

Comment 2

[haarp]

Attachment: before memory log

Yes, it is still happening. This was tested on Linux Mint 18, Firefox 54.0 and a fresh profile.

Comment 3

[haarp]

Attachment: memory-report-after.json.gz

The content process was using several gigabytes after merely monitoring

https://report-uri.io/account/live/hpkp/

for half a day or so.

Comment 4

[:Gijs (he/him)]

From the diff:

6,075.80 MB (100.0%) -- explicit
├──5,964.97 MB (98.18%) -- window-objects/top(https://report-uri.io/account/live/hpkp/, id=NNN)
│  ├──3,914.98 MB (64.44%) -- active/window(https://report-uri.io/account/live/hpkp/)
│  │  ├──3,396.42 MB (55.90%) -- dom
│  │  │  ├──3,396.24 MB (55.90%) ── orphan-nodes
│  │  │  └──────0.18 MB (00.00%) ++ (2 tiny)
│  │  ├────517.80 MB (08.52%) -- js-compartment(https://report-uri.io/account/live/hpkp/)
│  │  │    ├──517.78 MB (08.52%) -- classes
│  │  │    │  ├──193.66 MB (03.19%) -- class(Function)/objects
│  │  │    │  │  ├──169.51 MB (02.79%) ── gc-heap
│  │  │    │  │  └───24.15 MB (00.40%) ── malloc-heap/slots
│  │  │    │  ├──140.33 MB (02.31%) -- class(Object)/objects
│  │  │    │  │  ├───88.97 MB (01.46%) -- malloc-heap
│  │  │    │  │  │   ├──84.63 MB (01.39%) ── slots
│  │  │    │  │  │   └───4.34 MB (00.07%) ── elements/normal
│  │  │    │  │  └───51.36 MB (00.85%) ── gc-heap
│  │  │    │  ├──121.26 MB (02.00%) -- class(Call)/objects
│  │  │    │  │  ├──120.64 MB (01.99%) ── gc-heap
│  │  │    │  │  └────0.62 MB (00.01%) ── malloc-heap/slots
│  │  │    │  └───62.52 MB (01.03%) ++ (9 tiny)
│  │  │    └────0.02 MB (00.00%) ++ (6 tiny)
│  │  └──────0.76 MB (00.01%) ++ (3 tiny)
│  └──2,049.99 MB (33.74%) -- js-zone(0xNNN)
│     ├──2,026.47 MB (33.35%) ++ strings
│     └─────23.52 MB (00.39%) ++ (9 tiny)
└────110.83 MB (01.82%) ++ (9 tiny)


So just over half of the 6GB diff is DOM orphan-nodes, and then there's another 40% that's js zones. Andrew, can you forward this to someone who can dig further based on this and see where we're going wrong?

Comment 5

[Ben Kelly [:bkelly, not reviewing]]

If closing the tab removes the memory this could be a bug in the site.  How do other browsers perform on this page?

Comment 6

[Andrew McCreight [:mccr8]]

Yeah, what Ben said. Any site that has some kind of scrolling news feed kind of thing can end up leaking, if they hide expired things in the feed, but fail to drop all references to them. If Chrome doesn't experience the same issue, maybe there is a Firefox bug that is causing it, or maybe we're served different JS.

Comment 7

[haarp]

You are correct, this does appear to be a site bug. I am seeing the same leak in Chromium, although the rate at which memory consumption rises appears to be lower, in the order of ~ 1.5GB in 12h

Should this be closed?