Crash in nsAString_internal::Assign | nsAString_internal::Assign | mozilla::dom::MediaKeySystemMediaCapability::MediaKeySystemMediaCapability

NEW
Unassigned

Status

()

Core
Plug-ins
P3
critical
a year ago
3 months ago

People

(Reporter: philipp, Unassigned)

Tracking

({crash, regression})

50 Branch
x86
Windows
crash, regression
Points:
---

Firefox Tracking Flags

(firefox50 wontfix, firefox51 wontfix, firefox52 fix-optional, firefox53 fix-optional, firefox54 wontfix, firefox55 wontfix, firefox56 wontfix, firefox57 fix-optional)

Details

(crash signature)

(Reporter)

Description

a year ago
This bug was filed from the Socorro interface and is 
report bp-bd1906df-6b2e-4700-9e9d-a05022161116.
=============================================================
Crashing Thread (0)
Frame 	Module 	Signature 	Source
0 	xul.dll 	nsAString_internal::Assign(nsAString_internal const&, mozilla::fallible_t const&) 	xpcom/string/nsTSubstring.cpp:430
1 	xul.dll 	nsAString_internal::Assign(nsAString_internal const&) 	xpcom/string/nsTSubstring.cpp:396
2 	xul.dll 	mozilla::dom::MediaKeySystemMediaCapability::MediaKeySystemMediaCapability(mozilla::dom::MediaKeySystemMediaCapability const&) 	obj-firefox/dist/include/mozilla/dom/MediaKeySystemAccessBinding.h:58
3 	xul.dll 	nsTArray_Impl<mozilla::dom::MediaKeySystemMediaCapability, nsTArrayFallibleAllocator>::AssignRange<mozilla::dom::MediaKeySystemMediaCapability>(unsigned int, unsigned int, mozilla::dom::MediaKeySystemMediaCapability const*) 	obj-firefox/dist/include/nsTArray.h:1874
4 	xul.dll 	nsTArray_Impl<mozilla::dom::MozPluginParameter, nsTArrayInfallibleAllocator>::ReplaceElementsAt<mozilla::dom::MozPluginParameter, nsTArrayInfallibleAllocator>(unsigned int, unsigned int, mozilla::dom::MozPluginParameter const*, unsigned int) 	obj-firefox/dist/include/nsTArray.h:1893
5 	xul.dll 	nsPluginInstanceOwner::GetParameters(nsTArray<mozilla::dom::MozPluginParameter>&) 	dom/plugins/base/nsPluginInstanceOwner.cpp:1325
6 	xul.dll 	nsNPAPIPluginInstance::Start() 	dom/plugins/base/nsNPAPIPluginInstance.cpp:386
7 	xul.dll 	nsNPAPIPluginInstance::Initialize(nsNPAPIPlugin*, nsPluginInstanceOwner*, nsACString_internal const&) 	dom/plugins/base/nsNPAPIPluginInstance.cpp:236
8 	xul.dll 	nsPluginHost::TrySetUpPluginInstance(nsACString_internal const&, nsIURI*, nsPluginInstanceOwner*) 	dom/plugins/base/nsPluginHost.cpp:1004
9 	xul.dll 	nsPluginHost::SetUpPluginInstance(nsACString_internal const&, nsIURI*, nsPluginInstanceOwner*) 	dom/plugins/base/nsPluginHost.cpp:921
10 	xul.dll 	nsPluginHost::InstantiatePluginInstance(nsACString_internal const&, nsIURI*, nsObjectLoadingContent*, nsPluginInstanceOwner**) 	dom/plugins/base/nsPluginHost.cpp:853
11 	xul.dll 	nsObjectLoadingContent::InstantiatePluginInstance(bool) 	dom/base/nsObjectLoadingContent.cpp:810
12 	xul.dll 	nsObjectLoadingContent::SyncStartPluginInstance() 	dom/base/nsObjectLoadingContent.cpp:3037
13 	xul.dll 	nsAsyncInstantiateEvent::Run() 	dom/base/nsObjectLoadingContent.cpp:181
14 	xul.dll 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp:1076
15 	xul.dll 	mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp:100
16 	xul.dll 	mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp:317
17 	xul.dll 	_SEH_epilog4

