1590632 - High heap-unclassified memory browsing https://www.zedzone.space/amp/

Status: RESOLVED WORKSFORME

(Core :: Performance: General, defect, P3)

Description

[no]

Attachment: report 2 is shortly after opening firefox from nothing and going to the page. memory report 3 is after a few hours in the garden. memory report 4 is immediately after pressing "Minimize[sic] memory usage"

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

Starting from a fresh invocation of firefox, I opened a single web page, my amplifier control panel.

After a few hours it used over 1GB of memory. Running "Free Memory" from about:memory wiped out most of that 1GB+.

Actual results:

Firefox used 1GB to display a simple web application but most of it went away after running a gc run.

This was enough to force my computer to use swap.

Expected results:

It should run the garbage collector within that time by itself.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Andrew McCreight [:mccr8]]

Jon, can you take a look?

Comment 3

[Jon Coppeard (:jonco)]

This is a little surprising:

1,321.11 MB (100.0%) -- explicit
├──1,122.45 MB (84.96%) ── heap-unclassified

Bug 1549807 is related to this kind of problem.

Comment 4

[Jon Coppeard (:jonco)]

Thanks for reporting this. Is it possible to share the URL that triggered this problem? Also, which platform are you using?

Comment 5

[Jon Coppeard (:jonco)]

I heard back from the reporter via email. The URL is an internal application that we don't have access to.

Comment 6

[no]

I've extracted the local device app to a separate web page: https://www.zedzone.space/amp/ This only mimicks part of the functionality and obviously does nothing to the real machine. Load the page then go to 'Zone 2'. After startup it performs the same 3 xml queries every second. It should run with no http errors although the latency can be a bit high.

I've been running this for ~24 hours on an older version of firefox (52.0 / linux / amd64) using a new/unmodified profile (no settings changes) and it clears down memory once it gets to about +100MB usage which is as expected (i.e. hovers from X to X+100MB). I can't run it on the original reporting machine at the moment as i've had to reroute my network temporarily due to physical accessibility reasons (yay i broke my hip falling off a bicycle).

I guess I can download any other version and try it on that if you want.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:jonco, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

[no]

Attachment: memory-13.tar

report 1 is immediately after opening the application then the web page and then about:memory

report 3 is after 8 hours.

Comment 9

[no]

I've run this on the latest public download (70.0.1) against the url i supplied earlier. Using a non-altered profile (default everything).

After 8 hours it grows by about 300MB. See memory-13.tar for memory dumps.

Comment 10

[no]

After 24 hours it ran the GC (at some point). This is the significant part of the memory diff between 12 hours and 24 hours:

Web Content (pid NNN)
Explicit Allocations

-519.27 MB (100.0%) -- explicit
├──-465.35 MB (89.62%) ── heap-unclassified
├───-33.78 MB (06.51%) -- window-objects
│ ├──-32.02 MB (06.17%) -- top(https://www.zedzone.space/amp/, id=NNN)
│ │ ├──-31.08 MB (05.99%) -- active/window(https://www.zedzone.space/amp/)
│ │ │ ├──-16.75 MB (03.23%) -- js-realm(https://www.zedzone.space/amp/)
│ │ │ │ ├──-15.52 MB (02.99%) -- classes
│ │ │ │ │ ├──-10.22 MB (01.97%) ++ (9 tiny)
│ │ │ │ │ └───-5.30 MB (01.02%) ── class(HTMLCollection)/objects/gc-heap
│ │ │ │ └───-1.23 MB (00.24%) ++ (5 tiny)
│ │ │ ├──-14.36 MB (02.77%) -- dom
│ │ │ │ ├──-14.36 MB (02.77%) ── event-targets
│ │ │ │ └────0.00 MB (-00.00%) ++ (2 tiny)
│ │ │ └────0.03 MB (-00.01%) ++ layout
│ │ └───-0.93 MB (00.18%) ++ js-zone(0xNNN)
│ └───-1.76 MB (00.34%) ++ top(about:newtab, id=NNN)
├───-14.65 MB (02.82%) -- js-non-window
│ ├──-13.42 MB (02.58%) -- runtime
│ │ ├──-12.26 MB (02.36%) -- gc
│ │ │ ├──-11.00 MB (02.12%) ── nursery-committed [2]
│ │ │ └───-1.26 MB (00.24%) ++ (2 tiny)
│ │ └───-1.16 MB (00.22%) ++ (6 tiny)
│ └───-1.23 MB (00.24%) ++ (2 tiny)
├────-8.77 MB (01.69%) ++ (7 tiny)
└─────3.28 MB (-00.63%) -- heap-overhead
├──7.85 MB (-01.51%) ── bin-unused [2]
├──-5.23 MB (01.01%) ── bookkeeping [2]
└──0.67 MB (-00.13%) ── page-cache [2]

Comment 11

[Jon Coppeard (:jonco)]

The memory report indicates that this is probably not related to GC but another part of the browser (JS memory is relatively small).

Comment 12

[Ethan Tseng [:ethan]]

Patricia, it seems hard to debug heap-unclassfied memory issues like this. Does your team have strategies of tackling this kinid of problem?

Comment 13

[Bas Schouten (:bas.schouten)]

There's no really good way at the moment to debug these heap unclassified issues by end-users. I did briefly discuss with Markus the idea of allowing the use of profile markers to determine which areas of the code allocations come from.

Comment 14

[Andrew McCreight [:mccr8]]

The profiler does have some kind of memory profiling. I'm not sure how useful that will be for issues like this that only show up over long periods of time.

Comment 15

[Denis Palmeiro [:denispal]]

I cannot reproduce this issue locally. Please reopen if the problem persists.