Content process pegged near 100% CPU doing GC/CC

RESOLVED INCOMPLETE

Status

()

Core
XPCOM
P2
normal
RESOLVED INCOMPLETE
10 months ago
10 months ago

People

(Reporter: MattN, Unassigned)

Tracking

({hang, regression})

57 Branch
x86_64
Mac OS X
hang, regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

Created attachment 8907251 [details]
about:support

[Tracking Requested - why for this release]: Major lockups in the content process from CC or GC.

I don't have STR but my one content process is pegged near 100% CPU making pages/tabs in that process respond super slowly e.g. with 5 second delays upon link clicks.

PID 16383 ["Content (4 of 5)"  of the profile] is pegged near 100% CPU

Profile: https://perf-html.io/public/bb3090c885c401466b5117f122a94803bb272664/summary/?hiddenThreads=&thread=5&threadOrder=0-2-3-4-5-6-1

57.0a1 (2017-09-12) (64-bit) built from https://hg.mozilla.org/mozilla-central/rev/b0e945eed81db8bf076daf64e381c514f70144f0
Created attachment 8907252 [details]
Sample of NightlyCP Web Content 20171012
Created attachment 8907266 [details]
Screen Shot of memory usage

Here is a screenshot of memory usage. I also attached a private attachment of my anonymized memory report. I also tried to save a CC + GC log but I only got "incomplete" or empty logs for the PID in question e.g. incomplete-gc-edges.16383.1505247455

I can send them to someone if they're useful.
The hanging process isn't included in the memory report. (which is expected) It is possible, just based on the symptoms, that you are getting a lot of ghost windows (bug 1397062) and that's causing GC/CC to take a really long time. The good news is there's a fix for that on inbound. Without better steps to reproduce this will be hard to investigate.
jld has been seeing similar symptoms. If the two of you could periodically check, before things get catastrophically bad, in about:memory to see if you have ghost windows, that would be helpful.

Updated

10 months ago
Priority: -- → P2
This sounds bad, tentatively tracking for 57.
tracking-firefox57: ? → +
The profile shows this spending all of its time in CC so moving to the XPCOM component.
Component: JavaScript: GC → XPCOM

Comment 8

10 months ago
Matt, can you check with a Nightly with https://hg.mozilla.org/mozilla-central/rev/a8d001a6ee41 in it, to see if that solves your problem?  If so, I think this is just a duplicate of bug 1398671.
Flags: needinfo?(MattN+bmo)
I'm on 56, so it's probably not bug 1398671 if I understand correctly, and I think my bug is different for other reasons: it doesn't lock up as the previous comments describe, but the time for a full CC cycle in the content process exceeds kMaxICCDuration so there's multi-second jank every so often when it finishes the collection uninterruptibly.  In particular, I can get a full GC/CC log, at least in “concise” mode — and in one case the concise CC log was >700 MiB.
I didn't see this again recently
Status: NEW → RESOLVED
Last Resolved: 10 months ago
Flags: needinfo?(MattN+bmo)
Resolution: --- → INCOMPLETE
status-firefox57: affected → ---
tracking-firefox57: + → ---
You need to log in before you can comment on or make changes to this bug.