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

Steps to reproduce:

I just opened the Settings tab.

Actual results:

Firefox endlessly consumes memory.

Expected results:

Memory consumption should be finite.

I disabled all add-ons to be sure

Because this bug's Severity is normal and has not been changed, and this bug's priority is -- (none,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Hello! I have tried to reproduce the issue following the steps from the description but I haven't been able to with Firefox Nightly (2020-05-06) on Ubuntu 18.04 LTS.
I have a few questions:

1. Does the issue reproduce with a new profile? Here is link to how you can create a new profile: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Multiple_profiles
2. Can you verify that the issue reproduces on other OS's?
3. Is the issue reproducing on the latest Nightly version? Here is a link from where you can download it: https://nightly.mozilla.org/
4. Could you please provide a memory report from about:memory?

(In reply to Negritas Sergiu from comment #4)

1. Does the issue reproduce with a new profile? Here is link to how you can create a new profile: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Multiple_profiles

no

2. Can you verify that the issue reproduces on other OS's?

I cannot, sorry

3. Is the issue reproducing on the latest Nightly version? Here is a link from where you can download it: https://nightly.mozilla.org/

Yes, it is reproducing on 78.0a1 (2020-05-14) (64 bits)
Note: I only use Nightly and I update it everyday

4. Could you please provide a memory report from about:memory?

You will find 2 memory reports attached : the first before launching settings tab, the first with settings tab open.

Thank you for answering the questions Frederic!

Hello Eric!
Can you look into the memory reports provided in the comment and help us find a component for this issue?

Looks like over 2GB of heap-unclassifed in the main process. That's pretty bad. Lets move this to prefs for now.

This looks exactly like bug 1636067 and bug 1636196.

Reporter, would you be able to run mozregression ( https://mozilla.github.io/mozregression/ ) to find out when this broke? The first step (after installing) would be running the mozregression --launch command in combination with the --profile switch pointing to the profile path with which you're seeing this. mozregression will clone the profile you pass it. Then we can check it reproduces in that configuration - which I'm not sure about...

:njn, how could we get more info about the heap here? If we suspect these are fluent bundles/resources, how would we confirm/deny that?

(In reply to :Gijs (he/him) from comment #10)

Reporter, would you be able to run mozregression ( https://mozilla.github.io/mozregression/ ) to find out when this broke? The first step (after installing) would be running the mozregression --launch command in combination with the --profile switch pointing to the profile path with which you're seeing this. mozregression will clone the profile you pass it. Then we can check it reproduces in that configuration - which I'm not sure about...

I've been able to run mozregression.

Surprisingly, I had absolutely no memory leak with whatever nightly version !

The only difference I noticed was that mozregression ran Nightly in english even with my profile (the nightly I use is in french).

I then went back to modules to see if a "french" module might be te chause.

I deleted "French spelling dictionary", restarted Firefox, but the memory leak was still there.
I deleted "Français language pack", restarted Firefox and the memory leak was gone !

I attached the versions of these two packs as images.

(In reply to Frédéric BISSON from comment #12)

(In reply to :Gijs (he/him) from comment #10)

Reporter, would you be able to run mozregression ( https://mozilla.github.io/mozregression/ ) to find out when this broke? The first step (after installing) would be running the mozregression --launch command in combination with the --profile switch pointing to the profile path with which you're seeing this. mozregression will clone the profile you pass it. Then we can check it reproduces in that configuration - which I'm not sure about...

I've been able to run mozregression.

Surprisingly, I had absolutely no memory leak with whatever nightly version !

The only difference I noticed was that mozregression ran Nightly in english even with my profile (the nightly I use is in french).

OK.

I deleted "French spelling dictionary", restarted Firefox, but the memory leak was still there.
I deleted "Français language pack", restarted Firefox and the memory leak was gone !

Right, this does not surprise me very much, it appears the issue is something to do with having more than 1 locale available. But do you know how you installed the language pack originally? And if you reinstall it, does the issue return?

Right, this does not surprise me very much, it appears the issue is something to do with having more than 1 locale available. But do you know how you installed the language pack originally?

Sorry I do not remember.

And if you reinstall it, does the issue return?

Yes.

(In reply to Frédéric BISSON from comment #16)

Right, this does not surprise me very much, it appears the issue is something to do with having more than 1 locale available. But do you know how you installed the language pack originally?

Sorry I do not remember.

And if you reinstall it, does the issue return?

Yes.

Hm. Unfortunately, it hasn't been very easy for anyone else on Mozilla's side to reproduce this - I just tried again, installing some of the same add-ons as you, same language pack, on today's nightly, in an ubuntu 20.04 vm, and I can't reproduce the hang.

Reporter: Are you familiar with debuggers? Would you be able to record a trace with rr, perhaps?

Zibi: is there anything we can add to nightly in terms of logging (behind a pref or using MOZ_LOG) that'd help figure this out?

(In reply to :Gijs (he/him) from comment #11)

:njn, how could we get more info about the heap here? If we suspect these are fluent bundles/resources, how would we confirm/deny that?

DMD is the tool to use when faced with high heap-unclassified numbers. It's what it was designed for! :)

https://developer.mozilla.org/en-US/docs/Mozilla/Performance/DMD

(In reply to :Gijs (he/him) from comment #11)

:njn, how could we get more info about the heap here? If we suspect these are fluent bundles/resources, how would we confirm/deny that?

If this can be reproduced on Nightly, capturing a profile with the Firefox profiler (enable it at https://profiler.firefox.com) with the "Native Allocations" feature enabled (enable it in about:profiling) should give a lot of information about where memory is being allocated.

Zibi: is there anything we can add to nightly in terms of logging (behind a pref or using MOZ_LOG) that'd help figure this out?

My only guess would be to attempt to log traces of what triggers L10nRegistry::generateBundles.

We finally managed to track this down in bug 1642415 and are considering how to fix this more thoroughly there.