User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:43.0) Gecko/20100101 Firefox/43.0 Build ID: 20150820163010 Steps to reproduce: Install 43.0a1 from http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win64-pgo/1440124231/. Actual results: Fx crashed at startup Expected results: Fx should start up.

Good: https://hg.mozilla.org/integration/mozilla-inbound/rev/72ab85dd82abbace8f870bec523d7d9bff8ca7cb Bad: https://hg.mozilla.org/integration/mozilla-inbound/rev/4fd3f9fdf6c252a7538e6317222ab2148aa0cd5c Crash reports were produced but as I'm on inbound I don't know if they are of much use to you.

Crash Report: https://crash-stats.mozilla.com/report/index/18620374-7df6-4e2b-a1a2-71c892150821 Firefox 43.0a1 Crash Report [@ xul.dll@0x4e9514 | nss3.dll@0x2161f | xul.dll@0x44fc9a | mozglue.dll@0x52a3 ]

Problem appears to be caused by a Pref. Will try to find out which one.

The offending pref is this one in my prefs.js: user_pref("gfx.vsync.hw-vsync.enabled", false); I happened to receive an update to my AMD drivers this morning which I am guessing has something to do with the problem. The update was applied unsolicited.

I reinstalled the AMD drivers that I had previous to the update this morning and Fx43 still crashes with the pref set to false. This rules out the AMD drivers and points to some problem with vsync set to false within the regression range I gave.

(In reply to Gary [:streetwolf] from comment #4) > The offending pref is this one in my prefs.js: > user_pref("gfx.vsync.hw-vsync.enabled", false); > > I happened to receive an update to my AMD drivers this morning which I am > guessing has something to do with the problem. The update was applied > unsolicited. Did you have this pref as false before? It's been set to true by default since Gecko 40. Also, the good/bad range show EME, so it'd be curious if bug 1196308 caused it. The code path deleted in bug 1196308 shouldn't be used at all since gecko 40. The pref gfx.vsync.hw.vsync-enabled being false really shouldn't be supported anymore by the end of Gecko 43. Can you try the build here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1094708c473f That will isolate bug 1196308.

I've had it set to false for quite awhile. I use it along with the pref to increase my framerate from the default 60 to 120. I'll give your build a try.

Mason... I'm not familiar with what is shown at the link you gave me. Is there a complete build there that I need to download. If so, where is it?

I think I found it .... http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mchang@mozilla.com-1094708c473f/try-win64/ If this is what you want me to test I still crash at startup with vsync disabled.

So do you think it's https://bugzilla.mozilla.org/show_bug.cgi?id=1197022 causing the problem?

(In reply to Gary [:streetwolf] from comment #7) > I've had it set to false for quite awhile. I use it along with the pref to > increase my framerate from the default 60 to 120. I'll give your build a > try. I'm not surprised that you're crashing then. Having this preference be false isn't going to be supported anymore. If you have the preference set to true, does Firefox still crash? > I think I found it .... > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mchang@mozilla.com- > 1094708c473f/try-win64/ If this is what you want me to test I still crash > at startup with vsync disabled. Yup that's it! Does it still crash with vsync enabled? (In reply to Gary [:streetwolf] from comment #10) > So do you think it's https://bugzilla.mozilla.org/show_bug.cgi?id=1197022 > causing the problem? Probably not if you don't crash with the preference set to true.

(In reply to Gary [:streetwolf] from comment #9) > I think I found it .... > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mchang@mozilla.com- > 1094708c473f/try-win64/ If this is what you want me to test I still crash > at startup with vsync disabled. Can you also just try this build with vsync enabled and ensure that Firefox doesn't crash? Thanks!

No crash ever with vsync = true. Evidently something in the regression range I gave previously causes the crash to happen when vsync = false. Setting vsync = false and layout.frame_rate = 120 actually cause some graphic sites to show 120 fps instead of the normal 60 fps. Once such site is http://www.fishgl.com/. I don't know if this is for real or this particular demo just plugs in the frame rate from the pref. Some sites still show 60 fps.

Your try build doesn't crash with vsync enabled.

Nothing ever crashed with vsync enabled. It's when it's disabled after the 'good' build I posted above.

With bug 1196308, we deleted the non-vsync compositor code paths. The preferences however are still active. If hardware vsync was disabled, we'd try to use the vsync compositor still and the Vsync source wouldn't exist and we'd crash. This preference deletes the hardware vsync and vsync compositor preference paths so the crash should go away even if the preferences are false. In a follow up bug, I'll delete the refresh driver preference once I clean up the refresh driver some more.

Comment on attachment 8651577 [details] [diff] [review] Delete hardware vsync and vsync compositor preferences Review of attachment 8651577 [details] [diff] [review]: ----------------------------------------------------------------- \o/ \o/

url: https://hg.mozilla.org/integration/mozilla-inbound/rev/697f5d72aebe8d661e31424f328ffb1539d8e904 changeset: 697f5d72aebe8d661e31424f328ffb1539d8e904 user: Mason Chang <mchang@mozilla.com> date: Mon Aug 24 11:27:23 2015 -0400 description: Bug 1197201. Delete hardware vsync and vsync compositor prefs. r=kats