Open
Bug 1277980
Opened 8 years ago
Updated 2 years ago
crash in aticfx32.dll@0x4e405 from ImageClientSingle::UpdateImage
Categories
(Core :: Graphics, defect, P3)
Tracking
()
NEW
People
(Reporter: milan, Unassigned)
References
Details
(Whiteboard: [gfx-noted])
Follow up to bug 1099252 which (obviously) couldn't take care of blocking the drivers that were created since that bug was fixed.
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 bug 1099252; 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:
https://crash-stats.mozilla.com/search/?product=Firefox&signature=~aticfx32.dll%400x4e455&_facets=signature&_columns=date&_columns=signature&_columns=version&_columns=build_id&_columns=adapter_driver_version#crash-reports
Reporter | ||
Comment 1•8 years ago
|
||
All (*) of these crashes are from ImageClientSingle::UpdateImage.
Blocks: 1099252
Summary: crash in aticfx32.dll@0x4e405 (try again) → crash in aticfx32.dll@0x4e405 from ImageClientSingle::UpdateImage
Reporter | ||
Comment 2•8 years ago
|
||
Outside of blocking more drivers - anything we can do for the UpdateImage subset?
Flags: needinfo?(nical.bugzilla)
Comment 3•8 years ago
|
||
(In reply to Milan Sreckovic [:milan] from comment #2)
> Outside of blocking more drivers - anything we can do for the UpdateImage
> subset?
We could probably go into paranoid mode and check that GetImmediateContext provides a non-null context, although I don't think that's what we are running into here, and MSDN seems to indicate that the returned pointer is never null. The other thing we could try is ask the compositor if it is in a "good" state, and bail out of UpdateFromSurface early if it just went through a device reset or something alike. To be honest, this would only help if the driver has a specific bug with UpdateSubResource when getting into an awkward state (out of memory?), otherwise it'll probably just move the crash somewhere else.
Adding gfx critical error to the crashstats query you provided shows that a lot of the sessions already went through some failures before giving up: https://crash-stats.mozilla.com/search/?product=Firefox&signature=~aticfx32.dll%400x4e455&_facets=signature&_columns=date&_columns=signature&_columns=version&_columns=build_id&_columns=adapter_driver_version&_columns=graphics_critical_error#crash-reports
Flags: needinfo?(nical.bugzilla)
Updated•8 years ago
|
Whiteboard: [gfx-noted]
Reporter | ||
Updated•7 years ago
|
Priority: -- → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•