Opening a new content process hangs GUI for several seconds since the build of 2016-11-19

RESOLVED INCOMPLETE

Status

()

Core
DOM: Content Processes
--
major
RESOLVED INCOMPLETE
11 months ago
24 days ago

People

(Reporter: avada, Unassigned)

Tracking

(Blocks: 1 bug, {perf})

53 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox52 unaffected, firefox53 affected)

Details

(Whiteboard: [e10s-multi:-])

Attachments

(1 attachment)

(Reporter)

Description

11 months ago
Since this build whenever a new content process is started the GUI hangs for several seconds. I see the main process at around the maximum 25% CPU usage.
I could reproduce this in safe mode. And even with one content process the hang is noticeable at startup.
Downgrading to the previous nightly build restores normal functioning.

However I couldn't reproduce it with a brand new profile.
(Reporter)

Updated

11 months ago
Blocks: 1207306
Severity: normal → major
(Reporter)

Comment 1

11 months ago
Created attachment 8812581 [details]
about-support.txt

About:support from affected profile in safe mode.

Updated

11 months ago
Keywords: perf

Comment 2

11 months ago
Could you try to using mozregression to find the actual patch that caused the problem?
https://harthur.github.io/mozregression/
That would be extremely helpful! There's an option to use an existing profile.
Flags: needinfo?(dqeswn)
(Reporter)

Comment 3

11 months ago
(In reply to Bill McCloskey (:billm) from comment #2)
> Could you try to using mozregression to find the actual patch that caused
> the problem?
> https://harthur.github.io/mozregression/
> That would be extremely helpful! There's an option to use an existing
> profile.

No need. The day before it was good. I actually downgraded to 11-18 build, because it's excruciating to use FF like this, and the issue is gone.
So it's something that landed on the 2016-11-19 build.
Flags: needinfo?(dqeswn)

Comment 4

11 months ago
(In reply to avada from comment #3)
> (In reply to Bill McCloskey (:billm) from comment #2)
> > Could you try to using mozregression to find the actual patch that caused
> > the problem?
> > https://harthur.github.io/mozregression/
> > That would be extremely helpful! There's an option to use an existing
> > profile.
> 
> No need. The day before it was good. I actually downgraded to 11-18 build,
> because it's excruciating to use FF like this, and the issue is gone.
> So it's something that landed on the 2016-11-19 build.

Mozregression is more precise than that though. It can bisect mozilla-inbound builds and tell us exactly which patch caused the regression. Otherwise we'll have to sift through a list of 100 or so patches that landed that day and try to figure out what might have caused it.
(Reporter)

Comment 5

11 months ago
(In reply to Bill McCloskey (:billm) from comment #4)
> Mozregression is more precise than that though. It can bisect
> mozilla-inbound builds and tell us exactly which patch caused the
> regression. Otherwise we'll have to sift through a list of 100 or so patches
> that landed that day and try to figure out what might have caused it.

How do I specify bits? I run x86, but mozregression defaults to x64. And the guide has no information on this.
Status: UNCONFIRMED → NEW
status-firefox52: --- → unaffected
status-firefox53: --- → affected
Ever confirmed: true
Version: Trunk → 53 Branch
(Reporter)

Comment 6

11 months ago
(In reply to Bill McCloskey (:billm) from comment #4)
Okay. Without a more detailed guide I won't be doing it. I can't set it to be the same build as I have. This with "hu" locale to be precise: https://archive.mozilla.org/pub/firefox/nightly/2016/11/2016-11-19-03-02-04-mozilla-central-l10n/


Also it starts with an empty profile which is useless, because the issue is not present with a fresh profile, and I couldn't successfully specify the profile I needed.

Comment 7

11 months ago
avada, you can find some documentation for mozregression at https://mozilla.github.io/mozregression/.  I think the page linked by :billm is outdated?

To run a specific profile using a 32 bit build, you might do something like the following:

mozregression --good 2016-11-18 --bad 2016-11-19 --profile /path/to/profile --bits 32

A full list of commands can be found by typing:

mozregression --help
(Reporter)

Comment 8

11 months ago
(In reply to Trevor Rowbotham from comment #7)
> avada, you can find some documentation for mozregression at
> https://mozilla.github.io/mozregression/.  I think the page linked by :billm
> is outdated?
> 
> To run a specific profile using a 32 bit build, you might do something like
> the following:
> 
> mozregression --good 2016-11-18 --bad 2016-11-19 --profile /path/to/profile
> --bits 32
> 
> A full list of commands can be found by typing:
> 
> mozregression --help

That didn't work for me on windows. When I pasted the full windows path, enter didn't run the command but opened a new line. When I changed backslashes to slashes it was just completely ignored. So all it accomplished is wasting my time. No idea what format it expects.

I'm expected find the bug for mozilla, but no-one bothers to maintain a valid, usable guide.
(Reporter)

Comment 9

11 months ago
Okay, so I figured it out. It claims it's bug 1151899:

13:04.82 INFO: Looks like the following bug has the changes which introduced the regression:
https://bugzilla.mozilla.org/show_bug.cgi?id=1151899


(For the future, in case localization is a factor: How can I set mozregression to get builds that appear in the "latest-mozilla-central-l10n" section with a specific locale?)
Blocks: 1151899

Updated

11 months ago
Depends on: 1318432
Thanks so much avada! It looks like that patch will be disabled. I know regression finding seems like a thankless task, but in this case it helped.

Unfortunately I don't think we localize mozilla-inbound builds, so it's not possible to get a localized version for regression finding.
Is this still an issue or was it fixed by bug 1318432?
Whiteboard: [e10s-multi:?]
Flags: needinfo?(dqeswn)
(Reporter)

Comment 12

8 months ago
Not sure. I disabled that rust thing as the preference was added. I'll have to check.
Flags: needinfo?(dqeswn)
(Reporter)

Comment 13

8 months ago
Okay. So the issue is still present on my main profile. (network.standard-url.enable-rust;true)
Even in safe mode.

However on a new profile it isn't. No clue as to why. I guess there's another factor, a changed setting or something else.

Updated

7 months ago
Whiteboard: [e10s-multi:?] → [e10s-multi:-]

Comment 14

2 months ago
Can you try and run a diff on the settings files to see which ones are different? You/We can then work to figure it which pref is triggering this (if it is a pref at all).
Flags: needinfo?(dqeswn)
(Reporter)

Comment 15

2 months ago
Lost interest. I won't be using v57 and this won't make it to v56. Plus all anyone ever did with it was getting me to jump through hoops.

Anyway I did a quick test (one last time) with network.standard-url.enable-rust;true. I couldn't reproduce it on beta, central won't even start with my main profile anymore, but it doesn't show the symptomps either with legacy extensions disabled or in safe mode.

So it may have been accidentally be fixed.
Flags: needinfo?(dqeswn)

Updated

24 days ago
Status: NEW → RESOLVED
Last Resolved: 24 days ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.