crash in aticfx32.dll@0x4e405

VERIFIED FIXED in mozilla37

Status

()

Core
Graphics: Layers
--
critical
VERIFIED FIXED
3 years ago
2 years ago

People

(Reporter: lizzard, Assigned: nical)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {crash})

34 Branch
mozilla37
x86
Windows NT
crash
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox33 wontfix, firefox34 affected, firefox35 affected)

Details

(crash signature)

Attachments

(1 attachment)

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
Crash Signature: [@ aticfx32.dll@0x4e405] → [@ aticfx32.dll@0x4e405] [@ aticfx32.dll@0x4e455]
(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.
(Assignee)

Updated

3 years ago
Blocks: 1088034
(Assignee)

Comment 3

3 years ago
Created attachment 8529344 [details] [diff] [review]
Blacklist this driver version
Assignee: nobody → nical.bugzilla
Attachment #8529344 - Flags: review?(bas)
(Assignee)

Comment 4

3 years ago
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.
(Assignee)

Comment 5

3 years ago
Comment on attachment 8529344 [details] [diff] [review]
Blacklist this driver version

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

r=Bas on Nical's computer
Attachment #8529344 - Flags: review?(bas) → review+
(Assignee)

Comment 6

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/fb4748d18cc7
https://hg.mozilla.org/mozilla-central/rev/fb4748d18cc7
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
There don't seem be any more crashes in aticfx32.dll for version 37.
Status: RESOLVED → VERIFIED
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.
Depends on: 1277980
See Also: → bug 1277980
You need to log in before you can comment on or make changes to this bug.