Closed Bug 1249136 Opened 9 years ago Closed 8 years ago

Crashes in mozilla::layers::D3D9SurfaceImage::~D3D9SurfaceImage correlated to AMD

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Version:
44 Branch
Platform:
Unspecified
Windows
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
platform-rel --- +
firefox47 --- wontfix
firefox-esr45 --- wontfix

People

(Reporter: bkelly, Unassigned)

Details

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

Crash Data

Attachments

(1 file)

Supporttabcopytoclipboard1.docx.txt
9.39 KB, text/plain
Details 
Milan, are there any preferences this user could try to disable buggy drivers?
Flags: needinfo?(milan)
Ben, can you get the person's about:support page attached to this bug report? Looking at the crash data this shows up exclusively on AMD hardware and overwhelmingly on Windows 10.

More info:
https://crash-stats.mozilla.com/report/list?product=Firefox&signature=mozilla%3A%3Alayers%3A%3AD3D9SurfaceImage%3A%3A~D3D9SurfaceImage

Top 5 drivers are as follows:
1 	15.201.1151.1008 	54.34 %
2 	15.201.1151.0 	        20.85 %
3 	15.200.1055.0 	         6.79 %
4 	15.200.1062.1004         4.11 %
5 	15.200.1045.0 	         2.84 %

Top 5 devices are as follows:
1 	Cedar [Radeon HD 5000/6000/7350/8350 Series] (0x68f9) 	5.679%
2 	Wrestler [Radeon HD 6310] (0x9802) 	                4.938%
3 	Wrestler [Radeon HD 7310] (0x9809) 	                3.704%
4 	Thames [Radeon HD 7550M/7570M/7650M] (0x6841)           3.457%
5 	Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] (0x6779) 3.457%
Severity: normal → critical
Crash Signature: [@ mozilla::layers::D3D9SurfaceImage::~D3D9SurfaceImage]
Keywords: crash
Summary: User reports crashing on win10 → Crashes in mozilla::layers::D3D9SurfaceImage::~D3D9SurfaceImage correlated to AMD
Whiteboard: gfx-noted
Version: 45 Branch → 44 Branch
Here is the about:support from the user.
Matt, is this DXVA and should we block these drivers?
Flags: needinfo?(milan) → needinfo?(matt.woodrow)
OS: Unspecified → Windows
This definitely looks like a driver bug.

The vtable pointer of the mQuery member (IDirect3DQuery9) is nullptr when we try free the D3D9SurfaceImage, so we crash trying to call ::Release().

I think the only way that could happen is if it's already been deleted, so I'm guessing the driver has mismatched ref counting?

What's really interesting is that this only ever seems to happen during ResetDecode.

I can't see what would be special about ResetDecode that would cause these queries to be deleted, that wouldn't happen during normal playback.

If the d3d device gets destroyed then it seems plausible, but I can't see anything in the callstack that would cause that to happen.

Jya, think it's possible for the decoder to have been shutdown when we hit ResetDecode? Or more importantly, is this the only time where VideoData objects could outlive the decoder?


(In reply to Milan Sreckovic [:milan] from comment #6)
> This report:
> https://crash-stats.mozilla.com/report/index/f49f40b9-9353-4e00-8942-
> 6d3af2160212 hits the DXVA crash guard:
> https://dxr.mozilla.org/mozilla-central/source/gfx/src/DriverCrashGuard.
> cpp#471

This one is very confusing. If we're getting the crash guard message, then we should have already crashed, restarted and blocked DXVA. Yet we have DXVA output frames in the crash report?
Flags: needinfo?(matt.woodrow) → needinfo?(jyavenard)
(In reply to Matt Woodrow (:mattwoodrow) from comment #7)

sorry for the late reply, slipped out of the radar.

> Jya, think it's possible for the decoder to have been shutdown when we hit
> ResetDecode? Or more importantly, is this the only time where VideoData
> objects could outlive the decoder?

no, it is not possible for a shutdown decoder to continue to be used.
MediaDataDecoder::Shutdown being synchronous, immediately after shutting down, the decoder is destructed.


There is a single method available to shutdown the decoder by the MediaFormatReader:
https://dxr.mozilla.org/mozilla-central/source/dom/media/MediaFormatReader.h#260

So it is not possible for the MFR to use it after, it no longer has a reference to it.

There are plenty of time VideoData could outlive the decoder however. I had never heard that the decoder had to be kept alive while the VideoData was out there. I don't think how we could guarantee that even if we wanted to anyway.

Like when changing resolution on youtube. A VideoData is returned at the old resolution, sent back to the MDSM/Compositor ; and immediately after we detect a new resolution: the decoder is shutdown and a new one is created for the new resolution and then it is fed compressed data until we get a new VideoData.

So the first VideoData returned (the last one prior the resolution change) will always outlive its decoder.
Flags: needinfo?(jyavenard)
Crash volume for signature 'mozilla::layers::D3D9SurfaceImage::~D3D9SurfaceImage':
 - nightly (version 50): 0 crash from 2016-06-06.
 - aurora  (version 49): 0 crash from 2016-06-07.
 - beta    (version 48): 0 crash from 2016-06-06.
 - release (version 47): 1 crash from 2016-05-31.
 - esr     (version 45): 40 crashes from 2016-04-07.

Crash volume on the last weeks:
             Week N-1   Week N-2   Week N-3   Week N-4   Week N-5   Week N-6   Week N-7
 - nightly          0          0          0          0          0          0          0
 - aurora           0          0          0          0          0          0          0
 - beta             0          0          0          0          0          0          0
 - release          0          0          0          0          1          0          0
 - esr              6          6          3          4          3          4          3

Affected platform: Windows
status-firefox47: --- → affected
status-firefox-esr45: --- → affected
platform-rel: --- → ?
Whiteboard: gfx-noted → gfx-noted [platform-rel-AMD]
platform-rel: ? → +
D3D9 is on the way out.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Forgot to mention - no crashes since 45.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: