1926530 - chat.mozilla.org process spends a lot of time tracing JS in the cycle collector

Status: RESOLVED FIXED

(Core :: Cycle Collector, defect)

Description

[Julien Wajsberg [:julienw]]

Very regularly (let's say every 2 3 days without restarting Firefox), my pinned tab for chat.mozilla.org stops responding. Reloading the tab doesn't help, I need to restart Firefox completely. (I haven't tried closing the tab and opening it again).

From the profiles I took, it looks like Cycle Collector is happening and never stops.

https://share.firefox.dev/4f6bDiW
https://share.firefox.dev/4eQLMf9
https://share.firefox.dev/3YgqRLp

Firefox v133 (Build 20241020211110)

I think it happens for a few weeks.
It's difficult to find a regression window because it needs a few days to reproduce :-(

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

profiles don't really help in this kind of case. Need GC/CC logs. Which all mozilla.org sites are also in the same process?
(there is a bug somewhere where it was IIRC https://sql.telemetry.mozilla.org in the same process which was actually causing the issue)

Comment 2

[Andrew McCreight [:mccr8]]

Keep in mind that the GC/CC logs will contain a lot of private information about what is in memory so don't attach them to the bug.

Comment 3

[Julien Wajsberg [:julienw]]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #1)

profiles don't really help in this kind of case. Need GC/CC logs. Which all mozilla.org sites are also in the same process?
(there is a bug somewhere where it was IIRC https://sql.telemetry.mozilla.org in the same process which was actually causing the issue)

I believe it's mostly bugzilla and MDN, but I'll look more closely next time this happens.

Is it useful to enable GC/CC logs only when the issue happens or does that need to be enabled before that?

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Aligning the severity to bug 1893230, but if the symptom is more serious, feel free to upgrade it.

Comment 5

[Julien Wajsberg [:julienw]]

Happened again today. In about:processes chat.mozilla.org seems to be in its own process. Other mozilla.org processes are bugzilla and MDN.
About:processes says that the process hosting chat.mozilla.org takes 5 GB.
I'll try to look at about:memory from time to time before this happens (I guess that doing that when this happened is too late and we won't get any result when the process is pegged).

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #4)

Aligning the severity to bug 1893230, but if the symptom is more serious, feel free to upgrade it.

I believe this is the same bug, feel free to dupe one of these.
Although for me this happens every day or so...

If it's a problem only in chat.mozilla.org then I don't mind, but the behavior of Firefox doesn't look right to me. Instead of pegging it should crash the process IMO. (not saying it's easy)

Comment 6

[Julien Wajsberg [:julienw]]

Attachment: Screenshot of about:memory

I saved the dump locally, I can share it privately if needed.

Comment 7

[Julien Wajsberg [:julienw]]

In about:processes, the process was taking 5GB. It wasn't frozen yet. I tried to press in sequence GC / CC / GC in about:memory, but this didn't change anything.

Then I reloaded the tab. In about:processes I saw the process taking 10GB while chat.mozilla.org was loading, then it went down to less than 1GB. I also pressed GC / CC / GC in the about:memory page, so this may have done it too.

I do believe chat.mozilla.org is leaking, but Firefox' behavior could be improved.

Comment 8

[Andrew McCreight [:mccr8]]

Olli told me that he hit this issue locally and captured cycle collector logs. Hopefully he'll have a chance to post his analysis here.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

https://github.com/element-hq/element-web/issues/28307

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

So it is a bug in Element, but I think we might be able to hide that by making DOM Events skippable. And CanSkip implementation would need to do marking on the various m*Target objects, or their JS wrappers

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

Adding some kind of helper for this issue, to hopefully hide the leak from CC.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Attachment: Bug 1926530 - skip certainly alive Events, r=mccr8

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f1e7580708c9
skip certainly alive Events, r=mccr8

Comment 14

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/f1e7580708c9