97565 2012-09-25 07:07:49 -0700 [WK2][SOUP] Assertion hit in WebKit::DownloadManager::downloadFinished() when download fails 2012-10-05 08:22:12 -0700 1 1 1 Unclassified WebKit WebKit EFL 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED http://build.webkit.org/results/EFL%20Linux%2064-bit%20Debug%20WK2/r129496%20%283575%29.zip P2 Normal --- 1 rakuco mikhail.pozdnyakov cdumez cgarcia danw gustavo gyuyoung.kim jussi.kukkonen lucas.de.marchi mikhail.pozdnyakov mrobinson oldest_to_newest 727610 0 rakuco 2012-09-25 07:07:49 -0700 crash log for WebProcess (pid <unknown>): STDOUT: <empty> STDERR: ASSERTION FAILED: m_downloads.contains(download->downloadID()) STDERR: /home/buildslave-1/webkit-buildslave/efl-linux-64-debug-wk2/build/Source/WebKit2/WebProcess/Downloads/DownloadManager.cpp(76) : void WebKit::DownloadManager::downloadFinished(WebKit::Download*) STDERR: 1 0x7fdd4367c619 WebKit::DownloadManager::downloadFinished(WebKit::Download*) STDERR: 2 0x7fdd4367acbb WebKit::Download::didFail(WebCore::ResourceError const&, CoreIPC::DataReference const&) STDERR: 3 0x7fdd4373cf7b WebKit::DownloadClient::downloadFailed(WebCore::ResourceError const&) STDERR: 4 0x7fdd4373d3d2 WebKit::DownloadClient::didReceiveResponse(WebCore::ResourceHandle*, WebCore::ResourceResponse const&) STDERR: 5 0x7fdd4373c81b WebKit::Download::startWithHandle(WebKit::WebPage*, WebCore::ResourceHandle*, WebCore::ResourceResponse const&) STDERR: 6 0x7fdd4367c4e6 WebKit::DownloadManager::convertHandleToDownload(unsigned long, WebKit::WebPage*, WebCore::ResourceHandle*, WebCore::ResourceRequest const&, WebCore::ResourceResponse const&) STDERR: 7 0x7fdd436e64d4 WebKit::WebFrame::convertHandleToDownload(WebCore::ResourceHandle*, WebCore::ResourceRequest const&, WebCore::ResourceResponse const&) STDERR: 8 0x7fdd436c4ecc WebKit::WebFrameLoaderClient::download(WebCore::ResourceHandle*, WebCore::ResourceRequest const&, WebCore::ResourceResponse const&) STDERR: 9 0x7fdd3fcde7d4 WebCore::MainResourceLoader::continueAfterContentPolicy(WebCore::PolicyAction, WebCore::ResourceResponse const&) STDERR: 10 0x7fdd3fcdecfa WebCore::MainResourceLoader::continueAfterContentPolicy(WebCore::PolicyAction) STDERR: 11 0x7fdd3fcdec34 WebCore::MainResourceLoader::callContinueAfterContentPolicy(void*, WebCore::PolicyAction) STDERR: 12 0x7fdd3fce3666 WebCore::PolicyCallback::call(WebCore::PolicyAction) STDERR: 13 0x7fdd3fce44a3 WebCore::PolicyChecker::continueAfterContentPolicy(WebCore::PolicyAction) STDERR: 14 0x7fdd436e6384 WebKit::WebFrame::didReceivePolicyDecision(unsigned long, WebCore::PolicyAction, unsigned long) STDERR: 15 0x7fdd436c23d8 WebKit::WebFrameLoaderClient::dispatchDecidePolicyForResponse(void (WebCore::PolicyChecker::*)(WebCore::PolicyAction), WebCore::ResourceResponse const&, WebCore::ResourceRequest const&) STDERR: 16 0x7fdd3fce3f5a WebCore::PolicyChecker::checkContentPolicy(WebCore::ResourceResponse const&, void (*)(void*, WebCore::PolicyAction), void*) STDERR: 17 0x7fdd3fcdf304 WebCore::MainResourceLoader::didReceiveResponse(WebCore::ResourceResponse const&) STDERR: 18 0x7fdd3fcf19db WebCore::ResourceLoader::didReceiveResponse(WebCore::ResourceHandle*, WebCore::ResourceResponse const&) STDERR: 19 0x7fdd407e9d5a STDERR: 20 0x7fdd3bd9c8dd g_simple_async_result_complete STDERR: 21 0x7fdd3bd9ca0c STDERR: 22 0x7fdd3c0cee53 g_main_context_dispatch STDERR: 23 0x7fdd3d01223e STDERR: 24 0x7fdd3d00c7b1 STDERR: 25 0x7fdd3d00d245 STDERR: 26 0x7fdd3d00d547 ecore_main_loop_begin STDERR: 27 0x7fdd407d117d WebCore::RunLoop::run() STDERR: 28 0x7fdd4373f1f0 WebProcessMainEfl STDERR: 29 0x4007f4 main STDERR: 30 0x7fdd42d1976d __libc_start_main STDERR: 31 0x400719 STDERR: LEAK: 2 WebPageProxy STDERR: LEAK: 1 WebContext 728389 1 mikhail.pozdnyakov 2012-09-26 03:47:31 -0700 The actual problem is that with DownloadSoup.cpp implementation, functions WebKit::DownloadManager::convertHandleToDownload() and WebKit::DownloadManager::downloadFinished() are invoked in one call chain when download fails. And this is not supposed to happen by design of DownloadManager. To say in more details: 1) DownloadManager::convertHandleToDownload() is invoked, here is an extract from its body: download->startWithHandle(initiatingPage, handle, response); ASSERT(!m_downloads.contains(downloadID)); m_downloads.set(downloadID, download.leakPtr()); so download->startWithHandle() is invoked BEFORE the download is added to m_downloads. 2) In Download::startWithHandle (implementation for soup) have following workaround: // If the handle already got a response, make sure the download client is notified. ResourceHandleInternal* handleInternal = m_resourceHandle->getInternal(); if (!handleInternal->m_response.isNull()) m_downloadClient->didReceiveResponse(m_resourceHandle.get(), handleInternal->m_response); 3) In case of download failure DownloadClient::didReceiveResponse ends up with WebKit::DownloadManager::downloadFinished() 4) WebKit::DownloadManager::downloadFinished() has the following assertion that hits: ASSERT(m_downloads.contains(download->downloadID())); 5) CRASH 728780 2 jussi.kukkonen 2012-09-26 11:21:22 -0700 *** Bug 97698 has been marked as a duplicate of this bug. *** 729369 3 165961 cgarcia 2012-09-27 03:08:34 -0700 Created attachment 165961 Patch This patch should fix the crash by handling the response in an idle. 729438 4 165961 mikhail.pozdnyakov 2012-09-27 05:28:07 -0700 Comment on attachment 165961 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=165961&action=review > Source/WebKit2/WebProcess/Downloads/soup/DownloadSoup.cpp:159 > + void handleResponseLater(const ResourceResponse& response) Are you sure this will be invoked? I had very same patch yesterday (however used WebCore::RunLoop::Timer to invoke another call chain) but saw that DownloadClient instance is deleted with the same call chain, so callback was never invoked. > Source/WebKit2/WebProcess/Downloads/soup/DownloadSoup.cpp:195 > + static_cast<DownloadClient*>(m_downloadClient.get())->handleResponseLater(response); shouldn't we check that response is not null? 729446 5 cgarcia 2012-09-27 05:43:57 -0700 (In reply to comment #4) > (From update of attachment 165961 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=165961&action=review > > > Source/WebKit2/WebProcess/Downloads/soup/DownloadSoup.cpp:159 > > + void handleResponseLater(const ResourceResponse& response) > > Are you sure this will be invoked? I had very same patch yesterday (however used WebCore::RunLoop::Timer to invoke another call chain) but saw that > DownloadClient instance is deleted with the same call chain, so callback was never invoked. Yes, I'm sure, I've tried the patch updating the gtk minibrowser to reply with a download on response policy decision when the mime type can't be handled by the web view. > > Source/WebKit2/WebProcess/Downloads/soup/DownloadSoup.cpp:195 > > + static_cast<DownloadClient*>(m_downloadClient.get())->handleResponseLater(response); > > shouldn't we check that response is not null? We are now using the passed ResourceResponse that is the policy client one, so I don't think it can be Null. 729476 6 mikhail.pozdnyakov 2012-09-27 06:26:09 -0700 (In reply to comment #5) > (In reply to comment #4) > > (From update of attachment 165961 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=165961&action=review > > > > > Source/WebKit2/WebProcess/Downloads/soup/DownloadSoup.cpp:159 > > > + void handleResponseLater(const ResourceResponse& response) > > > > Are you sure this will be invoked? I had very same patch yesterday (however used WebCore::RunLoop::Timer to invoke another call chain) but saw that > > DownloadClient instance is deleted with the same call chain, so callback was never invoked. > > Yes, I'm sure, I've tried the patch updating the gtk minibrowser to reply with a download on response policy decision when the mime type can't be handled by the web view. > > > > Source/WebKit2/WebProcess/Downloads/soup/DownloadSoup.cpp:195 > > > + static_cast<DownloadClient*>(m_downloadClient.get())->handleResponseLater(response); > > > > shouldn't we check that response is not null? > > We are now using the passed ResourceResponse that is the policy client one, so I don't think it can be Null. Ok, thanks. Do you think it's worth also making (In reply to comment #5) > (In reply to comment #4) > > (From update of attachment 165961 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=165961&action=review > > > > > Source/WebKit2/WebProcess/Downloads/soup/DownloadSoup.cpp:159 > > > + void handleResponseLater(const ResourceResponse& response) > > > > Are you sure this will be invoked? I had very same patch yesterday (however used WebCore::RunLoop::Timer to invoke another call chain) but saw that > > DownloadClient instance is deleted with the same call chain, so callback was never invoked. > > Yes, I'm sure, I've tried the patch updating the gtk minibrowser to reply with a download on response policy decision when the mime type can't be handled by the web view. > > > > Source/WebKit2/WebProcess/Downloads/soup/DownloadSoup.cpp:195 > > > + static_cast<DownloadClient*>(m_downloadClient.get())->handleResponseLater(response); > > > > shouldn't we check that response is not null? > > We are now using the passed ResourceResponse that is the policy client one, so I don't think it can be Null. Ok, thank you. To my mind it might also worth making handleResponseLaterCallback() and class data members private. 729483 7 jussi.kukkonen 2012-09-27 06:36:40 -0700 (In reply to comment #3) > Created an attachment (id=165961) [details] > Patch > > This patch should fix the crash by handling the response in an idle. WFM, this fixes the three crashes I was seeing with patch from bug 94515: http/tests/multipart/policy-ignore-crash.php http/tests/multipart/multipart-replace-non-html-content.php http/tests/multipart/load-last-non-html-frame.php (just to be clear, both patches are needed to unskip these tests) 735626 8 165961 gustavo 2012-10-05 07:26:14 -0700 Comment on attachment 165961 Patch LGTM. I'm wondering, though, why don't we need to use this also for Download::start(WebPage*)? 735646 9 cgarcia 2012-10-05 08:19:40 -0700 (In reply to comment #8) > (From update of attachment 165961 [details]) > LGTM. I'm wondering, though, why don't we need to use this also for Download::start(WebPage*)? Because in Download::start() we haven't received the response yet, so the client callback will be called normally after Download::start(). 735651 10 cgarcia 2012-10-05 08:22:12 -0700 Committed r130506: <http://trac.webkit.org/changeset/130506> 165961 2012-09-27 03:08:34 -0700 2012-10-05 07:26:13 -0700 Patch wk2-downloads-crash.diff text/plain 5153 cgarcia ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQyL0NoYW5nZUxvZyBiL1NvdXJjZS9XZWJLaXQyL0No YW5nZUxvZwppbmRleCA4ZjVhNmZhLi5iMTNkZmEzIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViS2l0 Mi9DaGFuZ2VMb2cKKysrIGIvU291cmNlL1dlYktpdDIvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMzQg QEAKKzIwMTItMDktMjcgIENhcmxvcyBHYXJjaWEgQ2FtcG9zICA8Y2dhcmNpYUBpZ2FsaWEuY29t PgorCisgICAgICAgIFtXSzJdW1NPVVBdIEFzc2VydGlvbiBoaXQgaW4gV2ViS2l0OjpEb3dubG9h ZE1hbmFnZXI6OmRvd25sb2FkRmluaXNoZWQoKSB3aGVuIGRvd25sb2FkIGZhaWxzCisgICAgICAg IGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD05NzU2NQorCisgICAgICAg IFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIE1ha2Ugc3VyZSB0byBub3Rp ZnkgdGhlIGRvd25sYW9kIGNsaWVudCB0aGF0IHRoZSByZXNwb25zZSBoYXMgYmVlbgorICAgICAg ICByZWNlaXZlZCB3aGVuIHRoZSBuZXdseSBjcmVhdGVkIGRvd25sb2FkIGhhcyBhbHJlYWR5IGJl ZW4gYWRkZWQgdG8KKyAgICAgICAgdGhlIERvd25sb2FkTWFuYWdlciBkb3dubG9hZHMgbWFwLgor CisgICAgICAgICogV2ViUHJvY2Vzcy9Eb3dubG9hZHMvc291cC9Eb3dubG9hZFNvdXAuY3BwOgor ICAgICAgICAoV2ViS2l0OjpEb3dubG9hZENsaWVudDo6RG93bmxvYWRDbGllbnQpOiBJbml0aWFs aXplCisgICAgICAgIG1faGFuZGxlUmVzcG9uc2VMYXRlcklELgorICAgICAgICAoV2ViS2l0OjpE b3dubG9hZENsaWVudDo6fkRvd25sb2FkQ2xpZW50KTogUmVtb3ZlIHRoZSBzb3VyY2UgZm9yCisg ICAgICAgIHRoZSBkZWxheWVkIHJlc3BvbnNlIG5vdGlmaWNhdGlvbiBpZiBpdCBoYXNuJ3QgYmVl biB0cmlnZ2VyZWQuCisgICAgICAgIChXZWJLaXQ6OkRvd25sb2FkQ2xpZW50OjpkaWRSZWNlaXZl RGF0YSk6IElmIHJlc3BvbnNlIGhhc24ndCBiZWVuCisgICAgICAgIGhhbmRsZWQgeWV0LCByZW1v dmUgdGhlIHNvdXJjZSBmb3IgdGhlIGRlbGF5ZWQgcmVzcG9uc2UKKyAgICAgICAgbm90aWZpY2F0 aW9uIGFuZCBoYW5kbGUgdGhlIHJlc291cmNlIGJlZm9yZSBzdGFydCB3cml0aW5nIHRoZSBkYXRh CisgICAgICAgIHJlY2VpdmVkIHRvIHRoZSBvdXRwdXQgc3RyZWFtLgorICAgICAgICAoV2ViS2l0 OjpEb3dubG9hZENsaWVudDo6aGFuZGxlUmVzcG9uc2UpOiBDYWxsCisgICAgICAgIGRpZFJlY2Vp dmVSZXNwb25zZSgpIHdpdGggdGhlIGRlbGF5ZWQgcmVzcG9uc2UuCisgICAgICAgIChXZWJLaXQ6 OkRvd25sb2FkQ2xpZW50OjpoYW5kbGVSZXNwb25zZUxhdGVyQ2FsbGJhY2spOiBDYWxsCisgICAg ICAgIGhhbmRsZVJlc3BvbnNlKCkuCisgICAgICAgIChXZWJLaXQ6OkRvd25sb2FkQ2xpZW50Ojpo YW5kbGVSZXNwb25zZUxhdGVyKTogU2NoZWR1bGUgYW4gaWRsZQorICAgICAgICBjYWxsYmFjayB0 byBoYW5kbGUgdGhlIHJlc3BvbnNlIGxhdGVyLCB0byBtYWtlIHN1cmUgdGhlIGRvd25sb2FkCisg ICAgICAgIGhhcyBiZWVuIGFkZGVkIHRvIHRoZSBkb3dubG9hZHMgbWFwLgorICAgICAgICAoV2Vi S2l0OjpEb3dubG9hZDo6c3RhcnRXaXRoSGFuZGxlKTogQ2FsbCBoYW5kbGVSZXNwb25zZUxhdGVy KCkKKyAgICAgICAgd2l0aCB0aGUgZ2l2ZW4gcmVzcG9uc2UgdG8gaGFuZGxlIHRoZSByZXNwb25z ZSB3aGVuIHRoZSBkb3dubG9hZAorICAgICAgICBoYXMgYmVlbiBhZGRlZCB0byB0aGUgZG93bmxv YWRzIG1hcC4KKwogMjAxMi0wOS0yNiAgU2FtIFdlaW5pZyAgPHNhbUB3ZWJraXQub3JnPgogCiAg ICAgICAgIEZpeCBYUENTZXJ2aWNlcyBzeW1saW5rIHRvIG5vdCBiZSB0byBhbiBhYnNvbHV0ZSBw YXRoCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0Mi9XZWJQcm9jZXNzL0Rvd25sb2Fkcy9zb3Vw L0Rvd25sb2FkU291cC5jcHAgYi9Tb3VyY2UvV2ViS2l0Mi9XZWJQcm9jZXNzL0Rvd25sb2Fkcy9z b3VwL0Rvd25sb2FkU291cC5jcHAKaW5kZXggMzgxMTdlYi4uNmM0MjNmMSAxMDA2NDQKLS0tIGEv U291cmNlL1dlYktpdDIvV2ViUHJvY2Vzcy9Eb3dubG9hZHMvc291cC9Eb3dubG9hZFNvdXAuY3Bw CisrKyBiL1NvdXJjZS9XZWJLaXQyL1dlYlByb2Nlc3MvRG93bmxvYWRzL3NvdXAvRG93bmxvYWRT b3VwLmNwcApAQCAtNDksOSArNDksMTYgQEAgY2xhc3MgRG93bmxvYWRDbGllbnQgOiBwdWJsaWMg UmVzb3VyY2VIYW5kbGVDbGllbnQgewogcHVibGljOgogICAgIERvd25sb2FkQ2xpZW50KERvd25s b2FkKiBkb3dubG9hZCkKICAgICAgICAgOiBtX2Rvd25sb2FkKGRvd25sb2FkKQorICAgICAgICAs IG1faGFuZGxlUmVzcG9uc2VMYXRlcklEKDApCiAgICAgewogICAgIH0KIAorICAgIH5Eb3dubG9h ZENsaWVudCgpCisgICAgeworICAgICAgICBpZiAobV9oYW5kbGVSZXNwb25zZUxhdGVySUQpCisg ICAgICAgICAgICBnX3NvdXJjZV9yZW1vdmUobV9oYW5kbGVSZXNwb25zZUxhdGVySUQpOworICAg IH0KKwogICAgIHZvaWQgZG93bmxvYWRGYWlsZWQoY29uc3QgUmVzb3VyY2VFcnJvciYgZXJyb3Ip CiAgICAgewogICAgICAgICBtX2Rvd25sb2FkLT5kaWRGYWlsKGVycm9yLCBDb3JlSVBDOjpEYXRh UmVmZXJlbmNlKCkpOwpAQCAtMTAxLDYgKzEwOCwxMSBAQCBwdWJsaWM6CiAKICAgICB2b2lkIGRp ZFJlY2VpdmVEYXRhKFJlc291cmNlSGFuZGxlKiwgY29uc3QgY2hhciogZGF0YSwgaW50IGxlbmd0 aCwgaW50IC8qZW5jb2RlZERhdGFMZW5ndGgqLykKICAgICB7CisgICAgICAgIGlmIChtX2hhbmRs ZVJlc3BvbnNlTGF0ZXJJRCkgeworICAgICAgICAgICAgZ19zb3VyY2VfcmVtb3ZlKG1faGFuZGxl UmVzcG9uc2VMYXRlcklEKTsKKyAgICAgICAgICAgIGhhbmRsZVJlc3BvbnNlKCk7CisgICAgICAg IH0KKwogICAgICAgICBnc2l6ZSBieXRlc1dyaXR0ZW47CiAgICAgICAgIEdPd25QdHI8R0Vycm9y PiBlcnJvcjsKICAgICAgICAgZ19vdXRwdXRfc3RyZWFtX3dyaXRlX2FsbChHX09VVFBVVF9TVFJF QU0obV9vdXRwdXRTdHJlYW0uZ2V0KCkpLCBkYXRhLCBsZW5ndGgsICZieXRlc1dyaXR0ZW4sIDAs ICZlcnJvci5vdXRQdHIoKSk7CkBAIC0xMzIsOSArMTQ0LDM1IEBAIHB1YmxpYzoKICAgICAgICAg bm90SW1wbGVtZW50ZWQoKTsKICAgICB9CiAKKyAgICB2b2lkIGhhbmRsZVJlc3BvbnNlKCkKKyAg ICB7CisgICAgICAgIG1faGFuZGxlUmVzcG9uc2VMYXRlcklEID0gMDsKKyAgICAgICAgZGlkUmVj ZWl2ZVJlc3BvbnNlKDAsIG1fZGVsYXllZFJlc3BvbnNlKTsKKyAgICB9CisKKyAgICBzdGF0aWMg Z2Jvb2xlYW4gaGFuZGxlUmVzcG9uc2VMYXRlckNhbGxiYWNrKERvd25sb2FkQ2xpZW50KiBkb3du bG9hZENsaWVudCkKKyAgICB7CisgICAgICAgIGRvd25sb2FkQ2xpZW50LT5oYW5kbGVSZXNwb25z ZSgpOworICAgICAgICByZXR1cm4gRkFMU0U7CisgICAgfQorCisgICAgdm9pZCBoYW5kbGVSZXNw b25zZUxhdGVyKGNvbnN0IFJlc291cmNlUmVzcG9uc2UmIHJlc3BvbnNlKQorICAgIHsKKyAgICAg ICAgQVNTRVJUKCFtX3Jlc3BvbnNlKTsKKyAgICAgICAgQVNTRVJUKCFtX2hhbmRsZVJlc3BvbnNl TGF0ZXJJRCk7CisKKyAgICAgICAgbV9kZWxheWVkUmVzcG9uc2UgPSByZXNwb25zZTsKKworICAg ICAgICAvLyBDYWxsIGRpZFJlY2VpdmVSZXNwb25zZSBpbiBhbiBpZGxlIHRvIG1ha2Ugc3VyZSB0 aGUgZG93bmxvYWQgaXMgYWRkZWQKKyAgICAgICAgLy8gdG8gdGhlIERvd25sb2FkTWFuYWdlciBk b3dubG9hZHMgbWFwLgorICAgICAgICBtX2hhbmRsZVJlc3BvbnNlTGF0ZXJJRCA9IGdfaWRsZV9h ZGRfZnVsbChHX1BSSU9SSVRZX0RFRkFVTFQsIHJlaW50ZXJwcmV0X2Nhc3Q8R1NvdXJjZUZ1bmM+ KGhhbmRsZVJlc3BvbnNlTGF0ZXJDYWxsYmFjayksIHRoaXMsIDApOworICAgIH0KKwogICAgIERv d25sb2FkKiBtX2Rvd25sb2FkOwogICAgIEdSZWZQdHI8R0ZpbGVPdXRwdXRTdHJlYW0+IG1fb3V0 cHV0U3RyZWFtOwogICAgIEdSZWZQdHI8U291cE1lc3NhZ2U+IG1fcmVzcG9uc2U7CisgICAgUmVz b3VyY2VSZXNwb25zZSBtX2RlbGF5ZWRSZXNwb25zZTsKKyAgICB1bnNpZ25lZCBtX2hhbmRsZVJl c3BvbnNlTGF0ZXJJRDsKIH07CiAKIHZvaWQgRG93bmxvYWQ6OnN0YXJ0KFdlYlBhZ2UqKQpAQCAt MTQ2LDcgKzE4NCw3IEBAIHZvaWQgRG93bmxvYWQ6OnN0YXJ0KFdlYlBhZ2UqKQogICAgIGRpZFN0 YXJ0KCk7CiB9CiAKLXZvaWQgRG93bmxvYWQ6OnN0YXJ0V2l0aEhhbmRsZShXZWJQYWdlKiwgUmVz b3VyY2VIYW5kbGUqIHJlc291cmNlSGFuZGxlLCBjb25zdCBSZXNvdXJjZVJlc3BvbnNlJikKK3Zv aWQgRG93bmxvYWQ6OnN0YXJ0V2l0aEhhbmRsZShXZWJQYWdlKiwgUmVzb3VyY2VIYW5kbGUqIHJl c291cmNlSGFuZGxlLCBjb25zdCBSZXNvdXJjZVJlc3BvbnNlJiByZXNwb25zZSkKIHsKICAgICBB U1NFUlQoIW1fZG93bmxvYWRDbGllbnQpOwogICAgIEFTU0VSVCghbV9yZXNvdXJjZUhhbmRsZSk7 CkBAIC0xNTQsMTAgKzE5Miw3IEBAIHZvaWQgRG93bmxvYWQ6OnN0YXJ0V2l0aEhhbmRsZShXZWJQ YWdlKiwgUmVzb3VyY2VIYW5kbGUqIHJlc291cmNlSGFuZGxlLCBjb25zdCBSCiAgICAgcmVzb3Vy Y2VIYW5kbGUtPnNldENsaWVudChtX2Rvd25sb2FkQ2xpZW50LmdldCgpKTsKICAgICBtX3Jlc291 cmNlSGFuZGxlID0gcmVzb3VyY2VIYW5kbGU7CiAgICAgZGlkU3RhcnQoKTsKLSAgICAvLyBJZiB0 aGUgaGFuZGxlIGFscmVhZHkgZ290IGEgcmVzcG9uc2UsIG1ha2Ugc3VyZSB0aGUgZG93bmxvYWQg Y2xpZW50IGlzIG5vdGlmaWVkLgotICAgIFJlc291cmNlSGFuZGxlSW50ZXJuYWwqIGhhbmRsZUlu dGVybmFsID0gbV9yZXNvdXJjZUhhbmRsZS0+Z2V0SW50ZXJuYWwoKTsKLSAgICBpZiAoIWhhbmRs ZUludGVybmFsLT5tX3Jlc3BvbnNlLmlzTnVsbCgpKQotICAgICAgICBtX2Rvd25sb2FkQ2xpZW50 LT5kaWRSZWNlaXZlUmVzcG9uc2UobV9yZXNvdXJjZUhhbmRsZS5nZXQoKSwgaGFuZGxlSW50ZXJu YWwtPm1fcmVzcG9uc2UpOworICAgIHN0YXRpY19jYXN0PERvd25sb2FkQ2xpZW50Kj4obV9kb3du bG9hZENsaWVudC5nZXQoKSktPmhhbmRsZVJlc3BvbnNlTGF0ZXIocmVzcG9uc2UpOwogfQogCiB2 b2lkIERvd25sb2FkOjpjYW5jZWwoKQo=