1203191 - new crash in nsWrapperCache::PreserveWrapper(nsISupports*) in firefox 41.0b8

Status: RESOLVED WORKSFORME

Description

[[:philipp]]

This bug was filed from the Socorro interface and is 
report bp-bd973c3a-4422-4892-a62c-c3f602150908.
=============================================================
0 	xul.dll 	nsWrapperCache::PreserveWrapper(nsISupports*) 	dom/base/nsWrapperCache.h
1 	xul.dll 	mozilla::dom::HTMLUnknownElementBinding::_addProperty 	obj-firefox/dom/bindings/GamepadBinding.cpp
2 	xul.dll 	AddOrChangeProperty 	js/src/vm/NativeObject.cpp
3 	xul.dll 	js::NativeDefineProperty(js::ExclusiveContext*, JS::Handle<js::NativeObject*>, JS::Handle<jsid>, JS::Handle<JSPropertyDescriptor>, JS::ObjectOpResult&) 	js/src/vm/NativeObject.cpp
4 	xul.dll 	js::SetPropertyByDefining(JSContext*, JS::Handle<JSObject*>, JS::Handle<jsid>, JS::Handle<JS::Value>, JS::Handle<JS::Value>, bool, JS::ObjectOpResult&) 	js/src/vm/NativeObject.cpp
5 	xul.dll 	js::NativeSetProperty(JSContext*, JS::Handle<js::NativeObject*>, JS::Handle<jsid>, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::QualifiedBool, JS::ObjectOpResult&) 	js/src/vm/NativeObject.cpp
6 	xul.dll 	js::jit::DoSetPropFallback 	js/src/jit/BaselineIC.cpp
7 		@0x2c8042f4 	
8 		@0x2c095ff3 	
9 		@0x1a8dc72f 	
10 		@0x2c095ff3 	
11 		@0x1a8dc56f 	
12 		@0x2c80092f 	
13 	xul.dll 	js::jit::EnterBaselineMethod(JSContext*, js::RunState&) 	js/src/jit/BaselineJIT.cpp
14 	xul.dll 	Interpret 	js/src/vm/Interpreter.cpp
15 	xul.dll 	js::RunScript(JSContext*, js::RunState&) 	js/src/vm/Interpreter.cpp
16 	xul.dll 	js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) 	js/src/vm/Interpreter.cpp
17 	xul.dll 	js::CallOrConstructBoundFunction(JSContext*, unsigned int, JS::Value*) 	js/src/jsfun.cpp
18 	xul.dll 	js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) 	js/src/vm/Interpreter.cpp
19 	xul.dll 	JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) 	js/src/jsapi.cpp
20 	xul.dll 	mozilla::dom::EventListener::HandleEvent(JSContext*, JS::Handle<JS::Value>, mozilla::dom::Event&, mozilla::ErrorResult&) 	obj-firefox/dom/bindings/EventListenerBinding.cpp
21 	xul.dll 	mozilla::dom::EventListener::HandleEvent<mozilla::dom::EventTarget*>(mozilla::dom::EventTarget* const&, mozilla::dom::Event&, mozilla::ErrorResult&, char const*, mozilla::dom::CallbackObject::ExceptionHandling, JSCompartment*) 	obj-firefox/dist/include/mozilla/dom/EventListenerBinding.h
22 	xul.dll 	mozilla::EventListenerManager::HandleEventInternal(nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent**, mozilla::dom::EventTarget*, nsEventStatus*) 	dom/events/EventListenerManager.cpp
23 	xul.dll 	mozilla::EventTargetChainItem::HandleEventTargetChain(nsTArray<mozilla::EventTargetChainItem>&, mozilla::EventChainPostVisitor&, mozilla::EventDispatchingCallback*, mozilla::ELMCreationDetector&) 	dom/events/EventDispatcher.cpp
24 	xul.dll 	mozilla::EventDispatcher::Dispatch(nsISupports*, nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent*, nsEventStatus*, mozilla::EventDispatchingCallback*, nsTArray<mozilla::dom::EventTarget*>*) 	dom/events/EventDispatcher.cpp

this signature first appeared in firefox 41.0b8 and seems to be a startup crash most of the time. it's #2 in very early data in the top crash score board for beta 8.

Comment 1

[David Major [:dmajor]]

This is rather worrying since all of the reports are executing the middle of an instruction (always off by two on the same instruction).

I don't want to reach for this conclusion too quickly, but it may be a cpu issue:
Cpu info facet Rank 	Cpu info 	Count 	%
1 	GenuineIntel family 15 model 6 stepping 5 | 2 	61 	88.41 %
2 	GenuineIntel family 15 model 6 stepping 2 | 2 	8 	11.59 %

Let's see how things look once we have more data on b8.

Comment 2

[Robert Kaiser]

[Tracking Requested - why for this release]:
Nominating for tracking because of comment #1.

Comment 3

[[:philipp]]

not sure what's going on, but it looks like this signature has completely ceased to exist in 41.0b9 again.

Comment 4

[David Major [:dmajor]]

(In reply to philipp from comment #3)
> not sure what's going on, but it looks like this signature has completely
> ceased to exist in 41.0b9 again.

That would be consistent with a cpu issue if it's triggered by the specific code sequence of a particular build.

Let's leave this open for one more build to make sure it doesn't come back on the RC.

Comment 5

[Ritu Kothari (:ritu)]

David, I do not see many instances of this crash. Possible the signature has changed. I don't feel the need to track it and marking it as wontfix for 41. Please let me know if you have any concerns.