Closed Bug 1268379 Opened 4 years ago Closed 4 years ago
startup crash in @0x0 | CClient
Context Activator::Create Instance
[Tracking Requested - why for this release]: This bug was filed from the Socorro interface and is report bp-98f4fc5a-9f19-444d-9f23-c0fa52160428. ============================================================= Crashing Thread (25) Frame Module Signature Source 0 @0x0 1 ole32.dll CClientContextActivator::CreateInstance(IUnknown*, IActivationPropertiese*, IActivationPropertiesOut**) 2 ole32.dll CComActivator::DoCreateInstance(_GUID const&, IUnknown*, unsigned long, _COSERVERINFO*, unsigned long, tagMULTI_QI*, ActivationPropertiese*) 3 ole32.dll CoCreateInstanceEx 4 ole32.dll CoCreateInstance 5 xul.dll mozilla::MFTDecoder::Create(_GUID const&) dom/media/platforms/wmf/MFTDecoder.cpp 6 xul.dll mozilla::CanCreateMFTDecoder dom/media/platforms/wmf/WMFDecoderModule.cpp 7 xul.dll mozilla::CanCreateWMFDecoder<CLSID_CMSH264DecoderMFT> dom/media/platforms/wmf/WMFDecoderModule.cpp 8 xul.dll mozilla::gmp::GMPParent::ReadGMPInfoFile(nsIFile*) dom/media/gmp/GMPParent.cpp 9 xul.dll mozilla::gmp::GMPParent::ReadGMPMetaData() dom/media/gmp/GMPParent.cpp 10 xul.dll mozilla::gmp::GMPParent::Init(mozilla::gmp::GeckoMediaPluginServiceParent*, nsIFile*) dom/media/gmp/GMPParent.cpp 11 xul.dll mozilla::gmp::GeckoMediaPluginServiceParent::AddOnGMPThread(nsString) dom/media/gmp/GMPServiceParent.cpp 12 xul.dll mozilla::detail::ProxyRunnable<mozilla::MozPromise<bool, nsresult, 0>, mozilla::gmp::GeckoMediaPluginServiceParent, nsString>::Run() xpcom/threads/MozPromise.h 13 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp startup crashes with this signature in the media code are apparently regressing in firefox 47 - another signature that seems related is @0x0 | ICoCreateInstanceEx. together they make up 2.6% of crashes in early crash data for 47.0b1 (which would make it the #2 top crash).
This is a new top crash on 47.0b1 that was mentioned at the channel meeting. Hi Anthony, CPearce: I looked at the crashing thread on one of the crash reports and noticed GMP on the stack trace. I know we took at least one related uplifts in 47 i.e. bug 1265815. Would you be able to help investigate or find another dev owner?
During the startup-time creation of the clearkey GMP on Windows, there's a check to see if WMF can handle h264, by creating a decoder for it, and that creation fails. The main change on this code path is from https://hg.mozilla.org/releases/mozilla-beta/rev/c95419cb1a3d in bug 1245789; before that, the WMF check was done later, when actually requested. I'll see if I can reproduce that and somehow fix it. Easiest might be to revert that particular change.
Assignee: nobody → gsquelart
Component: Audio/Video → Audio/Video: Playback
Crash Signature: [@ @0x0 | CClientContextActivator::CreateInstance] [@ @0x0 | ICoCreateInstanceEx ] → [@ @0x0 | CClientContextActivator::CreateInstance] [@ @0x0 | ICoCreateInstanceEx ] [@ CClientContextActivator::CreateInstance] [@ ICoCreateInstanceEx]
The WMF HasAAC/HasH264 checks were done off the main thread, as soon as the plugin was loaded, which was way too soon in the overall startup process, when the WMF subsystem may not have been properly initialized yet, or may be in the middle of it. The solution here is to delay these checks until they are actually needed to respond to a format-support request, as they come later in the process. magic sequencing of events. Other avenues have been explored unsuccessfully yet, but we may want to revisit this issue after this urgent patch has landed. Review commit: https://reviewboard.mozilla.org/r/50135/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/50135/
Attachment #8748061 - Flags: review?(rjesup)
Comment on attachment 8748061 [details] MozReview Request: Bug 1268379 - Delay WMF checks in GMPParent - r?jesup https://reviewboard.mozilla.org/r/50135/#review46909
Attachment #8748061 - Flags: review?(rjesup) → review+
Reminder to request uplift to beta-47, and open follow-up bug to review architecture.
Comment on attachment 8748061 [details] MozReview Request: Bug 1268379 - Delay WMF checks in GMPParent - r?jesup Approval Request Comment [Feature/regressing bug #]: Regressing bug 1245789, which is in beta-47 [User impact if declined]: ~300 start-up crashes per day on 47+, mostly on win7 [Describe test coverage new/current, TreeHerder]: Media tests in aurora try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=103418711e401bf265057ae2fbca792715f293a5 and beta try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=8574705dc4f715235c58ee1bfa9943ae94f3e63f [Risks and why]: Low risk, as it was just moving some tests from an early method to a later one. [String/UUID change made/needed]: None
Chris, I think you should have a quick look at this bug: - First to check that the patch is not hiding something bad, as you know this code best. As per my commit description, this may not be the perfect solution, so we may want to revisit the area later on. - And second so that you are aware of this issue (WMF getting confused by a very-early decoder creation attempt), as it could be a possible cause of other recently-opened issues.
Flags: needinfo?(gsquelart) → needinfo?(cpearce)
Gerald: Were you able to reproduce this? It may be caused by us not initializing MSCOM on the thread yet. The MediaTaskQueue and Main threads have MSCOM initialized (SharedThreadPool does it via MSCOMInitThreadPoolListener), but I suspect that the GMP thread may not be doing it. So after we've uplift this fix, I'd be interested in reverting it and trying initializing MSCOM on the GMP thread, and seeing if this crash does not re-appear.
Flags: needinfo?(cpearce) → needinfo?(gsquelart)
No I've never reproduced it. I don't know anything (yet) about MSCOM. Once uplifted I'll open a new bug with your suggestion. (Keeping NI:myself)
Comment on attachment 8748061 [details] MozReview Request: Bug 1268379 - Delay WMF checks in GMPParent - r?jesup Top crash fix, Aurora48+, Beta47+
As per comment 12, I've opened bug 1271885 to work on Chris' comment 11 suggestion.
You need to log in before you can comment on or make changes to this bug.