Closed Bug 1449348 Opened 6 years ago Closed 6 years ago

browser/components/contextualidentity/test/browser/browser_eme.js | Uncaught exception - [Exception... "NS_ERROR_FAILURE (0x80004005)

Categories

(Core :: Security: Process Sandboxing, defect, P5)

defect

Tracking

()

RESOLVED FIXED
mozilla61
Tracking Status
firefox61 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: bobowen)

References

(Blocks 1 open bug)

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

Unfortunately, I got side-tracked by also having the top Beta crasher. :-(

This appears to be failing at [1], so the GMP process is failing to start properly.
The confusing thing here is why this would be an intermittent issue. The blocking of win32k calls is really an all or nothing thing.

I can only guess that there is some sort of timing issue and the win32k blocking affects the timing somehow.
Either that or the timing issue involves a call to a win32k API which fails, presumably this must be a debug only call.

I'm not sure how frequent an orange needs to be to consider a backout.
The win32k part of this is controlled by a pref, so we could flip that which would hopefully remove the orange.

It would be nice to leave this in Nightly for a while to see if any other issues arise.
I'll carry on looking at this in the morning.

[1] https://searchfox.org/mozilla-central/rev/028cd8342899357d80fafba2d528a0fd5819e316/dom/media/gmp/GMPParent.cpp#449
The following try pushes (running just the failing tests) are fairly conclusive that it is just the win32k disable part of the change that causes the intermittents.

win32k allowed:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=b87ce9f8399ab1afc131414432c2726e6fc4c671

win32k disabled:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=03900ba6892697ed16ca3c30664e0c77467a802c

I managed to use the cool feature of being able to edit the taskcluster tasks to change the environment variables to turn on logging for the sandbox and GMP. I guess these links won't last too long but here's a failing one:
https://taskcluster-artifacts.net/Ewy3XM0WR9yvTrScQSaIHA/0/public/logs/log_raw.log

and a working one:
https://taskcluster-artifacts.net/TCEhkxh8SRSMZIMKA-27JQ/0/public/logs/log_raw.log

There is a "resolved" message for the GMP path just before the launch of the process and in the working one we get a "GMPChild ctor" message immediately after.
In the failing one we get no GMP messages from the child, but we also don't get a failed launch SandboxBroker message from the parent.
So it looks like the process is starting and then failing very early.

I've tried to reproduce locally without any joy, so I guess we'll need to get a loaner to try and track this down.

It's not clear whether we're going to be moving any more processing into GMP anytime soon and we have other things we want to work on, so for the moment I'm going to pref this off and file a follow-up to investigate.
Assignee: nobody → bobowencode
Status: NEW → ASSIGNED
See Also: → 1451270
Attachment #8964813 - Flags: review?(jmathies) → review+
Pushed by bobowencode@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3c92c9b3f4db
Pref off win32k disable for GMP due to intermittent failures. r=jimm
https://hg.mozilla.org/mozilla-central/rev/3c92c9b3f4db
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
You need to log in before you can comment on or make changes to this bug.