31227 2009-11-07 10:16:51 -0800 Web site is stuck loading forever 2010-03-29 02:06:16 -0700 1 1 1 Unclassified WebKit Page Loading 528+ (Nightly build) All All RESOLVED FIXED http://www.parentsdanslesparages.com/ P2 Normal --- 1 dglazkov dglazkov hamaji hayato hyatt koivisto ojan sam oldest_to_newest 161358 0 dglazkov 2009-11-07 10:16:51 -0800 There's this cute web site that gets stuck loading forever in WebKit -- unless you click on it. The symptoms are: 1) go to http://www.parentsdanslesparages.com/ 2) witness the page being stuck in loading, painting white emptiness. 3) click on the page. 4) observe page loading What happens here is that the HTMLTokenizer::continueProcessing (http://trac.webkit.org/browser/trunk/WebCore/html/HTMLTokenizer.cpp#L1597) falls through without setting a timer to process another chunk of data, but there's nothing that picks up the processing. So we're stuck until you try to focus or trigger a hit test on the page, thus restarting processing cycle. 188089 1 hayato 2010-02-04 23:25:28 -0800 I can reproduce the issue in the following simple html: <!DOCTYPE html> <html> <head> <title>Stall Test</title> <script type="text/javascript"> //<![CDATA[ for (var i = 0; i < 10; ++i) { var req = new window.XMLHttpRequest(); req.open("GET", "hello.txt"); req.send(); } //]]> </script> </head> <body> <script type="text/javascript" src="./after.js"></script> <div>Finished</div> </body> </html> The point is that requesting a lot of XMLHTTPRequests, and then tring to load a JS file (after.js) after that. I guess the root cause exists in WebCore::Loader. Please take a look at Loader::Host::servePendingRequests: http://trac.webkit.org/browser/trunk/WebCore/loader/loader.cpp#L312 void Loader::Host::servePendingRequests(RequestQueue& requestsPending, bool& serveLowerPriority) { while (!requestsPending.isEmpty()) { ..... bool shouldLimitRequests = !m_name.isNull() || docLoader->doc()->parsing() || !docLoader->doc()->haveStylesheetsLoaded(); if (shouldLimitRequests && m_requestsLoading.size() + m_nonCachedRequestsInFlight >= m_maxRequestsInFlight) { serveLowerPriority = false; return; } Here, the Loader::Host finds that theare are a number of pending XHRs (=10) beyond the threshold (m_maxRequestsInFlight(=4)) and gives up servePendingRequests, which includes a request for loading 'after.js'. It seems that the loader gives up here *WITHOUT* putting another callback function (Loader::requestTimerFired) to timerHeap() (threadGlobalData().threadTimers().timerHeap()). So Loader::requestTimerFired won't be called again, and 'after.js' won't be loaded. As a result, HTMLTokenizer has a pending src (m_pendingSrc = "<div>Finished<div></body></html>" and it remains to be unprocessed. If loading 'after.js' were finished, it calls HTMLTokenizer::executeExternalScriptIfReady, and it calls HTMLTokenizer::write. But it is not the case. I am now thinking how to fix the issue. Please let me know if you guys have a nice idea to fix the issue. 188192 2 48235 hayato 2010-02-05 08:49:32 -0800 Created attachment 48235 fix-forever-page-loading 188197 3 48235 darin 2010-02-05 09:20:27 -0800 Comment on attachment 48235 fix-forever-page-loading Fix looks great. Thanks for tackling it. We require test cases for bug fixes. So this patch will need either a test case for the LayoutTests directory -- presumably it would be one of the http tests -- or an explanation of how we tried and were unable to make an automated test case and a manual test case of some sort. review- because of the lack of a test case 188576 4 48322 hayato 2010-02-07 23:28:59 -0800 Created attachment 48322 fix-forever-page-loading-with-test 188578 5 hayato 2010-02-07 23:31:50 -0800 Thank you for the review. I added a http test. Could you review it? (In reply to comment #3) > (From update of attachment 48235 [details]) > Fix looks great. Thanks for tackling it. > > We require test cases for bug fixes. > > So this patch will need either a test case for the LayoutTests directory -- > presumably it would be one of the http tests -- or an explanation of how we > tried and were unable to make an automated test case and a manual test case of > some sort. > > review- because of the lack of a test case 188666 6 48322 hayato 2010-02-08 10:03:34 -0800 Comment on attachment 48322 fix-forever-page-loading-with-test >diff --git a/LayoutTests/ChangeLog b/LayoutTests/ChangeLog >index a514359..5c266f3 100644 >--- a/LayoutTests/ChangeLog >+++ b/LayoutTests/ChangeLog >@@ -1,3 +1,17 @@ >+2010-02-07 Hayato Ito <hayato@chromium.org> >+ >+ Reviewed by NOBODY (OOPS!). >+ >+ Schedule a loading request when there are many in-flight requests beyond >+ the limit to avoid forever page loading. >+ >+ https://bugs.webkit.org/show_bug.cgi?id=31227 >+ >+ * http/tests/loading/load-javascript-after-many-xhrs-expected.txt: Added. >+ * http/tests/loading/load-javascript-after-many-xhrs.html: Added. >+ * http/tests/loading/resources/zero-length.js: Added. >+ * http/tests/loading/resources/zero-length.txt: Added. >+ > 2010-01-31 Kent Tamura <tkent@chromium.org> > > Reviewed by Darin Adler. >diff --git a/LayoutTests/http/tests/loading/load-javascript-after-many-xhrs-expected.txt b/LayoutTests/http/tests/loading/load-javascript-after-many-xhrs-expected.txt >new file mode 100644 >index 0000000..24597fe >--- /dev/null >+++ b/LayoutTests/http/tests/loading/load-javascript-after-many-xhrs-expected.txt >@@ -0,0 +1,6 @@ >+main frame - didStartProvisionalLoadForFrame >+main frame - didCommitLoadForFrame >+main frame - didFinishDocumentLoadForFrame >+main frame - didHandleOnloadEventsForFrame >+main frame - didFinishLoadForFrame >+Test for https://bugs.webkit.org/show_bug.cgi?id=31227. If it didn't crash, the browser passed the test. >diff --git a/LayoutTests/http/tests/loading/load-javascript-after-many-xhrs.html b/LayoutTests/http/tests/loading/load-javascript-after-many-xhrs.html >new file mode 100644 >index 0000000..1a2d474 >--- /dev/null >+++ b/LayoutTests/http/tests/loading/load-javascript-after-many-xhrs.html >@@ -0,0 +1,21 @@ >+<!DOCTYPE html> >+<html> >+<head> >+<script type="text/javascript"> >+for (var i = 0; i < 10; ++i) { >+ var req = new window.XMLHttpRequest(); >+ req.open("GET", "resources/zero-length.txt"); >+ req.send(); >+} >+</script> >+<script> >+if (window.layoutTestController) >+ layoutTestController.dumpAsText(); >+</script> >+</head> >+<body> >+<script type="text/javascript" src="resources/zero-length.js"></script> >+Test for <a href="https://bugs.webkit.org/show_bug.cgi?id=31227">https://bugs.webkit.org/show_bug.cgi?id=31227</a>. >+If it didn't crash, the browser passed the test. >+</body> >+</html> >diff --git a/LayoutTests/http/tests/loading/resources/zero-length.js b/LayoutTests/http/tests/loading/resources/zero-length.js >new file mode 100644 >index 0000000..e69de29 >diff --git a/LayoutTests/http/tests/loading/resources/zero-length.txt b/LayoutTests/http/tests/loading/resources/zero-length.txt >new file mode 100644 >index 0000000..e69de29 >diff --git a/WebCore/ChangeLog b/WebCore/ChangeLog >index f2e6b80..cdd3c5c 100644 >--- a/WebCore/ChangeLog >+++ b/WebCore/ChangeLog >@@ -1,3 +1,17 @@ >+2010-02-07 Hayato Ito <hayato@chromium.org> >+ >+ Reviewed by NOBODY (OOPS!). >+ >+ Schedule a loading request when there are many in-flight requests beyond >+ the limit to avoid forever page loading. >+ >+ https://bugs.webkit.org/show_bug.cgi?id=31227 >+ >+ Test: http/tests/loading/load-javascript-after-many-xhrs.html >+ >+ * loader/loader.cpp: >+ (WebCore::Loader::Host::servePendingRequests): >+ > 2010-01-31 Kent Tamura <tkent@chromium.org> > > Unreviewed. Revert r54112 and r54124 because of Windows build error. >diff --git a/WebCore/loader/loader.cpp b/WebCore/loader/loader.cpp >index d693341..4d2b474 100644 >--- a/WebCore/loader/loader.cpp >+++ b/WebCore/loader/loader.cpp >@@ -322,6 +322,7 @@ void Loader::Host::servePendingRequests(RequestQueue& requestsPending, bool& ser > bool shouldLimitRequests = !m_name.isNull() || docLoader->doc()->parsing() || !docLoader->doc()->haveStylesheetsLoaded(); > if (shouldLimitRequests && m_requestsLoading.size() + m_nonCachedRequestsInFlight >= m_maxRequestsInFlight) { > serveLowerPriority = false; >+ cache()->loader()->scheduleServePendingRequests(); > return; > } > requestsPending.removeFirst(); 188670 7 hayato 2010-02-08 10:11:59 -0800 Hmm.. Every bot's result colors are purple. It seems svn-apply doesn't work for a patch generated by git if a patch contains new empty file, isn't it? If commit-queue can't process the patch I attached, I'll make a patch using 'svn' instead of 'git'. I'll update the patch in a day. 188677 8 hamaji 2010-02-08 10:24:18 -0800 (In reply to comment #7) > Hmm.. Every bot's result colors are purple. > It seems svn-apply doesn't work for a patch generated by git if a patch > contains new empty file, isn't it? > > If commit-queue can't process the patch I attached, I'll make a patch using > 'svn' instead of 'git'. I'll update the patch in a day. I think your guess is correct. You don't need to update your patch - I'll manually land this patch tomorrow (or, you may be able to ask other committers to land). 188683 9 dglazkov 2010-02-08 10:35:02 -0800 I just wanted to say that you guys rock! 188797 10 48322 eric 2010-02-08 15:25:38 -0800 Comment on attachment 48322 fix-forever-page-loading-with-test Given that all of the EWS bubbles show purple for this, that would suggest the commit-queue won't be able to process this. 188886 11 hayato 2010-02-08 21:05:55 -0800 Thank you, hamaji-san. Could you land it? The issue that 'svn-apply' doesn't work here is already filed at https://bugs.webkit.org/show_bug.cgi?id=29684 (In reply to comment #8) > (In reply to comment #7) > > Hmm.. Every bot's result colors are purple. > > It seems svn-apply doesn't work for a patch generated by git if a patch > > contains new empty file, isn't it? > > > > If commit-queue can't process the patch I attached, I'll make a patch using > > 'svn' instead of 'git'. I'll update the patch in a day. > > I think your guess is correct. You don't need to update your patch - I'll > manually land this patch tomorrow (or, you may be able to ask other committers > to land). 188899 12 hamaji 2010-02-08 22:17:19 -0800 Committed r54526: <http://trac.webkit.org/changeset/54526> 188911 13 hamaji 2010-02-08 23:15:31 -0800 Committed r54529: <http://trac.webkit.org/changeset/54529> 188912 14 hamaji 2010-02-08 23:17:24 -0800 (In reply to comment #13) > Committed r54529: <http://trac.webkit.org/changeset/54529> This was an unreviewed attempt to make gtk bot green. The failure: http://build.webkit.org/results/GTK%20Linux%2032-bit%20Debug/r54527%20(3057)/http/tests/loading/ I think Bug 32170 is fixing this issue. 205343 15 koivisto 2010-03-29 02:06:16 -0700 This patch introduces a timer restart loop that makes CPU peak at 100% during loading. requestTimerFired() -> servePendingRequests() -> scheduleServePendingRequests() and repeat Bug 36703 48235 2010-02-05 08:49:32 -0800 2010-02-07 23:28:52 -0800 fix-forever-page-loading bug-31227-20100206014930.patch text/plain 1318 hayato ZGlmZiAtLWdpdCBhL1dlYkNvcmUvQ2hhbmdlTG9nIGIvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXgg ZjJlNmI4MC4uZWI3NTE2NCAxMDA2NDQKLS0tIGEvV2ViQ29yZS9DaGFuZ2VMb2cKKysrIGIvV2Vi Q29yZS9DaGFuZ2VMb2cKQEAgLTEsMyArMSwxMyBAQAorMjAxMC0wMi0wNSAgSGF5YXRvIEl0byAg PGhheWF0b0BjaHJvbWl1bS5vcmc+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BT ISkuCisKKyAgICAgICAgU2NoZWR1bGUgYSBsb2FkaW5nIHJlcXVlc3Qgd2hlbiB0aGVyZSBhcmUg bWFueSBpbi1mbGlnaHQgcmVxdWVzdHMgYmV5b25kIHRoZSBsaW1pdCB0byBhdm9pZCBmb3JldmVy IHBhZ2UgbG9hZGluZy4KKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcu Y2dpP2lkPTMxMjI3CisKKyAgICAgICAgKiBsb2FkZXIvbG9hZGVyLmNwcDoKKyAgICAgICAgKFdl YkNvcmU6OkxvYWRlcjo6SG9zdDo6c2VydmVQZW5kaW5nUmVxdWVzdHMpOgorCiAyMDEwLTAxLTMx ICBLZW50IFRhbXVyYSAgPHRrZW50QGNocm9taXVtLm9yZz4KIAogICAgICAgICBVbnJldmlld2Vk LiBSZXZlcnQgcjU0MTEyIGFuZCByNTQxMjQgYmVjYXVzZSBvZiBXaW5kb3dzIGJ1aWxkIGVycm9y LgpkaWZmIC0tZ2l0IGEvV2ViQ29yZS9sb2FkZXIvbG9hZGVyLmNwcCBiL1dlYkNvcmUvbG9hZGVy L2xvYWRlci5jcHAKaW5kZXggZDY5MzM0MS4uNGQyYjQ3NCAxMDA2NDQKLS0tIGEvV2ViQ29yZS9s b2FkZXIvbG9hZGVyLmNwcAorKysgYi9XZWJDb3JlL2xvYWRlci9sb2FkZXIuY3BwCkBAIC0zMjIs NiArMzIyLDcgQEAgdm9pZCBMb2FkZXI6Okhvc3Q6OnNlcnZlUGVuZGluZ1JlcXVlc3RzKFJlcXVl c3RRdWV1ZSYgcmVxdWVzdHNQZW5kaW5nLCBib29sJiBzZXIKICAgICAgICAgYm9vbCBzaG91bGRM aW1pdFJlcXVlc3RzID0gIW1fbmFtZS5pc051bGwoKSB8fCBkb2NMb2FkZXItPmRvYygpLT5wYXJz aW5nKCkgfHwgIWRvY0xvYWRlci0+ZG9jKCktPmhhdmVTdHlsZXNoZWV0c0xvYWRlZCgpOwogICAg ICAgICBpZiAoc2hvdWxkTGltaXRSZXF1ZXN0cyAmJiBtX3JlcXVlc3RzTG9hZGluZy5zaXplKCkg KyBtX25vbkNhY2hlZFJlcXVlc3RzSW5GbGlnaHQgPj0gbV9tYXhSZXF1ZXN0c0luRmxpZ2h0KSB7 CiAgICAgICAgICAgICBzZXJ2ZUxvd2VyUHJpb3JpdHkgPSBmYWxzZTsKKyAgICAgICAgICAgIGNh Y2hlKCktPmxvYWRlcigpLT5zY2hlZHVsZVNlcnZlUGVuZGluZ1JlcXVlc3RzKCk7CiAgICAgICAg ICAgICByZXR1cm47CiAgICAgICAgIH0KICAgICAgICAgcmVxdWVzdHNQZW5kaW5nLnJlbW92ZUZp cnN0KCk7Cg== 48322 2010-02-07 23:28:59 -0800 2010-02-08 15:25:38 -0800 fix-forever-page-loading-with-test bug-31227-20100208162857.patch text/plain 4083 hayato ZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL0NoYW5nZUxvZyBiL0xheW91dFRlc3RzL0NoYW5nZUxv ZwppbmRleCBhNTE0MzU5Li41YzI2NmYzIDEwMDY0NAotLS0gYS9MYXlvdXRUZXN0cy9DaGFuZ2VM b2cKKysrIGIvTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTcgQEAKKzIwMTAtMDIt MDcgIEhheWF0byBJdG8gIDxoYXlhdG9AY2hyb21pdW0ub3JnPgorCisgICAgICAgIFJldmlld2Vk IGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIFNjaGVkdWxlIGEgbG9hZGluZyByZXF1ZXN0 IHdoZW4gdGhlcmUgYXJlIG1hbnkgaW4tZmxpZ2h0IHJlcXVlc3RzIGJleW9uZAorICAgICAgICB0 aGUgbGltaXQgdG8gYXZvaWQgZm9yZXZlciBwYWdlIGxvYWRpbmcuCisKKyAgICAgICAgaHR0cHM6 Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTMxMjI3CisKKyAgICAgICAgKiBodHRw L3Rlc3RzL2xvYWRpbmcvbG9hZC1qYXZhc2NyaXB0LWFmdGVyLW1hbnkteGhycy1leHBlY3RlZC50 eHQ6IEFkZGVkLgorICAgICAgICAqIGh0dHAvdGVzdHMvbG9hZGluZy9sb2FkLWphdmFzY3JpcHQt YWZ0ZXItbWFueS14aHJzLmh0bWw6IEFkZGVkLgorICAgICAgICAqIGh0dHAvdGVzdHMvbG9hZGlu Zy9yZXNvdXJjZXMvemVyby1sZW5ndGguanM6IEFkZGVkLgorICAgICAgICAqIGh0dHAvdGVzdHMv bG9hZGluZy9yZXNvdXJjZXMvemVyby1sZW5ndGgudHh0OiBBZGRlZC4KKwogMjAxMC0wMS0zMSAg S2VudCBUYW11cmEgIDx0a2VudEBjaHJvbWl1bS5vcmc+CiAKICAgICAgICAgUmV2aWV3ZWQgYnkg RGFyaW4gQWRsZXIuCmRpZmYgLS1naXQgYS9MYXlvdXRUZXN0cy9odHRwL3Rlc3RzL2xvYWRpbmcv bG9hZC1qYXZhc2NyaXB0LWFmdGVyLW1hbnkteGhycy1leHBlY3RlZC50eHQgYi9MYXlvdXRUZXN0 cy9odHRwL3Rlc3RzL2xvYWRpbmcvbG9hZC1qYXZhc2NyaXB0LWFmdGVyLW1hbnkteGhycy1leHBl Y3RlZC50eHQKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uMjQ1OTdmZQotLS0g L2Rldi9udWxsCisrKyBiL0xheW91dFRlc3RzL2h0dHAvdGVzdHMvbG9hZGluZy9sb2FkLWphdmFz Y3JpcHQtYWZ0ZXItbWFueS14aHJzLWV4cGVjdGVkLnR4dApAQCAtMCwwICsxLDYgQEAKK21haW4g ZnJhbWUgLSBkaWRTdGFydFByb3Zpc2lvbmFsTG9hZEZvckZyYW1lCittYWluIGZyYW1lIC0gZGlk Q29tbWl0TG9hZEZvckZyYW1lCittYWluIGZyYW1lIC0gZGlkRmluaXNoRG9jdW1lbnRMb2FkRm9y RnJhbWUKK21haW4gZnJhbWUgLSBkaWRIYW5kbGVPbmxvYWRFdmVudHNGb3JGcmFtZQorbWFpbiBm cmFtZSAtIGRpZEZpbmlzaExvYWRGb3JGcmFtZQorVGVzdCBmb3IgaHR0cHM6Ly9idWdzLndlYmtp dC5vcmcvc2hvd19idWcuY2dpP2lkPTMxMjI3LiBJZiBpdCBkaWRuJ3QgY3Jhc2gsIHRoZSBicm93 c2VyIHBhc3NlZCB0aGUgdGVzdC4KZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL2h0dHAvdGVzdHMv bG9hZGluZy9sb2FkLWphdmFzY3JpcHQtYWZ0ZXItbWFueS14aHJzLmh0bWwgYi9MYXlvdXRUZXN0 cy9odHRwL3Rlc3RzL2xvYWRpbmcvbG9hZC1qYXZhc2NyaXB0LWFmdGVyLW1hbnkteGhycy5odG1s Cm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjFhMmQ0NzQKLS0tIC9kZXYvbnVs bAorKysgYi9MYXlvdXRUZXN0cy9odHRwL3Rlc3RzL2xvYWRpbmcvbG9hZC1qYXZhc2NyaXB0LWFm dGVyLW1hbnkteGhycy5odG1sCkBAIC0wLDAgKzEsMjEgQEAKKzwhRE9DVFlQRSBodG1sPgorPGh0 bWw+Cis8aGVhZD4KKzxzY3JpcHQgdHlwZT0idGV4dC9qYXZhc2NyaXB0Ij4KK2ZvciAodmFyIGkg PSAwOyBpIDwgMTA7ICsraSkgeworICAgdmFyIHJlcSA9IG5ldyB3aW5kb3cuWE1MSHR0cFJlcXVl c3QoKTsKKyAgIHJlcS5vcGVuKCJHRVQiLCAicmVzb3VyY2VzL3plcm8tbGVuZ3RoLnR4dCIpOwor ICAgcmVxLnNlbmQoKTsKK30KKzwvc2NyaXB0PgorPHNjcmlwdD4KK2lmICh3aW5kb3cubGF5b3V0 VGVzdENvbnRyb2xsZXIpCisgICAgbGF5b3V0VGVzdENvbnRyb2xsZXIuZHVtcEFzVGV4dCgpOwor PC9zY3JpcHQ+Cis8L2hlYWQ+Cis8Ym9keT4KKzxzY3JpcHQgdHlwZT0idGV4dC9qYXZhc2NyaXB0 IiBzcmM9InJlc291cmNlcy96ZXJvLWxlbmd0aC5qcyI+PC9zY3JpcHQ+CitUZXN0IGZvciA8YSBo cmVmPSJodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MzEyMjciPmh0dHBz Oi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0zMTIyNzwvYT4uCitJZiBpdCBkaWRu J3QgY3Jhc2gsIHRoZSBicm93c2VyIHBhc3NlZCB0aGUgdGVzdC4KKzwvYm9keT4KKzwvaHRtbD4K ZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL2h0dHAvdGVzdHMvbG9hZGluZy9yZXNvdXJjZXMvemVy by1sZW5ndGguanMgYi9MYXlvdXRUZXN0cy9odHRwL3Rlc3RzL2xvYWRpbmcvcmVzb3VyY2VzL3pl cm8tbGVuZ3RoLmpzCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLmU2OWRlMjkK ZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL2h0dHAvdGVzdHMvbG9hZGluZy9yZXNvdXJjZXMvemVy by1sZW5ndGgudHh0IGIvTGF5b3V0VGVzdHMvaHR0cC90ZXN0cy9sb2FkaW5nL3Jlc291cmNlcy96 ZXJvLWxlbmd0aC50eHQKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uZTY5ZGUy OQpkaWZmIC0tZ2l0IGEvV2ViQ29yZS9DaGFuZ2VMb2cgYi9XZWJDb3JlL0NoYW5nZUxvZwppbmRl eCBmMmU2YjgwLi5jZGQzYzVjIDEwMDY0NAotLS0gYS9XZWJDb3JlL0NoYW5nZUxvZworKysgYi9X ZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE3IEBACisyMDEwLTAyLTA3ICBIYXlhdG8gSXRv ICA8aGF5YXRvQGNocm9taXVtLm9yZz4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9P UFMhKS4KKworICAgICAgICBTY2hlZHVsZSBhIGxvYWRpbmcgcmVxdWVzdCB3aGVuIHRoZXJlIGFy ZSBtYW55IGluLWZsaWdodCByZXF1ZXN0cyBiZXlvbmQKKyAgICAgICAgdGhlIGxpbWl0IHRvIGF2 b2lkIGZvcmV2ZXIgcGFnZSBsb2FkaW5nLgorCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQu b3JnL3Nob3dfYnVnLmNnaT9pZD0zMTIyNworCisgICAgICAgIFRlc3Q6IGh0dHAvdGVzdHMvbG9h ZGluZy9sb2FkLWphdmFzY3JpcHQtYWZ0ZXItbWFueS14aHJzLmh0bWwKKworICAgICAgICAqIGxv YWRlci9sb2FkZXIuY3BwOgorICAgICAgICAoV2ViQ29yZTo6TG9hZGVyOjpIb3N0OjpzZXJ2ZVBl bmRpbmdSZXF1ZXN0cyk6CisKIDIwMTAtMDEtMzEgIEtlbnQgVGFtdXJhICA8dGtlbnRAY2hyb21p dW0ub3JnPgogCiAgICAgICAgIFVucmV2aWV3ZWQuIFJldmVydCByNTQxMTIgYW5kIHI1NDEyNCBi ZWNhdXNlIG9mIFdpbmRvd3MgYnVpbGQgZXJyb3IuCmRpZmYgLS1naXQgYS9XZWJDb3JlL2xvYWRl ci9sb2FkZXIuY3BwIGIvV2ViQ29yZS9sb2FkZXIvbG9hZGVyLmNwcAppbmRleCBkNjkzMzQxLi40 ZDJiNDc0IDEwMDY0NAotLS0gYS9XZWJDb3JlL2xvYWRlci9sb2FkZXIuY3BwCisrKyBiL1dlYkNv cmUvbG9hZGVyL2xvYWRlci5jcHAKQEAgLTMyMiw2ICszMjIsNyBAQCB2b2lkIExvYWRlcjo6SG9z dDo6c2VydmVQZW5kaW5nUmVxdWVzdHMoUmVxdWVzdFF1ZXVlJiByZXF1ZXN0c1BlbmRpbmcsIGJv b2wmIHNlcgogICAgICAgICBib29sIHNob3VsZExpbWl0UmVxdWVzdHMgPSAhbV9uYW1lLmlzTnVs bCgpIHx8IGRvY0xvYWRlci0+ZG9jKCktPnBhcnNpbmcoKSB8fCAhZG9jTG9hZGVyLT5kb2MoKS0+ aGF2ZVN0eWxlc2hlZXRzTG9hZGVkKCk7CiAgICAgICAgIGlmIChzaG91bGRMaW1pdFJlcXVlc3Rz ICYmIG1fcmVxdWVzdHNMb2FkaW5nLnNpemUoKSArIG1fbm9uQ2FjaGVkUmVxdWVzdHNJbkZsaWdo dCA+PSBtX21heFJlcXVlc3RzSW5GbGlnaHQpIHsKICAgICAgICAgICAgIHNlcnZlTG93ZXJQcmlv cml0eSA9IGZhbHNlOworICAgICAgICAgICAgY2FjaGUoKS0+bG9hZGVyKCktPnNjaGVkdWxlU2Vy dmVQZW5kaW5nUmVxdWVzdHMoKTsKICAgICAgICAgICAgIHJldHVybjsKICAgICAgICAgfQogICAg ICAgICByZXF1ZXN0c1BlbmRpbmcucmVtb3ZlRmlyc3QoKTsK