Closed Bug 1268379 Opened 4 years ago Closed 4 years ago

startup crash in @0x0 | CClientContextActivator::CreateInstance

Categories

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

47 Branch
x86
Windows NT
defect

Tracking

()

RESOLVED FIXED
mozilla49
Tracking Status
firefox47 + fixed
firefox48 --- fixed
firefox49 --- fixed

People

(Reporter: philipp, Assigned: gerald)

References

(Blocks 1 open bug)

Details

(4 keywords)

Crash Data

Attachments

(1 file)

[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).
Component: General → Audio/Video
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?
Flags: needinfo?(cpearce)
Flags: needinfo?(ajones)
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
Flags: needinfo?(cpearce)
Flags: needinfo?(ajones)
Priority: -- → P1
Crash Signature: [@ @0x0 | CClientContextActivator::CreateInstance] [@ @0x0 | ICoCreateInstanceEx ] → [@ @0x0 | CClientContextActivator::CreateInstance] [@ @0x0 | ICoCreateInstanceEx ] [@ CClientContextActivator::CreateInstance] [@ ICoCreateInstanceEx]
#4 top crash for 47 beta 1.
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.
Flags: needinfo?(gsquelart)
https://hg.mozilla.org/mozilla-central/rev/2481a3d507a0
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
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
Attachment #8748061 - Flags: approval-mozilla-beta?
Attachment #8748061 - Flags: approval-mozilla-aurora?
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+
Attachment #8748061 - Flags: approval-mozilla-beta?
Attachment #8748061 - Flags: approval-mozilla-beta+
Attachment #8748061 - Flags: approval-mozilla-aurora?
Attachment #8748061 - Flags: approval-mozilla-aurora+
Blocks: 1271885
As per comment 12, I've opened bug 1271885 to work on Chris' comment 11 suggestion.
Flags: needinfo?(gsquelart)
You need to log in before you can comment on or make changes to this bug.