1893230 - chat.mozilla.org: Cycle collector takes 100% and freezes the tab

Status: NEW

(Core :: Cycle Collector, defect)

Description

[Johan Lorenzo [:jlorenzo]]

Hello there! I'm no expert on the profiler so maybe I filed this bug in the wrong component. I don't think it's a recent regression. I've noticed chat.mozilla.org to be slow from times to times. Sometimes, I just switch to that tab (which takes longer than any other ones I have open). Sometimes, within that tab, I switch to another Element conversation. Sometimes, it's just when I'm typing a message: Element becomes entirely unresponsive. The latter motivated me to use the profiler today.

On this first record[1], we can see 2 periods where the CPU is used at ~100%. I was just swapping conversations. On this second record[2], I was writing a message until my keystrokes took several seconds to appear. In all cases, it seems Firefox spends its time in the Incremental GC.

I can easily reproduce this issue so don't hesitate to ask me for some more details.

Build info:

• Version: 127.0a1
• Build ID: 20240422094829
• OS: Darwin 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:10:42 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6000

[1] https://profiler.firefox.com/public/9ckvtw8ve69zhv1j43mebd27c53brf3tby3dvm8/calltree/?globalTrackOrder=0w2&thread=3&v=10
[2] https://profiler.firefox.com/public/q6w53y7h9ame8cxv8zsjj3tbtz5ygrtv0gcsnz0/calltree/?globalTrackOrder=0w3&thread=2&v=10

Comment 1

[Andrew McCreight [:mccr8]]

This is actually the cycle collector and not the garbage collector. This usually indicates a leak in the content process. What does about:memory look like for the Element process?

Comment 2

[Johan Lorenzo [:jlorenzo]]

Thanks for the super quick reply, :mcrr8! I currently don't manage to repro anymore. I'll try to get about:memory next time it happens 🙂

Comment 3

[Andreas Farre [:farre]]

Marking this as S3 until the reproduces.

Comment 4

[Johan Lorenzo [:jlorenzo]]

Attachment: memory-report.json.gz

Sorry for the delay. I just got back from PTO and was able to reproduce the problem several times today. Here's the anonymized report. chat.mozilla.org is in the process whose PID is 6073.

about:processes shows 6073 also handles 2 treeherder tabs, 2 bugzilla ones, one hg.mozilla.org tab and another for sql.telemetry.mozilla.org.

Let me know if I can provide more info 🙂

Comment 5

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

Have you tried disabling addons?
(I use Element heavily all the time and haven't seen this)

PID 6073 uses lots of memory in JS, though also elsewhere. (I see 541MB for Element, and that is quite reasonable)
Is the memory report without verbose checked?

Oh, "about:processes shows 6073 also handles 2 treeherder tabs". My guess is that it is treeherder which causes this. At least at some point it was using massive amounts of memory in JS. One just doesn't interact with treeherder in the same way as with Element, so jank might not be so visible.

Comment 6

[Johan Lorenzo [:jlorenzo]]

Thanks for the quick answer!

Have you tried disabling addons?

Not yet. I'll give it a try, next time.

Is the memory report without verbose checked?

Sorry, it's my first time generating this report. I did not check verbose 😅 I'll do it next time it happens.

My guess is that it is treeherder which causes this.

I wouldn't be surprised either. I'll also try closing these tabs, next time it happens.

All in all, I'm keeping the NI until I get more info on these 3 items 🙂

Comment 7

[Johan Lorenzo [:jlorenzo]]

Attachment: memory-report.json.gz (verbose, anonymized)

I got another wave of reproductions today.

Have you tried disabling addons?

Yes. I didn't notice any improvement. chat.m.o remains visibly slow. I deactivated all addons without restarting Firefox. The problem temporarily goes away if I restart Firefox.

My guess is that it is treeherder which causes this.

Good news: I had no treeherder tabs open when I started to reproduce this morning. I confirm I haven't opened any since then. That said, I have ~15 tabs open on sql.telemetry.mozilla.org. They all points to different Telemetry dashboards.

Is the memory report without verbose checked?

Here's a new submission with verbose checked this time. My unique Element tab is in PID 85314. This process is shared by:

• chat.m.o
• 4 bugzilla tabs
• 1 tab on sql.telemetry.mozilla.org,
• 1 tab on people.m.o
• 1 tab on support.m.o
• 1 tab on developer.m.o

Comment 8

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

sql.telemetry.mozilla.org is often massive.

We need GC/CC logs when the pause times aren't yet too bad, about:memory has buttons to create them

Comment 9

[Julien Wajsberg [:julienw]]

I had both treeherder and chat in the same process. I realized chat.mozilla.org wasn't responsing well anymore (for example the notifications bubble weren't disappearing). I decided to reload the tab. Then it took a while for the process to be responsive again, but it eventually managed to be responsive.
In about:processes I've seen the process going up to 12 GB while it was reloading (sorry I didn't think about looking at the size before starting the reload... but I've seen it at 10GB after starting and before hitting that 12GB mark), and now it's down to ~700MB. The treeherder tab is still there.
So I'm quite confident the leak is in chat.mozilla.org. It was a bit too late to get logs unfortunately. I'll try to think about that.

I still find it a bit weird how much memory the process takes while it's reloading the tab.

Comment 10

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

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

Comment 11

[Julien Wajsberg [:julienw]]

Sure, but firefox behavior is IMO problematic too, in this case.