1663059 - High Ram Usage on Settings Tab

Status: RESOLVED DUPLICATE of bug 1642415

(Core :: Internationalization, defect)

Description

[kolotxoz]

Attachment: fff.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0

Steps to reproduce:

I just opened the settings tab.

Actual results:

My browser freezes, and in task manager i can see how ram usage goes up until the browser almost eat all the ram (In include a picture of ram usage, firefox uses 9 of 16 gigs) and crashes

This happened to me on a intel pentium gold 5405U laptop and in a intel xeon e5-1620 v3 cpu, the laptop have windows 10 v2004 and the xeon machine have windows 10 v1909

Expected results:

The browser just had to open the settings tab and let me use it

Comment 1

[Francesco Lodolo [:flod]]

Can you follow these instructions?

1. Open about:support
2. Click the Copy raw data button
3. Click Attach new File in this bug, and paste the data from about:support, then press Submit at the bottom

Comment 2

[kolotxoz]

Attachment: raw.txt

Comment 3

[Francesco Lodolo [:flod]]

OK, this is strange. I assumed this was caused by an obsolete language pack, but you have the correct version:

• Firefox 80 (20200818235255)
• Español (AR) Language Pack (80.0buildid20200831163820)

I'd like you to try this:

• Open about:support
• Click the button to clear the startup cache, and restart Firefox as prompted
• Try opening preferences again

Does it work without eating CPU and memory?

As a final step, open about:addons, click the Languages pane on the left, and remove the Spanish language pack, then restart the browser. From your about:support, it looks like you're using a es-AR build, there's no need for the extra language pack for the same locale.

Comment 4

[:Gijs (he/him)]

