1636067 - Memory leak when open about:preferences.

Status: RESOLVED DUPLICATE of bug 1642415

(Core :: Internationalization, defect, P1)

Description

[仕刀_XC]

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

Steps to reproduce:

OS:Win10
FF version : 77.0b2 dev ver
Open about:preferences.

Actual results:

Firefox stopped responding and meanwhile allocating all avaliable memory.
After it allocated all memory, it would stuck there for a long time.
During this, a large number of disk write operations (50~140MB/s) occur intermittently, which will last for tens of seconds. At the same time, a large number of read operations are not observed.
I don't think the disk write is caused by memory swapped out because taskmgr will mark the IO caused by swapping as System.
It will take a while for FF to become responding. At this time, leaked memory are not released.
A while after I closed the about:preferences tab, memory usage dropped back to normal.
This recurrented for 4 times. Testing with new profile encountered no problems.

Expected results:

No memory leakage

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

[:Gijs (he/him)]

Can you post a performance profile of what happens when opening about:preferences on the affected profile? There's detailed steps on https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem .

Comment 3

[仕刀_XC]

Performance profile here: https://perfht.ml/2WzEW6X

Comment 4

[:Gijs (he/him)]

(In reply to 仕刀_XC from comment #3)

Performance profile here: https://perfht.ml/2WzEW6X

Thank you! Could you also attach your about:support information, and, just to check, if you use help > restart with add-ons disabled, does about:preferences load normally there or not? Also, did you not have this problem in earlier versions of devedition, perhaps?

I'm... not sure what's going on in that profile. The stacks seem incomplete. However, we appear to be spending many, many seconds running fluent's addResource code. Zibi, can you take a look?

Comment 5

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

16s in parsing of FluentResource is bizarre. I don't know how to explain it.

The only correlation I imagine is that somehow the FTL file got humongous and parsing it created an incredibly large AST.

Like, really extremely large. Parsing of the whole about:preferences context should take ~300 microseconds on a fast laptop, and up to 500 microseconds on a slow one. Even assuming as very slow CPU, the worse we should observe is within ~1ms range.
Seeing 16000 more time in the parsing and memory increasing by 14GB in that time feels like it might be a bogus FTL file?

Is it possible that a corruped omni.ja is feeding a bad FTL file to the parser?

I don't know how to test this hypothesis.

Comment 6

[仕刀_XC]

Attachment: about_support.txt

about:support

Comment 7

[仕刀_XC]

Didn't see this issue in safe mode.
When restarted with add-ons enabled, the issue came back again.
I've never seen this problem before.

Comment 8

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

Thank you for the report. That's still bizarre, but at least it seems like it may be related to extensions.
From the about:support you shared, it seems like this is your list of extensions:

Group 1:

侧边翻译 - [e-mail]
购物党实时比价工具(浏览器57以上版本安装) - {b33773df-f1f0-4f86-bf16-cbef3280ea08}
图片助手(ImageAssistant) 批量图片下载器 - {57e5e66f-a92e-4f72-ae46-68e88d0a0f5c}
网盘万能助手 - {b453e8d2-3ebb-46e2-8973-2a3ca92a68e3}
网页截图 - [e-mail]
Dark Reader - [e-mail]
EhSyringe - {759d5566-1dce-41ae-bae9-00dd5172c422}
G App Launcher (Google™ Shortcuts) - {5C46D283-ABDE-4dce-B83C-08881401921C}
Grammarly for Firefox - 87677a2c52b84ad3a151a4a72f5bd3c4@jetpack

Group 2:


IDM Integration Module - [e-mail]
JetBrains Toolbox Extension - {bf9e77ee-c405-4dd7-9bed-2f55e448d19a}
Mind the Time - jid0-HYNmqxA9zQGfJADREri4n2AHKSI@jetpack
pakku：哔哩哔哩弹幕过滤器 - {646d57f4-d65c-4f0d-8e80-5800b92cfdaa}
Privacy Pass - {48748554-4c01-49e8-94af-79662bf34d50}
Stash - [e-mail]
Stylus - {7a7a4a92-a2a0-41d1-9fd7-1e92480d612d}
Tampermonkey - [e-mail]
Textarea Cache - [e-mail]
Twitter Media Downloader - {8b344d1d-265c-4d48-8418-0b522359bad2}
uBlock Origin - [e-mail]

Group 3:


User-Agent Switcher and Manager - {a6c4a591-f1b2-4f03-b3ff-767e5bedf4e7}
删除谷歌重定向 - {3035f12c-7db1-4c20-a2bd-3b80ef60cb86}
网页翻译(Bing Microsoft Translator) - {7a2f15b3-e54e-490d-8c42-61434a35a34b}
Btools - [e-mail]
Cookie Quick Manager - {60f82f00-9ad5-4de5-b31c-b16a47c51558}
ePub Viewer - {32d3c582-a952-4ea8-b577-fcdce5857d8e}
EPUBReader - {5384767E-00D9-40E9-B72F-9CC39D655D6F}
Free Download Manager - [e-mail]
GitLab Markdown Viewer - {a8723c8a-1541-44c9-9a4f-2b55a994525d}
Katalon Recorder (Selenium tests generator) - {91f05833-bab1-4fb1-b9e4-187091a4d75d}
Markdown Editor for Firefox - {8ffc187c-9301-4bb6-805b-ac3d86102ae5}

Group 4:


Markdown Here - [e-mail]
markdownQuantum - [e-mail]
Proxy SwitchyOmega - [e-mail]
Selenium IDE - {a6fd85ed-e919-4a43-a5af-8da18bda539f}
Send to Aria2 WE - {9cc772b3-94a0-42b7-a777-bc9ff32726b7}
Tab Stash - [e-mail]
Tiled Tab Groups - {dcdaadfa-21f1-4853-9b34-aad681fff6f3}
To Google Translate 谷歌快译 - jid1-93WyvpgvxzGATw@jetpack
What Font - {3ab1d08e-5e80-4fa4-ae1a-d198a431755b}
XDown - [e-mail]
xPath Finder - {62c1d54c-f371-4d89-8e07-69e67c8ebea8}

Group 5:


百度 - [e-mail]
维基百科 - [e-mail]
亚马逊 - [e-mail]
Bing - [e-mail]
DuckDuckGo - [e-mail]
Google - [e-mail]
Firefox Color - [e-mail]
Firefox Multi-Account Containers - @testpilot-containers
Firefox Pioneer - [e-mail]

I divided them into 5 groups. Could you try to disable all but Group1, then all but Group 2 and so on, and see if you can reproduce it with a subset of the extensions?
That would make it possible for us to narrow down the scope and try to reproduce or dive deeper.

There are several possible scenarios and I'd like to make sure that it's not a bug in the Fluent Parser.

Comment 9

[仕刀_XC]

I conducted these tests.
Some plugins were disabled from the beginning, I did not enable them. (For example, when I tested the first group, I just disabled all the plugins in the first group, I did not enable disabled plugin in the other groups).
There are some plugins that I cannot disable. Seems they are builtin search add-on. They are:

百度 - [e-mail]
维基百科 - [e-mail]
亚马逊 - [e-mail]
Bing - [e-mail]
DuckDuckGo - [e-mail]
Google - [e-mail]

Since all plugins in the fourth group were disabled in the first place, I did not test the fourth group.
The test result:
In all four tests (group 4 not tested) , the problem appeared.

Comment 10

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

Thank you so much!

Seems I was wrong then! My next hypothesis is that it is not related to extensions but some other aspects of the safe mode.
I don't know how to debug it but maybe someone else from the dev team will come up with an idea!

Comment 11

[:Gijs (he/him)]

If you exit Firefox completely, then go to "C:\Users\username\AppData\Local\Mozilla\Firefox\Profiles\profilename\ and move the startupCache folder to startupCache-old, does the problem go away? Does it come back if you move the folder back into place?

Comment 12

[仕刀_XC]

If you exit Firefox completely, then go to "C:\Users\username\AppData\Local\Mozilla\Firefox\Profiles\profilename\ and move the startupCache folder to startupCache-old, does the problem go away?

Yes.

Does it come back if you move the folder back into place?

Maybe.....No? At least it's not allocating all memory.
For the first time I open about:preferences, it stuck for a very little time(about 1s?) and memory went up for about 1G.
The mem usage recovered when I closed the tab.
Then I closed the tab and opened again.This time it stuck longer(5s?) and mem usage went up about 3G.

Comment 13

[仕刀_XC]

update:
I tried again moving startupCache folder to startupCache-old and this time the issue happened.
The behavior is similiar to what I described in last reply: Not allocating all memory and short time stuck.

Comment 14

[:Gijs (he/him)]

You wrote you couldn't reproduce in a clean profile. In the clean profile, if you install the zh-CN langpack and make it the default and then restart, does the same issue happen? Does safe mode use the language pack? (I'm not sure off-hand, I sort of expect not...)

