1580742 - [ARM64] Widevine plugin crashes on Netflix and Amazon Prime

Status: VERIFIED FIXED

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

Description

[Timea Cernea [:tbabos][inactive]]

Attachment: Screenshot of error

Affected versions
Nightly 71.0a1 (2019-09-11) (64-bit)

Affected platforms
ARM64 - Windows 10 - Lenovo Yoga laptop with Qualcom Adreno 630 GPU.
Driver version: 25.18.10440.0

Steps to reproduce

• Launch Firefox
• Log in to Netflix account
• Wait for Widevine to be installed

Expected result
Widevine should be installed on a new profile

Actual Result
Widevine plugin crashes and a black screen with an error is displayed, error code: F7702-1003. Check the attached screenshot.

Regression-Range
Beta70 and Release69 are not affected by this issue, seems to be a new regression.
Tried to mozregress this but I'm constantly having BSOD due to Bug 1548410 and can't find the range..

Comment 1

[Timea Cernea [:tbabos][inactive]]

Attachment: Amazon Prime

Same plugin crash happens on Amazon Prime too.

Comment 2

[Chris]

I'm having the same issue on Hulu, Netflix, and Prime video as well.

Comment 3

[Pascal Chevrel:pascalc (PTO until April 26)]

Timea, does it still happen on a recent Nightly build?

Comment 4

[Timea Cernea [:tbabos][inactive]]

Yes, Widevine plugin still crashes on the latest Nightly (2019-10-09) on the Yoga laptops.

Comment 5

[Daniel Bodea [:danibodea]]

It also occurs on Spotify on Nightly v71.0a1 on Yoga.

Comment 6

[Daniel Bodea [:danibodea]]

It also occurs on HBO Go on Nightly v71.0a1 on Lenovo Yoga C630 13Q50, Windows 10 v1903 OS build 18362.418 and GPU driver 10.0.18362.1.

Comment 7

[Pascal Chevrel:pascalc (PTO until April 26)]

Nils, is that something we can fix before we ship 71?

Comment 8

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Could you try testing with the GMP sandbox disabled and seeing if that has any impact?

The steps can be found here -- essentially set the environment variable MOZ_DISABLE_GMP_SANDBOX=1 before starting Firefox and then testing.

Comment 9

[Rares Doghi, Desktop QA]

Hi, We tested this issue with the MOZ_DISABLE_GMP_SANDBOX=1 environment variable and its working this way. No Crashes, the Netflix videos play without issues.

Comment 10

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Thanks for checking, that's useful to know.

Bob, given comment 9, do you have any suggestions as to how we could further identify what the sandbox may be doing here?

Comment 11

[Bob Owen (:bobowen)]

I'll take a look as soon as I can, leaving NI for now.

Comment 12

[Bob Owen (:bobowen)]

mozregression was off to start with, but close enough that meant I got it to work on a second range just on autoland.
This was regressed by bug 1578422.
This is exactly the issue that it was designed to catch and explains why it is nightly only.

Now I just need to work out why the shared memory set-up for the crash reporter is failing.

Comment 13

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

The x86 media plugin isn't launched directly by the parent process, I think? (See bug 1530245.) So maybe the fix for bug 1575906 isn't working?

Comment 14

[Bob Owen (:bobowen)]

I think I've worked out what's going on here.

On arm64, because we don't have a native widevine DLL, we use an unsandboxed x86 process to launch a sandboxed x86 process to host the x86 widevine DLL we do have.
That is then hooked up via IPC channels to the arm64 processes.

The problem is that the CrashReporterClient tries to duplicate the handle for its shared memory to the real arm64 parent.
We added a rule in bug 1575906 for this to allow duplication back to the broker (normally the parent process).
In the arm64 case the sandboxed x86 process's broker is the unsandboxed x86 process, so the duplication to the real arm64 parent fails.

So, to allow the duplication to the real arm64 parent, we need to add a HANDLES_DUP_ANY rule instead and add the real parent as a target peer to the x86 broker.
I've tried this and the CrashReporterClient seems to initialize OK.
I can't test widevine properly, because it won't work in local or try builds, so we'll have to wait for a Nightly, but I think we should be OK.
I'll get the patch up tomorrow.

Comment 15

[Bob Owen (:bobowen)]

Attachment: Bug 1580742: Allow sandboxed x86 GMP process to duplicate crashreporter handle to the arm64 main process. r=handyman!

Comment 16

[Maire Reavy [:mreavy]]

Thanks for taking this, Bob.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f5bdb80f1108
Allow sandboxed x86 GMP process to duplicate crashreporter handle to the arm64 main process. r=handyman

Comment 18

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/f5bdb80f1108

Comment 19

[Pascal Chevrel:pascalc (PTO until April 26)]

Bob, 71 is marked as affected, is that a patch we could uplift in beta? Thanks

Comment 20

[Bob Owen (:bobowen)]

(In reply to Pascal Chevrel:pascalc from comment #19)

Bob, 71 is marked as affected, is that a patch we could uplift in beta? Thanks

The crash was caused by a diagnostic assert, so it doesn't happen on beta and release.
However, the shared memory issue is still there and has been since the first release on arm64, so I would be inclined to let it roll out normally, given that we're quite late in the cycle.

Comment 21

[Alin Ilea, Desktop QA]

Verified - fixed on latest Nightly 72.0a1 (Build id: 20191119043902) using ARM64 - Windows 10 - Lenovo Yoga laptop.