54219 2011-02-10 10:07:15 -0800 Crash in WebCore::FrameLoader::continueLoadAfterNavigationPolicy 2011-02-15 09:03:30 -0800 1 1 1 Unclassified WebKit WebCore Misc. 528+ (Nightly build) All All RESOLVED FIXED P2 Normal --- 1 creis webkit-unassigned abarth ap beidson commit-queue eric eroman fishd jamesr japhet mihaip tonyg webkit.review.bot oldest_to_newest 349155 0 creis 2011-02-10 10:07:15 -0800 This is currently a top crasher on the Chromium dev channel. 0x5b93e82b [chrome.dll - frameloader.cpp:2994 WebCore::FrameLoader::continueLoadAfterNavigationPolicy(WebCore::ResourceRequest const &,WTF::PassRefPtr<WebCore::FormState>,bool) 0x5b93e434 [chrome.dll - frameloader.cpp:2875 WebCore::FrameLoader::callContinueLoadAfterNavigationPolicy(void *,WebCore::ResourceRequest const &,WTF::PassRefPtr<WebCore::FormState>,bool) 0x5b9b1d16 [chrome.dll - policycallback.cpp:102 WebCore::PolicyCallback::call(bool) 0x5b9ae695 [chrome.dll - policychecker.cpp:160 WebCore::PolicyChecker::continueAfterNavigationPolicy(WebCore::PolicyAction) 0x5bca7bfc [chrome.dll - frameloaderclientimpl.cpp:958 WebKit::FrameLoaderClientImpl::dispatchDecidePolicyForNavigationAction(void ( WebCore::PolicyChecker::*)(WebCore::PolicyAction),WebCore::NavigationAction const &,WebCore::ResourceRequest const &,WTF::PassRefPtr<WebCore::FormState>) 0x5b9ae3a2 [chrome.dll - policychecker.cpp:88 WebCore::PolicyChecker::checkNavigationPolicy(WebCore::ResourceRequest const &,WebCore::DocumentLoader *,WTF::PassRefPtr<WebCore::FormState>,void (*)(void *,WebCore::ResourceRequest const &,WTF::PassRefPtr<WebCore::FormState>,bool),void *) 0x5b93bce2 [chrome.dll - frameloader.cpp:1491 WebCore::FrameLoader::loadWithDocumentLoader(WebCore::DocumentLoader *,WebCore::FrameLoadType,WTF::PassRefPtr<WebCore::FormState>) 0x5b93b9ce [chrome.dll - frameloader.cpp:1408 WebCore::FrameLoader::loadWithNavigationAction(WebCore::ResourceRequest const &,WebCore::NavigationAction const &,bool,WebCore::FrameLoadType,WTF::PassRefPtr<WebCore::FormState>) 0x5b93f327 [chrome.dll - frameloader.cpp:3258 WebCore::FrameLoader::loadDifferentDocumentItem(WebCore::HistoryItem *,WebCore::FrameLoadType) 0x5b9ac494 [chrome.dll - historycontroller.cpp:683 WebCore::HistoryController::recursiveGoToItem(WebCore::HistoryItem *,WebCore::HistoryItem *,WebCore::FrameLoadType) 0x5b9aba59 [chrome.dll - historycontroller.cpp:250 WebCore::HistoryController::goToItem(WebCore::HistoryItem *,WebCore::FrameLoadType) 0x5bc8fcfe [chrome.dll - webframeimpl.cpp:899 WebKit::WebFrameImpl::loadHistoryItem(WebKit::WebHistoryItem const &) 0x5b507560 [chrome.dll - render_view.cc:1426 RenderView::OnNavigate(ViewMsg_Navigate_Params const &) 349156 1 creis 2011-02-10 10:10:17 -0800 It looks like the crash is happening on this line: if (isBackForwardLoadType(type) && history()->provisionalItem()->isInPageCache()) { loadProvisionalItemFromCachedPage(); return; } It's possible history()->provisionalItem() might be null at the time. 349285 2 creis 2011-02-10 12:42:16 -0800 The location of the crash in the crash dump's disassembly does seem to confirm that we've already called isBackForwardNavigation and then blow up when we access history()->provisionalItem()->isInPageCache(), which is inlined. The curious thing is that the provisional item gets set on the first line of loadDifferentDocumentItem, which is still on the call stack. That means something between there and here cleared the provisional item. The closest thing I see is the call to stopAllLoaders just above the crash, but that's explicitly called with ShouldNotClearProvisionalItem (because we know a new navigation is in progress). We started clearing provisional items in stopAllLoaders as part of http://trac.webkit.org/changeset/76357. For what it's worth, a simple null check is not sufficient to fix the problem-- that just delays the crash until later. It looks like we're expecting the provisional item to be valid here. 350016 3 creis 2011-02-11 14:12:38 -0800 Eric Roman found a way to repro (posted on the corresponding Chrome bug, http://crbug.com/72458): 1. Visit http://shop.ebay.com/quickshipwarehouse/m.html?_nkw=&_armrs=1&_from=&_ipg=&_trksid=p3686 2. Click any product link and let it load fully. 3. Click the blue "Place Bid" button. 4. Click Back, then click Back again after the page has started to render but before it finishes. It turns out the product page (from step 2) does a DOMWindow::setLocation to a hash, which makes us call FrameLoader::loadInSameDocument. I recently updated that to clear the history's provisional item as part of http://trac.webkit.org/changeset/77705, since we don't want to leave it dangling in a normal same-document navigation. That leads to the crash. However, it's surprising that this can happen *within* a call to loadDifferentDocumentItem (via stopAllLoaders), as you can see deep within the stack trace below. In other words, as part of doing a back navigation, we stop the current loaders, which somehow lets the DOMWindow dispatch an event, where it then manages to set the location (even though we already have a navigation in progress). We then proceed with the back navigation logic that's already on the call stack, ending up with the crash. This nested navigation seems broken to me, but I'll admit that I don't understand enough of this flow to know whether this is the intended behavior. Even if we weren't clearing the provisional item in recursiveUpdateForSameDocumentNavigation, we'll end up confused due to the nested navigation. Any thoughts on the right way to fix this? 00 chrome_1210000!WebCore::HistoryController::recursiveUpdateForSameDocumentNavigation 01 chrome_1210000!WebCore::FrameLoader::loadInSameDocument+0x157 02 chrome_1210000!WebCore::FrameLoader::callContinueFragmentScrollAfterNavigationPolicy+0x37 03 chrome_1210000!WebCore::PolicyCallback::call+0x2b 04 chrome_1210000!WebCore::PolicyChecker::continueAfterNavigationPolicy+0xe7 05 chrome_1210000!WebKit::FrameLoaderClientImpl::dispatchDecidePolicyForNavigationAction+0x217 06 chrome_1210000!WebCore::PolicyChecker::checkNavigationPolicy+0x192 07 chrome_1210000!WebCore::FrameLoader::loadURL+0x2a9 08 chrome_1210000!WebCore::FrameLoader::loadFrameRequest+0x153 09 chrome_1210000!WebCore::FrameLoader::urlSelected+0x114 0a chrome_1210000!WebCore::FrameLoader::changeLocation+0x75 0b chrome_1210000!WebCore::NavigationScheduler::scheduleLocationChange+0xad 0c chrome_1210000!WebCore::DOMWindow::setLocation+0xe7 0d chrome_1210000!WebCore::V8Location::replaceCallback+0x65 0e chrome_1210000!v8::internal::HandleApiCallHelper<0>+0x16a 0f chrome_1210000!v8::internal::Builtin_HandleApiCall+0xf WARNING: Frame IP not in any known module. Following frames may be wrong. 10 0x1e1b028e 11 0x6c23af7 12 chrome_1210000!v8::internal::Invoke+0xf9 13 chrome_1210000!v8::internal::Execution::Call+0x25 14 chrome_1210000!v8::Function::Call+0xea 15 chrome_1210000!WebCore::V8Proxy::callFunction+0x13d 16 chrome_1210000!WebCore::V8EventListener::callListenerFunction+0x55 17 chrome_1210000!WebCore::V8AbstractEventListener::invokeEventHandler+0xdf 18 chrome_1210000!WebCore::V8AbstractEventListener::handleEvent+0x4f 19 chrome_1210000!WebCore::EventTarget::fireEventListeners+0xb6 1a chrome_1210000!WebCore::EventTarget::fireEventListeners+0x47 1b chrome_1210000!WebCore::DOMWindow::dispatchEvent+0x99 1c chrome_1210000!WebCore::DOMWindow::dispatchTimedEvent+0x31 1d chrome_1210000!WebCore::DOMWindow::dispatchLoadEvent+0x85 1e chrome_1210000!WebCore::Document::implicitClose+0xf4 1f chrome_1210000!WebCore::FrameLoader::checkCallImplicitClose+0x4d 20 chrome_1210000!WebCore::FrameLoader::checkCompleted+0x82 21 chrome_1210000!WebCore::FrameLoader::completed+0x59 22 chrome_1210000!WebCore::FrameLoader::checkCompleted+0x96 23 chrome_1210000!WebCore::FrameLoader::mainReceivedCompleteError+0x29 24 chrome_1210000!WebCore::DocumentLoader::mainReceivedError+0x41 25 chrome_1210000!WebCore::FrameLoader::receivedMainResourceError+0xd1 26 chrome_1210000!WebCore::MainResourceLoader::didCancel+0x50 27 chrome_1210000!WebCore::ResourceLoader::cancel+0x4a 28 chrome_1210000!WebCore::ResourceLoader::cancel+0x25 29 chrome_1210000!WebCore::DocumentLoader::stopLoading+0x7b 2a chrome_1210000!WebCore::FrameLoader::stopAllLoaders+0x68 2b chrome_1210000!WebCore::FrameLoader::stopLoadingSubframes+0x1d 2c chrome_1210000!WebCore::FrameLoader::stopAllLoaders+0x56 2d chrome_1210000!WebCore::FrameLoader::stopLoadingSubframes+0x1d 2e chrome_1210000!WebCore::FrameLoader::stopAllLoaders+0x56 2f chrome_1210000!WebCore::FrameLoader::continueLoadAfterNavigationPolicy+0xc8 30 chrome_1210000!WebCore::FrameLoader::callContinueLoadAfterNavigationPolicy+0x1e 31 chrome_1210000!WebCore::PolicyCallback::call+0x2b 32 chrome_1210000!WebCore::PolicyChecker::continueAfterNavigationPolicy+0xe7 33 chrome_1210000!WebKit::FrameLoaderClientImpl::dispatchDecidePolicyForNavigationAction+0x217 34 chrome_1210000!WebCore::PolicyChecker::checkNavigationPolicy+0x192 35 chrome_1210000!WebCore::FrameLoader::loadWithDocumentLoader+0x209 36 chrome_1210000!WebCore::FrameLoader::loadWithNavigationAction+0x135 37 chrome_1210000!WebCore::FrameLoader::loadDifferentDocumentItem+0x2bc 38 chrome_1210000!WebCore::HistoryController::recursiveGoToItem+0x100 39 chrome_1210000!WebCore::HistoryController::goToItem+0x82 3a chrome_1210000!WebKit::WebFrameImpl::loadHistoryItem+0x88 3b chrome_1210000!RenderView::OnNavigate+0x1a2 350031 4 mihaip 2011-02-11 14:20:29 -0800 (In reply to comment #3) > Any thoughts on the right way to fix this? At the very least, it seems like you'd want to protect the provisional item with a RefPtr. I ran into something similar with http://trac.webkit.org/changeset/71170. 350042 5 creis 2011-02-11 14:34:03 -0800 (In reply to comment #4) > (In reply to comment #3) > > Any thoughts on the right way to fix this? > > At the very least, it seems like you'd want to protect the provisional item with a RefPtr. I ran into something similar with http://trac.webkit.org/changeset/71170. Actually, it's already protected with a RefPtr in HistoryController. I suppose we could also put it in a RefPtr in loadDifferentDocumentItem, but that wouldn't prevent this crash. In other words, the HistoryItem itself isn't being deleted and then used. The problem is that we set the HistoryController's provisional item, then start an entirely unrelated nested navigation (which sets and commits a different provisional item), and then we expect to commit the first provisional item. HistoryController isn't set up to have a stack of navigations in progress. 350920 6 mihaip 2011-02-14 15:11:27 -0800 (In reply to comment #5) > HistoryController isn't set up to have a stack of navigations in progress. It looks like part of the problem is this part of NavigationScheduler::scheduleLocationChange // If the URL we're going to navigate to is the same as the current one, except for the // fragment part, we don't need to schedule the location change. KURL parsedURL(ParsedURLString, url); if (parsedURL.hasFragmentIdentifier() && equalIgnoringFragmentIdentifier(m_frame->document()->url(), parsedURL)) { loader->changeLocation(securityOrigin, loader->completeURL(url), referrer, lockHistory, lockBackForwardList); return; } Normally all page-initiated location changes are asynchronous, so we don't end up in this state of having more than one navigation in progress. One possible fix is to remove this special-casing of fragment changes here, and let them be handled like other navigations (which involves enqueuing a task on the NavigationScheduler queue, by the time that fires the previous navigation will be complete). 350937 7 creis 2011-02-14 15:32:44 -0800 (In reply to comment #6) > Normally all page-initiated location changes are asynchronous, so we don't end up in this state of having more than one navigation in progress. One possible fix is to remove this special-casing of fragment changes here, and let them be handled like other navigations (which involves enqueuing a task on the NavigationScheduler queue, by the time that fires the previous navigation will be complete). I can confirm that change would avoid the crash, but I'm not sure it'll catch all the ways we might get there. For example, about:blank does a similar shortcut. Nate and I were considering returning early from FrameLoader::loadURL if m_inStopAllLoaders is true. There's already a check like that in FrameLoader::load, and it would be a good sanity check. The biggest problem I'm facing right now is not being able to boil this down to a reduced test case. The Ebay URL in comment 3 works reliably, but only on Windows. I've written a test that puts an onload handler on a slow iframe, navigating to #foo once onload fires. I can't seem to get it to fire, though. Instead, FrameLoader::m_isComplete is true when we get to FrameLoader::checkCompleted (unlike in the Ebay example), so we never call FrameLoader::checkCallImplicitClose. (See frame 1f in comment 3.) I should have a patch as soon as I get the test working. 350970 8 82384 creis 2011-02-14 16:38:26 -0800 Created attachment 82384 Patch 350979 9 creis 2011-02-14 16:41:49 -0800 (In reply to comment #8) > Created an attachment (id=82384) [details] > Patch This patch avoids the crash by ensuring we don't start a new navigation with loadURL while stopAllLoaders is in progress. It mimics a check we have in FrameLoader::load. I'm not thrilled with the test-- it can only reproduce the crash if you click the back button in the browser, and not if we use history.back() to go back. This is currently a top crasher, though, so I wanted to get the fix in review as soon as possible. 351024 10 82399 creis 2011-02-14 17:56:18 -0800 Created attachment 82399 Patch 351026 11 creis 2011-02-14 17:59:33 -0800 (In reply to comment #10) > Created an attachment (id=82399) [details] > Patch Here's a patch with a manual test instead, since the layout test in the previous test wouldn't have caught a regression anyway. Mihai points out that the difference between Chromium's back button and history.back() is that the latter calls Page::goToItem (which calls FrameLoader::stopAllLoaders) before HistoryController::goToItem. That prevents the crash seen in this bug. It'd be nice to get either a way to call HistoryController::goToItem without Page::goToItem via layoutTestController, or change Chromium to call Page::goToItem. However, this is currently a top crasher for Chromium, so we're hoping to get a patch in quickly. I'm happy to iterate on the test design afterward. 351034 12 82399 mihaip 2011-02-14 18:08:16 -0800 Comment on attachment 82399 Patch This minimally-invasive change seems fine to not hold up the release, but I'd like a more through follow-up fix too (e.g. change chromium's WebFrameImpl to use Page::goToItem and/or stop loaders, and add an assert in HistoryController::goToItem that checks that loading is stopped). 351261 13 82399 commit-queue 2011-02-15 07:55:35 -0800 Comment on attachment 82399 Patch Clearing flags on attachment: 82399 Committed r78561: <http://trac.webkit.org/changeset/78561> 351263 14 commit-queue 2011-02-15 07:55:40 -0800 All reviewed patches have been landed. Closing bug. 351324 15 webkit.review.bot 2011-02-15 09:03:30 -0800 http://trac.webkit.org/changeset/78561 might have broken GTK Linux 64-bit Debug 82384 2011-02-14 16:38:26 -0800 2011-02-14 17:56:15 -0800 Patch bug-54219-20110214163824.patch text/plain 5210 creis SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDc4NTIzKQorKysgU291cmNlL1dlYkNvcmUvQ2hhbmdl TG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMTUgQEAKKzIwMTEtMDItMTQgIENoYXJsaWUg UmVpcyAgPGNyZWlzQGNocm9taXVtLm9yZz4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkg KE9PUFMhKS4KKworICAgICAgICBDcmFzaCBpbiBXZWJDb3JlOjpGcmFtZUxvYWRlcjo6Y29udGlu dWVMb2FkQWZ0ZXJOYXZpZ2F0aW9uUG9saWN5CisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQu b3JnL3Nob3dfYnVnLmNnaT9pZD01NDIxOQorCisgICAgICAgIEVuc3VyZSB3ZSBkbyBub3Qgc3Rh cnQgYSBuZXcgbmF2aWdhdGlvbiB3aGlsZSB3ZSBhcmUgaW4gdGhlIHByb2Nlc3Mgb2YKKyAgICAg ICAgc3RvcHBpbmcgYSBuYXZpZ2F0aW9uLgorCisgICAgICAgICogbG9hZGVyL0ZyYW1lTG9hZGVy LmNwcDoKKwogMjAxMS0wMi0xNCAgRW5yaWNhIENhc3VjY2kgIDxlbnJpY2FAYXBwbGUuY29tPgog CiAgICAgICAgIENvcHkvcGFzdGUgZnJvbSBhIFdlYktpdCB3aW5kb3cgdG8gYSBUZXh0RWRpdCB3 aW5kb3cgbG9zZXMgZm9udHMuCkluZGV4OiBTb3VyY2UvV2ViQ29yZS9sb2FkZXIvRnJhbWVMb2Fk ZXIuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9XZWJDb3JlL2xvYWRlci9GcmFtZUxvYWRlci5j cHAJKHJldmlzaW9uIDc4NTIzKQorKysgU291cmNlL1dlYkNvcmUvbG9hZGVyL0ZyYW1lTG9hZGVy LmNwcAkod29ya2luZyBjb3B5KQpAQCAtMTMwMSw2ICsxMzAxLDkgQEAgdm9pZCBGcmFtZUxvYWRl cjo6bG9hZEZyYW1lUmVxdWVzdChjb25zdAogdm9pZCBGcmFtZUxvYWRlcjo6bG9hZFVSTChjb25z dCBLVVJMJiBuZXdVUkwsIGNvbnN0IFN0cmluZyYgcmVmZXJyZXIsIGNvbnN0IFN0cmluZyYgZnJh bWVOYW1lLCBib29sIGxvY2tIaXN0b3J5LCBGcmFtZUxvYWRUeXBlIG5ld0xvYWRUeXBlLAogICAg IFBhc3NSZWZQdHI8RXZlbnQ+IGV2ZW50LCBQYXNzUmVmUHRyPEZvcm1TdGF0ZT4gcHJwRm9ybVN0 YXRlKQogeworICAgIGlmIChtX2luU3RvcEFsbExvYWRlcnMpCisgICAgICAgIHJldHVybjsKKwog ICAgIFJlZlB0cjxGb3JtU3RhdGU+IGZvcm1TdGF0ZSA9IHBycEZvcm1TdGF0ZTsKICAgICBib29s IGlzRm9ybVN1Ym1pc3Npb24gPSBmb3JtU3RhdGU7CiAgICAgCkluZGV4OiBMYXlvdXRUZXN0cy9D aGFuZ2VMb2cKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQotLS0gTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCShyZXZpc2lvbiA3 ODUyMykKKysrIExheW91dFRlc3RzL0NoYW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsx LDE3IEBACisyMDExLTAyLTE0ICBDaGFybGllIFJlaXMgIDxjcmVpc0BjaHJvbWl1bS5vcmc+CisK KyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgQ3Jhc2ggaW4g V2ViQ29yZTo6RnJhbWVMb2FkZXI6OmNvbnRpbnVlTG9hZEFmdGVyTmF2aWdhdGlvblBvbGljeQor ICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9NTQyMTkKKwor ICAgICAgICBUZXN0cyB0aGF0IHdlIGRvIG5vdCBzdGFydCBhIG5ldyBuYXZpZ2F0aW9uIGR1ZSB0 byBhbiBvbmxvYWQgaGFuZGxlcgorICAgICAgICB0cmlnZ2VyZWQgYnkgYSBiYWNrIG5hdmlnYXRp b24uCisKKyAgICAgICAgKiBodHRwL3Rlc3RzL2hpc3RvcnkvbmF2aWdhdGlvbi1kdXJpbmctb25s b2FkLXRyaWdnZXJlZC1ieS1iYWNrLWV4cGVjdGVkLnR4dDogQWRkZWQuCisgICAgICAgICogaHR0 cC90ZXN0cy9oaXN0b3J5L25hdmlnYXRpb24tZHVyaW5nLW9ubG9hZC10cmlnZ2VyZWQtYnktYmFj ay5odG1sOiBBZGRlZC4KKyAgICAgICAgKiBodHRwL3Rlc3RzL2hpc3RvcnkvcmVzb3VyY2VzL25h dmlnYXRpb24tZHVyaW5nLW9ubG9hZC1jb250YWluZXIuaHRtbDogQWRkZWQuCisKIDIwMTEtMDIt MTQgIFBldGVyIEthc3RpbmcgIDxwa2FzdGluZ0Bnb29nbGUuY29tPgogCiAgICAgICAgIFVucmV2 aWV3ZWQsIENocm9taXVtIHRlc3QgZXhwZWN0YXRpb25zIHVwZGF0ZS4KSW5kZXg6IExheW91dFRl c3RzL2h0dHAvdGVzdHMvaGlzdG9yeS9uYXZpZ2F0aW9uLWR1cmluZy1vbmxvYWQtdHJpZ2dlcmVk LWJ5LWJhY2stZXhwZWN0ZWQudHh0Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIExheW91dFRlc3RzL2h0dHAvdGVz dHMvaGlzdG9yeS9uYXZpZ2F0aW9uLWR1cmluZy1vbmxvYWQtdHJpZ2dlcmVkLWJ5LWJhY2stZXhw ZWN0ZWQudHh0CShyZXZpc2lvbiAwKQorKysgTGF5b3V0VGVzdHMvaHR0cC90ZXN0cy9oaXN0b3J5 L25hdmlnYXRpb24tZHVyaW5nLW9ubG9hZC10cmlnZ2VyZWQtYnktYmFjay1leHBlY3RlZC50eHQJ KHJldmlzaW9uIDApCkBAIC0wLDAgKzEsMTAgQEAKK0NPTlNPTEUgTUVTU0FHRTogbGluZSAyMzog U3RhcnRpbmcgdGVzdC4KK1Rlc3RzIHRoYXQgYW4gb25sb2FkIGhhbmRsZXIgdGhhdCBuYXZpZ2F0 ZXMgdG8gYSBoYXNoIHdoaWNoIGlzIHRyaWdnZXJlZCBieSBhIGhpc3RvcnkuYmFjaygpIGRvZXNu J3QgY3Jhc2ggdGhlIGJyb3dzZXIuCisKK09uIHN1Y2Nlc3MsIHlvdSB3aWxsIHNlZSBhIHNlcmll cyBvZiAiUEFTUyIgbWVzc2FnZXMsIGZvbGxvd2VkIGJ5ICJURVNUIENPTVBMRVRFIi4KKworCitQ QVNTIHN1Y2Nlc3NmdWxseVBhcnNlZCBpcyB0cnVlCisKK1RFU1QgQ09NUExFVEUKKwpJbmRleDog TGF5b3V0VGVzdHMvaHR0cC90ZXN0cy9oaXN0b3J5L25hdmlnYXRpb24tZHVyaW5nLW9ubG9hZC10 cmlnZ2VyZWQtYnktYmFjay5odG1sCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIExheW91dFRlc3RzL2h0dHAvdGVz dHMvaGlzdG9yeS9uYXZpZ2F0aW9uLWR1cmluZy1vbmxvYWQtdHJpZ2dlcmVkLWJ5LWJhY2suaHRt bAkocmV2aXNpb24gMCkKKysrIExheW91dFRlc3RzL2h0dHAvdGVzdHMvaGlzdG9yeS9uYXZpZ2F0 aW9uLWR1cmluZy1vbmxvYWQtdHJpZ2dlcmVkLWJ5LWJhY2suaHRtbAkocmV2aXNpb24gMCkKQEAg LTAsMCArMSwzOCBAQAorPCFET0NUWVBFIGh0bWw+Cis8aHRtbD4KKzxoZWFkPgorICA8bGluayBy ZWw9InN0eWxlc2hlZXQiIGhyZWY9Ii4uLy4uL2pzLXRlc3QtcmVzb3VyY2VzL2pzLXRlc3Qtc3R5 bGUuY3NzIj4KKyAgPHNjcmlwdCBzcmM9Ii4uLy4uL2pzLXRlc3QtcmVzb3VyY2VzL2pzLXRlc3Qt cHJlLmpzIj48L3NjcmlwdD4KKzwvaGVhZD4KKzxib2R5PgorPHAgaWQ9ImRlc2NyaXB0aW9uIj48 L3A+Cis8ZGl2IGlkPSJjb25zb2xlIj48L2Rpdj4KKworPHNjcmlwdD4KK2Rlc2NyaXB0aW9uKCdU ZXN0cyB0aGF0IGFuIG9ubG9hZCBoYW5kbGVyIHRoYXQgbmF2aWdhdGVzIHRvIGEgaGFzaCB3aGlj aCBpcyB0cmlnZ2VyZWQgYnkgYSBoaXN0b3J5LmJhY2soKSBkb2VzblwndCBjcmFzaCB0aGUgYnJv d3Nlci4nKTsKKworb25sb2FkID0gZnVuY3Rpb24oKQoreworICAgIGlmICh3aW5kb3cubG9jYWxT dG9yYWdlLnN0YXJ0ZWQpIHsKKyAgICAgICAgZGVsZXRlIHdpbmRvdy5sb2NhbFN0b3JhZ2Uuc3Rh cnRlZDsKKyAgICAgICAgZmluaXNoSlNUZXN0KCk7CisgICAgfSBlbHNlIHsKKyAgICAgICAgLy8g VG8gbWFrZSBzdXJlIHRoYXQgd2UgaGl0IHRoaXMgYnJhbmNoLCBsb2cgdGhpcyB0byB0aGUgY29u c29sZSBzbyB0aGF0IAorICAgICAgICAvLyBpdCBzaG93cyB1cCBpbiBleHBlY3RlZCBvdXRwdXQg KGRlYnVnKCkgd2lsbCBiZSBibG93biBhd2F5IG9uY2Ugd2UKKyAgICAgICAgLy8gbmF2aWdhdGUg b3V0KS4KKyAgICAgICAgY29uc29sZS5sb2coJ1N0YXJ0aW5nIHRlc3QuJyk7CisgICAgICAgIHdp bmRvdy5sb2NhbFN0b3JhZ2Uuc3RhcnRlZCA9IHRydWU7CisgICAgICAgIC8vIE5hdmlnYXRlIGlu IGEgdGltZW91dCB0byBtYWtlIHN1cmUgd2UgY3JlYXRlIGEgaGlzdG9yeSBlbnRyeS4KKyAgICAg ICAgc2V0VGltZW91dChmdW5jdGlvbigpIHsKKyAgICAgICAgICAgIHdpbmRvdy5sb2NhdGlvbi5o cmVmID0gJ3Jlc291cmNlcy9uYXZpZ2F0aW9uLWR1cmluZy1vbmxvYWQtY29udGFpbmVyLmh0bWwn OworICAgICAgICB9LCAwKTsKKyAgICB9Cit9OworCit2YXIgc3VjY2Vzc2Z1bGx5UGFyc2VkID0g dHJ1ZTsKK3ZhciBqc1Rlc3RJc0FzeW5jID0gdHJ1ZTsKKzwvc2NyaXB0PiAKKworPHNjcmlwdCBz cmM9Ii4uLy4uL2pzLXRlc3QtcmVzb3VyY2VzL2pzLXRlc3QtcG9zdC5qcyI+PC9zY3JpcHQ+Cis8 L2JvZHk+Cis8L2h0bWw+CkluZGV4OiBMYXlvdXRUZXN0cy9odHRwL3Rlc3RzL2hpc3RvcnkvcmVz b3VyY2VzL25hdmlnYXRpb24tZHVyaW5nLW9ubG9hZC1jb250YWluZXIuaHRtbAo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Ci0tLSBMYXlvdXRUZXN0cy9odHRwL3Rlc3RzL2hpc3RvcnkvcmVzb3VyY2VzL25hdmlnYXRpb24t ZHVyaW5nLW9ubG9hZC1jb250YWluZXIuaHRtbAkocmV2aXNpb24gMCkKKysrIExheW91dFRlc3Rz L2h0dHAvdGVzdHMvaGlzdG9yeS9yZXNvdXJjZXMvbmF2aWdhdGlvbi1kdXJpbmctb25sb2FkLWNv bnRhaW5lci5odG1sCShyZXZpc2lvbiAwKQpAQCAtMCwwICsxLDEyIEBACis8c2NyaXB0Pgorb25s b2FkID0gZnVuY3Rpb24oKSB7CisgIHdpbmRvdy5sb2NhdGlvbi5yZXBsYWNlKCIjZm9vIik7Cit9 OworPC9zY3JpcHQ+Citjb250YWluZXIKKzxpZnJhbWUgc3JjPSJiYWNrLWR1cmluZy1vbmxvYWQt bWlkZGxlLmh0bWwiPjwvaWZyYW1lPgorPHNjcmlwdD4KKy8vIE5vdGU6IFRoaXMgYmFjayBuYXZp Z2F0aW9uIG11c3QgYmUgZG9uZSB3aXRoIHRoZSBicm93c2VyJ3MgYmFjayBidXR0b24gdG8KKy8v IGNhdXNlIHRoZSBjcmFzaCBzZWVuIGluIGh0dHA6Ly93ZWJraXQub3JnL2IvNTQyMTkuCitoaXN0 b3J5LmJhY2soKTsKKzwvc2NyaXB0Pgo= 82399 2011-02-14 17:56:18 -0800 2011-02-15 07:55:35 -0800 Patch bug-54219-20110214175617.patch text/plain 3183 creis SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDc4NTIzKQorKysgU291cmNlL1dlYkNvcmUvQ2hhbmdl TG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMTggQEAKKzIwMTEtMDItMTQgIENoYXJsaWUg UmVpcyAgPGNyZWlzQGNocm9taXVtLm9yZz4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkg KE9PUFMhKS4KKworICAgICAgICBDcmFzaCBpbiBXZWJDb3JlOjpGcmFtZUxvYWRlcjo6Y29udGlu dWVMb2FkQWZ0ZXJOYXZpZ2F0aW9uUG9saWN5CisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQu b3JnL3Nob3dfYnVnLmNnaT9pZD01NDIxOQorCisgICAgICAgIEVuc3VyZXMgd2UgZG8gbm90IHN0 YXJ0IGEgbmV3IG5hdmlnYXRpb24gd2hpbGUgd2UgYXJlIGluIHRoZSBwcm9jZXNzIG9mCisgICAg ICAgIHN0b3BwaW5nIGEgbmF2aWdhdGlvbi4gIEFsc28gYWRkcyBhIG1hbnVhbCB0ZXN0LCBzaW5j ZSB0aGUgY3Jhc2ggY2FuCisgICAgICAgIG9ubHkgYmUgcmVwcm9kdWNlZCB1c2luZyB0aGUgYmFj ayBidXR0b24gYW5kIG5vdCBoaXN0b3J5LmJhY2soKS4KKworICAgICAgICAqIGxvYWRlci9GcmFt ZUxvYWRlci5jcHA6CisgICAgICAgICogbWFudWFsLXRlc3RzL25hdmlnYXRpb24tZHVyaW5nLW9u bG9hZC10cmlnZ2VyZWQtYnktYmFjay5odG1sOiBBZGRlZC4KKyAgICAgICAgKiBtYW51YWwtdGVz dHMvcmVzb3VyY2VzL25hdmlnYXRpb24tZHVyaW5nLW9ubG9hZC1jb250YWluZXIuaHRtbDogQWRk ZWQuCisKIDIwMTEtMDItMTQgIEVucmljYSBDYXN1Y2NpICA8ZW5yaWNhQGFwcGxlLmNvbT4KIAog ICAgICAgICBDb3B5L3Bhc3RlIGZyb20gYSBXZWJLaXQgd2luZG93IHRvIGEgVGV4dEVkaXQgd2lu ZG93IGxvc2VzIGZvbnRzLgpJbmRleDogU291cmNlL1dlYkNvcmUvbG9hZGVyL0ZyYW1lTG9hZGVy LmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2ViQ29yZS9sb2FkZXIvRnJhbWVMb2FkZXIuY3Bw CShyZXZpc2lvbiA3ODUyMykKKysrIFNvdXJjZS9XZWJDb3JlL2xvYWRlci9GcmFtZUxvYWRlci5j cHAJKHdvcmtpbmcgY29weSkKQEAgLTEzMDEsNiArMTMwMSw5IEBAIHZvaWQgRnJhbWVMb2FkZXI6 OmxvYWRGcmFtZVJlcXVlc3QoY29uc3QKIHZvaWQgRnJhbWVMb2FkZXI6OmxvYWRVUkwoY29uc3Qg S1VSTCYgbmV3VVJMLCBjb25zdCBTdHJpbmcmIHJlZmVycmVyLCBjb25zdCBTdHJpbmcmIGZyYW1l TmFtZSwgYm9vbCBsb2NrSGlzdG9yeSwgRnJhbWVMb2FkVHlwZSBuZXdMb2FkVHlwZSwKICAgICBQ YXNzUmVmUHRyPEV2ZW50PiBldmVudCwgUGFzc1JlZlB0cjxGb3JtU3RhdGU+IHBycEZvcm1TdGF0 ZSkKIHsKKyAgICBpZiAobV9pblN0b3BBbGxMb2FkZXJzKQorICAgICAgICByZXR1cm47CisKICAg ICBSZWZQdHI8Rm9ybVN0YXRlPiBmb3JtU3RhdGUgPSBwcnBGb3JtU3RhdGU7CiAgICAgYm9vbCBp c0Zvcm1TdWJtaXNzaW9uID0gZm9ybVN0YXRlOwogICAgIApJbmRleDogU291cmNlL1dlYkNvcmUv bWFudWFsLXRlc3RzL25hdmlnYXRpb24tZHVyaW5nLW9ubG9hZC10cmlnZ2VyZWQtYnktYmFjay5o dG1sCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9XZWJDb3JlL21hbnVhbC10ZXN0cy9uYXZpZ2F0aW9u LWR1cmluZy1vbmxvYWQtdHJpZ2dlcmVkLWJ5LWJhY2suaHRtbAkocmV2aXNpb24gMCkKKysrIFNv dXJjZS9XZWJDb3JlL21hbnVhbC10ZXN0cy9uYXZpZ2F0aW9uLWR1cmluZy1vbmxvYWQtdHJpZ2dl cmVkLWJ5LWJhY2suaHRtbAkocmV2aXNpb24gMCkKQEAgLTAsMCArMSwxNiBAQAorPGh0bWw+Cis8 aGVhZD4KKzwvaGVhZD4KKzxib2R5PgorPHA+U2FtZS1kb2N1bWVudCBuYXZpZ2F0aW9uIGluIG9u bG9hZCB0cmlnZ2VyZWQgYnkgYmFjayBuYXZpZ2F0aW9uLjwvcD4KKyAgICA8b2w+CisgICAgICAg IDxsaT5TdGFydCB0aGUgbGF5b3V0IHRlc3Qgd2ViIHNlcnZlciB3aXRoIFRvb2xzL1NjcmlwdHMv cnVuLXdlYmtpdC1odHRwZC48L2xpPgorICAgICAgICA8bGk+Q2xpY2sgPGEgaHJlZj0icmVzb3Vy Y2VzL25hdmlnYXRpb24tZHVyaW5nLW9ubG9hZC1jb250YWluZXIuaHRtbCI+aGVyZTwvYT4uPC9s aT4KKyAgICAgICAgPGxpPkNsaWNrIEJhY2suPC9saT4KKyAgICA8L29sPgorPHA+WW91IHNob3Vs ZCBub3QgY3Jhc2guPC9wPgorPHA+V2UgY2Fubm90IHVzZSBoaXN0b3J5LmJhY2soKSB0byB0ZXN0 IHRoaXMsIGJlY2F1c2UgaXQgY2FsbHMgUGFnZTo6Z29Ub0l0ZW0KKyh3aGljaCBjYWxscyBGcmFt ZUxvYWRlcjo6c3RvcEFsbExvYWRlcnMpIGZpcnN0LiAgQ2hyb21pdW0ncyBiYWNrIGJ1dHRvbiBk b2VzCitub3QgY2FsbCBzdG9wQWxsTG9hZGVycyBmaXJzdC48L3A+Cis8L2JvZHk+Cis8L2h0bWw+ CkluZGV4OiBTb3VyY2UvV2ViQ29yZS9tYW51YWwtdGVzdHMvcmVzb3VyY2VzL25hdmlnYXRpb24t ZHVyaW5nLW9ubG9hZC1jb250YWluZXIuaHRtbAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2ViQ29y ZS9tYW51YWwtdGVzdHMvcmVzb3VyY2VzL25hdmlnYXRpb24tZHVyaW5nLW9ubG9hZC1jb250YWlu ZXIuaHRtbAkocmV2aXNpb24gMCkKKysrIFNvdXJjZS9XZWJDb3JlL21hbnVhbC10ZXN0cy9yZXNv dXJjZXMvbmF2aWdhdGlvbi1kdXJpbmctb25sb2FkLWNvbnRhaW5lci5odG1sCShyZXZpc2lvbiAw KQpAQCAtMCwwICsxLDEwIEBACis8c2NyaXB0Pgorb25sb2FkID0gZnVuY3Rpb24oKSB7CisgIHdp bmRvdy5sb2NhdGlvbi5yZXBsYWNlKCIjZm9vIik7Cit9OworPC9zY3JpcHQ+Citjb250YWluZXIK KzxpZnJhbWUgc3JjPSJodHRwOi8vMTI3LjAuMC4xOjgwMDAvaGlzdG9yeS9yZXNvdXJjZXMvYmFj ay1kdXJpbmctb25sb2FkLW1pZGRsZS5odG1sIj48L2lmcmFtZT4KKzxwPgorQ2xpY2sgdGhlIGJh Y2sgYnV0dG9uIGFuZCBzZWUgaWYgdGhlIGJyb3dzZXIgY3Jhc2hlcy4KKzwvcD4K