1240241 - crash in mozilla::gfx::FilterCachedColorModels::ForColorModel

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Zac Campbell]

This bug was filed from the Socorro interface and is 
report bp-52240b1e-15af-4af4-b7da-1d8dc2160109.
=============================================================

This crash is occurring on a mid-range tablet running Windows 8.1.

The crash is always preceded by the whole Firefox window losing its visuals.. What I mean is that the content area goes solid black and the XUL area (ie tab, address bar, etc) loses all of its features and just takes the background colour of Windows 8.1.
Unfortunately I don't have a screenshot nor a steps to replicate just now. I have seen it with both very resources intensive websites (ie large google sheets) and also on simple pages.

When Firefox reaches this state it does not 'come back' even after waiting several minutes. The only work around I know is to resize the window, which is not perfect but sometimes makes all the xul and content area come back. However aggressively resizing the window usually results in a crash.

Comment 1

[Zac Campbell]

This crash (also mine) has arisen from a similar symptoms and seems closely related.

https://crash-stats.mozilla.com/report/index/5f989792-0b5e-45b1-aba2-0c6412160110

Comment 2

[Adrian Florinescu [:aflorinescu]]

In last 3days, crash confirmed as follow:

Windows 8.1	35.90%	14
Windows 7	33.33%	13
Windows 10	25.64%	10
Windows 8	5.13%	2

Based on crash signature assigning component.

Comment 3

[u279076]

This is strongly correlated to systems with Intel graphics cards (94%), mainly Ivybridge and Haswell chips. It also goes back to Firefox 40 based on six months of data but doesn't show up in any Aurora or Nightly builds. Not nominating to track at this point since current volume does not even break into the top-300 signatures. 

Intel GPU Breakdown:
====================
6th Generation [0.4%]
* Sandybridge-GT1 - 0.4%

7th Generation [82.5%]
* Ivybridge-GT1 - 23.1%
* Ivybridge-GT2 - 20.9%
* Haswell-GT1 - 5.5%
* Haswell-GT2 - 28.3%
* Baytrail - 4.7%

8th Generation [6.0%]
* Broadwell-GT2 - 6%

9th Generation [1.3%]
* Skylake-GT2 - 1.3%

Intel Driver Breakdown:
=======================
10.18.10.* - 71.8%
10.18.14.* - 14.5%
10.18.15.* - 10.7%
20.19.15.* -  1.7%
 9.17.10.* -  0.9%

Firefox Version Breakdown:
==========================
Firefox 40.* - 32.0%
Firefox 41.* - 22.8%
Firefox 42.* - 19.0%
Firefox 43.* - 19.0%
Firefox 44.* -  7.2%

Comment 4

[u279076]

The stacks look really weird here, 1024 frames of WrapForColorModel() calling ForColorModel() calling WrapForColorModel() calling ForColorModel() and so on....

Milan, do you know who's best on the GFX team to look at this?

Comment 5

[Zac Campbell]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #3)
> This is strongly correlated to systems with Intel graphics cards (94%),
> mainly Ivybridge and Haswell chips. 

I just googled and yeah mine has the Intel graphics chip!

> It also goes back to Firefox 40 based on six months of data but doesn't show up in any Aurora or Nightly builds. 

Do you think this is significant or just an artifact of low crash numbers? 
It occurs on my 2nd computer so I don't use it every day, but I can spend some time with Nightly and see if i can replicate this crash.

Comment 6

[Milan Sreckovic [:milan] (needinfo for best results)]

Let's see if we need to uplift this once we have a fix.

Comment 7

[u279076]

