Closed Bug 1188876 Opened 10 years ago Closed 6 years ago

Crash in atiumdag.dll with old AMD drivers

Categories

(Core :: Audio/Video: Playback, defect, P3)

Product:
Core
Component:
Audio/Video: Playback
Platform:
x86
Windows 7
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: philipp, Unassigned)

References

(
URL
)

Details

(Keywords: crash, Whiteboard: [platform-rel-AMD])

Crash Data

This bug was filed from the Socorro interface and is report bp-c973e772-2c0a-4d0b-b6c7-ef4892150729. ============================================================= the crash was reported by a user in the support forum and didn't have an associated bug yet. apparently it's not happening in safemode: https://support.mozilla.org/en-US/questions/1074910 crash stats show that this kind of crash is half of the time occurring <1m uptime and another 25% during the first 5 minutes. this crash happens predominantly with old amd driver versions 8.892.1.1000, 8.892.0.0 and 8.892.2.3000 from 2012. affected gpus are: 1 Radeon HD 6530D (0x964a) 113 40.79 % 2 Radeon HD 6410D (0x9644) 44 15.88 % 3 Radeon HD 6370D (0x9642) 30 10.83 % 4 Radeon HD 6550D (0x9640) 28 10.11 % 5 Radeon HD 6320 (0x9806) 19 6.86 % 6 Radeon HD 6450 (0x6779) 15 5.42 % 7 Radeon HD 5570 (0x68c7) 11 3.97 % 8 Radeon HD 5450 (0x68f9) 7 2.53 %
Note that there's been 258 reports over the last week so it's not really high volume. I also see reports back to Firefox 12 so this isn't a new regression. 100% of the crashes are happening on Windows 7. If you could see whether disabling hardware acceleration works around this that'd be good to know. If so we might be able to solve this with blacklisting, particularly since this seems to be mostly with outdated drivers. Here is the stack: 0 ntdll.dll RtlpCoalesceFreeBlocks 1 ntdll.dll RtlpFreeHeap 2 ntdll.dll RtlpCoalesceFreeBlocks 3 kernel32.dll HeapFree Ø 4 atiumdag.dll atiumdag.dll@0x441bc Ø 5 atiumdva.dll atiumdva.dll@0x8b47 Ø 6 atiumdva.dll atiumdva.dll@0x8d78 Ø 7 atiumdva.dll atiumdva.dll@0x8c4d Ø 8 atiumdva.dll atiumdva.dll@0x18e7 Ø 9 atiumdva.dll atiumdva.dll@0x180b Ø 10 atiumdva.dll atiumdva.dll@0x13f7 Ø 11 atiumdag.dll atiumdag.dll@0x3aae0 Ø 12 atiumdag.dll atiumdag.dll@0x1207 Ø 13 atiumdag.dll atiumdag.dll@0x2bde Ø 14 atiu9pag.dll atiu9pag.dll@0x3132 Ø 15 atiu9pag.dll atiu9pag.dll@0x34a3 Ø 16 aticfx32.dll aticfx32.dll@0x21a3b Ø 17 aticfx32.dll aticfx32.dll@0x242fd Ø 18 aticfx32.dll aticfx32.dll@0x2426f Ø 19 aticfx32.dll aticfx32.dll@0x2188b Ø 20 aticfx32.dll aticfx32.dll@0x208df 21 d3d9.dll CreateDeviceLHDDI 22 d3d9.dll D3D9CreateDirectDrawObject 23 d3d9.dll FetchDirectDrawData 24 d3d9.dll D3D8ReenableDirectDrawObject 25 d3d9.dll CEnum::CEnum(unsigned int, int) 26 d3d9.dll Direct3DCreate9Impl(unsigned int, int, IDirect3D9Ex**) 27 d3d9.dll Direct3DCreate9Ex 28 xul.dll mozilla::D3D9DXVA2Manager::Init() dom/media/wmf/DXVA2Manager.cpp 29 xul.dll mozilla::DXVA2Manager::Create() dom/media/wmf/DXVA2Manager.cpp 30 xul.dll mozilla::CreateDXVAManagerEvent::Run() dom/media/fmp4/wmf/WMFVideoMFTManager.cpp 31 xul.dll nsThreadSyncDispatch::Run() xpcom/threads/nsThread.cpp 32 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp 33 xul.dll mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 34 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc 35 xul.dll nsThreadManager::UnregisterCurrentThread(nsThread*) xpcom/threads/nsThreadManager.cpp 36 xul.dll nsBaseAppShell::Run() widget/nsBaseAppShell.cpp 37 xul.dll nsAppStartup::Run() toolkit/components/startup/nsAppStartup.cpp 38 xul.dll XREMain::XRE_mainRun() toolkit/xre/nsAppRunner.cpp Philipp, please make sure you include the stack when reporting a crash bug. Thanks.
OS: Windows → Windows 7
the user in the sumo thread reported that safemode as well as updating the driver fixed the crashes, so blocklisting might be helpful here.
(In reply to philipp from comment #2) > the user in the sumo thread reported that safemode as well as updating the > driver fixed the crashes, so blocklisting might be helpful here. Thanks for checking in to this. Lawrence, I'm not sure what the normal blacklist requesting process is so flagging you for attention.
Flags: needinfo?(lmandel)
milan ^ driver blacklist request
Flags: needinfo?(lmandel) → needinfo?(milan)
actually my description of the scope of these types of crashes in my original bug comment may have been far too small, as there are a lot more crashes with similar signatures (around 2000 last week): https://crash-stats.mozilla.com/search/?product=Firefox&signature=~atiumdag.dll&signature=~RtlpFreeHeap&_facets=signature&_facets=adapter_driver_version&_facets=app_notes&_facets=version&_facets=adapter_device_id&_facets=adapter_vendor_id&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature also the driver versions where this is happening might be spread out more as well, so i'm not sure anymore if blocklisting is the right approach. could someone from gfx take a closer look at this?
Crash Signature: [@ RtlpCoalesceFreeBlocks | RtlpFreeHeap | RtlpCoalesceFreeBlocks | HeapFree | atiumdag.dll@0x441bc] [@ RtlpCreateSplitBlock | RtlpFreeHeap | RtlpCoalesceFreeBlocks | HeapFree | atiumdag.dll@0x441bc] → [@ RtlpCoalesceFreeBlocks | RtlpFreeHeap | RtlpCoalesceFreeBlocks | HeapFree | atiumdag.dll@0x441bc] [@ RtlpCreateSplitBlock | RtlpFreeHeap | RtlpCoalesceFreeBlocks | HeapFree | atiumdag.dll@0x441bc] [@ RtlpCoalesceFreeBlocks | RtlpFreeHeap | RtlpCoales…
Summary: Crash in atiumdag.dll@0x441bc with old AMD drivers → Crash in atiumdag.dll with old AMD drivers
Matt, looks like we should blocklist the DXVA, or is it the D3D9 DXVA + D3D11 layers that's the problem and we're not noticing the blocklisting that may already be there?
Component: Graphics → Audio/Video
Flags: needinfo?(milan) → needinfo?(matt.woodrow)
This particular stack looks to only be d3d9 specific, not DXVA. I can see some crashes with stacks coming from WebGL/ANGLE initialization, and I assume (if a user set the prefer-d3d9 pref) we could also crash trying to initialize the compositor. Our blacklisting rules for d3d9 currently on apply to layers, do we want to extend these to the other users of d3d9 (dxva and ANGLE)? I think we want to do a few things here: * Add dvander's crash detection helpers to these two callsites so that we won't attempt to use this functionality again in the future if we crash. * Blacklist DXVA, WebGL and D3D9 layers for these drivers. OR * Make DXVA and WebGL check the D3D9 blacklist, and only blacklist d3d9.
Flags: needinfo?(matt.woodrow) → needinfo?(dvander)
I'll do the driver init crash detection in bug 1190281. That'll help bug 1184215 which has the exact same stack. Some telemetry data on proceeding with blacklisting: The top four devices in comment #0 are 4402 out of 2897764 sessions (0.15%), which is about 1% of AMD sessions. The driver versions in comment #0 are 1361 out of 2897764 sessions (0.05%), or about 0.34% of AMD sessions. So it seems reasonable to proceed with blacklisting?
Flags: needinfo?(dvander) → needinfo?(matt.woodrow)
Component: Audio/Video → Audio/Video: Playback
Still seeing reports in socorro. Why doesn't the starup check blacklist this?
The startup check's cached data get cleared with each driver update or firefox release. So we'd expect each affected user to crash once per release, does that match what you're seeing Ralph?
I believe the "once per release/update" is not there for Nightly, so those would be repeated? Also, non-withstanding comment 5, are there some driver versions that we do want to block?
Flags: needinfo?(matt.woodrow)
We can't easily blacklist here, because we don't have a blacklist option for just d3d9 (DXVA or otherwise). We could block DXVA, but that would disable d3d11 too, which wouldn't be affected by this crash. I think we might need to add a d3d9 specific feature that also disables all other features that use it (d3d9 layers, d3d9 dxva, d3d9 ANGLE).
(In reply to Matt Woodrow (:mattwoodrow) from comment #12) > We can't easily blacklist here, because we don't have a blacklist option for > just d3d9 (DXVA or otherwise). Is D3D11 DXVA available on this old driver and does it work?
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #13) > (In reply to Matt Woodrow (:mattwoodrow) from comment #12) > > We can't easily blacklist here, because we don't have a blacklist option for > > just d3d9 (DXVA or otherwise). > > Is D3D11 DXVA available on this old driver and does it work? Someone else might be able to answer this better, but it appears that this crash happens on all versions of windows. If these drivers are available on win8+ (which it appears they are), then it should be possible to get d3d11 dxva.
This has a crash guard (bug 1190281), right? So, the crashes only happen once for each user/version/driver. Or, am I not interpreting the code correctly?
Yeah, this crash should fall under the crash guard.
(In reply to David Anderson [:dvander] from comment #16) > Yeah, this crash should fall under the crash guard. I'm going to lower the priority then.
Priority: P1 → P3
Soccoro shows no crashes with this signature since 23-June. Should we close?
Flags: needinfo?(ajones)
Flags: needinfo?(ajones) → needinfo?(madperson)
platform-rel: --- → ?
Whiteboard: [platform-rel-AMD]
platform-rel: ? → +
platform-rel: + → ---
Closing because no crash reported since 12 weeks.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Closing because no crash reported since 12 weeks.
You need to log in before you can comment on or make changes to this bug.