1423330 - Crash in mozilla::dom::AllChildrenIterator::AllChildrenIterator

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Marcia Knous [:marcia]]

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

=============================================================

Comment 1

[David Bolter [:davidb] (NeedInfo me for attention)]

Alex does anything in that regression range jump out?

Comment 2

[Nicholas Nethercote [inactive]]

This is the #7 windows topcrash in Nightly 20171208220141.

Comment 3

[alexander :surkov (:asurkov)]

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.

Comment 4

[Marcia Knous [:marcia]]

Since this was filed, I don't see any recent crashes on 59 and only 2 crashes on 57.

Comment 5

[Eitan Isaacson [:eeejay]]

Hopefully unflagging myself won't nudge this issue back into existence..

Comment 6

[Marcia Knous [:marcia]]

No recent crashes on release - resolving as WFM.