Closed
Bug 899450
Opened 11 years ago
Closed 8 years ago
crash in nsCSSFrameConstructor::ContentRemoved @ mozilla::a11y::Accessible::EnsureChildren
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
RESOLVED
INCOMPLETE
| Tracking | Status | |
|---|---|---|
| firefox24 | --- | unaffected |
| firefox25 | --- | affected |
People
(Reporter: scoobidiver, Unassigned)
Details
(Keywords: crash, regression)
Crash Data
With the stack trace below, it first showed up in 25.0a1/20130724 and currently happens only on Windows 8. The regression range for the spike is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5ceea82a79c7&tochange=2983ca6d4d1a It might be a regression from bug 884061. Signature mozilla::a11y::Accessible::EnsureChildren() More Reports Search UUID 9072dec0-7e3d-45e5-b0f0-591fc2130729 Date Processed 2013-07-29 18:35:24.569167 Uptime 11 Install Age 966 since version was first installed. Install Time 2013-07-29 18:15:53 Product Firefox Version 25.0a1 Build ID 20130729030214 Release Channel nightly OS Windows NT OS Version 6.2.9200 Build Architecture x86 Build Architecture Info GenuineIntel family 6 model 28 stepping 10 | 4 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x2c App Notes AdapterVendorID: 0x8086, AdapterDeviceID: 0xa001, AdapterSubsysID: 070ba0a0, AdapterDriverVersion: 8.15.10.2697 D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers- Accessibility Active Frame Module Signature Source 0 xul.dll mozilla::a11y::Accessible::EnsureChildren() accessible/src/generic/Accessible.cpp 1 xul.dll mozilla::a11y::DocManager::GetDocAccessible(nsIDocument *) accessible/src/base/DocManager.cpp 2 xul.dll mozilla::a11y::DocManager::GetDocAccessible(nsIPresShell const *) obj-firefox/dist/include/mozilla/a11y/DocManager.h 3 xul.dll nsAccessibilityService::ContentRemoved(nsIPresShell *,nsIContent *,nsIContent *) accessible/src/base/nsAccessibilityService.cpp 4 xul.dll nsCSSFrameConstructor::ContentRemoved(nsIContent *,nsIContent *,nsIContent *,nsCSSFrameConstructor::RemoveFlags,bool *) layout/base/nsCSSFrameConstructor.cpp 5 xul.dll PresShell::ContentRemoved(nsIDocument *,nsIContent *,nsIContent *,int,nsIContent *) layout/base/nsPresShell.cpp 6 xul.dll nsNodeUtils::ContentRemoved(nsINode *,nsIContent *,int,nsIContent *) content/base/src/nsNodeUtils.cpp 7 xul.dll mozilla::dom::FragmentOrElement::RemoveChildAt(unsigned int,bool) content/base/src/FragmentOrElement.cpp 8 xul.dll nsINode::Remove() content/base/src/nsINode.cpp 9 xul.dll mozilla::dom::ElementBinding::remove obj-firefox/dom/bindings/ElementBinding.cpp 10 xul.dll mozilla::dom::ElementBinding::genericMethod obj-firefox/dom/bindings/ElementBinding.cpp 11 mozjs.dll js::Invoke(JSContext *,JS::Value const &,JS::Value const &,unsigned int,JS::Value *,JS::MutableHandle<JS::Value>) js/src/vm/Interpreter.cpp 12 mozjs.dll js::CrossCompartmentWrapper::call(JSContext *,JS::Handle<JSObject *>,JS::CallArgs const &) js/src/jswrapper.cpp 13 mozjs.dll js::CrossCompartmentWrapper::get(JSContext *,JS::Handle<JSObject *>,JS::Handle<JSObject *>,JS::Handle<int>,JS::MutableHandle<JS::Value>) js/src/jswrapper.cpp 14 mozjs.dll js::Proxy::get(JSContext *,JS::Handle<JSObject *>,JS::Handle<JSObject *>,JS::Handle<int>,JS::MutableHandle<JS::Value>) js/src/jsproxy.cpp 15 mozjs.dll proxy_GetGeneric js/src/jsproxy.cpp 16 mozjs.dll GetPropertyOperation(JSContext *,js::StackFrame *,JS::Handle<JSScript *>,unsigned char *,JS::MutableHandle<JS::Value>,JS::MutableHandle<JS::Value>) js/src/vm/Interpreter.cpp 17 mozjs.dll JSFunction::getOrCreateScript(JSContext *) js/src/jsfun.h More reports at: https://crash-stats.mozilla.com/report/list?product=Firefox&signature=mozilla%3A%3Aa11y%3A%3AAccessible%3A%3AEnsureChildren%28%29
|
||
Comment 1•11 years ago
|
||
Trev, ideas? How ApplicationAcc() could fail?
|
||
Comment 2•11 years ago
|
||
(In reply to alexander :surkov from comment #1) > Trev, ideas? How ApplicationAcc() could fail? only thing I can think of is maybe its during shutdown? However something is cutting stack off so I can't see if that's the case. Can we look at a minidump in a debugger?
|
|
||
Comment 3•11 years ago
|
||
It looks like this has gone away?
|
||
Comment 4•10 years ago
|
||
(In reply to Trevor Saunders (:tbsaunde) from comment #3) > It looks like this has gone away? rare, but not zero https://crash-stats.mozilla.com/report/index/01a59e6c-6d47-4195-bc21-12e0b2140503 https://crash-stats.mozilla.com/report/index/ce0d99b7-2562-48c2-8aee-6e2cc2140504 https://crash-stats.mozilla.com/report/index/478440cc-49b4-413a-8923-553572140519 https://crash-stats.mozilla.com/report/index/f441ff44-04a5-4763-bbfb-8d1ab2140522 https://crash-stats.mozilla.com/report/index/6e07588b-3b00-4e07-a475-049ce2140527 https://crash-stats.mozilla.com/report/index/6b4f847f-674a-48f6-bda3-0d9442140504
Flags: needinfo?(trev.saunders)
|
||
Updated•9 years ago
|
Crash Signature: [@ mozilla::a11y::Accessible::EnsureChildren()] → [@ mozilla::a11y::Accessible::EnsureChildren()]
[@ mozilla::a11y::Accessible::EnsureChildren]
|
|
||
Comment 5•8 years ago
|
||
The spike mentioned in comment 0 must be gone. And previously stated that the stack is cutoff. Without steps and with such low crash rate I suspect this isn't actionable. (And quite probably not even in a11y)
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(tbsaunde+mozbugs)
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•