1399238 - Content process pegged near 100% CPU doing GC/CC

Status: RESOLVED INCOMPLETE

(Core :: XPCOM, defect, P2)

Description

[Matthew N. [:MattN]]

Attachment: 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

Comment 1

[Matthew N. [:MattN]]

Attachment: Sample of NightlyCP Web Content 20171012

Comment 3

[Matthew N. [:MattN]]

Attachment: 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.

Comment 4

[Andrew McCreight [:mccr8]]

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.

Comment 5

[Andrew McCreight [:mccr8]]

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.

Comment 6

[Julien Cristau [:jcristau]]

This sounds bad, tentatively tracking for 57.

Comment 7

[Jon Coppeard (:jonco)]

The profile shows this spending all of its time in CC so moving to the XPCOM component.

Comment 8

[Nathan Froyd [:froydnj]]

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.

Comment 9

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

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.

Comment 10

[Matthew N. [:MattN]]

I didn't see this again recently