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)
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.
![]() |
||
Comment 2•10 years ago
|
||
[Tracking Requested - why for this release]:
Nominating for tracking because of comment #1.
status-firefox41:
--- → affected
tracking-firefox41:
--- → ?
Reporter | ||
Comment 3•10 years ago
|
||
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.
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.
Description
•