[Webkit-unassigned] [Bug 43152] New: Assertion failure in FrameView::layout when modifying the DOM during pagehide with PageCache enabled

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jul 28 15:19:11 PDT 2010


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

           Summary: Assertion failure in FrameView::layout when modifying
                    the DOM during pagehide with PageCache enabled
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Page Loading
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: mihaip at chromium.org
                CC: darin at apple.com, bdakin at apple.com


Created an attachment (id=62885)
 --> (https://bugs.webkit.org/attachment.cgi?id=62885)
Test case

The attached test case triggers this assertion failure in debug builds:

ASSERTION FAILED: m_frame->view() == this
(/Users/mihaip/Developer/source/webkit1/WebCore/page/FrameView.cpp:634 void WebCore::FrameView::layout(bool))

0   com.apple.WebCore                 0x00000001017fd345 WebCore::FrameView::layout(bool) + 449 (FrameView.cpp:634)
1   com.apple.WebCore                 0x00000001017fe5ea WebCore::FrameView::layoutTimerFired(WebCore::Timer<WebCore::FrameView>*) + 30 (FrameView.cpp:1332)
2   com.apple.WebCore                 0x0000000101801753 WebCore::Timer<WebCore::FrameView>::fired() + 113 (Timer.h:98)
3   com.apple.WebCore                 0x000000010202ce68 WebCore::ThreadTimers::sharedTimerFiredInternal() + 208 (ThreadTimers.cpp:115)
4   com.apple.WebCore                 0x000000010202cff7 WebCore::ThreadTimers::sharedTimerFired() + 25 (ThreadTimers.cpp:91)
5   com.apple.WebCore                 0x0000000101efefd4 WebCore::timerFired(__CFRunLoopTimer*, void*) + 73 (SharedTimerMac.mm:87)
6   com.apple.CoreFoundation          0x00007fff83b67678 __CFRunLoopRun + 6488
7   com.apple.CoreFoundation          0x00007fff83b6584f CFRunLoopRunSpecific + 575
8   com.apple.HIToolbox               0x00007fff830e991a RunCurrentEventLoopInMode + 333
9   com.apple.HIToolbox               0x00007fff830e971f ReceiveNextEventCommon + 310
10  com.apple.HIToolbox               0x00007fff830e95d8 BlockUntilNextEventMatchingListInMode + 59
11  com.apple.AppKit                  0x00007fff8451e29e _DPSNextEvent + 708
12  com.apple.AppKit                  0x00007fff8451dbed -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 155
13  com.apple.Safari                  0x0000000100015c96 0x100000000 + 89238
14  com.apple.AppKit                  0x00007fff844e38d3 -[NSApplication run] + 395
15  com.apple.AppKit                  0x00007fff844dc5f8 NSApplicationMain + 364
16  com.apple.Safari                  0x0000000100009b18 0x100000000 + 39704

The triggering conditions appear to be 1) the DOM being modified in the pagehide handler 2) the page cache being enabled (adding an unload event handler to disable results in this not crashing). The fact that it's a data: URL does not seem to matter, the crash also happens when changing the location to a regular URL.

There is this comment and check in FrameView.cpp immediately after the assert:

    // This early return should be removed when rdar://5598072 is resolved. In the meantime, there is a
    // gigantic CrashTracer because of this issue, and the early return will hopefully cause graceful 
    // failure instead.  
    if (m_frame->view() != this)
        return;

That was added in http://trac.webkit.org/changeset/29878. Cc-ing Darin and Beth in case there's anything relevant to this bug at the rdar:// URL.

Bug 32752 may be related, since it's the same assert and it happens on a page transition, but I can't reproduce it. Bug 19564 also mentions this assert, and says that HTMLFrameElement09.xhtml fails because of it (and it's still disabled as of http://trac.webkit.org/changeset/34803), but I can't reproduce the assert  when running it locally (though the test doesn't pass).

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



More information about the webkit-unassigned mailing list