(In reply to Zac Campbell from comment #5)
> (In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #3)
> > This is strongly correlated to systems with Intel graphics cards (94%),
> > mainly Ivybridge and Haswell chips. 
> 
> I just googled and yeah mine has the Intel graphics chip!
> 
> > It also goes back to Firefox 40 based on six months of data but doesn't show up in any Aurora or Nightly builds. 
> 
> Do you think this is significant or just an artifact of low crash numbers?

I suspect this has more to do with crash volumes although we certainly have Aurora and Nightly users with these chipset/driver combinations given they're fairly modern. That said, Nightly/Aurora users tend to have multi-process turned on which might be another factor. It certainly wouldn't hurt if you could try reproducing this in Nightly with and without multiprocess enabled. If you can reproduce it there it'd be worth seeing if you can get a regression window using mozregression.

Comment 8

[Markus Stange [:mstange]]

This is funny crash.

// Internally, this is achieved by wrapping the original FilterNode with
// conversion FilterNodes. These filter nodes are cached in such a way that no
// repeated or back-and-forth conversions happen.
... unless creating the wrapper fails. Then we get infinite recursion.

So yes, I can fix this particular crash, but it probably won't get us out of the black window state. It sounds like once we get into this state, all graphics resources are completely exhausted and allocating any graphics object will fail.

Comment 9

[Zac Campbell]

I haven't managed to replicate the issue on Nightly precisely as originally reported however I got it into a similarly graphically corrupted state which sounds like it could be as described in comment 8. In this case the browser window would not update unless I resized the window. All the elements on the page were working and if you clicked on the page and a link was in that place then link would load, however the content area would not change to reflect that until the screen was resized and it was refreshed. In the screenshot you can see that some tabs that have been closed (by me using keyboard shortcuts) and some new ones opened.

I left the browser like this for about 30 minutes incase some garbage cleaner kicked in and fixed it all up but nothing happened.

I'm still not sure quite how to replicate this aside from opening up a bunch of graphics heavy tabs.

Comment 10

[Zac Campbell]

Attachment: nightly-buggyscreenshot.png

Screenshot to go with my previous comment.

Comment 11

[Milan Sreckovic [:milan] (needinfo for best results)]

Let's make this bug about the infinite recursion crash, but the problems seen with the corruption are also elsewhere and I want to see if we can get more information from this particular workflow. 

Zac, when bad things start happening, but they get better by resizing the window - any "error" messages in the graphics section of about:support?

Comment 12

[Zac Campbell]

Milan, shall we spin off a separate bug for that issue? In the meantime I'll work on getting the information from about:support.

Comment 13

[Milan Sreckovic [:milan] (needinfo for best results)]

The about:support may give us a hint that it's one of the existing bugs, but if that is not the case, for sure we should get another bug opened.

Comment 14

[Markus Stange [:mstange]]

Attachment: MozReview Request: Bug 1240241 - Don't recurse infinitely in FilterCachedColorModels::ForColorModel if the original filter node was null. r?roc

Review commit: https://reviewboard.mozilla.org/r/31667/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/31667/

Comment 15

[Zac Campbell]

I've caused another crash but a different trace this time:
https://crash-stats.mozilla.com/report/index/96e3f62e-32d0-4e54-990a-e8cd42160122
In this case it was switching from a youtube fullscreen video with alt-tab rather than pressing Esc.

Still working on getting the about:support for the active but not updating scenario.

Comment 16

[Zac Campbell]

I still haven't replicated comment 0 on Nightly, but I have suffered the comment #15 crash again.

Just before that crash occurred I captured this graphics information from about:support

Graphics
--------

Adapter Description: Intel(R) HD Graphics
Adapter Drivers: igdumdim32 igd10iumd32 igd10iumd32
Adapter RAM: Unknown
Asynchronous Pan/Zoom: none
Device ID: 0x0f31
DirectWrite Enabled: false (6.3.9600.18123)
Driver Date: 6-9-2014
Driver Version: 10.18.10.3643
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Subsys ID: 221b17aa
Supports Hardware H264 Decoding: No; CheckDeviceFormatConversion failed with error 8876086A
Vendor ID: 0x8086
windowLayerManagerRemote: true
AzureCanvasBackend: skia
AzureContentBackend: cairo
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0
(#0) Assert: [D3D11] 2 CreateTexture2D failure Size(1920,1036) Code: 0x887a0005
(#194) Assert: Failed 2 buffer db=00000000 dw=00000000 for 0, 0, 942, 1134
(#195) Assert: Failed 2 buffer db=00000000 dw=00000000 for 0, 0, 942, 1134
(#196) Assert: Failed 2 buffer db=00000000 dw=00000000 for 0, 0, 942, 1134
(#197) Assert: Failed 2 buffer db=00000000 dw=00000000 for 0, 0, 942, 1134
(#198) Assert: Failed 2 buffer db=00000000 dw=00000000 for 0, 0, 942, 1134




I am not sure if these are the same bug but they are definitely all associated with poor graphics/usability.


During normal use, the Graphics section in about:support reads:

Graphics
--------

Adapter Description: Intel(R) HD Graphics
Adapter Drivers: igdumdim32 igd10iumd32 igd10iumd32
Adapter RAM: Unknown
Asynchronous Pan/Zoom: none
Device ID: 0x0f31
Direct2D Enabled: true
DirectWrite Enabled: true (6.3.9600.18123)
Driver Date: 6-9-2014
Driver Version: 10.18.10.3643
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Subsys ID: 221b17aa
Supports Hardware H264 Decoding: Yes
Vendor ID: 0x8086
WebGL Renderer: Google Inc. -- ANGLE (Intel(R) HD Graphics Direct3D11 vs_5_0 ps_5_0)
windowLayerManagerRemote: true
AzureCanvasBackend: direct2d 1.1
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 8710744 [details]
MozReview Request: Bug 1240241 - Don't recurse infinitely in FilterCachedColorModels::ForColorModel if the original filter node was null. r?roc

https://reviewboard.mozilla.org/r/31667/#review29125

Comment 18

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/97292625fc86

Comment 19

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Zac Campbell from comment #15)
> I've caused another crash but a different trace this time:
> https://crash-stats.mozilla.com/report/index/96e3f62e-32d0-4e54-990a-
> e8cd42160122
> In this case it was switching from a youtube fullscreen video with alt-tab
> rather than pressing Esc.
> 
> Still working on getting the about:support for the active but not updating
> scenario.

Let's get a separate bug for this.  I want to make sure we don't lose this information as this bug gets resolved once the patch lands.  Same for the crash from comment 16.

Comment 20

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/97292625fc86

Comment 21

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/97292625fc86