[Webkit-unassigned] [Bug 10339] New: compareBoundaryPoints crash

[bugzilla-daemon at opendarwin.org]

http://bugzilla.opendarwin.org/show_bug.cgi?id=10339

           Summary: compareBoundaryPoints crash
           Product: WebKit
           Version: 420+ (nightly)
          Platform: Macintosh
        OS/Version: Mac OS X 10.4
            Status: NEW
          Severity: normal
          Priority: P3
         Component: New Bugs
        AssignedTo: webkit-unassigned at opendarwin.org
        ReportedBy: Graham.Dennis at gmail.com


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.


-- 
Configure bugmail: http://bugzilla.opendarwin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.