Bug 10339 – compareBoundaryPoints crash

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: New Bugs

[Graham Dennis]

A large number of users of Sandvox have reported a crash in Range::compareBoundaryPoints(Node *, int, Node *, int) that is caused by commonAncestorContainer returning NULL. These crashes all seem to be related to removing a node from the DOM tree, but the causes of this DOM node removal are various. I have not been able to reproduce this bug myself. The following addresses are from the PPC version of the WebKit build in Sandvox 1.0.4

The common part of the crash is:
0  com.apple.WebCore                  0x0102ea2c WebCore::Range::compareBoundaryPoints(WebCore::Node*, int, WebCore::Node*, int) + 452
1  com.apple.WebCore                  0x0102eaa4 WebCore::Range::compareBoundaryPoints(WebCore::Position const&, WebCore::Position const&) + 44
2  com.apple.WebCore                  0x01195ce4 WebCore::SelectionController::nodeWillBeRemoved(WebCore::Node*) + 1024
3  com.apple.WebCore                  0x010be32c WebCore::Document::notifyBeforeNodeRemoval(WebCore::Node*) + 84
4  com.apple.WebCore                  0x010c9d04 WebCore::willRemoveChild(WebCore::Node*) + 104
5  com.apple.WebCore                  0x010ca34c WebCore::ContainerNode::removeChild(WebCore::Node*, int&) + 384

Some of the various traces before this stack trace include:
6  com.apple.WebCore                  0x0118cf88 WebCore::RemoveNodeCommand::doApply() + 52
7  com.apple.WebCore                  0x0117fd78 WebCore::EditCommand::apply() + 188
8  com.apple.WebCore                  0x01178034 WebCore::CompositeEditCommand::applyCommandToComposite(WebCore::EditCommandPtr&) + 196
9  com.apple.WebCore                  0x011791ac WebCore::CompositeEditCommand::removeNode(WebCore::Node*) + 100
10  com.apple.WebCore                  0x011717f0 WebCore::ApplyStyleCommand::surroundNodeRangeWithElement(WebCore::Node*, WebCore::Node*, WebCore::Element*) + 132
11  com.apple.WebCore                  0x011744dc WebCore::ApplyStyleCommand::addInlineStyleIfNeeded(WebCore::CSSMutableStyleDeclaration*, WebCore::Node*, WebCore::Node*) + 1020
12  com.apple.WebCore                  0x0117623c WebCore::ApplyStyleCommand::applyInlineStyle(WebCore::CSSMutableStyleDeclaration*) + 1780
13  com.apple.WebCore                  0x011772fc WebCore::ApplyStyleCommand::doApply() + 244
14  com.apple.WebCore                  0x0117fd78 WebCore::EditCommand::apply() + 188
15  com.apple.WebCore                  0x01178034 WebCore::CompositeEditCommand::applyCommandToComposite(WebCore::EditCommandPtr&) + 196
16  com.apple.WebCore                  0x01179a9c WebCore::CompositeEditCommand::applyStyle(WebCore::CSSStyleDeclaration*, WebCore::EditAction) + 108
17  com.apple.WebCore                  0x01184fd8 WebCore::InsertParagraphSeparatorCommand::applyStyleAfterInsertion() + 308
18  com.apple.WebCore                  0x01185804 WebCore::InsertParagraphSeparatorCommand::doApply() + 2064
19  com.apple.WebCore                  0x0117fd78 WebCore::EditCommand::apply() + 188
20  com.apple.WebCore                  0x01178034 WebCore::CompositeEditCommand::applyCommandToComposite(WebCore::EditCommandPtr&) + 196
21  com.apple.WebCore                  0x0119b78c WebCore::TypingCommand::insertParagraphSeparator() + 96
22  com.apple.WebCore                  0x0119d0d8 WebCore::TypingCommand::doApply() + 176
23  com.apple.WebCore                  0x0117fd78 WebCore::EditCommand::apply() + 188
24  com.apple.WebCore                  0x0119b890 WebCore::TypingCommand::insertParagraphSeparator(WebCore::Document*) + 168
25  com.apple.WebCore                  0x010cd0cc -[WebCoreFrameBridge insertParagraphSeparator] + 56

and:
WebCore::ContainerNode::removeChild(WebCore::Node*, int&) + 384
WebCore::ContainerNode::replaceChild(WTF::PassRefPtr<WebCore::Node>, WebCore::Node*, int&) + 192
-[DOMNode replaceChild::] + 132
-[KTDocWindowController(WebEditing) processEditableElementsFromDoc:] (in Sandvox)
-[KTDocWindowController(WebView) webView:didFinishLoadForFrame:] (in Sandvox)

The actual crash is on line 461 of Range.cpp (of about a week's old ToT):
    Node *n = cmnRoot->firstChild();

All that follows is pure speculation as I have not been able to reproduce the bug myself.
In the assembly, it is the first Range::compareBoundaryPoints call that crashes, and from the C code, this call is:
Range::compareBoundaryPoints(m_sel.start(), Position(node, 0))
It seems to me that the only way that commonAncestorNode could return NULL (without crashing) is if the start node still exists, however its documentElement has been deleted, but the document hasn't. This can happen if the last external reference to the document is destroyed, as at that point, the document deletes all nodes that aren't otherwise retained, clears its documentElement, but keeps itself around while it still has nodes that are referenced.

So it would appear that the selection points to nodes in an old document, but the selection is cleared when the frame is cleared by the frame view. 

I'm marking this P3 as I cannot reproduce it.

[Anne van Kesteren]

This code has been refactored quite a few times over the years.