[Webkit-unassigned] [Bug 26044] Crash at Node::nodeIndex()

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=26044





------- Comment #19 from eric at webkit.org  2009-06-04 09:20 PDT -------
(In reply to comment #18)
> (From update of attachment 30935 [review])
> I have no object to speculative fixes, but I don't see a theory of the bug
> here. If the theory is that someone m_start.container() becomes 0, could you
> tell me the hypothetical about how that could happen? Maybe with a little more
> checking into calls to functions on m_start we can come up with something
> stronger.

Sure thing.  I can demonstrate m_start.container() becoming zero.  The attached
test case does that by preventing the insertion of the split text node into the
document.

// This call will hit an ASSERT due to void Range::textNodeSplit(Text* oldNode)
    // being called with oldNode->nextSibling() == NULL
    // In release builds, the ASSERT won't fire and a Range attached to the
document
    // will end up with an invalid start.  Ranges with an invalid start aren't
    // properly detached in ~Range, causing the Document to end up with
pointers
    // to deleted ranges.
    text.splitText(1);

Looking at the the code, RangeBoundaryPoint::set() seems like the only way that
one can make a RBP have a .container() == NULL.  The only place it's called is
from the text node handling code, which ASSERTs that ->nextSibling() and
->previousSibling() are != NULL, but doesn't handle when they are (for the
release case).  The only case I was able to come up with was using dom mutation
events.  There may be others though, I'm not sure.

I never got my test case to crash due to *this* bug, but I did get it to hit
the various ASSERTs which try to guard against RBP's container() ever being
NULL.  The test case to just hit those ASSERTs is much simpler than the one
attached however. ;)

Making m_start.container() null was the only way I could think of to get a dead
range into the Document's m_ranges list.  It's also possible that some
unrelated memory smasher has smashed the Document, Node or Range.  But a
deleted Range left in the Document's m_ranges list seems to be the most likely
theory.


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