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)

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

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.

Nightly75.0a1 Windows10 without WebRender also crashes with bp-7f4eab86-c9b4-4e12-87b0-9de910200213

Regression window from comment#3:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=07a4c42f&tochange=440eac58

Regression window with further bisection:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4c5cb4d45593abd679eec77c9651c6fc4187e2e9&tochange=248d909386f55c57aaf622eed1d0425d96bb6ee8

Regressed by: Bug 1542808 rather than Bug 1594128

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

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.

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().

• VsyncRefreshDriverTimer::mVsyncSource
• RefreshTimerVsyncDispatcher::mDisplay

Sorry, no idea.

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.

Backed out changeset 8bc3cd786136 for causing leaks.

Backout link: https://hg.mozilla.org/integration/autoland/rev/8c15464d5d636c8cf192c523f09f18cdd17c9df9

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Crunnable&tochange=8c15464d5d636c8cf192c523f09f18cdd17c9df9&fromchange=14a6cc2958978f583171712634654c075b7aee0f&selectedJob=293069114

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=293069178&repo=autoland&lineNumber=1653

Apologies for the hiccup, leakcheck looks good now.

Backed out changeset ef75f461147c (bug 1614212) for GTest failures

Backout: https://hg.mozilla.org/integration/autoland/rev/0fdeafcdcb41a6e7def0650ef1d93e3e5bef9299

Failure push: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=ef75f461147c5148755e505ed8b8c2d9ca20f856

Failure log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=293259931&repo=autoland&lineNumber=3791
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=293260945&repo=autoland&lineNumber=24268

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.

https://hg.mozilla.org/mozilla-central/rev/2a815d6be90d

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.