Comment 15

[仕刀_XC]

does the same issue happen?

Language settings in new profile by default are:

1. zh_CN
2. zh
3. zh_TW
4. zh_HK
5. en_US
6. en

Language settings in my old profile are:

1. zh_CN
2. zh
3. zh_TW
4. en_US
5. en

So I deleted the zh_HK langpack in the new profile and restarted. I met no problem.

Does safe mode use the language pack?

Yes

Comment 16

[仕刀_XC]

A question:
When trying to open about:preferences from the menu, if there is an existing about:preferences tab, FF will switch to that tab.
Will FF reload the existing tab internally? Or just switch to that tab?

This question is because:
I tried to open about:preferences from the menu while it's already opened in another window.
FF switched to the existing tab and stuck there.

Comment 17

[:Gijs (he/him)]

(In reply to 仕刀_XC from comment #16)

A question:
When trying to open about:preferences from the menu, if there is an existing about:preferences tab, FF will switch to that tab.
Will FF reload the existing tab internally? Or just switch to that tab?

It will just switch to that tab. No internal reloading will happen, though we might switch to a different pane.

This question is because:
I tried to open about:preferences from the menu while it's already opened in another window.
FF switched to the existing tab and stuck there.

(In reply to 仕刀_XC from comment #15)

does the same issue happen?

Language settings in new profile by default are:

1. zh_CN
2. zh
3. zh_TW
4. zh_HK
5. en_US
6. en

Language settings in my old profile are:

1. zh_CN
2. zh
3. zh_TW
4. en_US
5. en

So I deleted the zh_HK langpack in the new profile and restarted. I met no problem.

Does safe mode use the language pack?

Yes

So I'm a bit confused. Does your devedition build have the zh_CN language files builtin, rather than them being a language pack? Because your about:support data says:

  "intl": {
    "localeService": {
      "requested": [
        "zh-CN"
      ],
      "available": [
        "zh-CN",
        "en-US"
      ],
      "supported": [
        "zh-CN",
        "en-US"
      ],
      "regionalPrefs": [
        "zh-CN"
      ],
      "defaultLocale": "zh-CN"
    },
    "osPrefs": {
      "systemLocales": [
        "zh-Hans-CN",
        "en-US"
      ],
      "regionalPrefsLocales": [
        "zh-CN"
      ]
    }
  },

:flod, can you help clarify what is going on here and how I'd attempt to reproduce?

Comment 18

[Francesco Lodolo [:flod]]

@仕刀_XC
What do you mean when you say "language settings"? Where do you check them?

To avoid any confusion, it would be great if you could go to about:support, and copy the content of the Internationalization & Localization table at the end of the page in the new table, at least for the new profile where the problem doesn't occur.

Side note: there's no zh-HK language pack. zh-HK is not a language that we support in our systems, on addons.mozilla.org you can only find language packs for official languages at this point (zh-CN, zh-TW).

I would also like to understand how you change the language, and where you download the language pack from.

Comment 19

[仕刀_XC]

#18

What do you mean when you say "language settings"? Where do you check them?

I meant webpage language preference.
I checked them at about:preferences->语言与外观 (language and appearance)->语言 (language)->网页语言设置 (webpage language settings)(translation may not be word-accurate)

To avoid any confusion, it would be great if you could go to about:support, and copy the content of the Internationalization & Localization table at the end of the page in the new table, at least for the new profile where the problem doesn't occur.

table in old profile, I translated most keys :

国际化与本地化(i18n&l10n)
应用程序设置(app setting)
要求的语言环境 	["zh-CN"]
可用的语言环境(aval lang env) 	["zh-CN","en-US"]
应用程序语言环境(app lang env) 	["zh-CN","en-US"]
地区偏好(locale preference) 	["zh-CN"]
默认语言环境(default lang env) 	"zh-CN"
操作系统(OS)
系统语言环境(OS lang env) 	["zh-Hans-CN","en-US"]
地区偏好(locale preference) 	["zh-CN"]

table in new profile:

国际化与本地化
应用程序设置
要求的语言环境 	["zh-CN"]
可用的语言环境 	["zh-CN","en-US"]
应用程序语言环境 	["zh-CN","en-US"]
地区偏好 	["zh-CN"]
默认语言环境 	"zh-CN"
操作系统
系统语言环境 	["zh-Hans-CN","en-US"]
地区偏好 	["zh-CN"]

I would also like to understand how you change the language, and where you download the language pack from.

I don't remember what exactly I did. It was too long ago.
I suppose there was a builtin Chinese language pack.

there's no zh-HK language pack. zh-HK is not a language that we support in our systems, on addons.mozilla.org you can only find language packs for official languages at this point (zh-CN, zh-TW).

Maybe I did something wrong......
Sorry about that.

---

#17

So I'm a bit confused. Does your devedition build have the zh_CN language files builtin, rather than them being a language pack?

I don't remember exactly. It was too long ago.
I don't know if Developer Edition has Chinese language pack builtin, because:
In the very beginning I was using release Firefox then I switched to release Firefox Developer Edition with my old profile.
I suppose there was a builtin Chinese language pack from release Firefox but not very sure.

It will just switch to that tab. No internal reloading will happen, though we might switch to a different pane.

But the issue still happened......
Just a guess, maybe it's not related with loading the page?

Comment 20

[:Gijs (he/him)]

[Tracking Requested - why for this release]:
Serious undiagnosed issue in localization/i18n code leading to hangs / recursion.

:flod, there's another case in the see also bug. Did the previous answer help with your questions, and/or do you have any idea how we can reproduce this? This is effectively a critical bug, but without steps to reproduce. :-\

Comment 21

[Francesco Lodolo [:flod]]

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

:flod, there's another case in the see also bug. Did the previous answer help with your questions, and/or do you have any idea how we can reproduce this? This is effectively a critical bug, but without steps to reproduce. :-\

Unfortunately no, it didn't give me any hint on how to reproduce it. The confusion around zh-TW was due to mixing UI language and Web Content language.

From the about:support information, it looks like a zh-CN build, not even with a language pack installed. I expect that to be the situation for the majority of zh-CN users, so we should have seen other reports by now if it's widespread.

Comment 22

[:Gijs (he/him)]

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

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

:flod, there's another case in the see also bug. Did the previous answer help with your questions, and/or do you have any idea how we can reproduce this? This is effectively a critical bug, but without steps to reproduce. :-\

Unfortunately no, it didn't give me any hint on how to reproduce it. The confusion around zh-TW was due to mixing UI language and Web Content language.

From the about:support information, it looks like a zh-CN build, not even with a language pack installed. I expect that to be the situation for the majority of zh-CN users, so we should have seen other reports by now if it's widespread.

I mean, I have no idea, but I imagine our zh-CN numbers on beta/devedition aren't that large - and there is now another report, though I suspect with a different locale.

Comment 23

[Francesco Lodolo [:flod]]

It's also not happening in a new profile though. I'm not exactly sure if we have an easy way to clean up a profile from personal data and get it uploaded somewhere for someone else to test. Was anything changed around the startup cache in 77?

Needless to say, I tried zh-CN DevEdition on my machine, and it works as expected (about 25MB according to about:performance, nothing out of the ordinary in the process manager.

Comment 24

[:Gijs (he/him)]

(In reply to 仕刀_XC from comment #12)

If you exit Firefox completely, then go to "C:\Users\username\AppData\Local\Mozilla\Firefox\Profiles\profilename\ and move the startupCache folder to startupCache-old, does the problem go away?

Yes.

Does it come back if you move the folder back into place?

Maybe.....No? At least it's not allocating all memory.
For the first time I open about:preferences, it stuck for a very little time(about 1s?) and memory went up for about 1G.
The mem usage recovered when I closed the tab.
Then I closed the tab and opened again.This time it stuck longer(5s?) and mem usage went up about 3G.

Would you mind creating an archive (zipfile or similar) of the contents of the startupcache folder that reproduce this problem for you (even if it's "only" 5s of being stuck), and email it to me (gijs at ) and flod (flod at) mozilla.com ? It shouldn't contain any private information - just pre-cached copies of some internal Firefox files (markup and scripts for the browser's own UI). Please also mention in the email what exact version (ie which build number, you can find it in about:support) of Firefox DevEdition you last ran with the profile from which you're taking the startupCache folder.

Thank you!

Comment 25

[:Gijs (he/him)]

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

It's also not happening in a new profile though. I'm not exactly sure if we have an easy way to clean up a profile from personal data and get it uploaded somewhere for someone else to test. Was anything changed around the startup cache in 77?

We briefly broke it, bug 1632544. And we changed from what thread it's written to disk ( bug 1614795). But I don't think either of them are at play here, given that the issue reproduces even while Firefox is running (per comment #12) and not updating. I think this is probably again a problem with how fluent and the startupcache and the xul minicache interact.

Comment 26

[Francesco Lodolo [:flod]]

I'm confused: is it expected to not have a startupCache at all on macOS? None of my profiles have one. ~/Library/Cache/Firefox/Profiles is empty, and the folder is not in the main profile folder either.

EDIT: ignore the part above, apparently they're hidden on macOS (or, at least on mine).

I tried on a VM with Windows 10 Home x64.

版本 	77.0b4
版本 ID 	20200511090718

Created a new profile, tried closing and opening several times, interact with preferences. No spikes in memory, it stays in the 250-300MB range.

I tried replacing the startupCache folder with the ones provided, but the behavior is the same, no matter how many times I try.

I even tried downloading 77.0b2 from FTP and keep the network disconnected to avoid updates, the memory usage is even lower (200-220 MB).

版本 	77.0b2
版本 ID 	20200505174119

Comment 27

[Florian Quèze [:florian]]

(In reply to 仕刀_XC from comment #3)

Performance profile here: https://perfht.ml/2WzEW6X

Thanks for the profile. Is there any chance you could capture another profile, and this time select the "Firefox Front-End" settings before clicking the "Start Recording" button? Thanks!

Comment 28

[:Gijs (he/him)]

Also, out of interest, how big is the handlers.json file in your profile? Does copying it to a new profile make the problem appear there?

Comment 29

[仕刀_XC]

#27

https://perfht.ml/3fLSSDm

#28

how big is the handlers.json file in your profile?

1847Bytes.

Does copying it to a new profile make the problem appear there?

No. After tried 5 times and restarted FF once.

Comment 30

[:Gijs (he/him)]

(In reply to 仕刀_XC from comment #29)

#27

https://perfht.ml/3fLSSDm

#28

how big is the handlers.json file in your profile?

1847Bytes.

Does copying it to a new profile make the problem appear there?

No. After tried 5 times and restarted FF once.

Thanks!

Zibi/Axel: the new profile shows that we end up in a very deep recursion in generateResourceSetsForLocale at https://searchfox.org/mozilla-beta/rev/12e38004655427d9b5dfe285b92ec00294cc05cb/intl/l10n/L10nRegistry.jsm#364 . There are comments in that code but I do not understand what they mean, practically speaking - based on the about:support attached, this is running on a build with Chinese and English available, nothing else - why would we be needing to recurse very deeply here? Would it be caused by missing files in one translation, or missing messages, or something else? And how would we be able to reproduce / fix ? Note that there is some custom code in main.js to deal with the "restart to use Firefox in <lang>" stuff, but AFAICT it should only get invoked if the user changes the selection in the language dropdown, not on pageload (and this code doesn't appear in the profile, though because of the async resumption stacks, that might be an illusion...).

Comment 31

[Axel Hecht [:Pike]]

So, I see a stack of 18, and we have 18 resources in prefs. But I also don't know what that means. Leaving that up to Zibi.

Comment 32

[Francesco Lodolo [:flod]]

Additional note: zh-CN is always fully localized in Beta, and rarely has missing strings on Nightly.
https://l10n.mozilla.org/teams/zh-CN

Comment 33

[:Gijs (he/him)]

When about:preferences finishes loading, if you open the devtools console (ctrl-shift-k) or browser console (ctrl-shift-j), are there warnings in there that mention [fluent] ? What are they?

Comment 34

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

(In reply to Axel Hecht [:Pike] from comment #31)

So, I see a stack of 18, and we have 18 resources in prefs. But I also don't know what that means.

Yeah, that's exactly it. We go 18 deep for 18 resources, that's expected and every locale does it.

Looking at the profile:

• Each generateResourceSetsForLocale takes very little self time - 10-20ms
• 20ms per AsyncGeneratorNext is still slow (accumulates to 400ms out of those 4.4 sec)
• There seem to be a lot of calls around Promises and GC from SpiderMonkey
• No single call seems to have any substantial "self-time".

It may be worth getting someone from SpiderMonkey to look at this

Comment 35

[:Gijs (he/him)]

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #34)

(In reply to Axel Hecht [:Pike] from comment #31)

So, I see a stack of 18, and we have 18 resources in prefs. But I also don't know what that means.

Yeah, that's exactly it. We go 18 deep for 18 resources, that's expected and every locale does it.

Looking at the profile:

• Each generateResourceSetsForLocale takes very little self time - 10-20ms
• 20ms per AsyncGeneratorNext is still slow (accumulates to 400ms out of those 4.4 sec)
• There seem to be a lot of calls around Promises and GC from SpiderMonkey
• No single call seems to have any substantial "self-time".

It may be worth getting someone from SpiderMonkey to look at this

Pike suggested on matrix that these iterators should be cached. However, looking at small chunks of this profile in the stack view shows that we repeatedly do this iteration for 18 resources - that wouldn't be expected if the result is cached, right? (cf. https://perfht.ml/2WSlySH )

In the entire profile, there are also references to maybeReportErrorToGecko (which is cheap, so I could imagine it's getting called a lot more than what is showing up in the profile), so I still think something is going wrong inside fluent here.

Comment 36

[仕刀_XC]

#33

Are there warnings in there that mention [fluent] ?

No

Comment 37

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

Pike suggested on matrix that these iterators should be cached. However, looking at small chunks of this profile in the stack view shows that we repeatedly do this iteration for 18 resources - that wouldn't be expected if the result is cached, right?

The "repeatedly" sounds off. We should do this 18 times, once, max twice if we are loading a fallback.

In the entire profile, there are also references to maybeReportErrorToGecko (which is cheap, so I could imagine it's getting called a lot more than what is showing up in the profile), so I still think something is going wrong inside fluent here.

Right, it would be super-valuable to get this information, but since the user is on production, we don't display it. One way to circumvent it might be to change the maybeReportErrorToGecko to check some optional preference and if it's on, display the error to the user.
This way in such scenario we could get the errors.

I agree with you that there's probably something related to Fluent. Whether it is an error in L10nRegistry, our DOMLocalization or some external code that somehow triggers l10n context to be recreated many times, is unclear to me. I'm also not sure why it would ever stop.

Comment 38

[Pascal Chevrel:pascalc]

It seems unlikely that we get this fixed for 77.0 but I want to keep it on my radar for the eventuality of including a fix in a dot-release (as a ride-along, probably not as a driver). Given that this is a P1/S1 bug, could we have an assignee please? Thanks

Comment 39

[Julien Cristau [:jcristau]]

Any takers to own this issue?

Comment 40

[:Gijs (he/him)]

(In reply to Julien Cristau [:jcristau] from comment #39)

Any takers to own this issue?

Although I have repeatedly tried here and in the other bugs, so far we have no clear idea what is triggering this issue, and nobody within Mozilla has managed to reproduce it. The problem is something to do with fluent getting into a bad state where code that should run once runs repeatedly, but we don't know how it gets into this state (or even exactly what state it is) and I am not familiar with the internals of fluent so I can't help debug that.

Comment 41

[Tim Spurway [:tspurway]]

S1 or S2 bugs need an assignee - could you find someone for this bug?

Comment 42

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

(In reply to Julien Cristau [:jcristau] from comment #39)

Any takers to own this issue?

I'm current working on project shirley blocker and don't have cycles to take this.

Comment 43

[Makoto Kato [:m_kato] (PTO until 5/6)]

仕刀_XC, could this still reproduce on Nightly 78/79 and beta 78 (coming in this week)? It seems to be environment/profile issue, but no one reproduces this.

Comment 44

[Makoto Kato [:m_kato] (PTO until 5/6)]

Profile issue, so down to S3. But if we can find repro step, I may be up to severity.

Comment 45

[仕刀_XC]

Can't reproduce in 78.0b3 .

Comment 46

[:Gijs (he/him)]

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