[Chromium] Crash in WebFrameImpl::currentHistoryItem() due to null activeDocumentLoader()

• Component: WebKit Misc.
• Status: RESOLVED FIXED

[Nate Chapin]

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'.

[Nate Chapin]

Created attachment 79795 [details]
patch

[Darin Fisher (:fishd, Google)]

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?

[Nate Chapin]

(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.

[Nate Chapin]

Created attachment 100044 [details]
Early exit for null activeDocumentLoader()

[WebKit Review Bot]

Comment on attachment 100044 [details]
Early exit for null activeDocumentLoader()

Clearing flags on attachment: 100044

Committed r90641: <http://trac.webkit.org/changeset/90641>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[John Bates]

Created attachment 100381 [details]
Patch

[John Bates]

(In reply to comment #7)
> Created an attachment (id=100381) [details]
> Patch

wrong bug, ignore patch