1664271 - MainThread excessive memory usage on Fedora 32 MainThread goes up to to 10.3 GB firefox-80.0.1-2.

Status: RESOLVED INACTIVE

(Core :: Widget: Gtk, defect)

Description

[RobbieTheK]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36

Steps to reproduce:

Have a few open tabs

Actual results:

On Fedora 32, 5.8.6-201, MainThread goes up to to 10.3 GB! firefox-80.0.1-2.fc32.x86_64

top - 13:54:33 up 1 day, 13:50, 2 users, load average: 11.95, 10.92, 6.85
Tasks: 301 total, 1 running, 300 sleeping, 0 stopped, 0 zombie
%Cpu(s): 9.9 us, 5.8 sy, 0.0 ni, 3.7 id, 79.6 wa, 0.5 hi, 0.4 si, 0.0 st
MiB Mem : 7833.4 total, 180.4 free, 7094.5 used, 558.5 buff/cache
MiB Swap: 7632.0 total, 3366.1 free, 4265.9 used. 137.3 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
100678 ts 20 0 8334468 5.0g 55732 D 19.9 64.8 6:23.71 Web Content
73286 ts 20 0 3108680 62040 20024 S 11.1 0.8 136:15.77 Web Content
64663 ts 20 0 10.3g 359440 130660 D 10.5 4.5 582:54.71 MainThread

And the logs are peppered with:
firefox.desktop[66111]: (/usr/lib64/firefox/firefox:66111): Gdk-CRITICAL **: 12:57:35.797: gdk_screen_get_monitor_scale_factor: assertion 'monitor_num < gdk_screen_get_n_monitors (screen)' failed

Comment 1

[Florian Quèze [:florian]]

Thanks for opening the bug. It unfortunately doesn't contain enough information currently to figure out what's happening.

Opening the page about:memory and clicking the 'Measure' button there might give you a sense of where the memory is being used. You can also use the 'Measure and save…' button to generate a file with this information, and attach the file here if you think something is wrong and you would like some help to look at it.

Comment 2

[Pablo]

Hi robbie

I tried this today with the latest release version 80.0.1 and nightly version 82.0a1 on Ubuntu 20.04, sadly i dont have fedora at hand and i am unable to reproduce.
It would really help if you can provide a memory report from about:memory, here are the steps:

-Wait until Firefox is consuming a large amount of memory
-In the URL bar type about:memory and press enter
-Click "Measure and save" (optionally with "anonymize" checked to hide URLs, although this will likely make it more difficult for us to figure out which site, if any, is causing the leak)
-Save the memory report somewhere
-Attach the report to this bug

Another thing that would be great to have:

Please retest issue on latest nightly build, can be downloaded from here: https://nightly.mozilla.org/ and retest the problem.
Capture a performance profile using the Firefox built-in profiler. You can get more info on how to install and use the Firefox built-in profiler add-on (that helps you get the performance profile) by going to:
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler
http://profiler.firefox.com/
Please also note that the profiler works better on Firefox Nightly, so it's better if you are able to reproduce the issue on Nightly first.

Another thing that would be nice to try is running firefox with a brand new profile: you have the steps here:https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

Lastly test if the issue is reproducible in safe mode, here is a link that can help you:
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Regards
Pablo

Comment 3

[RobbieTheK]

Attachment: memory report from 9/20/2020 on firefox-80.0.1-2

Problem happened again over the weekend here's a memory report and Firefox is now firefox-80.0.1-2

Comment 4

[Pablo]

Hi Andrew.

I was not able to replicate this issue on Firefox with Ubuntu 20.04
Could you please advise what component we should send this bug to? there is a memory report attached

thank you.

Comment 5

[Andrew McCreight [:mccr8]]

It looks like the memory report didn't upload properly, so I am unable to open it.

Comment 6

[Pablo]

Hi Robbie, when i try to extract the .gz file from memory report from 9/20/2020 on firefox-80.0.1-2 i also get an error
Can you attach it again? thanks

Comment 7

[RobbieTheK]

Attachment: memory-report.json.gz

take 2

Comment 8

[RobbieTheK]

(In reply to Pablo from comment #6)

Hi Robbie, when i try to extract the .gz file from memory report from 9/20/2020 on firefox-80.0.1-2 i also get an error
Can you attach it again? thanks

I see the unexpected end of file error too, try using zcat or zless, both work for me.

Comment 9

[Andrew McCreight [:mccr8]]

(In reply to RobbieTheK from comment #8)

I see the unexpected end of file error too, try using zcat or zless, both work for me.

That works to extract the file, but the underlying json appears to be truncated. This is the end of the file:

  {
   "process": "web (pid 517520)",
   "path": "explicit/string-bundles/SharedStringBundle(url=\"chrome:\\\\global\\locale\\mathml\\mathml.properties\", shared=false, refCount=1)",
   "kin

Comment 10

[RobbieTheK]

Attachment: memory-report.json

Here's an updated memory report and the logs have this:
firefox.desktop[86532]: [Child 86532, MediaDecoderStateMachine #7] WARNING: Decoder=7ff56cc1c000 Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - RefPtr<mozilla::Mo
zPromise<RefPtr<mozilla::MediaTrackDemuxer::SamplesHolder>, mozilla::MediaResult, true> > mozilla::MediaSourceTrackDemuxer::DoGetSamples(int32_t): manager is detached.: file /builddir/build/BUILD/fi
refox-82.0/dom/media/MediaDecoderStateMachine.cpp, line 3471

Firefox updated to firefox-82.0-5.fc32.x86_64

Comment 11

[Pablo]

Hi Andrew
a new memory report is attached.
Do you know what component we should set this bug with?

thanks

Comment 12

[Andrew McCreight [:mccr8]]

In the main process, there's 112MB of bin-unused, which is jemalloc fragmentation.

The first content process has about 600MB of stuff. Mostly random JS engine things.

The second content process, pid 49198, has about 114MB of bin-unused. It has a peak memory usage of 2.7GB, but the current usage is more like 500MB.

The third content process, pid 87749, is using about 360MB total, and a third of that is media/resources.

The other processes look fairly small. So, unfortunately, nothing really stands out for me in this memory report. The high peak memory usages and the large amount of bin-unused suggest that maybe there was a lot of memory being used, but that it went away somehow.

Comment 13

[Pablo]

set componet widget:gtk since it looks like an OS issue and not a memory

Comment 14

[Gian-Carlo Pascutto [:gcp]]

We weren't able to reach anything actionable originally and too much time has passed (and changes have been made) for the info here to still be relevant at this point.