Closed Bug 1197201 Opened 5 years ago Closed 5 years ago

43.0a1 crashes on startup due to pref user_pref("gfx.vsync.hw-vsync.enabled", false);

Categories

(Core :: Graphics, defect, P2)

43 Branch
x86_64
Windows 10
defect

Tracking

()

RESOLVED FIXED
mozilla43
Tracking Status
firefox43 --- fixed

People

(Reporter: streetwolf, Assigned: mchang)

References

Details

(Keywords: regression, Whiteboard: gfx-noted)

Attachments

(1 file)

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.
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 ]
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Severity: normal → blocker
Priority: -- → P1
Problem appears to be caused by a Pref. Will try to find out which one.
Severity: blocker → normal
Priority: P1 → P2
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.
Component: Untriaged → Graphics
Product: Firefox → Core
Summary: 43.0a1 crashes on startup → 43.0a1 crashes on startup due to pref user_pref("gfx.vsync.hw-vsync.enabled", false);
(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.
Flags: needinfo?(garyshap)
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.
Flags: needinfo?(garyshap)
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.
Flags: needinfo?(garyshap)
(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.
Flags: needinfo?(garyshap)
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.
Attachment #8651577 - Flags: review?(bugmail.mozilla)
Whiteboard: gfx-noted
Comment on attachment 8651577 [details] [diff] [review]
Delete hardware vsync and vsync compositor preferences

Review of attachment 8651577 [details] [diff] [review]:
-----------------------------------------------------------------

\o/ \o/
Attachment #8651577 - Flags: review?(bugmail.mozilla) → review+
Assignee: nobody → mchang
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
https://hg.mozilla.org/mozilla-central/rev/697f5d72aebe
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
Blocks: 1133528
You need to log in before you can comment on or make changes to this bug.