106726 2013-01-11 20:17:54 -0800 20% regression on dom_perf/DomDivWalk 2013-01-24 23:07:32 -0800 1 1 1 Unclassified WebKit WebCore Misc. 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED PerfRegression P1 Normal --- 1 ojan falken cmarcelo dglazkov esprehn falken jchaffraix leviw morrita noel.gordon ojan.autocc rniwa shinyak webkit.review.bot oldest_to_newest 805821 0 ojan 2013-01-11 20:17:54 -0800 Regression range: http://trac.webkit.org/log/?verbose=on&rev=139402&stop_rev=139400 REGRESSIONS http://chromium-perf.appspot.com/?tab=linux-release-webkit-latest&graph=DOMDivWalk&trace=score&rev=176358&history=150&master=ChromiumWebkit&testSuite=dom_perf&details=true PROGRESSIONS http://chromium-perf.appspot.com/?tab=linux-release-webkit-latest&graph=Get%20Elements&trace=score&history=150&master=ChromiumWebkit&testSuite=dom_perf&details=true 807528 1 leviw 2013-01-15 11:48:12 -0800 I ran these tests locally with each of the patches reverted individually. Reverting 139402 took a full second off the runtime on my machine. I'm assigning to falken@ to investigate further. 808095 2 falken 2013-01-16 00:00:09 -0800 Not sure what's going on here. The only code from my patch that this test can hit is in Element::removedFrom. I found this code is hit over 9M times when running DOMDivWalk, so it does look suspicious. On the other hand, the change seems innocuous. Before the patch, Element::removedFrom did: setIsInTopLayer(false); which did: ensureElementRareData()->setIsInTopLayer(inTopLayer); setNeedsStyleRecalc(SyntheticStyleChange); After patch, Element::removedFrom does: document()->removeFromTopLayer(this); which does: if (!element->isInTopLayer()) return; And isInTopLayer is just: return hasRareData() && elementRareData()->isInTopLayer(); I don't have luck reproducing the regression locally. The test runs are about 67 ms, with or without my patch. Any ideas how to proceed? 808097 3 rniwa 2013-01-16 00:02:39 -0800 Also note that I don't see the regression on http://webkit-perf.appspot.com/graph.html#tests=[[6107,2001,3001],[6107,2001,2389050],[6107,2001,173262]]&sel=1357718371985,1358323171985&displayrange=7&datatype=running 808122 4 falken 2013-01-16 00:47:25 -0800 (In reply to comment #3) > Also note that I don't see the regression on http://webkit-perf.appspot.com/graph.html#tests=[[6107,2001,3001],[6107,2001,2389050],[6107,2001,173262]]&sel=1357718371985,1358323171985&displayrange=7&datatype=running It looks like that's for DOMWalk, not DOMDivWalk. I don't see the regression in the link below either, but somehow there's no data for Chromium Linux earlier than today. http://webkit-perf.appspot.com/graph.html#tests=[[6104,2001,173262],[6104,2001,2389050],[6104,2001,3001]]&sel=1357720675021,1358325475021&displayrange=7&datatype=running 808456 5 ojan 2013-01-16 09:54:52 -0800 Nothing obvious there. Maybe something is getting inlined differently? Couple shot-in-the-dark things you could try: -Move the element->isInTopLayer() check to removedFrom -move isInTopLayer implementation to the header to get it to inline 808877 6 falken 2013-01-16 17:25:24 -0800 (In reply to comment #5) > Nothing obvious there. Maybe something is getting inlined differently? Couple shot-in-the-dark things you could try: > -Move the element->isInTopLayer() check to removedFrom > -move isInTopLayer implementation to the header to get it to inline I'll give it a try. Is there a way to submit a try job to the perf bot? It's not reproducing locally (maybe my machine is too fast). Or should I just commit and see what happens? 810050 7 falken 2013-01-17 18:09:42 -0800 Rolled out the patch: http://trac.webkit.org/changeset/140080 810684 8 ojan 2013-01-18 09:08:55 -0800 Looks like 139402 wasn't the cause of the regression. It's been rolled out and there's no improvement. Matt, r=me on relanding that. This is why it's usually best to rollout first and ask questions later with perf regressions. Saves everyone work. :) I wonder if it's the FrameSelection change in http://trac.webkit.org/changeset/139401/. Shinya-san, can you try a rollout to confirm? If it's not the culprit r=me on relanding it. 810831 9 rniwa 2013-01-18 10:51:52 -0800 Please try to run the latest locally before rolling the patch out. All these rollouts are causing svn churn. 810833 10 ojan 2013-01-18 10:53:50 -0800 Comment 1 already tried reproducing locally and clearly the test variance is too high to get a reliable result locally. I agree that the commit churn isn't great, but until someone builds better infrastructure for trying perf changes on bots, I don't see an alternative. 812045 11 rniwa 2013-01-21 05:04:56 -0800 (In reply to comment #10) > Comment 1 already tried reproducing locally and clearly the test variance is too high to get a reliable result locally. I agree that the commit churn isn't great, but until someone builds better infrastructure for trying perf changes on bots, I don't see an alternative. If the variance is the issue, you should be able to run the test 20, 100, or even 1000 times and use the mean of those results. It should reflect the said regression if it's really reproducible. 812766 12 falken 2013-01-22 01:24:13 -0800 It looks like my patch is indeed the culprit. A short while after the rollout the perf indeed went back up and immediately after relanding it dropped back down. Sorry for the SVN churn but I think I have to rollout again. I don't think variance is the issue, the regression just doesn't occur on my machine. I had the test run 200 iterations instead of the normal 20 and the results of 'run-perf-tests ./PerformanceTests/DOM/DOMDivWalk.html' were: (without my patch) RESULT DOM: DOMDivWalk= 67.3472753909 ms median= 67.2489583376 ms, stdev= 0.787590427719 ms, min= 64.9623333205 ms, max= 70.2458332914 ms (with my patch) RESULT DOM: DOMDivWalk= 68.0555829093 ms median= 67.6872915453 ms, stdev= 1.23173675198 ms, min= 66.4260832709 ms, max= 73.4682503195 ms It looks like we may not have a way to do a try job on the perf bot. I'm curious why the regression doesn't occur on http://webkit-perf.appspot.com. What does it do differently from http://chromium-perf.appspot.com? I also opened DOMDivWalk in Chrome itself but didn't seem to get meaningful results (my patch was faster than without). 812863 13 falken 2013-01-22 03:16:05 -0800 I think moving the top layer flag from ElementRareData to NodeFlags has a chance of fixing the regression, and seems to be a good idea anyway. I want to try to land the patch at bug 107542 and see if it fixes it. 813142 14 rniwa 2013-01-22 10:21:28 -0800 (In reply to comment #12) > (without my patch) > RESULT DOM: DOMDivWalk= 67.3472753909 ms > median= 67.2489583376 ms, stdev= 0.787590427719 ms, min= 64.9623333205 ms, max= 70.2458332914 ms > (with my patch) > RESULT DOM: DOMDivWalk= 68.0555829093 ms > median= 67.6872915453 ms, stdev= 1.23173675198 ms, min= 66.4260832709 ms, max= 73.4682503195 ms There is a slight difference between the two: 67.35 vs. 68.06. I bet if you took 2000 or 5000 samples instead of a mere 200, you'll see more clear deviation between the two. 813776 15 184130 falken 2013-01-22 21:17:22 -0800 Created attachment 184130 Patch 813778 16 184130 rniwa 2013-01-22 21:22:17 -0800 Comment on attachment 184130 Patch Is this patch speculative? If it is, I don't see how it could fix the perf. regression. 813780 17 falken 2013-01-22 21:25:18 -0800 (mid-air collision) The NodeFlags patch did not help. I have another idea I'd like to try. I realized there is already a check in Element::removedFrom for Fullscreen. I'll try to absorb the perf hit of the check for top layer by moving the Fullscreen and top layer checks into a slow path. This code is somewhat ugly but it should be fixed as the plan is for Fullscreen and top layer to merge (bug 107617). I get somewhat promising results: (with slow path patch) RESULT DOM: DOMDivWalk= 63.8586679573 ms median= 63.7347082957 ms, stdev= 0.864724536393 ms, min= 62.3731666322 ms, max= 70.3177498071 ms (with current build) RESULT DOM: DOMDivWalk= 64.9818412457 ms median= 64.8267084325 ms, stdev= 1.28962335807 ms, min= 62.4124999352 ms, max= 70.5802498269 ms I ran the first test for 2000 iterations but the second one only 200 (I accidentally ran 2000 on the wrong build...). If this also fails, I'll rollout all three patches and start over. 813787 18 184130 morrita 2013-01-22 21:34:32 -0800 Comment on attachment 184130 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=184130&action=review > Source/WebCore/dom/Node.cpp:-2623 > -#if ENABLE(DIALOG_ELEMENT) we don't need this. Instead of that.... > Source/WebCore/dom/Node.h:694 > + void setIsInTopLayer(bool); The disabled case could be inlined here. I think guarding whole definition(s) would be cleaner than having the ifdef in the function body. 813854 19 184145 falken 2013-01-22 22:42:01 -0800 Created attachment 184145 Patch 813893 20 184145 webkit.review.bot 2013-01-22 23:32:59 -0800 Comment on attachment 184145 Patch Clearing flags on attachment: 184145 Committed r140512: <http://trac.webkit.org/changeset/140512> 813894 21 webkit.review.bot 2013-01-22 23:33:03 -0800 All reviewed patches have been landed. Closing bug. 814178 22 falken 2013-01-23 07:21:08 -0800 r140512 did not fix the regression. I'll roll out the three patches (r140307, r140411, r140512). rniwa had a clue that run-perf-tests and webkit-perf.appspot.com use a different test runner than dom_perf, which may explain why I couldn't reproduce locally and why the regression doesn't show on webkit-perf.appspot.com. Particularly, the webkit runner certainly doesn't include element removal in the benchmark time, but dom_perf might. So I have some room to investigate more before attempting to land something again. 814258 23 esprehn 2013-01-23 09:26:45 -0800 (In reply to comment #22) > r140512 did not fix the regression. I'll roll out the three patches (r140307, r140411, r140512). > > rniwa had a clue that run-perf-tests and webkit-perf.appspot.com use a different test runner than dom_perf, which may explain why I couldn't reproduce locally and why the regression doesn't show on webkit-perf.appspot.com. Particularly, the webkit runner certainly doesn't include element removal in the benchmark time, but dom_perf might. So I have some room to investigate more before attempting to land something again. The patches here don't make sense, doing hasRareData() || isInTopLayer() is only avoiding a single function call, and if that was the "slow part" then my patch that checks pseudoElement for BEFORE and AFTER should have caused a 40% regression: https://trac.webkit.org/changeset/140452 I don't think we're focusing on the right thing, certainly not with trying to avoid this one place of method call overhead (that's definitely not 20% of the time spent in DOMDivWalk). If anything the original patch should have made things _much_ faster since we were inadvertently allocating rare data for every element that was removed from the DOM because Element::removedFrom did setIsInTopLayer(false) which did ensureRareData() which was super bad for memory usage. At the very least setIsInTopLayer needs to check if (!hasRareData() && !inTopLayer) return; to avoid allocating rare data for every node that gets removed... 814272 24 esprehn 2013-01-23 09:40:40 -0800 (In reply to comment #23) > (In reply to comment #22) > ... > Can we please roll out this patch? There's no reason for this if guard, as there's no reason that isInTopLayer() should be slower than pseudoElement(BEFORE) or AFTER right above this. 814594 25 falken 2013-01-23 13:50:06 -0800 Rolled out: http://trac.webkit.org/changeset/140546 Now DOMDivWalk looks better again. 814811 26 morrita 2013-01-23 16:37:31 -0800 (In reply to comment #25) > Rolled out: http://trac.webkit.org/changeset/140546 > > Now DOMDivWalk looks better again. Sigh. We should definitely look how our internal test runner work. I guess we can run it on DRT instead of full Chromium with small modifications. Then running it will have less pain. 815223 27 falken 2013-01-24 01:11:16 -0800 On IRC, Elliott had a very promising theory about what is happening. A much earlier patch (r136575) inadvertently changed Element::removedFrom to always allocate rare data, by calling setIsInTopLayer. Element::removedFrom is not called during the DOMDivWalk benchmark itself, just in the setup/teardown between iterations. This means every element gets rare data for free, and perf hits that would normally occur by allocating rare data vanish from the benchmark, resulting in a higher score. Since my patch changed removedFrom to not allocate rare data unless needed, the score decreases. The graph supports this theory: http://chromium-perf.appspot.com/?tab=linux-release-webkit-latest&graph=DOMDivWalk&trace=score&rev=179000&history=700&master=ChromiumWebkit&testSuite=dom_perf&details=true - r136575: always allocate rare data in Element::removedFrom - r139402: first landing of my patch - r140080: rollout - r140307: reland - r140546: rollout - r140638: fix for always allocating rare data So if this is the case, we should see a perf hit for 140638, which so far is happening. I should have realized this too because my code before r136575 was performing the isInTopLayer() check on each Element::removedFrom call, and evidently no perf regression occurred. 816093 28 ojan 2013-01-24 19:09:17 -0800 Seems reasonable to me. It doesn't seem to me like there's more to be had from digging deeper here. 816119 29 falken 2013-01-24 20:21:47 -0800 Just for more evidence, I slowed down rare data allocation with a sleep and tested with and without r140638: (always allocating rare data) RESULT DOM: DOMDivWalk= 3293.468275 ms (not allocating rare data) RESULT DOM: DOMDivWalk= 1865.209725 ms The benchmark uses childNodes, which uses rare data. I'll reland the patch. 816121 30 falken 2013-01-24 20:24:02 -0800 (In reply to comment #29) > (always allocating rare data) > RESULT DOM: DOMDivWalk= 3293.468275 ms > (not allocating rare data) > RESULT DOM: DOMDivWalk= 1865.209725 ms Oops, I reversed those. Always allocating rare data is faster than not. 816277 31 rniwa 2013-01-24 22:58:33 -0800 (In reply to comment #30) > (In reply to comment #29) > > (always allocating rare data) > > RESULT DOM: DOMDivWalk= 3293.468275 ms > > (not allocating rare data) > > RESULT DOM: DOMDivWalk= 1865.209725 ms > > Always allocating rare data is faster than not. That's not really true. We're just shifting the runtime cost to where it's not measured. We're paying the same runtime cost at the end of the day. 816282 32 falken 2013-01-24 23:07:32 -0800 (In reply to comment #31) > That's not really true. We're just shifting the runtime cost to where it's not measured. We're paying the same runtime cost at the end of the day. Yes that was unclear wording on my part... I meant the always allocated case has the better/faster benchmark result. 184130 2013-01-22 21:17:22 -0800 2013-01-22 22:41:57 -0800 Patch bug-106726-20130123141416.patch text/plain 4409 falken U3VidmVyc2lvbiBSZXZpc2lvbjogMTQwNTAyCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggNTAxMmQ2N2IwZGFkNDNj YTgwNjVmOGE2MzgwNmUwNmE0MjVmYzA1ZC4uZmMyNmNlNmMxNWJiYTVhZTMxNzU5Zjg0NDg0YjA3 YmU4NzgzMTcwOSAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDI4IEBACisyMDEzLTAxLTIyICBNYXR0 IEZhbGtlbmhhZ2VuICA8ZmFsa2VuQGNocm9taXVtLm9yZz4KKworICAgICAgICAyMCUgcmVncmVz c2lvbiBvbiBkb21fcGVyZi9Eb21EaXZXYWxrCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQu b3JnL3Nob3dfYnVnLmNnaT9pZD0xMDY3MjYKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkg KE9PUFMhKS4KKworICAgICAgICBUaGlzIHBhdGNoIG1vdmVzIHRoZSBjaGVja3MgaW4gRWxlbWVu dDo6cmVtb3ZlZEZyb20gZm9yIEZ1bGxzY3JlZW4gYW5kIHRvcCBsYXllciBmbGFncworICAgICAg ICBpbnRvIGEgc2xvdyBwYXRoLiBUaGUgaWRlYSBpcyBmb3IgdGhlIHR3byBjaGVja3MgZm9yIEZ1 bGxzY3JlZW4gYW5kIHRvcCBsYXllcgorICAgICAgICB0byBiZSByZXBsYWNlZCBieSBvbmUgZmFz dGVyIGNoZWNrIGluIHRoZSBmYXN0IHBhdGguCisKKyAgICAgICAgVGhlIHBsYW4gaXMgdG8gbWln cmF0ZSB0aGUgRnVsbHNjcmVlbiBpbXBsZW1lbnRhdGlvbiB0byB1c2UgdG9wIGxheWVyLCBzbyB0 aGlzIGlzIGp1c3QgYQorICAgICAgICBzaG9ydC10ZXJtIGZpeCBmb3IgdGhlIHBlcmYgcmVncmVz c2lvbi4KKworICAgICAgICBObyBuZXcgdGVzdHM6IG5vIGZ1bmN0aW9uYWxpdHkgY2hhbmdlCisK KyAgICAgICAgKiBkb20vRWxlbWVudC5jcHA6CisgICAgICAgIChXZWJDb3JlOjpFbGVtZW50Ojpy ZW1vdmVkRnJvbSk6IENyZWF0ZSBhIHNsb3cgcGF0aCB0byBtb3ZlIHRoZSBGdWxsc2NyZWVuIGFu ZCB0b3AgbGF5ZXIgY2hlY2tzIGludG8uCisgICAgICAgICogZG9tL05vZGUuY3BwOgorICAgICAg ICAoV2ViQ29yZTo6Tm9kZTo6c2V0SXNJblRvcExheWVyKTogVG8gYWxsb3cgZm9yIGNsZWFuZXIg Y29kZSBpbiBFbGVtZW50OjpyZW1vdmVkRnJvbSwgZGVmaW5lCisgICAgICAgIHNldElzSW5Ub3BM YXllciBhbmQgaXNJblRvcExheWVyIGV2ZW4gd2hlbiB0aGUgZmVhdHVyZSBmbGFnIGlzIG9mZi4K KyAgICAgICAgKiBkb20vTm9kZS5oOgorICAgICAgICAoV2ViQ29yZTo6Tm9kZTo6aXNJblRvcExh eWVyKTogRGl0dG8uCisgICAgICAgIChOb2RlKToKKwogMjAxMy0wMS0yMiAgQW5kZXJzIENhcmxz c29uICA8YW5kZXJzY2FAYXBwbGUuY29tPgogCiAgICAgICAgIFVzZSBhIHBsYXRmb3JtIHN0cmF0 ZWd5IGZvciBsb2NhbCBzdG9yYWdlCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9kb20vRWxl bWVudC5jcHAgYi9Tb3VyY2UvV2ViQ29yZS9kb20vRWxlbWVudC5jcHAKaW5kZXggYzIwMzFkYTUz OTM4NTZmOGMzMzI3YjdlNzFhZTdkYmEwY2ZkODllMy4uNDJiZmI0YWVjMDVmM2FhOWYyZjdlZWY0 MDk4NjhhNzQzZmFmMDJlNyAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvZG9tL0VsZW1lbnQu Y3BwCisrKyBiL1NvdXJjZS9XZWJDb3JlL2RvbS9FbGVtZW50LmNwcApAQCAtMTE4MiwxNCArMTE4 MiwyMiBAQCB2b2lkIEVsZW1lbnQ6OnJlbW92ZWRGcm9tKENvbnRhaW5lck5vZGUqIGluc2VydGlv blBvaW50KQogICAgIGlmIChFbGVtZW50KiBhZnRlciA9IHBzZXVkb0VsZW1lbnQoQUZURVIpKQog ICAgICAgICBhZnRlci0+cmVtb3ZlZEZyb20oaW5zZXJ0aW9uUG9pbnQpOwogCisgICAgLy8gRklY TUU6IEZ1bGxzY3JlZW4gc2hvdWxkIGJlIG1pZ3JhdGVkIHRvIHVzZSB0aGUgdG9wIGxheWVyIChi dWcgMTA3NjE3KS4gVGhlbiB0aGlzIGNhbiBqdXN0IGJlIGEgc2luZ2xlIGNoZWNrLgorICAgIC8v IFRoZSBwdXJwb3NlIG9mIHRoZSBvdXRlciBpZiBzdGF0ZW1lbnQgaXMgdG8gcXVpY2tseSBkZXRl cm1pbmUgd2hldGhlciB3ZSBtdXN0IGRvIHRoZSBhZGRpdGlvbmFsCisgICAgLy8gY2hlY2tzIGlu IGEgc2xvdyBwYXRoLgorI2lmIEVOQUJMRShESUFMT0dfRUxFTUVOVCkgfHwgRU5BQkxFKEZVTExT Q1JFRU5fQVBJKQorICAgIGlmIChoYXNSYXJlRGF0YSgpIHx8IGlzSW5Ub3BMYXllcigpKSB7CiAj aWYgRU5BQkxFKERJQUxPR19FTEVNRU5UKQotICAgIGlmIChpc0luVG9wTGF5ZXIoKSkKLSAgICAg ICAgZG9jdW1lbnQoKS0+cmVtb3ZlRnJvbVRvcExheWVyKHRoaXMpOworICAgICAgICBpZiAoaXNJ blRvcExheWVyKCkpCisgICAgICAgICAgICBkb2N1bWVudCgpLT5yZW1vdmVGcm9tVG9wTGF5ZXIo dGhpcyk7CiAjZW5kaWYKICNpZiBFTkFCTEUoRlVMTFNDUkVFTl9BUEkpCi0gICAgaWYgKGNvbnRh aW5zRnVsbFNjcmVlbkVsZW1lbnQoKSkKLSAgICAgICAgc2V0Q29udGFpbnNGdWxsU2NyZWVuRWxl bWVudE9uQW5jZXN0b3JzQ3Jvc3NpbmdGcmFtZUJvdW5kYXJpZXMoZmFsc2UpOworICAgICAgICBp ZiAoY29udGFpbnNGdWxsU2NyZWVuRWxlbWVudCgpKQorICAgICAgICAgICAgc2V0Q29udGFpbnNG dWxsU2NyZWVuRWxlbWVudE9uQW5jZXN0b3JzQ3Jvc3NpbmdGcmFtZUJvdW5kYXJpZXMoZmFsc2Up OwogI2VuZGlmCisgICAgfQorI2VuZGlmCisKICNpZiBFTkFCTEUoUE9JTlRFUl9MT0NLKQogICAg IGlmIChkb2N1bWVudCgpLT5wYWdlKCkpCiAgICAgICAgIGRvY3VtZW50KCktPnBhZ2UoKS0+cG9p bnRlckxvY2tDb250cm9sbGVyKCktPmVsZW1lbnRSZW1vdmVkKHRoaXMpOwpkaWZmIC0tZ2l0IGEv U291cmNlL1dlYkNvcmUvZG9tL05vZGUuY3BwIGIvU291cmNlL1dlYkNvcmUvZG9tL05vZGUuY3Bw CmluZGV4IDliZDhmMmMxN2RhZTQzYWNkOWQyN2JhZDBiYzdlNjA2NmIzODllODYuLmUyOWM2YTU1 NzkzYWIwN2NjMzMyZjg4YTgzODllYWVkOTZjMTI5ZTMgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJD b3JlL2RvbS9Ob2RlLmNwcAorKysgYi9Tb3VyY2UvV2ViQ29yZS9kb20vTm9kZS5jcHAKQEAgLTI2 MjAsMTYgKzI2MjAsMTggQEAgdm9pZCBOb2RlOjpkZWNyZW1lbnRDb25uZWN0ZWRTdWJmcmFtZUNv dW50KHVuc2lnbmVkIGFtb3VudCkKICAgICByYXJlRGF0YSgpLT5kZWNyZW1lbnRDb25uZWN0ZWRT dWJmcmFtZUNvdW50KGFtb3VudCk7CiB9CiAKLSNpZiBFTkFCTEUoRElBTE9HX0VMRU1FTlQpCiB2 b2lkIE5vZGU6OnNldElzSW5Ub3BMYXllcihib29sIGlzSW5Ub3BMYXllcikKIHsKKyNpZiBFTkFC TEUoRElBTE9HX0VMRU1FTlQpCiAgICAgc2V0RmxhZyhpc0luVG9wTGF5ZXIsIElzSW5Ub3BMYXll cik7CiAKICAgICAvLyBXZSBtdXN0IGVuc3VyZSBhIHJlYXR0YWNoIG9jY3VycyBzbyB0aGUgcmVu ZGVyZXIgaXMgaW5zZXJ0ZWQgaW4gdGhlIGNvcnJlY3Qgc2libGluZyBvcmRlciB1bmRlciBSZW5k ZXJWaWV3IGFjY29yZGluZyB0byBpdHMKICAgICAvLyB0b3AgbGF5ZXIgcG9zaXRpb24sIG9yIGlu IGl0cyB1c3VhbCBwbGFjZSBpZiBub3QgaW4gdGhlIHRvcCBsYXllci4KICAgICByZWF0dGFjaElm QXR0YWNoZWQoKTsKLX0KKyNlbHNlCisgICAgVU5VU0VEX1BBUkFNKGlzSW5Ub3BMYXllcik7CiAj ZW5kaWYKK30KIAogdm9pZCBOb2RlOjpyZWdpc3RlclNjb3BlZEhUTUxTdHlsZUNoaWxkKCkKIHsK ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL2RvbS9Ob2RlLmggYi9Tb3VyY2UvV2ViQ29yZS9k b20vTm9kZS5oCmluZGV4IDlkZDYwMTk1N2JhMThiZDRhMDE5MGM1NjFjNzAxMDJlYTExZGViNzAu LjI3ZDQ2NmY1MjI1NzU5N2U4YWU1MzY2ZjVlMjhiM2VkZTNiNzRlOTcgMTAwNjQ0Ci0tLSBhL1Nv dXJjZS9XZWJDb3JlL2RvbS9Ob2RlLmgKKysrIGIvU291cmNlL1dlYkNvcmUvZG9tL05vZGUuaApA QCAtNjgyLDEwICs2ODIsMTYgQEAgcHVibGljOgogICAgIHZvaWQgaW5jcmVtZW50Q29ubmVjdGVk U3ViZnJhbWVDb3VudCh1bnNpZ25lZCBhbW91bnQgPSAxKTsKICAgICB2b2lkIGRlY3JlbWVudENv bm5lY3RlZFN1YmZyYW1lQ291bnQodW5zaWduZWQgYW1vdW50ID0gMSk7CiAKKyAgICBib29sIGlz SW5Ub3BMYXllcigpIGNvbnN0CisgICAgewogI2lmIEVOQUJMRShESUFMT0dfRUxFTUVOVCkKLSAg ICBib29sIGlzSW5Ub3BMYXllcigpIGNvbnN0IHsgcmV0dXJuIGdldEZsYWcoSXNJblRvcExheWVy KTsgfQotICAgIHZvaWQgc2V0SXNJblRvcExheWVyKGJvb2wpOworICAgICAgICByZXR1cm4gZ2V0 RmxhZyhJc0luVG9wTGF5ZXIpOworI2Vsc2UKKyAgICAgICAgcmV0dXJuIGZhbHNlOwogI2VuZGlm CisgICAgfQorCisgICAgdm9pZCBzZXRJc0luVG9wTGF5ZXIoYm9vbCk7CiAKIHByaXZhdGU6CiAg ICAgZW51bSBOb2RlRmxhZ3Mgewo= 184145 2013-01-22 22:42:01 -0800 2013-01-22 23:32:58 -0800 Patch bug-106726-20130123153854.patch text/plain 3330 falken U3VidmVyc2lvbiBSZXZpc2lvbjogMTQwNTAyCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggNTAxMmQ2N2IwZGFkNDNj YTgwNjVmOGE2MzgwNmUwNmE0MjVmYzA1ZC4uZmMyNmNlNmMxNWJiYTVhZTMxNzU5Zjg0NDg0YjA3 YmU4NzgzMTcwOSAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDI4IEBACisyMDEzLTAxLTIyICBNYXR0 IEZhbGtlbmhhZ2VuICA8ZmFsa2VuQGNocm9taXVtLm9yZz4KKworICAgICAgICAyMCUgcmVncmVz c2lvbiBvbiBkb21fcGVyZi9Eb21EaXZXYWxrCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQu b3JnL3Nob3dfYnVnLmNnaT9pZD0xMDY3MjYKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkg KE9PUFMhKS4KKworICAgICAgICBUaGlzIHBhdGNoIG1vdmVzIHRoZSBjaGVja3MgaW4gRWxlbWVu dDo6cmVtb3ZlZEZyb20gZm9yIEZ1bGxzY3JlZW4gYW5kIHRvcCBsYXllciBmbGFncworICAgICAg ICBpbnRvIGEgc2xvdyBwYXRoLiBUaGUgaWRlYSBpcyBmb3IgdGhlIHR3byBjaGVja3MgZm9yIEZ1 bGxzY3JlZW4gYW5kIHRvcCBsYXllcgorICAgICAgICB0byBiZSByZXBsYWNlZCBieSBvbmUgZmFz dGVyIGNoZWNrIGluIHRoZSBmYXN0IHBhdGguCisKKyAgICAgICAgVGhlIHBsYW4gaXMgdG8gbWln cmF0ZSB0aGUgRnVsbHNjcmVlbiBpbXBsZW1lbnRhdGlvbiB0byB1c2UgdG9wIGxheWVyLCBzbyB0 aGlzIGlzIGp1c3QgYQorICAgICAgICBzaG9ydC10ZXJtIGZpeCBmb3IgdGhlIHBlcmYgcmVncmVz c2lvbi4KKworICAgICAgICBObyBuZXcgdGVzdHM6IG5vIGZ1bmN0aW9uYWxpdHkgY2hhbmdlCisK KyAgICAgICAgKiBkb20vRWxlbWVudC5jcHA6CisgICAgICAgIChXZWJDb3JlOjpFbGVtZW50Ojpy ZW1vdmVkRnJvbSk6IENyZWF0ZSBhIHNsb3cgcGF0aCB0byBtb3ZlIHRoZSBGdWxsc2NyZWVuIGFu ZCB0b3AgbGF5ZXIgY2hlY2tzIGludG8uCisgICAgICAgICogZG9tL05vZGUuY3BwOgorICAgICAg ICAoV2ViQ29yZTo6Tm9kZTo6c2V0SXNJblRvcExheWVyKTogVG8gYWxsb3cgZm9yIGNsZWFuZXIg Y29kZSBpbiBFbGVtZW50OjpyZW1vdmVkRnJvbSwgZGVmaW5lCisgICAgICAgIHNldElzSW5Ub3BM YXllciBhbmQgaXNJblRvcExheWVyIGV2ZW4gd2hlbiB0aGUgZmVhdHVyZSBmbGFnIGlzIG9mZi4K KyAgICAgICAgKiBkb20vTm9kZS5oOgorICAgICAgICAoV2ViQ29yZTo6Tm9kZTo6aXNJblRvcExh eWVyKTogRGl0dG8uCisgICAgICAgIChOb2RlKToKKwogMjAxMy0wMS0yMiAgQW5kZXJzIENhcmxz c29uICA8YW5kZXJzY2FAYXBwbGUuY29tPgogCiAgICAgICAgIFVzZSBhIHBsYXRmb3JtIHN0cmF0 ZWd5IGZvciBsb2NhbCBzdG9yYWdlCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9kb20vRWxl bWVudC5jcHAgYi9Tb3VyY2UvV2ViQ29yZS9kb20vRWxlbWVudC5jcHAKaW5kZXggYzIwMzFkYTUz OTM4NTZmOGMzMzI3YjdlNzFhZTdkYmEwY2ZkODllMy4uNDJiZmI0YWVjMDVmM2FhOWYyZjdlZWY0 MDk4NjhhNzQzZmFmMDJlNyAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvZG9tL0VsZW1lbnQu Y3BwCisrKyBiL1NvdXJjZS9XZWJDb3JlL2RvbS9FbGVtZW50LmNwcApAQCAtMTE4MiwxNCArMTE4 MiwyMiBAQCB2b2lkIEVsZW1lbnQ6OnJlbW92ZWRGcm9tKENvbnRhaW5lck5vZGUqIGluc2VydGlv blBvaW50KQogICAgIGlmIChFbGVtZW50KiBhZnRlciA9IHBzZXVkb0VsZW1lbnQoQUZURVIpKQog ICAgICAgICBhZnRlci0+cmVtb3ZlZEZyb20oaW5zZXJ0aW9uUG9pbnQpOwogCisgICAgLy8gRklY TUU6IEZ1bGxzY3JlZW4gc2hvdWxkIGJlIG1pZ3JhdGVkIHRvIHVzZSB0aGUgdG9wIGxheWVyIChi dWcgMTA3NjE3KS4gVGhlbiB0aGlzIGNhbiBqdXN0IGJlIGEgc2luZ2xlIGNoZWNrLgorICAgIC8v IFRoZSBwdXJwb3NlIG9mIHRoZSBvdXRlciBpZiBzdGF0ZW1lbnQgaXMgdG8gcXVpY2tseSBkZXRl cm1pbmUgd2hldGhlciB3ZSBtdXN0IGRvIHRoZSBhZGRpdGlvbmFsCisgICAgLy8gY2hlY2tzIGlu IGEgc2xvdyBwYXRoLgorI2lmIEVOQUJMRShESUFMT0dfRUxFTUVOVCkgfHwgRU5BQkxFKEZVTExT Q1JFRU5fQVBJKQorICAgIGlmIChoYXNSYXJlRGF0YSgpIHx8IGlzSW5Ub3BMYXllcigpKSB7CiAj aWYgRU5BQkxFKERJQUxPR19FTEVNRU5UKQotICAgIGlmIChpc0luVG9wTGF5ZXIoKSkKLSAgICAg ICAgZG9jdW1lbnQoKS0+cmVtb3ZlRnJvbVRvcExheWVyKHRoaXMpOworICAgICAgICBpZiAoaXNJ blRvcExheWVyKCkpCisgICAgICAgICAgICBkb2N1bWVudCgpLT5yZW1vdmVGcm9tVG9wTGF5ZXIo dGhpcyk7CiAjZW5kaWYKICNpZiBFTkFCTEUoRlVMTFNDUkVFTl9BUEkpCi0gICAgaWYgKGNvbnRh aW5zRnVsbFNjcmVlbkVsZW1lbnQoKSkKLSAgICAgICAgc2V0Q29udGFpbnNGdWxsU2NyZWVuRWxl bWVudE9uQW5jZXN0b3JzQ3Jvc3NpbmdGcmFtZUJvdW5kYXJpZXMoZmFsc2UpOworICAgICAgICBp ZiAoY29udGFpbnNGdWxsU2NyZWVuRWxlbWVudCgpKQorICAgICAgICAgICAgc2V0Q29udGFpbnNG dWxsU2NyZWVuRWxlbWVudE9uQW5jZXN0b3JzQ3Jvc3NpbmdGcmFtZUJvdW5kYXJpZXMoZmFsc2Up OwogI2VuZGlmCisgICAgfQorI2VuZGlmCisKICNpZiBFTkFCTEUoUE9JTlRFUl9MT0NLKQogICAg IGlmIChkb2N1bWVudCgpLT5wYWdlKCkpCiAgICAgICAgIGRvY3VtZW50KCktPnBhZ2UoKS0+cG9p bnRlckxvY2tDb250cm9sbGVyKCktPmVsZW1lbnRSZW1vdmVkKHRoaXMpOwpkaWZmIC0tZ2l0IGEv U291cmNlL1dlYkNvcmUvZG9tL05vZGUuaCBiL1NvdXJjZS9XZWJDb3JlL2RvbS9Ob2RlLmgKaW5k ZXggOWRkNjAxOTU3YmExOGJkNGEwMTkwYzU2MWM3MDEwMmVhMTFkZWI3MC4uYTNkNGVmZmJkMTQ4 OGNkYjJkYTg4NjZjMTQzNWEyYzc3NzEzOTIxOSAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUv ZG9tL05vZGUuaAorKysgYi9Tb3VyY2UvV2ViQ29yZS9kb20vTm9kZS5oCkBAIC02ODUsNiArNjg1 LDkgQEAgcHVibGljOgogI2lmIEVOQUJMRShESUFMT0dfRUxFTUVOVCkKICAgICBib29sIGlzSW5U b3BMYXllcigpIGNvbnN0IHsgcmV0dXJuIGdldEZsYWcoSXNJblRvcExheWVyKTsgfQogICAgIHZv aWQgc2V0SXNJblRvcExheWVyKGJvb2wpOworI2Vsc2UKKyAgICBib29sIGlzSW5Ub3BMYXllcigp IGNvbnN0IHsgcmV0dXJuIGZhbHNlOyB9CisgICAgdm9pZCBzZXRJc0luVG9wTGF5ZXIoYm9vbCkg eyB9CiAjZW5kaWYKIAogcHJpdmF0ZToK