This bug was filed from the Socorro interface and is report bp-ba798070-3b34-4602-b56c-0cdd22141111. ============================================================= This signature is at 132/15167 crashes for 34.0b8. It also looks high for the 33.0.3 and 33.1 releases, and is present in 35. Crashing thread: 0 aticfx32.dll aticfx32.dll@0x4e405 Ø 1 aticfx32.dll aticfx32.dll@0x4e471 Ø 2 aticfx32.dll aticfx32.dll@0x1deb3 Ø 3 aticfx32.dll aticfx32.dll@0x19e95 Ø 4 aticfx32.dll aticfx32.dll@0x12302 5 d3d11.dll CContext::ID3D11DeviceContext1_UpdateSubresource_<1>(ID3D11DeviceContext1*, ID3D11Resource*, unsigned int, D3D11_BOX const*, void const*, unsigned int, unsigned int) 6 xul.dll mozilla::layers::DataTextureSourceD3D11::Update(mozilla::gfx::DataSourceSurface*, nsIntRegion*, mozilla::gfx::IntPointTyped<mozilla::gfx::UnknownUnits>*) gfx/layers/d3d11/TextureD3D11.cpp 7 xul.dll mozilla::layers::BufferTextureHost::Upload(nsIntRegion*) gfx/layers/composite/TextureHost.cpp 8 xul.dll mozilla::layers::BufferTextureHost::Lock() gfx/layers/composite/TextureHost.cpp 9 xul.dll mozilla::layers::ContentHostTexture::Lock() gfx/layers/composite/ContentHost.h 10 xul.dll mozilla::layers::ContentHostBase::Composite(mozilla::layers::EffectChain&, float, mozilla::gfx::Matrix4x4 const&, mozilla::gfx::Filter const&, mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits> const&, nsIntRegion const*) gfx/layers/composite/ContentHost.cpp 11 xul.dll mozilla::layers::ThebesLayerComposite::RenderLayer(nsIntRect const&) gfx/layers/composite/ThebesLayerComposite.cpp

This driver is pretty old... Image path: C:\Windows\System32\aticfx32.dll Timestamp: Sat Apr 02 15:58:22 2011 (4D9690CE) File version: 8.17.10.1071

(Submitted too early) I also added another signature that appears only on this driver and in similar context. There are several different "version" fields but they are all consistent (gfx team, which do you care most about?). The aticfx32.dll version is 8.17.10.1071, the atiuxpag.dll version is 8.14.1.6195, and the crash annotations say 8.832.0.0.

I am wondering if this crash is due to the driver not properly handling running out of memory, failing to allocate textures and choking on it. I don't have much to back this theory, but if it is the case, blocklisting isn't great because it mostly moves the crash to our regular OOM signature and the affected users don't enjoy hardware acceleration any more. The system memory use percentage is pretty high in these reports. Higher than the average crash and somewhat comparable to the numbers you can see when searching for OOM signatures in crashstats (granted, this isn't a very scientific observation). On the other hand There were very few crashes with this driver version before 33/OMTC even though some stack traces show that the D3D10 code is implemented on top of D3D11 internally. I would expect similar crashes to have shown up before OMTC if it was caused by texture allocation failure in the driver since OOMs are not specific to OMTC. There is also nothing in the appnotes and if this was triggered by OOM I would expect that at least some of the times gecko would have failed to allocate something before and reported it in the appnotes. With the information we have I suppose that the safe thing to do is blocklist this driver version, but it'd be nice to be certain that it isn't caused by OOMs which would crash gecko somewhere else anyway.

Comment on attachment 8529344 [details] [diff] [review] Blacklist this driver version Review of attachment 8529344 [details] [diff] [review]: ----------------------------------------------------------------- r=Bas on Nical's computer

There don't seem be any more crashes in aticfx32.dll for version 37.

These two are on 46, so I can't tell if the user is forcing acceleration somehow, but they are accelerated, while matching the configuration blocked in this bug; Windows 7, ATI, 8.832.0.0: https://crash-stats.mozilla.com/report/index/11cd8568-7212-4451-831f-7a7652160529 https://crash-stats.mozilla.com/report/index/fc6c9104-fef3-4879-9e80-bd1d82160603 On the other hand, we have seemingly the same crashes on different drivers 8.834.* and 8.836.*. (as in, at exact the same address.) I imagine the newer drivers just moved the address, which is why we only see those three sets. I will open another bug with this, because we did see the improvement for 37.