Closed Bug 1203191 Opened 10 years ago Closed 10 years ago

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

Categories

(Core :: General, defect)

41 Branch
x86
Windows NT
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox41 --- wontfix

People

(Reporter: philipp, Unassigned)

Details

(Keywords: crash, regression)

Crash Data

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.
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.
[Tracking Requested - why for this release]: Nominating for tracking because of comment #1.
not sure what's going on, but it looks like this signature has completely ceased to exist in 41.0b9 again.
(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.
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.
Flags: needinfo?(dmajor)
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(dmajor)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.