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

RESOLVED INCOMPLETE

Status

()

--
major
RESOLVED INCOMPLETE
2 years ago
a year ago

People

(Reporter: dqeswn, Unassigned)

Tracking

({perf})

53 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox52 unaffected, firefox53 affected)

Details

(Whiteboard: [e10s-multi:-])

Attachments

(1 attachment)

(Reporter)

Description

2 years 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

2 years ago
Blocks: 1207306
Severity: normal → major
(Reporter)

Comment 1

2 years ago
Created attachment 8812581 [details]
about-support.txt

About:support from affected profile in safe mode.

Updated

2 years ago
Keywords: perf
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

2 years 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)
(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

2 years 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

2 years 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.
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

2 years 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

2 years 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?)
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

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

Comment 13

2 years 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.
Whiteboard: [e10s-multi:?] → [e10s-multi:-]

Comment 14

a year 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

a year 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)
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.