Closed Bug 934533 Opened 6 years ago Closed 6 years ago

Nightly Nov-04, crash in gfxContext::gfxContext(mozilla::gfx::DrawTarget*) if gfx.content.azure.enabled = false

Categories

(Core :: Graphics, defect, critical)

28 Branch
x86
Windows 7
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla28
Tracking Status
firefox26 --- unaffected
firefox27 + unaffected
firefox28 + verified

People

(Reporter: alice0775, Assigned: mattwoodrow)

References

Details

(Keywords: crash, regression, topcrash-win)

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is 
report bp-95570d66-1d24-4985-9333-307812131104.
=============================================================

Build Identifier:
http://hg.mozilla.org/mozilla-central/rev/b4143e04bea1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131104044747

Browser crashes when click menuitem if ugfx.content.azure.enabled = false

Graphics
--------

Adapter Description: ATI Radeon HD 4300/4500 Series
Adapter Drivers: aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64
Adapter RAM: 512
ClearType Parameters: Gamma: 2200 Pixel Structure: RGB ClearType Level: 50 Enhanced Contrast: 50
Device ID: 0x954f
Direct2D Enabled: true
DirectWrite Enabled: true (6.1.7601.18245)
Driver Date: 4-29-2013
Driver Version: 8.970.100.1100
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 10
Vendor ID: 0x1002
WebGL Renderer: Google Inc. -- ANGLE (ATI Radeon HD 4300/4500 Series Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote: false
AzureCanvasBackend: direct2d
AzureContentBackend: none
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0
Summary: crash in gfxContext::gfxContext(mozilla::gfx::DrawTarget*) → crash in gfxContext::gfxContext(mozilla::gfx::DrawTarget*) if gfx.content.azure.enabled = false
Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/56fc3fc6a42a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131103181808
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/a60b5eb6b8ba
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131103182508
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=56fc3fc6a42a&tochange=a60b5eb6b8ba

Suspected: Bug 922942
Blocks: 922942
Summary: crash in gfxContext::gfxContext(mozilla::gfx::DrawTarget*) if gfx.content.azure.enabled = false → Nightly Nov-04, crash in gfxContext::gfxContext(mozilla::gfx::DrawTarget*) if gfx.content.azure.enabled = false
Assigning to Matt based on Alice's suspected change.
Assignee: nobody → matt.woodrow
As mentioned in the Mozilla build forum (http://forums.mozillazine.org/viewtopic.php?f=23&t=2765951), I have  gfx.content.azure.enabled set to true, and the Nov 04 Nightly crashes nonetheless.

I'm using 32-bit WinXP SP-3. 

Since it seems to be graphics related, maybe I should add that I'm using a Matrox graphics adapter, for which Fx blocks some components. 

The crash report (the latest of many today) says is related to bugs 914134 and 934533, but I don't have time to look them up right now.

The crash reports are being submitted, and I've already received a "Thank you" note and apology from Mozilla!
:-)
Matt, are there any normal user scenarios where gfx.content.azure.enabled is set to false for Windows users? We're trying to measure the criticality. Thanks!
Flags: needinfo?(matt.woodrow)
There should't be, no. I suspect this only happens to users with customs prefs set.

The fix here is to stop using the pref, since we no longer support having it disabled.
Flags: needinfo?(matt.woodrow)
Note that dropping support for disabling Azure will make resolving bug 812695 more urgent (the suggested workaround there is to disable Azure).
I have to set it to false, because i get graphical bugs with the graphical card of the motherboard. This is the problem u fixed time ago -> https://bugzilla.mozilla.org/show_bug.cgi?id=890902
I've just tried it again with a completely new profile, and the crash is gone. It must be one of my extensions. Does anyone see an obvious candidate?
about:addons-memory 7
Adblock Plus 2.4
Adblock Plus Pop-up Addon 0.9.1
Add Bookmark Here ² 23.0.20130728
Add-on Compatibility Reporter 2.0.1 [DISABLED]
Add-ons Manager Dialog Returns 1.4.1 [DISABLED]
Beef Taco (Targeted Advertising Cookie Opt-Out) 1.3.7
BetterPrivacy 1.68
Cleanest Addon Manager 7.0
Cookie Button 0.9.3
Custom Toolbar Buttons 0.6.0.8
Download YouTube Videos as MP4 1.7.12
DownThemAll! 2.0.16
Element Hiding Helper for Adblock Plus 1.2.3
Fasterfox Lite 3.9.9Lite
FireFTP 2.0.16
Flashblock 1.5.17
FlashGot 1.5.5.94rc2
FoxyProxy Standard 4.2.3
Greasemonkey 1.12
Hide Tab Bar With One Tab 1.1
ImageTweak 0.25.1
JS Switch 0.2.10
keyconfig 20110522
Nightly Tester Tools 3.7
Norton Toolbar 2013.4.4.3 [DISABLED]
Norton Vulnerability Protection 12.0.3.2 - 1 [DISABLED]
NoScript 2.6.8.4
Open link in... 1.9
OptimizeGoogle 0.79.1
Print Edit 10.2
Quick Locale Switcher 1.7.8.5
QuickPageZoom 1.6.3
Remove It Permanently 1.0.6.10
Restart application 1.2.1
SaveAsFilename 0.1
Screengrab  (fix version) 0.97.15c
Site Favicon in Urlbar 8.1
SmoothWheel (AMO) 0.45.8.20130519.3
Status-4-Evar 2013.10.31.22
Theme Font & Size Changer 7.2
UAControl 0.1.3.1
User-Agent JS Fixer 1.3
Web Developer 1.2.5
YouTube Unblocker 0.5.3 [DISABLED]
Creating a new profile should reset all pref, that means 'gfx.content.azure.enabled' is back to true, that's why you haven't the problem. It's not an extension problem.
As I've said, gfx.content.azure.enabled IS set to true, but I still have the crashes. When I go back to 03 Nov, everything's fine.
Also, it immediately crashes when I right click.
I've just tried the 64-bit Nightly on Win7 (on another computer), and it's exactly the same. "gfx.content.azure.enabled" is set to true on that machine, too.

On Win7, though, once Fx crashed, I wasn't able to restart it, even in safe mode. This wasn't the case on Win XP. 

Like on XP, though, a new profile solved the problem. 

I really think it must be an extension: I have the same ones on both machines.
Attachment #827041 - Flags: review?(ncameron)
(In reply to JoeG from comment #10)
> As I've said, gfx.content.azure.enabled IS set to true, but I still have the
> crashes. When I go back to 03 Nov, everything's fine.

You might have a custom value for gfx.content.azure.backends that is causing azure to be disabled.

(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #6)
> Note that dropping support for disabling Azure will make resolving bug
> 812695 more urgent (the suggested workaround there is to disable Azure).

Right, we need to do something there. Unfortunately we can't keep supporting non-azure content forever, so we need a real fix or a different workaround.
That was it, Matt. Thanks very much. Somehow I had set it so that there was no value there at all. I reset it, and now I'm OK on both machines. Sorry for my ignorance.
Comment on attachment 827041 [details] [diff] [review]
Remove azure pref

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

See the second comment

::: gfx/thebes/gfxPlatform.h
@@ +661,2 @@
>      /**
>       * If aEnabledPrefName is non-null, checks the aEnabledPrefName pref and

remove this part of the comment

::: gfx/thebes/gfxPlatformMac.cpp
@@ +68,5 @@
>  
>      uint32_t canvasMask = (1 << BACKEND_CAIRO) | (1 << BACKEND_SKIA) | (1 << BACKEND_COREGRAPHICS);
>      uint32_t contentMask = (1 << BACKEND_CAIRO) | (1 << BACKEND_COREGRAPHICS);
> +    InitBackendPrefs(canvasMask, BACKEND_CAIRO,
> +                     contentMask, BACKEND_COREGRAPHICS);

Why don't we just always use cairo as the default backend and not pass a default around. There should always be better options in the pref list, so we should (in theory) never use the default - it should be an absolute worst case fallback for when a user does something unlikely like delete the whole list. With the customisable default it just adds complexity because there is an extra way to set a fallback backend.
Attachment #827041 - Flags: review?(ncameron)
(In reply to Alex Keybl [:akeybl] from comment #4)
> Matt, are there any normal user scenarios where gfx.content.azure.enabled is
> set to false for Windows users? We're trying to measure the criticality.
> Thanks!

Yes, there have been any number of folks that set the pref to false as a work-around for blurry fonts since the MS patch landed months ago that messes up display randomly for AMD/ATI graphics cards.  Recently with the uplift to Win8.1, they too are now seeing the issue and are setting it to 'false'. 

See https://bugzilla.mozilla.org/show_bug.cgi?id=812695 for the MS Pre patch and its large number of Duplicate bugs and Dependencies, now approaching its first birthday.

Not sure if there are any data Mozilla may have of those that have tweaked the pref to 'false'.

Removing the pref and forcing the pref to 'true' is going to leave folks with blurry fonts, and no work-around or fix short of a computer upgrade.
I sure hope a fix is right around the corner 'cause, as much as I would like to, I can't have azure left on without fonts getting messed up.
In local build
Last Good: 412123f1e16a
First Bad: effddcf29fa7

Triggered by: 
effddcf29fa7	Matt Woodrow — Bug 922942 - Use the screen reference draw target in SVG. r=jwatt
(In reply to Nick Cameron [:nrc] from comment #16)
> ::: gfx/thebes/gfxPlatformMac.cpp
> @@ +68,5 @@
> >  
> >      uint32_t canvasMask = (1 << BACKEND_CAIRO) | (1 << BACKEND_SKIA) | (1 << BACKEND_COREGRAPHICS);
> >      uint32_t contentMask = (1 << BACKEND_CAIRO) | (1 << BACKEND_COREGRAPHICS);
> > +    InitBackendPrefs(canvasMask, BACKEND_CAIRO,
> > +                     contentMask, BACKEND_COREGRAPHICS);
> 
> Why don't we just always use cairo as the default backend and not pass a
> default around. There should always be better options in the pref list, so
> we should (in theory) never use the default - it should be an absolute worst
> case fallback for when a user does something unlikely like delete the whole
> list. With the customisable default it just adds complexity because there is
> an extra way to set a fallback backend.

I really don't trust users to set sane values for this pref.

It seemed better to fallback to our choices unless the user had a sane override set in the prefs. I can change it if you feel strongly though, it doesn't really matter.
(In reply to Matt Woodrow (:mattwoodrow) from comment #20)
> (In reply to Nick Cameron [:nrc] from comment #16)
> > ::: gfx/thebes/gfxPlatformMac.cpp
> > @@ +68,5 @@
> > >  
> > >      uint32_t canvasMask = (1 << BACKEND_CAIRO) | (1 << BACKEND_SKIA) | (1 << BACKEND_COREGRAPHICS);
> > >      uint32_t contentMask = (1 << BACKEND_CAIRO) | (1 << BACKEND_COREGRAPHICS);
> > > +    InitBackendPrefs(canvasMask, BACKEND_CAIRO,
> > > +                     contentMask, BACKEND_COREGRAPHICS);
> > 
> > Why don't we just always use cairo as the default backend and not pass a
> > default around. There should always be better options in the pref list, so
> > we should (in theory) never use the default - it should be an absolute worst
> > case fallback for when a user does something unlikely like delete the whole
> > list. With the customisable default it just adds complexity because there is
> > an extra way to set a fallback backend.
> 
> I really don't trust users to set sane values for this pref.
> 

Nor me, but I think it will be a very small number of users and they will still get something that works, just not optimally, which is better than what you get if you mess with many other prefs.

> It seemed better to fallback to our choices unless the user had a sane
> override set in the prefs. I can change it if you feel strongly though, it
> doesn't really matter.

I think we should, I don't think it is worth the extra code complexity. And at some point someone will want to turn it into a pref, and then we'll need another default, and...
Comment on attachment 827041 [details] [diff] [review]
Remove azure pref

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

r=me with the nit fixed and Cairo removed from the mac bit mask

(summary of discussion on irc: we can't always use Cairo because it is not supported on Mac due to ContentClientIncremental (the bitmask in gfxPlatformMac is currently incorrect), therefore we need some mechanism for specifying the default, and even though it adds a bit of complexity, this is probably as good as it gets. If anyone wants to turn that default parameter into a pref at some time in the future they should not do that.)
Attachment #827041 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/53c000e62746
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
I believe this should be uplifted to Aurora.

This pref is in Aurora (27). Crash stats is also showing reports of this signature on 27.0a2. I was also able to reproduce on Win 8 Surface Pro as a startup crasher by setting gfx.content.azure.enabled = false. 

As more of the fixed higher volume crashes drop off the top of this list, this will rise into the top 10. It is now #13 topcrash-win on the 7 day report and #10 on the 3 day report. 

Also note: gfxContext::gfxContext(mozilla::gfx::DrawTarget*) remains on Nightly (28), but those are probably bug 914314.
Firefox 26 is also effected.  I got nailed by this crash (#937969) when upgrading from Firefox 26 Beta 3 to Firefox Beta 4.
(In reply to [:tracy] Tracy Walker - QA Mentor from comment #25)
> I believe this should be uplifted to Aurora.
> 
> This pref is in Aurora (27). Crash stats is also showing reports of this
> signature on 27.0a2. I was also able to reproduce on Win 8 Surface Pro as a
> startup crasher by setting gfx.content.azure.enabled = false. 
> 
> As more of the fixed higher volume crashes drop off the top of this list,
> this will rise into the top 10. It is now #13 topcrash-win on the 7 day
> report and #10 on the 3 day report. 
> 
> Also note: gfxContext::gfxContext(mozilla::gfx::DrawTarget*) remains on
> Nightly (28), but those are probably bug 914314.

I think you're seeing bug 937972, which should be uplifted.

We can't uplift this patch to branches, because we don't actually support azure properly there yet.
(In reply to Matt Woodrow (:mattwoodrow) from comment #27)

> 
> I think you're seeing bug 937972, which should be uplifted.
> 
> We can't uplift this patch to branches, because we don't actually support
> azure properly there yet.

Isn't bug 937972 a dupe of this bug?  in both cases, setting gfx.content.azure.enabled = false makes the browser crashy.
True, but the callstack to that crash is different.

This bug is because we decided that we would no longer support disabling azure for 28. We landed some patches that relied on that assumption, but didn't actually remove the pref. The patch landed for this bug has fixed that problem.

Bug 937972 is because we accidentally uplifted a patch also making the same assumption onto a branch where it wasn't the case. The fix there was to change what was uplifted so that it doesn't rely on azure being enabled.

This bug shouldn't be tracking firefox27, as it doesn't affect it.
Matt,  

Thank you for explaining. My case of confusion is cleared up. :-)
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.