Open Bug 1277980 Opened 8 years ago Updated 2 years ago

crash in aticfx32.dll@0x4e405 from ImageClientSingle::UpdateImage

Categories

(Core :: Graphics, defect, P3)

Unspecified
Windows 7
defect

Tracking

()

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
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
Outside of blocking more drivers - anything we can do for the UpdateImage subset?
Flags: needinfo?(nical.bugzilla)
(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)
Whiteboard: [gfx-noted]
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.