Bug 36443 - [chromium] Renderer crashes when navigating to a reference fragment in a frame that has no current HistoryItem.
Summary: [chromium] Renderer crashes when navigating to a reference fragment in a fram...
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit API (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Darin Fisher (:fishd, Google)
URL: http://www.fandango.com/hottubtimemac...
Depends on:
Reported: 2010-03-22 08:21 PDT by Dave Moore
Modified: 2010-03-22 11:17 PDT (History)
1 user (show)

See Also:

v1 patch (4.05 KB, patch)
2010-03-22 09:21 PDT, Darin Fisher (:fishd, Google)
no flags Details | Formatted Diff | Diff
v2 patch (minus svn:eol-style on layout tests) (3.67 KB, patch)
2010-03-22 09:31 PDT, Darin Fisher (:fishd, Google)
japhet: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Moore 2010-03-22 08:21:18 PDT
1) Go to this page: http://www.fandango.com/hottubtimemachine_126387/movietimes?date= in tip of tree chromium.
2) Place cursor in zip code text field.

Sad tab appears

I ran the linux build and got the stack trace below. It looks like the problem is in the second frame at FrameLoaderClientImpl.cpp:591, where the return of currentItem() is NULL. 

This appears to be recent code, introduced into webkit here:

#0  0x09257db6 in WTF::RefPtr<WebCore::SerializedScriptValue>::get (this=0x74)
    at third_party/WebKit/JavaScriptCore/wtf/RefPtr.h:58
#1  0x09257dce in WebCore::HistoryItem::stateObject (this=0x0)
    at third_party/WebKit/WebCore/history/HistoryItem.h:137
#2  0x09c1c31b in WebKit::FrameLoaderClientImpl::dispatchDidNavigateWithinPage
    at third_party/WebKit/WebKit/chromium/src/FrameLoaderClientImpl.cpp:591
#3  0x0925121b in WebCore::FrameLoader::loadInSameDocument(WebCore::KURL const&, WebCore::SerializedScriptValue*, bool) ()
#4  0x092514b3 in WebCore::FrameLoader::continueFragmentScrollAfterNavigationPolicy(WebCore::ResourceRequest const&, bool) ()
#5  0x092514e6 in WebCore::FrameLoader::callContinueFragmentScrollAfterNavigationPolicy(void*, WebCore::ResourceRequest const&, WTF::PassRefPtr<WebCore::FormState>, bool) ()
#6  0x09263d9a in WebCore::PolicyCallback::call(bool) ()
#7  0x092648aa in WebCore::PolicyChecker::continueAfterNavigationPolicy(WebCore::PolicyAction) ()
#8  0x09c1b875 in WebKit::FrameLoaderClientImpl::dispatchDecidePolicyForNavigationAction (this=0xe82250c, 
    function=0x92646d6 <WebCore::PolicyChecker::continueAfterNavigationPolicy(WebCore::PolicyAction)>, action=..., request=..., formState=...)
    at third_party/WebKit/WebKit/chromium/src/FrameLoaderClientImpl.cpp:975
#9  0x09264dd4 in WebCore::PolicyChecker::checkNavigationPolicy(WebCore::Resourc---Type <return> to continue, or q <return> to quit---
eRequest const&, WebCore::DocumentLoader*, WTF::PassRefPtr<WebCore::FormState>, void (*)(void*, WebCore::ResourceRequest const&, WTF::PassRefPtr<WebCore::FormState>, bool), void*) ()
#10 0x0925556a in WebCore::FrameLoader::loadURL(WebCore::KURL const&, WebCore::String const&, WebCore::String const&, bool, WebCore::FrameLoadType, WTF::PassRefPtr<WebCore::Event>, WTF::PassRefPtr<WebCore::FormState>) ()
#11 0x09255afd in WebCore::FrameLoader::loadFrameRequest(WebCore::FrameLoadRequest const&, bool, bool, WTF::PassRefPtr<WebCore::Event>, WTF::PassRefPtr<WebCore::FormState>, WebCore::ReferrerPolicy) ()
#12 0x09255ec9 in WebCore::FrameLoader::urlSelected(WebCore::ResourceRequest const&, WebCore::String const&, WTF::PassRefPtr<WebCore::Event>, bool, bool, bool, WebCore::ReferrerPolicy) ()
#13 0x092560b6 in WebCore::FrameLoader::changeLocation(WebCore::KURL const&, WebCore::String const&, bool, bool, bool, bool) ()
#14 0x09268dbf in WebCore::RedirectScheduler::scheduleLocationChange(WebCore::String const&, WebCore::String const&, bool, bool, bool) ()
#15 0x094e98cf in WebCore::navigateIfAllowed(WebCore::Frame*, WebCore::KURL const&, bool, bool) ()
#16 0x09dd3925 in WebCore::V8Location::replaceCallback(v8::Arguments const&) ()
#17 0x08e8d19f in HandleApiCallHelper<false> (args=...)
    at v8/src/builtins.cc:904
#18 0x08e8d24a in Builtin_Impl_HandleApiCall (args=...)
    at v8/src/builtins.cc:921
---Type <return> to continue, or q <return> to quit---
#19 0x08e8d26f in Builtin_HandleApiCall (args=...) at v8/src/builtins.cc:920
#20 0xebc7238e in ?? ()
#21 0x00000003 in ?? ()
Comment 1 Darin Fisher (:fishd, Google) 2010-03-22 08:37:29 PDT
Yeah, we've received a lot of reports of this crash:
Comment 2 Darin Fisher (:fishd, Google) 2010-03-22 09:21:36 PDT
Created attachment 51293 [details]
v1 patch
Comment 3 Darin Fisher (:fishd, Google) 2010-03-22 09:31:20 PDT
Created attachment 51295 [details]
v2 patch (minus svn:eol-style on layout tests)
Comment 4 Nate Chapin 2010-03-22 11:10:00 PDT
Comment on attachment 51295 [details]
v2 patch (minus svn:eol-style on layout tests)


Re: the FIXME: Do we have any idea how currentItem is ending up null?  I'm assuming that it is a bug that script shenanigans like the ones in this layout test can cause it to become null?
Comment 5 Darin Fisher (:fishd, Google) 2010-03-22 11:12:28 PDT
(In reply to comment #4)
> (From update of attachment 51295 [details])
> Re: the FIXME: Do we have any idea how currentItem is ending up null?  I'm
> assuming that it is a bug that script shenanigans like the ones in this layout
> test can cause it to become null?

Yes, I plan on fixing cases that cause this to be null, but that will be done as a separate patch.  First things first:  fix the crash :-)
Comment 6 Darin Fisher (:fishd, Google) 2010-03-22 11:17:52 PDT
Landed as http://trac.webkit.org/changeset/56346