Closed Bug 1619772 Opened 5 years ago Closed 3 years ago

Lots of heap-unclassified in the main process after leaving the browser open

Categories

(Core :: Performance, defect)

73 Branch
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: alsoijw, Unassigned)

References

Details

Attachments

(5 files)

(deleted), application/octet-stream
Details
(deleted), application/gzip
Details
(deleted), application/octet-stream
Details
(deleted), application/x-gzip
Details
(deleted), application/octet-stream
Details
Attached file memory-reports.zip (deleted) —

User Agent: Mozilla/5.0 (X11; Linux i686; rv:73.0) Gecko/20100101 Firefox/73.0

Steps to reproduce:

I restart browser one time in many days, so it may work for two week for example. So, I have notice that it use too many memory. I have measured memory usage after start, then I surf. After I have worked I closed all opened tab except about:memory and measured again. And I repeated measuring after day later. I expect that I can to get back memory after closing tab, but memory usage by main proccess doesn't reduced, it is even increased.

Hello could you please provide more detailed steps on how to reproduce this issue like what webpages you are visiting and what addons you might have installed? Does this issue still occur with a new profile and on the latest nightly? Here is a link that describes how to create a new profile https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Multiple_profiles and from where you can download the latest nightly build https://nightly.mozilla.org/.

Mike can you please look into this memory report?

Flags: needinfo?(mconley)
Flags: needinfo?(alsoijw)

Hi alsoijw,

Did you happen to have any DevTools toolboxes open when you noticed the leak?

Yes, I am usually using DevTools. I noticed this problem in several different profile. On first profile I rarely open DevTools and I use this to surf Internet like regular user. In second profile I often use DevTools as develeoper.

There are some differences in extensions list. On each profile I'm using uBlock Origin and Smart HTTPS.

Flags: needinfo?(alsoijw)

And I view different pages in different profile, if it is important. I don't think that it depend of sites.

Attached file fm.tar.gz (deleted) —

This is measuring after start and some opened tabs in nightly build without any extension in empty profyle and I didn't open DevTool too.

I'm not seeing anything particularly unusual about the "memory-report-end" report in your latest attachment. At the point where you gathered it, were you experiencing excessive memory usage? How much?

Flags: needinfo?(mconley) → needinfo?(alsoijw)

At the beginning of measuring Main Process Explicit Allocation was 172.49 Mb. After some work it is 276.24 Mb so difference is 103.75 Mb. I expect that after I closed tabs memory usage will be reduce. It is quick test, when I open several tabs and closed it. When I use stable version, then difference between start usage and current usage become more bigger, because I use it not five minute but few days so Main Process can use more that 1 Gb. And browser still using this 1 Gb despite I close all tab and wait 30 minutes for example. So difference between initial memory usage and current memory usage become over 900 Mb. Are there any reasons why main process can use so many ram?

Flags: needinfo?(alsoijw)

Hi Mike!
When you have time, could you please take a look at the answer from the reporter?
Does it help us find the right component for this issue?
Do you have any ideas where it might fit?
Thank you!

Flags: needinfo?(mconley)

Hi alsoijw,

So difference between initial memory usage and current memory usage become over 900 Mb.

If you could capture the before and after states of this situation in an about:memory report, that'd be much more illustrative, I think.

Flags: needinfo?(mconley) → needinfo?(alsoijw)

Closing as Resolved: Incomplete due to no update from the reporter. If anyone can still reproduce this issue, please feel free to reopen the bug.
Thanks!

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
Attached file 30.08.2021.tar.gz (deleted) —

I'm sorry that I didn't answer for a long time, but it looks like I was able to reproduce this problem again. Now it's more that 900 Mb.

Flags: needinfo?(alsoijw)

Thank you for the reply!
Mike can you take a look at the memory report?

Status: RESOLVED → REOPENED
Ever confirmed: true
Flags: needinfo?(mconley)
Resolution: INCOMPLETE → ---

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core

Thanks alsoijw for coming back with the memory report!

I extracted the memory report that has the heavier memory usage and attached it above.

So two things jump out to me from this memory report:

  1. There's about 640MB of heap-unclassified in the parent process. This is effectively "dark matter", and the memory report can't tell what it is.
  2. There's a detached browser window apparently holding about 146MB of memory alive. So that sounds like a window leak to me.

Hey mccr8, does anything else jump out at you from this memory report?

Flags: needinfo?(mconley) → needinfo?(continuation)

Sorry I didn't reply to this in a timely fashion. I don't see anything else besides what you have in comment 15. The heap-unclassified does seem to be the main issue here. Maybe it is something related to graphics or devtools, but we can't really tell.

Component: DOM: Core & HTML → Performance
Flags: needinfo?(continuation)
Summary: Memory leak after long work → Lots of heap-unclassified in the main process after leaving the browser open

To get more information about where the heap unclassified memory is coming from, we would need a DMD report: https://firefox-source-docs.mozilla.org/performance/memory/dmd.html
Obtaining a DMD report is a bit of an involved process, but the output is really valuable. Do you think you could give it a try?

Flags: needinfo?(alsoijw)

Hey alsoijw, just wondering if you'd had a chance yet to look at the DMD documentation that mstange linked to in comment 17. Would you be willing to try to capture a DMD report?

I'll try to do it.

Flags: needinfo?(alsoijw)
Attached file dmd.tar.gz (deleted) —

Done.

Thanks for the report. I took a look at the included memory report and the heap-unclassified in the main process is around 136MB (14%) which doesn't see that out of the ordinary.

You'll probably also need to run dmd.py on the DMD file for the parent process before uploading it, or give some more information about the build, because it needs symbols. I'm not sure the best way to do that unfortunately.

(In reply to Andrew McCreight [:mccr8] from comment #21)

or give some more information about the build, because it needs symbols. I'm not sure the best way to do that unfortunately.

It looks like the DMD json does not contain any information about the build ID, or the debug IDs of the loaded libraries. I don't think we can add symbols at this point if we don't have that information.

Hi alsoijw, could you try to get another DMD report and then also run dmd.py as described under Processing the output? This would be very useful. Thank you!

Flags: needinfo?(alsoijw)

I'm going to close this bug for now because we unfortunately can't take any further action until we have a DMD report with symbols.

alsoijw, if you find time to get another DMD report and are able to attach the output of dmd.py, please reopen. Thanks!

Status: REOPENED → RESOLVED
Closed: 4 years ago3 years ago
Resolution: --- → INCOMPLETE
Flags: needinfo?(alsoijw)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: