Bug 52923 - [Chromium] Crash in WebFrameImpl::currentHistoryItem() due to null activeDocumentLoader()
Summary: [Chromium] Crash in WebFrameImpl::currentHistoryItem() due to null activeDocu...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nate Chapin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-21 14:28 PST by Nate Chapin
Modified: 2011-07-11 16:37 PDT (History)
3 users (show)

See Also:


Attachments
patch (1.62 KB, patch)
2011-01-21 14:35 PST, Nate Chapin
fishd: review+
fishd: commit-queue-
Details | Formatted Diff | Diff
Early exit for null activeDocumentLoader() (1.45 KB, patch)
2011-07-07 16:07 PDT, Nate Chapin
no flags Details | Formatted Diff | Diff
Patch (1.85 KB, patch)
2011-07-11 16:33 PDT, John Bates
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Chapin 2011-01-21 14:28:02 PST
Original report at http://code.google.com/p/chromium/issues/detail?id=65674

FrameLoader::activeDocumentLoader() is not guaranteed to be non-null, and we appear to be hitting null cases when calling it from RenderView::syncNavigationState() via WebFrameImpl::currentHistoryItem().

It appears we're just using activeDocumentLoader() to determine whether we're still loading.  A null activeDocumentLoader() should answer that question pretty clearly as a 'no'.
Comment 1 Nate Chapin 2011-01-21 14:35:23 PST
Created attachment 79795 [details]
patch
Comment 2 Darin Fisher (:fishd, Google) 2011-01-21 16:28:22 PST
Comment on attachment 79795 [details]
patch

This is OK, but I'd really like to understand how this is possible.  For example, we might want to return WebHistoryItem() in cases like this.  Maybe this is happening at shutdown time?
Comment 3 Nate Chapin 2011-07-06 11:40:40 PDT
(In reply to comment #2)
> (From update of attachment 79795 [details])
> This is OK, but I'd really like to understand how this is possible.  For example, we might want to return WebHistoryItem() in cases like this.  Maybe this is happening at shutdown time?

Picking this bug back up after 6 months :)

Looking through when we set the DocumentLoader members of FrameLoader, it *might* happen during a cancel, but shutdown looks far more likely.
Comment 4 Nate Chapin 2011-07-07 16:07:30 PDT
Created attachment 100044 [details]
Early exit for null activeDocumentLoader()
Comment 5 WebKit Review Bot 2011-07-08 10:25:05 PDT
Comment on attachment 100044 [details]
Early exit for null activeDocumentLoader()

Clearing flags on attachment: 100044

Committed r90641: <http://trac.webkit.org/changeset/90641>
Comment 6 WebKit Review Bot 2011-07-08 10:25:09 PDT
All reviewed patches have been landed.  Closing bug.
Comment 7 John Bates 2011-07-11 16:33:54 PDT
Created attachment 100381 [details]
Patch
Comment 8 John Bates 2011-07-11 16:35:34 PDT
(In reply to comment #7)
> Created an attachment (id=100381) [details]
> Patch

wrong bug, ignore patch