[Webkit-unassigned] [Bug 52819] Crash in WebCore::HistoryController::itemsAreClones

[bugzilla-daemon at webkit.org]

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





--- Comment #2 from Charles Reis <creis at chromium.org>  2011-01-20 10:15:23 PST ---
Interesting.  There's an ASSERT on both arguments in recursiveSetProvisionalItem, but it turns out ASSERTs are compiled out of release builds:
http://webkit.org/coding/assertion-guidelines.html

It's possible the crash happens if both item1 and item2 are null.  We should still see the ASSERT failing even in debug builds if that's the case-- we just have to find out the repro steps.

Here's the crashing code, for reference:

bool HistoryController::itemsAreClones(HistoryItem* item1, HistoryItem* item2) const
{
    // If the item we're going to is a clone of the item we're at, then we do
    // not need to load it again.  The current frame tree and the frame tree
    // snapshot in the item have to match.
    // Note: Some clients treat a navigation to the current history item as
    // a reload.  Thus, if item1 and item2 are the same, we need to create a
    // new document and should not consider them clones.
    // (See http://webkit.org/b/35532 for details.)
    return item1 != item2
        && item1->itemSequenceNumber() == item2->itemSequenceNumber()
        && currentFramesMatchItem(item1)
        && item2->hasSameFrames(item1);
}

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