Open Bug 1228730 Opened 5 years ago Updated 2 years ago

Memory leak on report-uri.io

Categories

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

42 Branch
x86_64
Linux
defect

Tracking

()

UNCONFIRMED

People

(Reporter: liquitsnake, Unassigned)

Details

(Keywords: memory-leak, Whiteboard: [qf-])

Attachments

(2 files)

69.70 KB, application/gzip
Details
274.46 KB, application/gzip
Details
- 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
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!
Component: General → Untriaged
Flags: needinfo?(liquitsnake)
Attached file before memory log
Yes, it is still happening. This was tested on Linux Mint 18, Firefox 54.0 and a fresh profile.
The content process was using several gigabytes after merely monitoring

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

for half a day or so.
Flags: needinfo?(liquitsnake)
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?
Component: Untriaged → DOM
Flags: needinfo?(continuation)
Keywords: mlk
Product: Firefox → Core
Whiteboard: [qf]
If closing the tab removes the memory this could be a bug in the site.  How do other browsers perform on this page?
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.
Flags: needinfo?(continuation)
Whiteboard: [qf] → [qf-]
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?
Priority: -- → P5
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.