1213107 - crash in RtlpCreateSplitBlock | RtlpFreeHeap | RtlpCoalesceFreeBlocks | HeapFree | atiumdag.dll@0x45bdc

Status: RESOLVED FIXED

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

Description

[Benoit Girard (:BenWa)]

This bug was filed from the Socorro interface and is 
report bp-8383479b-db02-460c-8f3c-f438d2151008.
=============================================================

Reproduces 100% of the time on Toronto's G575 (6250 Radeon) laptop when going to about:support.

Comment 1

[Benoit Girard (:BenWa)]

dvander maybe? You've looked at handling crashes with this file.

Comment 2

[David Anderson [:dvander] - inactive, e-mail if emergency]

(In reply to Benoit Girard (:BenWa) from comment #1)
> dvander maybe? You've looked at handling crashes with this file.

After it crashes, when you restart Firefox, does it crash again? I'm wondering if the crash guard is doing its job here. If not, what about on a new profile?

Either way sounds like we should block either the driver or the device or both.

Comment 3

[Benoit Girard (:BenWa)]

It's a nearly brand new profile. I went to about:support 2 or 3 times in a row and got the crash each time.

Comment 4

[David Anderson [:dvander] - inactive, e-mail if emergency]

Right, I forgot. The crash guard is disabled in nightly builds so that's why you keep getting the crash. Okay let's just block this device then, both its driver and device ID have very low occurrences on Telemetry (~0.1%).

Comment 5

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: blocklist patch

There are a handful of reports with ATI crashes in d3d9 device creation, with the same signature. They are all on one of two driver versions, on Windows 7, and it looks like the crashes can come from ANGLE as well.

This blocks the devices and drivers in those crash reports, for hardware video decoding and D3D9 ANGLE.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 8671723 [details] [diff] [review]
blocklist patch

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

Why are we blocking those particular devices unconditionally? Do we have any reason to believe there's something specific to those devices and the problem isn't more widespread?

Comment 7

[David Anderson [:dvander] - inactive, e-mail if emergency]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #6)
> Comment on attachment 8671723 [details] [diff] [review]
> blocklist patch
> 
> Review of attachment 8671723 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Why are we blocking those particular devices unconditionally? Do we have any
> reason to believe there's something specific to those devices and the
> problem isn't more widespread?

The particular crash doesn't have very high volume and it looked limited to two driver versions and three device IDs. The patch blocks both independently. But actually just blocking the driver versions is probably good enough, if you think that's better.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 8671723 [details] [diff] [review]
blocklist patch

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

Yes. I'd rather just block the driver.

Comment 9

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/81be051cd7a8

Comment 10

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Backed out for Windows build bustage: https://treeherder.mozilla.org/logviewer.html#?job_id=15456368&repo=mozilla-inbound

https://hg.mozilla.org/integration/mozilla-inbound/rev/2883cb33dcce

Comment 11

[Benoit Girard (:BenWa)]

Comment on attachment 8671723 [details] [diff] [review]
blocklist patch

Sorry for the drive-by r- but WebGL works on that machine for us and Chrome. It's just this crash, which seems to be with hardware decoding, that bites us in about:support.

I don't think we should disable WebGL there.

Comment 12

[David Anderson [:dvander] - inactive, e-mail if emergency]

I'd rather be safe than sorry, most crashes with this signature are in webgl since creating d3d9 devices is what's mysteriously broken. The incidence of this driver is really low on Telemetry.

Comment 13

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8141f1fc49d2

Comment 14

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/8141f1fc49d2