Closed Bug 1423330 Opened 2 years ago Closed 5 months ago
Crash in mozilla::dom::All
Children Iterator::All Children Iterator
This bug was filed from the Socorro interface and is report bp-154b7820-c6ae-40e0-9419-c04f60171205. ============================================================= Seen while looking at crash stats - new crash which started using 20171204234137: http://bit.ly/2BC25cP Some of the crashes appear to be the same user crashing, but there are a few unique users hitting it. Possible regression range based on Build ID: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=de1f7a92e8726bdd365d4bbc5e65eaa369fbc20a&tochange=88b2d7276416f8b69191ca5fb1b5c670ec8178b8 Top 10 frames of crashing thread: 0 xul.dll mozilla::dom::AllChildrenIterator::AllChildrenIterator dom/base/ChildIterator.h:197 1 xul.dll mozilla::a11y::DocAccessible::ContentRemoved accessible/generic/DocAccessible.cpp:2045 2 xul.dll mozilla::a11y::DocAccessible::ContentRemoved accessible/generic/DocAccessible.cpp:2047 3 xul.dll nsNodeUtils::ContentRemoved dom/base/nsNodeUtils.cpp:221 4 xul.dll mozilla::dom::FragmentOrElement::RemoveChildAt dom/base/FragmentOrElement.cpp:1359 5 xul.dll nsINode::RemoveChild dom/base/nsINode.cpp:619 6 xul.dll mozilla::dom::NodeBinding::removeChild dom/bindings/NodeBinding.cpp:1024 7 xul.dll mozilla::dom::GenericBindingMethod dom/bindings/BindingUtils.cpp:3042 8 xul.dll js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:473 9 xul.dll js::fun_call js/src/jsfun.cpp:1239 =============================================================
Alex does anything in that regression range jump out?
Crash Signature: [@ mozilla::dom::AllChildrenIterator::AllChildrenIterator] → [@ mozilla::dom::AllChildrenIterator::AllChildrenIterator] [@ mozilla::dom::ExplicitChildIterator::ExplicitChildIterator]
This is the #7 windows topcrash in Nightly 20171208220141.
the list is fairly big for a through-out check, but skimming it doesn't reveal anything evident, there are two a11y commits by Eitan and Jamie, but they don't look related neither. The stack looks incomplete - some frames are missing. It appears ContentRemoved() gets called on a dead document accessible by nsAccessibilityService::ContentRemoved, which grabs a document accessible from a PresShell, which stores it as a raw pointer. If this assumption is correct, then we can stop bleeding by using strong pointers. Btw all crashes are Windwos NT platform. Eitan, ni you if you have any insights on the issue.
Flags: needinfo?(surkov.alexander) → needinfo?(eitan)
Since this was filed, I don't see any recent crashes on 59 and only 2 crashes on 57.
Hopefully unflagging myself won't nudge this issue back into existence..
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.