[Webkit-unassigned] [Bug 146842] New: Crash in HistoryController::updateForCommit dereferencing a null HistoryItem

[bugzilla-daemon at webkit.org]

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

            Bug ID: 146842
           Summary: Crash in HistoryController::updateForCommit
                    dereferencing a null HistoryItem
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Page Loading
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: beidson at apple.com

We're seeing crashes in HistoryController::updateForCommit dereferencing a null HistoryItem

      38 WebCore: WebCore::HistoryController::updateForCommit() <==
        30 WebCore: WebCore::HistoryController::updateForCommit()
        | 30 WebCore: WebCore::FrameLoader::transitionToCommitted(WebCore::CachedPage*)
        |   30 WebCore: WebCore::FrameLoader::commitProvisionalLoad()
        |     30 WebCore: WebCore::DocumentLoader::commitLoad(char const*, int)
        |       28 WebCore: WebCore::CachedRawResource::notifyClientsDataWasReceived(char const*, unsigned int)
        |       | 28 WebCore: WebCore::CachedRawResource::addDataBuffer(WebCore::SharedBuffer&)
        |       |   28 WebCore: WebCore::SubresourceLoader::didReceiveDataOrBuffer(char const*, int, WTF::PassRefPtr<WebCore::SharedBuffer>, long long, WebCore::DataPayloadType)
        |       |     28 WebCore: WebCore::SubresourceLoader::didReceiveData(char const*, unsigned int, long long, WebCore::DataPayloadType)
        |       |       28 WebKit: WebKit::WebResourceLoader::didReceiveWebResourceLoaderMessage(IPC::Connection&, IPC::MessageDecoder&)


The problem is when setCurrentItem(*m_provisionalItem) executes, but m_provisionalItem is null.

In updateForCommit there's been a long standing "ASSERT(m_provisionalItem)", but it is still definitely null sometimes. For many years, setting the current item to null in release builds has been a thing.

As of http://trac.webkit.org/changeset/179472 we stopped successfully handing the nullptr and started crashing instead.

While we want to get to the bottom of why the provisional item might be null (which is why we have the ASSERT there), we should restore the previous "handles null" behavior to get rid of the crashes.

<rdar://problem/21371589>

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150710/5cf4a057/attachment.html>