Closed Bug 1614212 Opened 10 months ago Closed 9 months ago

Crash when changing the value of layout.frame_rate

Categories

(Core :: Widget, defect, P2)

Desktop
Windows
defect

Tracking

()

VERIFIED FIXED
mozilla76
Tracking Status
firefox-esr68 --- unaffected
firefox73 --- wontfix
firefox74 --- wontfix
firefox75 --- wontfix
firefox76 --- verified

People

(Reporter: yoasif, Assigned: kennylevinsen)

References

(Regression)

Details

(Keywords: regression)

Crash Data

Attachments

(1 file)

Spawned from https://bugzilla.mozilla.org/show_bug.cgi?id=1560090#c5

Steps to reproduce:

  1. Navigate to about:config
  2. Update layout.frame_rate to 120

What happens:

Firefox crashes with [GFX1-]: Receive IPC close with reason=AbnormalShutdown

Expected result:

Firefox does not crash.

2020-02-09T13:34:24: INFO : Narrowed nightly regression window from [2019-11-26, 2019-11-28] (2 days) to [2019-11-26, 2019-11-27] (1 days) (~0 steps left)

Has STR: --- → yes
Keywords: regression
See Also: → 1560090

:yoasif, could you try to find a regression range in using for example mozregression?

Hello,
I have been able to reproduce this on Nightly version 75.0a1 (2020-02-12), beta version 74.0b2 (64-bit) and release 73.0 (64-bit) using the same repro steps on Windows 10x64, MacOs 10.13.6 and Ubuntu 18.04.3.
I have set a component for this issue, however if you feel like it's not the correct one, feel free to change it.

Component: Untriaged → Preferences
Product: Firefox → Toolkit
Version: 72 Branch → Trunk

I have performed a regression test with mozregression and these are my results:

2020-02-13T15:58:43: INFO : Narrowed inbound regression window from [bcbb45f7, 440eac58] (3 builds) to [07a4c42f, 440eac58] (2 builds) (~1 steps left)
2020-02-13T15:58:43: DEBUG : Starting merge handling...
2020-02-13T15:58:43: DEBUG : Using url: https://hg.mozilla.org/mozilla-central/json-pushes?changeset=440eac58d324fd982a89a21c25a6c9d2a9c8ccf6&full=1
2020-02-13T15:58:44: DEBUG : Found commit message:
Backed out 12 changesets (bug 1594128) because of rendering regressions a=backout
Backed out changeset 39f51911efa8 (bug 1594128)
Backed out changeset a8ee6dbf146b (bug 1594128)
Backed out changeset beeeb1889588 (bug 1594128)
Backed out changeset 84e767a37637 (bug 1594128)
Backed out changeset 54efcc9976cf (bug 1594128)
Backed out changeset 5768997fb391 (bug 1594128)
Backed out changeset 0d89ea8665df (bug 1594128)
Backed out changeset ba4668d01dc5 (bug 1594128)
Backed out changeset e5f6739f790d (bug 1594128)
Backed out changeset 550591122788 (bug 1594128)
Backed out changeset 6386aa316da9 (bug 1594128)
Backed out changeset 6762aab18459 (bug 1594128)
2020-02-13T15:58:44: DEBUG : Did not find a branch, checking all integration branches
2020-02-13T15:58:44: INFO : The bisection is done.
2020-02-13T15:58:44: INFO : Stopped

It appears that the regressor is bug 1594128. If incorrect, please NI me.

Regressed by: 1594128
Component: Preferences → Graphics: WebRender
Product: Toolkit → Core
Crash Signature: [@ MessageLoop::PostTask_Helper | D3DVsyncSource::D3DVsyncDisplay::EnableVsync]
Regressed by: 1542808
No longer regressed by: 1594128

The regressing patch is pretty big. Not sure if either of you remember enough about it to diagnose?

Flags: needinfo?(sotaro.ikeda.g)
Flags: needinfo?(lsalzman)
OS: Unspecified → Windows
Priority: -- → P2
Hardware: Unspecified → Desktop
Flags: needinfo?(stransky)
Flags: needinfo?(lsalzman)
Flags: needinfo?(bugzilla)
Component: Graphics: WebRender → Widget

The supposedly offending patch is a Linux/GTK change, with a relatively small cross-platform part. Thus, from the perspective of debugging a Windows regression, it should not be that daunting.

I can try to look at it, but it will be a bit cumbersome as I do not have a Windows development environment.

:RyanVM Sorry, could you update the statuses again? I ended up overwriting them by accident due to comment collision, and yet I don't have the rights to set them back.

Flags: needinfo?(ryanvm)

Crash happened, since D3DVsyncSource::EnableVsync() was called after D3DVsyncSource::Shutdown() call. mVsyncThread was already deleted and mVsyncThread was a dangling pointer.

CompositorVsyncDispatcher change in Bug 1542808 has a problem. By the change, CompositorVsyncDispatcher became to hold VsyncSource, but VsyncSource is re-created by gfxPlatform::ReInitFrameRate(). Old VsyncSource is shutdown. All references of the old VsyncSource need to be updated.

And the followings also seem to cause a problem with gfxPlatform::ReInitFrameRate().

Flags: needinfo?(sotaro.ikeda.g)

Sorry, no idea.

Flags: needinfo?(stransky)

This switch was very important to me for variable refresh rate testing.

When FireFox used this command line option, and running in full screen mode, with NVIDIA Control Panel configured to Variable Refresh Rate, the browser automatically played as if the frame rate was a refresh rate. 77 frames per second ran exactly like 77 Hertz refresh rate.

There's a need for standardizing variable refresh rate support in web browsers, but this was one of the possible mechanisms to test variable refresh rate support.

I can reproduce on X11. With the help of sotaro's analysis, I'm working on a fix. The core problem is easy to fix, but with it comes a little bit of lock reorganization/cleanup.

CompositorVsyncDispatcher holds a reference to the VsyncSource, so it must be informed on change.

Assignee: nobody → bugzilla
Status: NEW → ASSIGNED
Pushed by ccoroiu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8bc3cd786136
Migrate global VsyncSource users correctly on frame rate change r=sotaro

Apologies for the hiccup, leakcheck looks good now.

Flags: needinfo?(bugzilla)
Pushed by ccoroiu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ef75f461147c
Migrate global VsyncSource users correctly on frame rate change r=sotaro

A RefPtr was incorrectly changed to a weak ptr while solving the circular dependency causing the previous leaks on shutdown. Additional tests run, still fixes the original issue, and still doesn't trip the leakchecks, so I think we're good now.

Flags: needinfo?(bugzilla)
Pushed by nerli@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2a815d6be90d
Migrate global VsyncSource users correctly on frame rate change r=sotaro
Status: ASSIGNED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla76
Flags: qe-verify+

Reproduced the crash using Firefox 74.0a1 (20200209215935) and STR from comment 0 on Windows 10 without WebRender.
The issue is verified fixed using Firefox 76.0b5 (20200415234430) on Windows 10x64. No crashes encountered while setting layout.frame_rate to 120.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
See Also: → 1630631
You need to log in before you can comment on or make changes to this bug.