78070 2012-02-07 19:25:48 -0800 REGRESSION: Page Cycler Moz regression from presentation attribute changes. 2013-02-16 16:13:24 -0800 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) All All RESOLVED WONTFIX P2 Normal --- 78220 78497 78590 78604 78798 78891 79195 79304 79468 80370 82816 77861 1 jchaffraix kling cmarcelo dglazkov gregsimon jchaffraix kling koivisto loislo michaeln mikelawther podivilov rniwa tony tonyg webkit.review.bot oldest_to_newest 551711 0 jchaffraix 2012-02-07 19:25:48 -0800 Using our integration bots (following WebKit and Chromium ToT) did catch up the regression but we did not hear them (not on WebKit: http://build.chromium.org/f/chromium/perf/mac-release-10.6-webkit-latest/moz/report.html?history=150&rev=-1 You can see 2 spikes (the revision number is written on the bottom left side of the graph): * first one at r120492 * second one at r120514 I have found out which one corresponds to each build: * first one -> http://build.chromium.org/p/chromium.webkit/builders/Mac10.6%20Perf/builds/6206 * second one -> http://build.chromium.org/p/chromium.webkit/builders/Mac10.6%20Perf/builds/6212 A chromium change could have regressed everything though we doubt it as rolling back WebKit removed the regression. First spike points at http://trac.webkit.org/changeset/106741. Second spike seems to point at http://trac.webkit.org/changeset/106756 (there is another change so I am not 100% sure). 552058 1 kling 2012-02-08 05:53:11 -0800 Would it be possible to get a CPU profile dump of this test? Best thing would be a way for me to run the test myself, but as I understand it that's not possible. :/ 552172 2 kling 2012-02-08 08:58:21 -0800 Is there some way you could tell me which page(s) have regressed? 552244 3 tony 2012-02-08 10:16:48 -0800 (In reply to comment #1) > Would it be possible to get a CPU profile dump of this test? Best thing would be a way for me to run the test myself, but as I understand it that's not possible. :/ I've sent you an email with the page cycler data. 552812 4 kling 2012-02-08 20:43:38 -0800 (In reply to comment #3) > (In reply to comment #1) > > Would it be possible to get a CPU profile dump of this test? Best thing would be a way for me to run the test myself, but as I understand it that's not possible. :/ > > I've sent you an email with the page cycler data. Thanks a lot Tony. Using the data, I came up with the patch on bug 78199, which landed in <http://trac.webkit.org/changeset/107173>. I hope this fixes the regression. 553233 5 jchaffraix 2012-02-09 09:40:19 -0800 Unfortunately it doesn't seem to have helped. You can always look at the graphs on Chromium side: * Mac: http://build.chromium.org/f/chromium/perf/mac-release-10.6-webkit-latest/moz/report.html?history=150&rev=-1 * Linux: http://build.chromium.org/f/chromium/perf/linux-release-webkit-latest/moz/report.html?history=150&rev=-1 * Win Vista: http://build.chromium.org/f/chromium/perf/vista-release-webkit-latest/moz/report.html?history=150&rev=-1 Unfortunately they don't show the WebKit revisions (this has been reported) but they do follow ToT WebKit. 555040 6 kling 2012-02-12 23:19:41 -0800 FYI, I am still working on this. Landed <http://trac.webkit.org/changeset/107484> which re-enables the matched declaration cache optimizations for elements with presentation attributes. I have a few more things coming, faster style sharing rejection, bypassing CSSParser where possible, etc. If none of this helps I'm going to reinstate the cache for tagname/attrname/attrvalue -> style. 555718 7 tony 2012-02-13 16:10:59 -0800 We're continuing to get slower as patches land and it's getting harder to determine the cause. Here's the current graph: http://build.chromium.org/f/chromium/perf/vista-release-webkit-latest/moz/report.html?history=150&rev=121749 We recorded another 2% regression to the moz page cycler between r107445 and r107543: http://trac.webkit.org/log/trunk/Source?rev=107543&stop_rev=107445&verbose=on 556061 8 kling 2012-02-14 00:43:58 -0800 (In reply to comment #7) > We're continuing to get slower as patches land and it's getting harder to determine the cause. Here's the current graph: > http://build.chromium.org/f/chromium/perf/vista-release-webkit-latest/moz/report.html?history=150&rev=121749 > > We recorded another 2% regression to the moz page cycler between r107445 and r107543: http://trac.webkit.org/log/trunk/Source?rev=107543&stop_rev=107445&verbose=on Did <http://trac.webkit.org/changeset/107573> get rolled in yet? How do I know which WebKit revision the perf builder is at? 556072 9 kling 2012-02-14 01:01:30 -0800 (In reply to comment #8) > (In reply to comment #7) > > We're continuing to get slower as patches land and it's getting harder to determine the cause. Here's the current graph: > > http://build.chromium.org/f/chromium/perf/vista-release-webkit-latest/moz/report.html?history=150&rev=121749 > > > > We recorded another 2% regression to the moz page cycler between r107445 and r107543: http://trac.webkit.org/log/trunk/Source?rev=107543&stop_rev=107445&verbose=on > > Did <http://trac.webkit.org/changeset/107573> get rolled in yet? How do I know which WebKit revision the perf builder is at? Never mind, I guess this is what the "Roll webkit deps from r107561 to r107621." commits are about. :) 557371 10 tony 2012-02-15 10:32:36 -0800 loislo bisected the recent 2% perf regression and narrowed it down to http://trac.webkit.org/changeset/107484. Andreas, should we open a new bug for that regression? 561199 11 tony 2012-02-21 14:01:58 -0800 We seem to be holding steady at a 2% page cycler regression: http://build.chromium.org/f/chromium/perf/xp-release-dual-core/moz/report.html?history=400&rev=122870 561227 12 tony 2012-02-21 14:24:12 -0800 Sorry, I read the graph wrong. It's around 9.5% right now on Windows. Here's the graph: http://build.chromium.org/f/chromium/perf/xp-release-dual-core/moz/report.html?history=500&rev=122870 The first bump is the initial bug report, the second smaller bump is bug 78798. Both still exist. On Mac 10.6, it's only about 6-7%, but that's still pretty bad: http://build.chromium.org/f/chromium/perf/mac-release-10.6/moz/report.html?history=570&rev=122870 It's been 2 weeks since this bug was filed, should we consider reverting changes? 561250 13 kling 2012-02-21 14:58:31 -0800 (In reply to comment #12) > It's been 2 weeks since this bug was filed, should we consider reverting changes? Reverting these changes would be a task of unsavory proportions, and I'd prefer that we didn't resort to that. It's important to note that the content in this particular PLT is ~12 years old, and reflects a very different web where the nearly all styling is done with presentation attributes rather than CSS. To give you some idea, the largest style sheet in the test is 12 kB. That said, I do intend to make up for this regression. Much of the remaining delta is due to repeated reparsing of the same CSS values. My next step will be to introduce a String->CSSValue cache in CSSValuePool for use by presentation attributes. 569015 14 tony 2012-03-01 16:00:31 -0800 How're things progressing? It looks like we got back the 2%, but we're still a 7% regression. http://build.chromium.org/f/chromium/perf/xp-release-dual-core/moz/report.html?history=700&rev=124156 570938 15 130179 koivisto 2012-03-05 12:21:06 -0800 Created attachment 130179 possible patch 570947 16 webkit.review.bot 2012-03-05 12:31:53 -0800 Attachment 130179 did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/dom/StyledElement.cpp', u'S..." exit_code: 1 Source/WebCore/dom/StyledElement.cpp:52: This { should be at the end of the previous line [whitespace/braces] [4] Source/WebCore/dom/StyledElement.cpp:85: Place brace on its own line for function definitions. [whitespace/braces] [4] Total errors found: 2 in 2 files If any of these errors are false positives, please file a bug against check-webkit-style. 570982 17 130179 webkit-ews 2012-03-05 13:08:54 -0800 Comment on attachment 130179 possible patch Attachment 130179 did not pass qt-ews (qt): Output: http://queues.webkit.org/results/11818158 571003 18 130179 webkit.review.bot 2012-03-05 13:37:41 -0800 Comment on attachment 130179 possible patch Attachment 130179 did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/11817178 571141 19 130179 jchaffraix 2012-03-05 16:18:11 -0800 Comment on attachment 130179 possible patch View in context: https://bugs.webkit.org/attachment.cgi?id=130179&action=review I run Mozilla page cycler locally and it looks like this gives us a 1.8% increase in performance. > Source/WebCore/dom/StyledElement.cpp:246 > + PresentationAttributeCache::iterator cacheEntry; > + if (!cacheKey.isNull()) > + cacheEntry = presentationAttributeCache().add(cacheKey, 0).first; This is what makes Chromium unhappy: cacheEntry can be used later without having been properly initialized. Adding a default initialization to presentationAttributeCache().end() removes the issue. 574028 20 130179 jchaffraix 2012-03-08 11:51:37 -0800 Comment on attachment 130179 possible patch View in context: https://bugs.webkit.org/attachment.cgi?id=130179&action=review > Source/WebCore/dom/StyledElement.cpp:101 > + static PresentationAttributeCache* cache = new PresentationAttributeCache(); This could also use DEFINE_STATIC_LOCAL. >> Source/WebCore/dom/StyledElement.cpp:246 >> + cacheEntry = presentationAttributeCache().add(cacheKey, 0).first; > > This is what makes Chromium unhappy: cacheEntry can be used later without having been properly initialized. Adding a default initialization to presentationAttributeCache().end() removes the issue. It looks like there is some race conditions here and we can still do a re-hashing (causing an ASSERT in debug). I though this was because we postpone the size() check to the end of the function and that we don't properly cap the size to minimumTableSize (I think it should be >= instead of >). Patching that did not help though. Strangely enough changing our traits minimumTableSize to 255 (bad as it is not a power of 2) solves the problem. I would have to dig deeper into this to understand why. 578101 21 jchaffraix 2012-03-13 18:58:26 -0700 The situation on the bots hasn't moved since this bug was filed and it makes no sense. I could see the performance degradation on my Linux machine (a solid 2% under Chromium's DRT) and on the same setup, Antti's change brought us back to the performance level prior to r106740. The linux perf bot is very noisy which makes it hard to know if he agrees with me here. I will see if I can reproduce the situation on a Mac SL machine. 578684 22 koivisto 2012-03-14 13:04:59 -0700 Yeah, it seems to me the sum of gains from the various fixes roughly matches the original regression. The bot graphs have a general long term trend of creeping up. I wonder if the what we have now is part of that trend, a collection of unrelated smaller regressions, apparently mostly affecting windows platform. It also doesn't make sense to spend too much engineering effort on these tests. The web that they measure (all simple presentational html, no stylesheet, barely any scripts) doesn't exist anymore and we in any case load 40 of these kinds page in a second on an average laptop. 578726 23 tony 2012-03-14 13:45:45 -0700 (In reply to comment #22) > Yeah, it seems to me the sum of gains from the various fixes roughly matches the original regression. The bot graphs have a general long term trend of creeping up. I wonder if the what we have now is part of that trend, a collection of unrelated smaller regressions, apparently mostly affecting windows platform. This regression isn't Windows specific, here's the long view on the mac bot (looks like about 5% since this started): http://build.chromium.org/f/chromium/perf/mac-release-10.6-webkit-latest/moz/report.html?history=700&rev=126700 Also, because it's easy for other perf regressions to creep in, this is why it's better to roll out rather than fix in the tree over the span of weeks. > It also doesn't make sense to spend too much engineering effort on these tests. The web that they measure (all simple presentational html, no stylesheet, barely any scripts) doesn't exist anymore and we in any case load 40 of these kinds page in a second on an average laptop. There's similar regressions noticed in the intl1 and intl2 page cyclers, which are from a scrape in 2007. They're mostly pages from countries other than the US, but it's probably not that different from if we did a scrape of today's top US sites. http://build.chromium.org/f/chromium/perf/vista-release-webkit-latest/intl1/report.html?history=700&rev=126700 http://build.chromium.org/f/chromium/perf/vista-release-webkit-latest/intl2/report.html?history=700&rev=126700 Which is to say, the regression may still impact today's pages, but it's hard to tell without a page cycler or some other perf test. 587932 24 jchaffraix 2012-03-26 11:11:13 -0700 I have more info on the regression. It is related to the matched properties cache in CSSStyleSelector: * the original change (r106740) disabled matched properties caching for element with presentation attribute change. * r107484 (bug 78381) re-introduced the caching but it did not improve the hit rate. There is actually a strong correlation here: what we would not cache before just ends up not finding any entries (the numbers are very close). * other fixes have pumped up the average matched properties cache hit rate up but the case of presentation attribute change is still pathological. I don't have a good idea why bug 78381 hasn't helped here though. 604179 25 jchaffraix 2012-04-17 11:32:14 -0700 Before I forget, here are my notes on this regression as I had to move to something else: * When it comes to matched properties cache hit, there are 2 statistical populations: elements with and without presentation attributes. Element without presentation attributes have hit rate of ~60%, those with presentation attributes ~40%. * I haven't been able to find the reasons for this big difference (I have investigated the presentation attribute cache, the style sharing algorithm and the matched properties cache). * The original regression broke 2 levels of caching for presentation attributes (matched properties relies on the presentation attributes cache which was removed in r116740). Bug 80707 re-introduced the presentation attributes cache with a different design. However the new design may miss opportunities for cache hits: the old code would try to re-use CSSMappedAttributeDeclaration between different tags by using some buckets for each presentation attribute [called MappedAttributeEntry]. An early prototype of re-adding those buckets did not lead to any improvements though. * Most of the matched properties cache misses for elements with presentation attribute are for: td (51% of the records), img (22%), table (11%) and body (4%). The remaining records are below 2%. * Compared to pre-r116740, we are trying harder to cache matched properties which did help the overall cache hit rate. On intl* page cycler, our top reason for not caching is that the parent style has explicitly inherited properties (according for 38% of the records). This is likely due to table parts having borders related properties inherited by default. 610882 26 tony 2012-04-26 13:16:24 -0700 At this point, too much time has passed and no one is actively investigating. We may as well just close the bug. 834878 27 kling 2013-02-16 16:13:24 -0800 (In reply to comment #26) > At this point, too much time has passed and no one is actively investigating. We may as well just close the bug. Indeed. 130179 2012-03-05 12:21:06 -0800 2012-03-08 11:51:37 -0800 possible patch presentation-attribute-cache-2.patch text/plain 6282 koivisto SW5kZXg6IFNvdXJjZS9XZWJDb3JlL2RvbS9TdHlsZWRFbGVtZW50LmNwcAo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSBTb3VyY2UvV2ViQ29yZS9kb20vU3R5bGVkRWxlbWVudC5jcHAJKHJldmlzaW9uIDEwOTUxNikK KysrIFNvdXJjZS9XZWJDb3JlL2RvbS9TdHlsZWRFbGVtZW50LmNwcAkod29ya2luZyBjb3B5KQpA QCAtNDYsNiArNDYsNjggQEAgbmFtZXNwYWNlIFdlYkNvcmUgewogCiB1c2luZyBuYW1lc3BhY2Ug SFRNTE5hbWVzOwogCitzdGF0aWMgY29uc3QgaW50IHByZXNlbnRhdGlvbkF0dHJpYnV0ZUNhY2hl TWF4aW11bVNpemUgPSAyNTY7CisKK3N0cnVjdCBQcmVzZW50YXRpb25BdHRyaWJ1dGVDYWNoZUtl eQoreworICAgIEF0b21pY1N0cmluZ0ltcGwqIHRhZ05hbWU7CisgICAgVmVjdG9yPHBhaXI8QXRv bWljU3RyaW5nSW1wbCosIEF0b21pY1N0cmluZz4sIDM+IGF0dHJpYnV0ZXNBbmRWYWx1ZXM7Cisg ICAgCisgICAgYm9vbCBpc051bGwoKSBjb25zdCB7IHJldHVybiAhdGFnTmFtZTsgfQorfTsKKwor c3RhdGljIGJvb2wgb3BlcmF0b3I9PShjb25zdCBQcmVzZW50YXRpb25BdHRyaWJ1dGVDYWNoZUtl eSYgYSwgY29uc3QgUHJlc2VudGF0aW9uQXR0cmlidXRlQ2FjaGVLZXkmIGIpCit7CisgICAgaWYg KGEudGFnTmFtZSAhPSBiLnRhZ05hbWUpCisgICAgICAgIHJldHVybiBmYWxzZTsKKyAgICByZXR1 cm4gYS5hdHRyaWJ1dGVzQW5kVmFsdWVzID09IGIuYXR0cmlidXRlc0FuZFZhbHVlczsKK30KKwor c3RydWN0IFByZXNlbnRhdGlvbkF0dHJpYnV0ZUhhc2ggeworICAgIHN0YXRpYyBib29sIGVxdWFs KGNvbnN0IFByZXNlbnRhdGlvbkF0dHJpYnV0ZUNhY2hlS2V5JiBhLCBjb25zdCBQcmVzZW50YXRp b25BdHRyaWJ1dGVDYWNoZUtleSYgYikKKyAgICB7CisgICAgICAgIHJldHVybiBhID09IGI7Cisg ICAgfQorICAgIHN0YXRpYyB1bnNpZ25lZCBoYXNoKGNvbnN0IFByZXNlbnRhdGlvbkF0dHJpYnV0 ZUNhY2hlS2V5JiBrZXkpCisgICAgeworICAgICAgICB1bnNpZ25lZCBoID0ga2V5LnRhZ05hbWUt PmV4aXN0aW5nSGFzaCgpOworICAgICAgICBoID0gaCA8PCAxOworICAgICAgICBoIF49IFN0cmlu Z0hhc2hlcjo6aGFzaE1lbW9yeShrZXkuYXR0cmlidXRlc0FuZFZhbHVlcy5kYXRhKCksIGtleS5h dHRyaWJ1dGVzQW5kVmFsdWVzLnNpemUoKSAqIHNpemVvZihrZXkuYXR0cmlidXRlc0FuZFZhbHVl c1swXSkpOworICAgICAgICByZXR1cm4gaDsKKyAgICB9CisgICAgc3RhdGljIGNvbnN0IGJvb2wg c2FmZVRvQ29tcGFyZVRvRW1wdHlPckRlbGV0ZWQgPSB0cnVlOworfTsKKworfQorCituYW1lc3Bh Y2UgV1RGIHsKK3RlbXBsYXRlPD4gc3RydWN0IEhhc2hUcmFpdHM8V2ViQ29yZTo6UHJlc2VudGF0 aW9uQXR0cmlidXRlQ2FjaGVLZXk+IDogR2VuZXJpY0hhc2hUcmFpdHM8V2ViQ29yZTo6UHJlc2Vu dGF0aW9uQXR0cmlidXRlQ2FjaGVLZXk+IHsKKyAgICBzdGF0aWMgdm9pZCBjb25zdHJ1Y3REZWxl dGVkVmFsdWUoV2ViQ29yZTo6UHJlc2VudGF0aW9uQXR0cmlidXRlQ2FjaGVLZXkmIHNsb3QpIHsK KyAgICAgICAgbWVtc2V0KCZzbG90LCAwLCBzaXplb2Yoc2xvdCkpOworICAgICAgICBzbG90LnRh Z05hbWUgPSBzdGFyQXRvbS5pbXBsKCk7IAorICAgIH0KKyAgICBzdGF0aWMgYm9vbCBpc0RlbGV0 ZWRWYWx1ZShjb25zdCBXZWJDb3JlOjpQcmVzZW50YXRpb25BdHRyaWJ1dGVDYWNoZUtleSYgc2xv dCkgeyByZXR1cm4gc2xvdC50YWdOYW1lID09IHN0YXJBdG9tLmltcGwoKTsgfQorICAgIC8vIEF2 b2lkIHJlaGFzaGluZy4KKyAgICBzdGF0aWMgY29uc3QgaW50IG1pbmltdW1UYWJsZVNpemUgPSBX ZWJDb3JlOjpwcmVzZW50YXRpb25BdHRyaWJ1dGVDYWNoZU1heGltdW1TaXplOworfTsKK30KKwor bmFtZXNwYWNlIFdlYkNvcmUgeworICAgIAordHlwZWRlZiBIYXNoTWFwPFByZXNlbnRhdGlvbkF0 dHJpYnV0ZUNhY2hlS2V5LCBSZWZQdHI8U3R5bGVQcm9wZXJ0eVNldD4sIFByZXNlbnRhdGlvbkF0 dHJpYnV0ZUhhc2g+IFByZXNlbnRhdGlvbkF0dHJpYnV0ZUNhY2hlOworCitzdGF0aWMgUHJlc2Vu dGF0aW9uQXR0cmlidXRlQ2FjaGUmIHByZXNlbnRhdGlvbkF0dHJpYnV0ZUNhY2hlKCkKK3sKKyAg ICBzdGF0aWMgUHJlc2VudGF0aW9uQXR0cmlidXRlQ2FjaGUqIGNhY2hlID0gbmV3IFByZXNlbnRh dGlvbkF0dHJpYnV0ZUNhY2hlKCk7CisgICAgcmV0dXJuICpjYWNoZTsKK30KKworc3RhdGljIGlu bGluZSBib29sIGF0dHJpYnV0ZU5hbWVTb3J0KGNvbnN0IHBhaXI8QXRvbWljU3RyaW5nLCBBdG9t aWNTdHJpbmc+JiBwMSwgY29uc3QgcGFpcjxBdG9taWNTdHJpbmcsIEF0b21pY1N0cmluZz4mIHAy KQoreworICAgIC8vIFNvcnQgYmFzZWQgb24gdGhlIGF0dHJpYnV0ZSBuYW1lIGF0b21pYyBzdHJp bmcgcG9pbnRlcnMuIEl0IGRvZXNuJ3QgbWF0dGVyIHdoYXQgdGhlIG9yZGVyIGlzIGFzIGxvbmcg YXMgaXQgaXMgYWx3YXlzIHRoZSBzYW1lLiAKKyAgICByZXR1cm4gcDEuZmlyc3QuaW1wbCgpIDwg cDIuZmlyc3QuaW1wbCgpOworfQorCiB2b2lkIFN0eWxlZEVsZW1lbnQ6OnVwZGF0ZVN0eWxlQXR0 cmlidXRlKCkgY29uc3QKIHsKICAgICBBU1NFUlQoIWlzU3R5bGVBdHRyaWJ1dGVWYWxpZCgpKTsK QEAgLTE0OSwyMSArMjExLDY5IEBAIHZvaWQgU3R5bGVkRWxlbWVudDo6YWRkU3VicmVzb3VyY2VB dHRyaWIKICAgICAgICAgaW5saW5lU3R5bGUtPmFkZFN1YnJlc291cmNlU3R5bGVVUkxzKHVybHMs IGRvY3VtZW50KCktPmVsZW1lbnRTaGVldCgpKTsKIH0KIAotdm9pZCBTdHlsZWRFbGVtZW50Ojp1 cGRhdGVBdHRyaWJ1dGVTdHlsZSgpCit2b2lkIFN0eWxlZEVsZW1lbnQ6Om1ha2VQcmVzZW50YXRp b25BdHRyaWJ1dGVDYWNoZUtleShQcmVzZW50YXRpb25BdHRyaWJ1dGVDYWNoZUtleSYgcmVzdWx0 KSBjb25zdAogewotICAgIFJlZlB0cjxTdHlsZVByb3BlcnR5U2V0PiBzdHlsZSA9IFN0eWxlUHJv cGVydHlTZXQ6OmNyZWF0ZSgpOwotICAgIGZvciAodW5zaWduZWQgaSA9IDA7IGkgPCBhdHRyaWJ1 dGVDb3VudCgpOyArK2kpIHsKKyAgICAvLyBGSVhNRTogRW5hYmxlIGZvciBTVkcgdG9vPworICAg IGlmIChuYW1lc3BhY2VVUkkoKSAhPSB4aHRtbE5hbWVzcGFjZVVSSSkKKyAgICAgICAgcmV0dXJu OworICAgIHVuc2lnbmVkIHNpemUgPSBhdHRyaWJ1dGVDb3VudCgpOworICAgIGZvciAodW5zaWdu ZWQgaSA9IDA7IGkgPCBzaXplOyArK2kpIHsKICAgICAgICAgQXR0cmlidXRlKiBhdHRyaWJ1dGUg PSBhdHRyaWJ1dGVJdGVtKGkpOwotICAgICAgICBjb2xsZWN0U3R5bGVGb3JBdHRyaWJ1dGUoYXR0 cmlidXRlLCBzdHlsZS5nZXQoKSk7CisgICAgICAgIGlmICghaXNQcmVzZW50YXRpb25BdHRyaWJ1 dGUoYXR0cmlidXRlLT5uYW1lKCkpKQorICAgICAgICAgICAgY29udGludWU7CisgICAgICAgIGlm ICghYXR0cmlidXRlLT5uYW1lc3BhY2VVUkkoKS5pc051bGwoKSkKKyAgICAgICAgICAgIHJldHVy bjsKKyAgICAgICAgLy8gQmFja2dyb3VuZCBVUkwgbWF5IGRlcGVuZCBvbiB0aGUgYmFzZSBVUkwu IERpc2FsbG93IGNhY2hpbmcuCisgICAgICAgIGlmIChhdHRyaWJ1dGUtPm5hbWUoKSA9PSBiYWNr Z3JvdW5kQXR0cikKKyAgICAgICAgICAgIHJldHVybjsKKyAgICAgICAgcmVzdWx0LmF0dHJpYnV0 ZXNBbmRWYWx1ZXMuYXBwZW5kKG1ha2VfcGFpcihhdHRyaWJ1dGUtPmxvY2FsTmFtZSgpLmltcGwo KSwgYXR0cmlidXRlLT52YWx1ZSgpKSk7CisgICAgfQorICAgIGlmICghcmVzdWx0LmF0dHJpYnV0 ZXNBbmRWYWx1ZXMuaXNFbXB0eSgpKSB7CisgICAgICAgIC8vIFRoZSBjYWNoZSBrZXkgaXMgbm9u LW51bGwgd2hlbiB0aGUgdGFnTmFtZSBpcyBzZXQuCisgICAgICAgIHJlc3VsdC50YWdOYW1lID0g bG9jYWxOYW1lKCkuaW1wbCgpOworICAgICAgICAvLyBBdHRyaWJ1dGUgb3JkZXIgZG9lc24ndCBt YXR0ZXIuIFNvcnQgZm9yIGVhc3kgZXF1YWxpdHkgY29tcGFyaXNvbi4KKyAgICAgICAgc3RkOjpz b3J0KHJlc3VsdC5hdHRyaWJ1dGVzQW5kVmFsdWVzLmJlZ2luKCksIHJlc3VsdC5hdHRyaWJ1dGVz QW5kVmFsdWVzLmVuZCgpLCBhdHRyaWJ1dGVOYW1lU29ydCk7CiAgICAgfQorfQorCit2b2lkIFN0 eWxlZEVsZW1lbnQ6OnVwZGF0ZUF0dHJpYnV0ZVN0eWxlKCkKK3sKKyAgICBQcmVzZW50YXRpb25B dHRyaWJ1dGVDYWNoZUtleSBjYWNoZUtleTsKKyAgICBtYWtlUHJlc2VudGF0aW9uQXR0cmlidXRl Q2FjaGVLZXkoY2FjaGVLZXkpOworCisgICAgUHJlc2VudGF0aW9uQXR0cmlidXRlQ2FjaGU6Oml0 ZXJhdG9yIGNhY2hlRW50cnk7CisgICAgaWYgKCFjYWNoZUtleS5pc051bGwoKSkKKyAgICAgICAg Y2FjaGVFbnRyeSA9IHByZXNlbnRhdGlvbkF0dHJpYnV0ZUNhY2hlKCkuYWRkKGNhY2hlS2V5LCAw KS5maXJzdDsKKworICAgIFJlZlB0cjxTdHlsZVByb3BlcnR5U2V0PiBzdHlsZTsKKyAgICBpZiAo Y2FjaGVLZXkuaXNOdWxsKCkgfHwgIWNhY2hlRW50cnktPnNlY29uZCkgeworICAgICAgICBzdHls ZSA9IFN0eWxlUHJvcGVydHlTZXQ6OmNyZWF0ZSgpOworICAgICAgICB1bnNpZ25lZCBzaXplID0g YXR0cmlidXRlQ291bnQoKTsKKyAgICAgICAgZm9yICh1bnNpZ25lZCBpID0gMDsgaSA8IHNpemU7 ICsraSkgeworICAgICAgICAgICAgQXR0cmlidXRlKiBhdHRyaWJ1dGUgPSBhdHRyaWJ1dGVJdGVt KGkpOworICAgICAgICAgICAgY29sbGVjdFN0eWxlRm9yQXR0cmlidXRlKGF0dHJpYnV0ZSwgc3R5 bGUuZ2V0KCkpOworICAgICAgICB9CisgICAgfSBlbHNlCisgICAgICAgIHN0eWxlID0gY2FjaGVF bnRyeS0+c2Vjb25kOworCiAgICAgY2xlYXJBdHRyaWJ1dGVTdHlsZURpcnR5KCk7CiAKICAgICBp ZiAoc3R5bGUtPmlzRW1wdHkoKSkKICAgICAgICAgYXR0cmlidXRlRGF0YSgpLT5zZXRBdHRyaWJ1 dGVTdHlsZSgwKTsKICAgICBlbHNlIHsKICAgICAgICAgc3R5bGUtPnNocmlua1RvRml0KCk7Ci0g ICAgICAgIGF0dHJpYnV0ZURhdGEoKS0+c2V0QXR0cmlidXRlU3R5bGUoc3R5bGUucmVsZWFzZSgp KTsKKyAgICAgICAgYXR0cmlidXRlRGF0YSgpLT5zZXRBdHRyaWJ1dGVTdHlsZShzdHlsZSk7CiAg ICAgfQorCisgICAgaWYgKGNhY2hlS2V5LmlzTnVsbCgpIHx8IGNhY2hlRW50cnktPnNlY29uZCkK KyAgICAgICAgcmV0dXJuOworCisgICAgaWYgKHByZXNlbnRhdGlvbkF0dHJpYnV0ZUNhY2hlKCku c2l6ZSgpID4gcHJlc2VudGF0aW9uQXR0cmlidXRlQ2FjaGVNYXhpbXVtU2l6ZSkgeworICAgICAg ICAvLyBTdGFydCBidWlsZGluZyBmcm9tIHNjcmF0Y2ggaWYgdGhlIGNhY2hlIGV2ZXIgZ2V0cyBi aWcuCisgICAgICAgIHByZXNlbnRhdGlvbkF0dHJpYnV0ZUNhY2hlKCkuY2xlYXIoKTsKKyAgICAg ICAgcHJlc2VudGF0aW9uQXR0cmlidXRlQ2FjaGUoKS5zZXQoY2FjaGVLZXksIHN0eWxlLnJlbGVh c2UoKSk7CisgICAgfSBlbHNlCisgICAgICAgIGNhY2hlRW50cnktPnNlY29uZCA9IHN0eWxlLnJl bGVhc2UoKTsKIH0KIAogdm9pZCBTdHlsZWRFbGVtZW50OjphZGRQcm9wZXJ0eVRvQXR0cmlidXRl U3R5bGUoU3R5bGVQcm9wZXJ0eVNldCogc3R5bGUsIGludCBwcm9wZXJ0eUlELCBpbnQgaWRlbnRp ZmllcikKSW5kZXg6IFNvdXJjZS9XZWJDb3JlL2RvbS9TdHlsZWRFbGVtZW50LmgKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQotLS0gU291cmNlL1dlYkNvcmUvZG9tL1N0eWxlZEVsZW1lbnQuaAkocmV2aXNpb24gMTA5NTE2 KQorKysgU291cmNlL1dlYkNvcmUvZG9tL1N0eWxlZEVsZW1lbnQuaAkod29ya2luZyBjb3B5KQpA QCAtMzEsNiArMzEsNyBAQAogbmFtZXNwYWNlIFdlYkNvcmUgewogCiBjbGFzcyBBdHRyaWJ1dGU7 CitzdHJ1Y3QgUHJlc2VudGF0aW9uQXR0cmlidXRlQ2FjaGVLZXk7CiAKIGNsYXNzIFN0eWxlZEVs ZW1lbnQgOiBwdWJsaWMgRWxlbWVudCB7CiBwdWJsaWM6CkBAIC04Miw2ICs4Myw3IEBAIHByaXZh dGU6CiAgICAgdmlydHVhbCB2b2lkIHVwZGF0ZVN0eWxlQXR0cmlidXRlKCkgY29uc3Q7CiAgICAg dm9pZCBpbmxpbmVTdHlsZUNoYW5nZWQoKTsKIAorICAgIHZvaWQgbWFrZVByZXNlbnRhdGlvbkF0 dHJpYnV0ZUNhY2hlS2V5KFByZXNlbnRhdGlvbkF0dHJpYnV0ZUNhY2hlS2V5JikgY29uc3Q7CiAg ICAgdm9pZCB1cGRhdGVBdHRyaWJ1dGVTdHlsZSgpOwogCiAgICAgdm9pZCBkZXN0cm95SW5saW5l U3R5bGVEZWNsKCkK