(In reply to Francesco Lodolo [:flod] from comment #3)

OK, this is strange. I assumed this was caused by an obsolete language pack, but you have the correct version:

• Firefox 80 (20200818235255)
• Español (AR) Language Pack (80.0buildid20200831163820)

Is the es-AR localization complete, and in particular, are any strings used from about:preferences missing?

Comment 5

[kolotxoz]

Hi, i just cleared the startup cache, and "refresh" the firefox installation, and the problem went away, maybe you were right, and the problem was related to the old language pack or a bad add-on, because this only happened reciently.

Thanks.

Comment 6

[Francesco Lodolo [:flod]]

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

(In reply to Francesco Lodolo [:flod] from comment #3)

OK, this is strange. I assumed this was caused by an obsolete language pack, but you have the correct version:

• Firefox 80 (20200818235255)
• Español (AR) Language Pack (80.0buildid20200831163820)

Is the es-AR localization complete, and in particular, are any strings used from about:preferences missing?

I believe it was, but it shouldn't really matter, because at least the en-US one is guaranteed to be complete.

Leaving the NI open to try to replicate this on 80 with es-AR.

Comment 7

[Francesco Lodolo [:flod]]

I can replicate with Firefox es-AR release, and installing the es-AR language pack from AMO (it's not available from prefs)
https://addons.mozilla.org/firefox/addon/espa%C3%B1ol-ar-language-pack/

Langpack: 80.0buildid20200831163820
Firefox: 80.0.1 (20200831163820)

At this point I don't think I understand bug 1642415, although this is likely a dupe of that. I thought the problem would only happen if we didn't have a full localization to fall back to?

The language pack doesn't include en-US, but the build does. We don't even look at what's in the build because es-AR is available in both? If I install Afrikaans, which is very incomplete, everything works as expected.

Comment 8

[:Gijs (he/him)]

(In reply to Francesco Lodolo [:flod] from comment #7)

At this point I don't think I understand bug 1642415, although this is likely a dupe of that. I thought the problem would only happen if we didn't have a full localization to fall back to?

No, the problem there is combinatorial explosion of the number of combinations of sources for FTL files, if strings are missing in the first source. See also https://bugzilla.mozilla.org/show_bug.cgi?id=1642415#c39 and comment #41 . As noted on the bug, I could reproduce with just en-US + an outdated en-US langpack - we will look at langpacks first, and so if the langpacks miss strings, we run 2^19 combinations instead of 2.

If the langpack is missing any strings required by the prefs in 80 (e.g. also possible if the prefs are mistakenly requesting some string from fluent that just doesn't exist!), this bug can happen. That said, when debugging this, I don't see any errors for missing strings when reproducing (but using the JS debugger to prevent runaway memory/CPU usage). I do see us not finding the certManager.ftl file

From a very quick look, it seems like langpacks only list browser source in their sources key in manifest.json, but the prefs require security and toolkit FTLs as well. There's a hardcoded entry for toolkit in https://searchfox.org/mozilla-central/rev/2fb77a351ab34e9994f01377e2e12486a50f1737/toolkit/components/extensions/Extension.jsm#1126-1131 . But AIUI that means that we'll never find the "security" strings. That seems wrong and likely to cause problems? Still, then I'd expect the same issue with any langpack installed on any version of 80 - though perhaps if we have no other sources for the same language, we switch to looking at a different language, and that avoids the problem?

Comment 9

[:Gijs (he/him)]

I suspect this really affects all fluent-ized versions.

I also still don't understand how users end up with locale packs that match the build locale, and why we even bother using them.

Comment 10

[Francesco Lodolo [:flod]]

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

I suspect this really affects all fluent-ized versions.

I also still don't understand how users end up with locale packs that match the build locale, and why we even bother using them.

The only way is to manually install from AMO. In preferences, the same locale of the build is not available from download, at least from the tests I did.

Leaving the rest of the questions to Zibi, because that's too deep in technical details for me to know :-(
Indeed it seems wrong that we're not loading strings outside of browser.

Comment 11

[Francesco Lodolo [:flod]]

I thought of writing a query to check how many clients have a language pack with the same locale as the build, but we don't have that information in telemetry (bug 1637260).

Comment 12

[:Gijs (he/him)]

(In reply to Francesco Lodolo [:flod] from comment #10)

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

I suspect this really affects all fluent-ized versions.

I also still don't understand how users end up with locale packs that match the build locale, and why we even bother using them.

The only way is to manually install from AMO. In preferences, the same locale of the build is not available from download, at least from the tests I did.

I mean, I feel like we must be missing something here, considering how often this is coming up - why would people go to AMO to install a langpack for a language they already use? Is it possible we at some point mis-updated people from en-US (+ langpack-in-profile) to a repack, and now they're in this state?

Comment 13

[Francesco Lodolo [:flod]]

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

I mean, I feel like we must be missing something here, considering how often this is coming up - why would people go to AMO to install a langpack for a language they already use? Is it possible we at some point mis-updated people from en-US (+ langpack-in-profile) to a repack, and now they're in this state?

I don't think that's possible, as far as I know we update based on the language of the build, and the update system doesn't know anything about language packs or other requested locales. I expect this to be the result of users' actions.

One source of confusion, at least in one previous case, is the unclear separation between language packs and dictionaries. Spell checking doesn't work, they go to AMO and install the language pack, assuming it would also add a dictionary for spell checking. It doesn't help either that Add dictionaries… in the context menu gets you to a page with both language packs and dictionaries.

Comment 14

[Francesco Lodolo [:flod]]

(In reply to kolotxoz from comment #5)

Hi, i just cleared the startup cache, and "refresh" the firefox installation, and the problem went away, maybe you were right, and the problem was related to the old language pack or a bad add-on, because this only happened reciently.

Do you remember installing the language pack from https://addons.mozilla.org/? If not, any idea how it was installed on your system?

Comment 15

[kolotxoz]

(In reply to Francesco Lodolo [:flod] from comment #14)

(In reply to kolotxoz from comment #5)

Hi, i just cleared the startup cache, and "refresh" the firefox installation, and the problem went away, maybe you were right, and the problem was related to the old language pack or a bad add-on, because this only happened reciently.

Do you remember installing the language pack from https://addons.mozilla.org/? If not, any idea how it was installed on your system?

Hi Francesco, I think I could have installed a language pack in a previous version of the Firefox installation but i dont remember well, I have updated that Firefox installation normally up to v80 which was the one that presented the problem that i reported

Comment 16

[Jens Stutte [:jstutte]]

Hi, can you please check if this should really be S1 and/or adjust priority accordingly ?

Comment 17

[Makoto Kato [:m_kato]]

According to comment #10 and comment #11, this occurs if you install lack pack. I think that this isn't S1. If this occurs on all-localized build, I will set the priory again.

Comment 18

[Zibi Braniecki [:zbraniecki][:gandalf]]

This was hopefully fixed in bug 1642415.

Reopen if needed.