this crash signature is regressing in firefox 50 and subsequent builds - is this related to https://reviewboard.mozilla.org/r/64788/diff/3#index_header from bug 1278198 perhaps?
Flags: needinfo?(cpearce)
I don't think this is a regression from bug 1278198. Looking at the call stack, we're calling in from nsNPAPIPluginInstance::Start(), calling into array operations. I think that the array operations that I added in bug 1278198 are being optimized into the same code that is being used by nsNPAPIPluginInstance::Start(). The bug must be in a change to nsNPAPIPluginInstance or related code, not in the MediaKeytSystem* code.
Component: Audio/Video: Playback → Plug-ins
Flags: needinfo?(cpearce)
Benjamin, would you mind taking a look here? Or any advice on what steps can help move this forward?
Flags: needinfo?(benjamin)

Comment 3

a year ago
This is not a new crash: the prior signature was nsAString_internal::Assign | nsAString_internal::Assign | mozilla::dom::MozPluginParameter::MozPluginParameter although I don't think there was a bug filed for that.

crash address: 0xfffffff8 - this is the pointer to the stringbuffer for a DOM MozPluginParameter.name, and we're crashing trying to refcount it.

assuming that all of the relevant nsObjectLoadingContent, nsPluginHost, nsNPAPIPluginInstance, and nsPluginInstanceOwner are alive/valid pointers, this seems like it would be a DOM or string bug. Admittedly we've had ownership issues with nsNPAPIPluginInstance and nsPluginInstanceOwner before, but it's hard to believe that's a problem in this case because memory poisoning should have caused more distinctive crashes well before we hit this codepath.

I looked and there aren't any suspicious addon correlations.

Happy to leave this in Plugins, but I doubt we have engineering staff to follow up on it.
Flags: needinfo?(benjamin)
Priority: -- → P3
Not super-urgent but if you have time to dig around a bit, qDot, it'd be appreciated.
Flags: needinfo?(kyle)
Crash stats for signature mentioned in Comment 3: https://crash-stats.mozilla.com/signature/?_sort=-date&signature=nsAString_internal%3A%3AAssign%20%7C%20nsAString_internal%3A%3AAssign%20%7C%20mozilla%3A%3Adom%3A%3AMozPluginParameter%3A%3AMozPluginParameter&date=%3E%3D2016-12-09T00%3A35%3A00.000Z&date=%3C2016-12-16T00%3A35%3A00.000Z

Looks like the signature in this bug is getting WAY more crashes, but yeah, mostly the same stack otherwise.
Flags: needinfo?(kyle)
Whoops. ni?'ing myself to take a more than cursory look at some point soon.
Flags: needinfo?(kyle)

Comment 7

a year ago
Your date range only covers the 50 release, so if you pick an earlier range you'll see a higher volume of FF49 crashes with the other signature.
status-firefox50: affected → wontfix
Unfortunately we're still getting this crash a lot. I poked around more but not really getting anywhere with this. I can't figure out why we'd have problems with ref counting the plugin parameters on copy, as this doesn't seem to be a particularly special operation. 

The stack misidentification could be from the fact that the MediaKeySystemMediaCapabilities and MozPluginParameters dictionaries are the same (2 DOMStrings, both defaulting to ""), so comment 2 seems valid.
Flags: needinfo?(kyle)
status-firefox51: affected → wontfix
status-firefox52: affected → fix-optional
status-firefox53: affected → fix-optional
status-firefox54: --- → affected

Updated

6 months ago
status-firefox54: affected → wontfix
status-firefox55: --- → affected
Crash volume is extremely low these days.
status-firefox55: affected → wontfix
status-firefox56: --- → wontfix
status-firefox57: --- → fix-optional
You need to log in before you can comment on or make changes to this bug.