161242 2016-08-26 06:53:25 -0700 [GTK][Threaded Compositor] Several flaky tests 2020-01-23 08:36:46 -0800 1 1 1 Unclassified WebKit Tools / Tests WebKit Local Build Unspecified Unspecified RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=160450 https://bugs.webkit.org/show_bug.cgi?id=206662 Gtk P2 Normal --- 1 cgarcia webkit-unassigned bugs-noreply clopez lforschler mcatanzaro zan oldest_to_newest 1223498 0 cgarcia 2016-08-26 06:53:25 -0700 Even after fixing bug #160450 we still have a lot of laky tests sometimes in the bots. We no longer see the problem of scrollbars partially rendered, but we see scrollbars in some cases where they shouldn't be there at all (the contents are not bigger than the view size). That made me think that maybe there are tests leaving the view in an inconsistent state, most of the flaky tests are ref tests and all run by the same worker. But I tried to run all the tests using a single worker and I couldn't reproduce the problem so there must be something else. The other thing I can think of is that maybe in some cases the bot is more overloaded and a particular worker has less priority and things happen slower. We are still assuming that scheduling the task in the next loop iteration in the UI process after a force redraw ensures a redraw. The patch I initially posted in bug #160450 as a workaround tried to fix that assumption. I'm not sure that's the problem though, but we could try that patch and roll it out if it doesn't work. I'm a bit lost with this, because it only happens sometimes in the bots and I've never been able to reproduce it locally in any of machines I've tried. 1223508 1 mcatanzaro 2016-08-26 08:21:20 -0700 Doesn't hurt to try. 1223569 2 clopez 2016-08-26 10:19:58 -0700 (In reply to comment #0) > Even after fixing bug #160450 we still have a lot of laky tests sometimes in > the bots. We no longer see the problem of scrollbars partially rendered, but > we see scrollbars in some cases where they shouldn't be there at all (the > contents are not bigger than the view size). That made me think that maybe > there are tests leaving the view in an inconsistent state, most of the flaky > tests are ref tests and all run by the same worker. But I tried to run all > the tests using a single worker and I couldn't reproduce the problem so > there must be something else. The other thing I can think of is that maybe > in some cases the bot is more overloaded and a particular worker has less > priority and things happen slower. We are still assuming that scheduling the > task in the next loop iteration in the UI process after a force redraw > ensures a redraw. The patch I initially posted in bug #160450 as a > workaround tried to fix that assumption. I'm not sure that's the problem > though, but we could try that patch and roll it out if it doesn't work. I'm > a bit lost with this, because it only happens sometimes in the bots and I've > never been able to reproduce it locally in any of machines I've tried. I think you will be able to reproduce this if you run the whole test suite instead a subset of it. And this is something that I believe was happening before the threaded compositor with other kind of tests. I have found many tests that are flaky when the whole test suite is run, but if you run then manually or you run a subset of the test suite (for example: run only the fast/ tests). Then its not longer reproducible. I'm not sure if the problem is on webkit itself or is in the tooling and the way the tests are ran. 1223885 3 cgarcia 2016-08-26 23:42:33 -0700 (In reply to comment #2) > (In reply to comment #0) > > Even after fixing bug #160450 we still have a lot of laky tests sometimes in > > the bots. We no longer see the problem of scrollbars partially rendered, but > > we see scrollbars in some cases where they shouldn't be there at all (the > > contents are not bigger than the view size). That made me think that maybe > > there are tests leaving the view in an inconsistent state, most of the flaky > > tests are ref tests and all run by the same worker. But I tried to run all > > the tests using a single worker and I couldn't reproduce the problem so > > there must be something else. The other thing I can think of is that maybe > > in some cases the bot is more overloaded and a particular worker has less > > priority and things happen slower. We are still assuming that scheduling the > > task in the next loop iteration in the UI process after a force redraw > > ensures a redraw. The patch I initially posted in bug #160450 as a > > workaround tried to fix that assumption. I'm not sure that's the problem > > though, but we could try that patch and roll it out if it doesn't work. I'm > > a bit lost with this, because it only happens sometimes in the bots and I've > > never been able to reproduce it locally in any of machines I've tried. > > I think you will be able to reproduce this if you run the whole test suite > instead a subset of it. I did run all the tests using a single worker. > And this is something that I believe was happening before the threaded > compositor with other kind of tests. > > I have found many tests that are flaky when the whole test suite is run, but > if you run then manually or you run a subset of the test suite (for example: > run only the fast/ tests). Then its not longer reproducible. > > I'm not sure if the problem is on webkit itself or is in the tooling and the > way the tests are ran. I'm pretty sure the problem is in the tests infrastructure. 1223888 4 cgarcia 2016-08-27 02:14:32 -0700 (In reply to comment #1) > Doesn't hurt to try. Yes, I don't think it will fix it, to be honest, but actually ensuring a drawing in dispatchAfterEnsuringDrawing instead of assuming it will happen in the next run loop iteration makes sense in any case. So, let's see if it helps. 1223890 5 cgarcia 2016-08-27 02:20:53 -0700 Committed r205075: <http://trac.webkit.org/changeset/205075> 1224000 6 mcatanzaro 2016-08-27 17:58:43 -0700 (In reply to comment #4) > Yes, I don't think it will fix it, to be honest Right as usual. :( > but actually ensuring a > drawing in dispatchAfterEnsuringDrawing instead of assuming it will happen > in the next run loop iteration makes sense in any case. Agreed. 1224001 7 mcatanzaro 2016-08-27 17:59:14 -0700 (Reopening.) 1224060 8 cgarcia 2016-08-28 03:38:01 -0700 (In reply to comment #6) > (In reply to comment #4) > > Yes, I don't think it will fix it, to be honest > > Right as usual. :( However, it seems the number of flaky tests has been reduced a bit, and what is more important, the errors we see now are different too. Before the patch, there were tests in which we were showing scrollbars when we shouldn't. Now what I see is that contents are blurry and/or clipped, and in many of the cases both the expected and the actual rendering are wrong. So, I think there's a condition somewhere that can leave a different page scale or device scale factor in the web view that affects other tests. > > but actually ensuring a > > drawing in dispatchAfterEnsuringDrawing instead of assuming it will happen > > in the next run loop iteration makes sense in any case. > > Agreed. 1224078 9 mcatanzaro 2016-08-28 12:39:52 -0700 (In reply to comment #8) > However, it seems the number of flaky tests has been reduced a bit It was probably just luck: https://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release%20%28Tests%29/builds/17930 1224116 10 zan 2016-08-28 23:43:09 -0700 Would it be possible to test on the bots without using the software rasterizer? The clipping issues look as if the resizing of the underlying pixmap is not yet complete, or as if just a part of it is rendered. 1224140 11 cgarcia 2016-08-29 01:21:31 -0700 (In reply to comment #10) > Would it be possible to test on the bots without using the software > rasterizer? Yes, please, swrast doesn't work with wayland either, because of eglCreateImage being dummy when using the software rasterizer. > The clipping issues look as if the resizing of the underlying pixmap is not > yet complete, or as if just a part of it is rendered. Why are we using the software path, to not depend on the bot drivers? Maybe that's why I could never reproduce those issues. And that would explain why all this started when switched to the threaded compositor. 1224548 12 clopez 2016-08-30 06:31:09 -0700 (In reply to comment #11) > (In reply to comment #10) > > Would it be possible to test on the bots without using the software > > rasterizer? > > Yes, please, swrast doesn't work with wayland either, because of > eglCreateImage being dummy when using the software rasterizer. > > > The clipping issues look as if the resizing of the underlying pixmap is not > > yet complete, or as if just a part of it is rendered. > > Why are we using the software path, to not depend on the bot drivers? Maybe > that's why I could never reproduce those issues. And that would explain why > all this started when switched to the threaded compositor. We use swrast because its the best way of ensuring that developers can get consistent results for the layout tests. Otherwise it will be a nightmare. Think in developers having nvidia cards, or intel ones. With different versions of the drivers, etc. I have tested the following: 1) Reproduce the problem. I was able to do this at the first try. The trick is run the whole test suite using the same workers as number of CPUs, which is the default. So if you want to reproduce this, don't force any number of workers and simply tun the full test suite. I did this: $ Tools/Scripts/run-webkit-tests --no-show-results --no-new-test-results --no-sample-on-timeout --results-directory layout-test-results-xvfb-swrast --debug-rwt-logging --release --gtk And I got this: https://people.igalia.com/clopez/wkbug/161242/xresults/layout-test-results-xvfb-swrast/results.html From the stdout.log, you see that I got 122 unexpected image-only flakiness (122): https://people.igalia.com/clopez/wkbug/161242/xresults/layout-test-results-xvfb-swrast/ Now I did the same but using my native x11 display with the opengl nvidia drivers. To do that, simply export the variable USE_NATIVE_XDISPLAY=1 before running the tests. I did several runs of this, storing each run in a different directory. This are the results: -> Run 1: Unexpected flakiness: image-only failures (159) https://people.igalia.com/clopez/wkbug/161242/xresults/layout-test-results-xvfb-xdisplay1/results.html -> Run 2: Unexpected flakiness: image-only failures (25) https://people.igalia.com/clopez/wkbug/161242/xresults/layout-test-results-xvfb-xdisplay2/results.html -> Run 3: Unexpected flakiness: image-only failures (22) https://people.igalia.com/clopez/wkbug/161242/xresults/layout-test-results-xvfb-xdisplay3/results.html So, my conclusion is that is not caused by swrast. I can reproduce the flakiness also with the nvidia driver. BTW, Check this results: - swrast: https://people.igalia.com/clopez/wkbug/161242/xresults/layout-test-results-xvfb-swrast/fast/flexbox/auto-height-with-flex-diffs.html - nvidia run 1: https://people.igalia.com/clopez/wkbug/161242/xresults/layout-test-results-xvfb-xdisplay1/fast/flexbox/auto-height-with-flex-diffs.html - nvidia run 2: https://people.igalia.com/clopez/wkbug/161242/xresults/layout-test-results-xvfb-xdisplay2/fast/flexbox/auto-height-with-flex-diffs.html As you can see. Both the expected and the actual images are different on each one of the three cases. On the nvidia run 2, the expected result didn't even reached the point to render anything than a blank viewport. I think that using swrast instead of hardware-backed opengl is not the problem here. 1224550 13 cgarcia 2016-08-30 06:47:28 -0700 Thanks for the so detailed analysis, Carlos. So, the results are the same than in the bots, both the expected and actual files are incorrectly rendered and scale factors seem to have something to do there. Maybe there's a condition (test timing out or crashing) causing that any of the scale factors is note correctly reset between tests. The device scale factor is changed from the UI process, while all other are changed in the web process on every BeginTest message. 1225310 14 cgarcia 2016-09-01 05:06:43 -0700 Finally found the issue. The problem is the viewport controller, that is changed by the fixed layout tests, but never reset. There's also a problem with the fixed layout tests that could leave the view in an inconsistent state as I explained in bug #160117. I'm already working on a proper fix, but in the meantime I've skipped fixed layout tests (they are only two) to make sure we don't see all those flaky tests in the bots anymore. To easily reproduce it, launch run-webkit-tests with a single worker job and run fixed layout test first and then other ref tests, for example: $ run-webkit-tests --gtk --release --child-processes=1 fast/fixed-layout/fixed-layout.html fast/regions 1225376 15 mcatanzaro 2016-09-01 10:33:52 -0700 (In reply to comment #14) > Finally found the issue. The problem is the viewport controller, that is > changed by the fixed layout tests, but never reset. There's also a problem > with the fixed layout tests that could leave the view in an inconsistent > state as I explained in bug #160117. I'm already working on a proper fix, > but in the meantime I've skipped fixed layout tests (they are only two) to > make sure we don't see all those flaky tests in the bots anymore. To easily > reproduce it, launch run-webkit-tests with a single worker job and run fixed > layout test first and then other ref tests, for example: > > $ run-webkit-tests --gtk --release --child-processes=1 > fast/fixed-layout/fixed-layout.html fast/regions It's clearly a big improvement, good job. But it's still not completely fixed. We have 50 unexpected passes in build #18009, for example. These are tests that normally always fail, but occasionally pass now that we've enabled threaded compositor. 1225707 16 cgarcia 2016-09-01 22:40:04 -0700 (In reply to comment #15) > (In reply to comment #14) > > Finally found the issue. The problem is the viewport controller, that is > > changed by the fixed layout tests, but never reset. There's also a problem > > with the fixed layout tests that could leave the view in an inconsistent > > state as I explained in bug #160117. I'm already working on a proper fix, > > but in the meantime I've skipped fixed layout tests (they are only two) to > > make sure we don't see all those flaky tests in the bots anymore. To easily > > reproduce it, launch run-webkit-tests with a single worker job and run fixed > > layout test first and then other ref tests, for example: > > > > $ run-webkit-tests --gtk --release --child-processes=1 > > fast/fixed-layout/fixed-layout.html fast/regions > > It's clearly a big improvement, good job. > > But it's still not completely fixed. We have 50 unexpected passes in build > #18009, for example. These are tests that normally always fail, but > occasionally pass now that we've enabled threaded compositor. You are assuming again that there's a single issue. This particular problem that was making both the expected and actual rendering of reftest fail, was caused by the fixed layout (it changes the viewport controller state that is never reset). Of course there are more issues, but I think the situation now is mostly the same to what we had before switching to the threaded compositor. 1225751 17 mcatanzaro 2016-09-02 04:52:41 -0700 (In reply to comment #16) > You are assuming again that there's a single issue. No, clearly there were many different issues, as you've fixed three different issues so far.... > I think the situation now > is mostly the same to what we had before switching to the threaded > compositor. Yes, except for the fact that sometimes a bunch of tests pass when they usually fail. In build #18023 we have 84 unexpected passes; that never happened before. What's interesting is these tests either always pass or always fail in a particular run of run-webkit-tests; they are clearly flaky, but they don't contribute to the flakiness count. 1225761 18 cgarcia 2016-09-02 06:25:48 -0700 (In reply to comment #17) > (In reply to comment #16) > > You are assuming again that there's a single issue. > > No, clearly there were many different issues, as you've fixed three > different issues so far.... > > > I think the situation now > > is mostly the same to what we had before switching to the threaded > > compositor. > > Yes, except for the fact that sometimes a bunch of tests pass when they > usually fail. In build #18023 we have 84 unexpected passes; that never > happened before. What's interesting is these tests either always pass or > always fail in a particular run of run-webkit-tests; they are clearly flaky, > but they don't contribute to the flakiness count. We should probably mark them as pass, to see what's wrong when they fail 1225772 19 clopez 2016-09-02 08:32:44 -0700 (In reply to comment #18) > (In reply to comment #17) > > (In reply to comment #16) > > > You are assuming again that there's a single issue. > > > > No, clearly there were many different issues, as you've fixed three > > different issues so far.... > > > > > I think the situation now > > > is mostly the same to what we had before switching to the threaded > > > compositor. > > > > Yes, except for the fact that sometimes a bunch of tests pass when they > > usually fail. In build #18023 we have 84 unexpected passes; that never > > happened before. What's interesting is these tests either always pass or > > always fail in a particular run of run-webkit-tests; they are clearly flaky, > > but they don't contribute to the flakiness count. > > We should probably mark them as pass, to see what's wrong when they fail That don't makes much sense to me. You can see the failure diff even if they are expected failures. You just have to navigate under https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20%28Tests%29/ to find them. For example: 1) Check the unexpected passes at end of build #18023 https://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release%20%28Tests%29/builds/18023/steps/layout-test/logs/stdio and pick 1 2) I pick: imported/mozilla/svg/blend-difference-stacking.html 3) Check that on the next build that test failed. Log of the next build: https://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release%20%28Tests%29/builds/18024/steps/layout-test/logs/stdio <--- yes it failed 4) Go to https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20%28Tests%29/ and find the results for build #18204 -> https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20%28Tests%29/r205335%20%2818024%29/ 5) Now under that folder navigate to imported/mozilla/svg/ and look for the blend-difference-stacking diff 6) Here you have it: https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20%28Tests%29/r205335%20%2818024%29/imported/mozilla/svg/blend-difference-stacking-diffs.html 1226087 20 cgarcia 2016-09-02 22:44:41 -0700 (In reply to comment #19) > (In reply to comment #18) > > (In reply to comment #17) > > > (In reply to comment #16) > > > > You are assuming again that there's a single issue. > > > > > > No, clearly there were many different issues, as you've fixed three > > > different issues so far.... > > > > > > > I think the situation now > > > > is mostly the same to what we had before switching to the threaded > > > > compositor. > > > > > > Yes, except for the fact that sometimes a bunch of tests pass when they > > > usually fail. In build #18023 we have 84 unexpected passes; that never > > > happened before. What's interesting is these tests either always pass or > > > always fail in a particular run of run-webkit-tests; they are clearly flaky, > > > but they don't contribute to the flakiness count. > > > > We should probably mark them as pass, to see what's wrong when they fail > > That don't makes much sense to me. > > You can see the failure diff even if they are expected failures. You just > have to navigate under > https://build.webkit.org/results/GTK%20Linux%2064- > bit%20Release%20%28Tests%29/ to find them. > > For example: > > 1) Check the unexpected passes at end of build #18023 > https://build.webkit.org/builders/GTK%20Linux%2064- > bit%20Release%20%28Tests%29/builds/18023/steps/layout-test/logs/stdio and > pick 1 > > 2) I pick: imported/mozilla/svg/blend-difference-stacking.html > > 3) Check that on the next build that test failed. Log of the next build: > https://build.webkit.org/builders/GTK%20Linux%2064- > bit%20Release%20%28Tests%29/builds/18024/steps/layout-test/logs/stdio <--- > yes it failed > > 4) Go to > https://build.webkit.org/results/GTK%20Linux%2064- > bit%20Release%20%28Tests%29/ and find the results for build #18204 -> > https://build.webkit.org/results/GTK%20Linux%2064- > bit%20Release%20%28Tests%29/r205335%20%2818024%29/ > > 5) Now under that folder navigate to imported/mozilla/svg/ and look for the > blend-difference-stacking diff > > 6) Here you have it: > https://build.webkit.org/results/GTK%20Linux%2064- > bit%20Release%20%28Tests%29/r205335%20%2818024%29/imported/mozilla/svg/blend- > difference-stacking-diffs.html hmm, well, not very convenient, but still. I have theory, though. When they unexpectedly pass, they don't actually pass, we just fail to render both the actual and expected files in the same way (for example a fully white image in both cases). That's a problem of the reftests. So, more interesting to see what's failing, which can be also reproduced locally more easily, would be to see what we render when they pass. 1226635 21 288009 cgarcia 2016-09-06 03:35:41 -0700 Created attachment 288009 Patch 1226678 22 288009 mcatanzaro 2016-09-06 07:55:40 -0700 Comment on attachment 288009 Patch (wrong bug) 1226683 23 288025 cgarcia 2016-09-06 08:41:16 -0700 Created attachment 288025 Patch 1226709 24 288025 mcatanzaro 2016-09-06 09:32:54 -0700 Comment on attachment 288025 Patch r=me for the CoordinatedGraphics changes. I'll let you decide whether or not to wait for an owner on the iOS code you moved; it looks clearly fine to me, though. 1227071 25 cgarcia 2016-09-06 23:43:08 -0700 Committed r205537: <http://trac.webkit.org/changeset/205537> 1227136 26 mcatanzaro 2016-09-07 05:26:20 -0700 Reopening since we still have one bug causing flakiness left (per comment #17) 1227144 27 cgarcia 2016-09-07 06:09:20 -0700 Please no. Use new bug reports for remaining flaky tests. We have always had flaky tests, so remaining ones might not be related to threaded compositor. 1227173 28 mcatanzaro 2016-09-07 08:31:14 -0700 (In reply to comment #27) > Please no. Use new bug reports for remaining flaky tests. We have always had > flaky tests, so remaining ones might not be related to threaded compositor. Bug #161688. They are almost certainly related to threaded compositor; we've never had more than maybe 10 flaky tests appear in unexpected passes until threaded compositor, now we have dozens. 288009 2016-09-06 03:35:41 -0700 2016-09-06 07:55:40 -0700 Patch wk2-plugins-cache.diff text/plain 2817 cgarcia ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQyL0NoYW5nZUxvZyBiL1NvdXJjZS9XZWJLaXQyL0No YW5nZUxvZwppbmRleCBhMzg4OGZlLi5kZTQ0MDBhIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViS2l0 Mi9DaGFuZ2VMb2cKKysrIGIvU291cmNlL1dlYktpdDIvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTcg QEAKKzIwMTYtMDktMDYgIENhcmxvcyBHYXJjaWEgQ2FtcG9zICA8Y2dhcmNpYUBpZ2FsaWEuY29t PgorCisgICAgICAgIFtHVEtdW1dheWxhbmRdIGV2aW5jZS1icm93c2VyLXBsdWdpbiBwcmV2ZW50 cyB2aWV3aW5nIFBERnMKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcu Y2dpP2lkPTE1ODY5NworCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisg ICAgICAgIFVzZSBhIGRpZmZlcmVudCBjYWNoZSBmaWxlIGZvciBwbHVnaW5zIGRlcGVuZGluZyBv biB0aGUgY3VycmVudCBwbGF0Zm9ybSBkaXNwbGF5LiBQbHVnaW5zIGNhbiBjbGFpbSB0byB3b3Jr IG9uCisgICAgICAgIFgxMSBidXQgbm90IG9uIFdheWxhbmQsIGZvciBleGFtcGxlLCBpZiB0aGV5 IG5lZWQgWEVtZWJlZCB0byB3b3JrLiBUaGF0J3MgdGhlIGNhc2Ugb2YgdGhlIGV2aW5jZSBicm93 c2VyIHBsdWdpbi4KKworICAgICAgICAqIFVJUHJvY2Vzcy9QbHVnaW5zL2d0ay9QbHVnaW5JbmZv Q2FjaGUuY3BwOgorICAgICAgICAoV2ViS2l0OjpjYWNoZUZpbGVuYW1lRm9yQ3VycmVudERpc3Bs YXkpOgorICAgICAgICAoV2ViS2l0OjpQbHVnaW5JbmZvQ2FjaGU6OlBsdWdpbkluZm9DYWNoZSk6 CisKIDIwMTYtMDktMDUgIFphbiBEb2JlcnNlayAgPHpkb2JlcnNla0BpZ2FsaWEuY29tPgogCiAg ICAgICAgIEZpeCBFTkFCTEUoR0FNRVBBRCkgYnVpbGQgZXJyb3JzIG9uIG5vbi1Db2NvYSBwbGF0 Zm9ybXMKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQyL1VJUHJvY2Vzcy9QbHVnaW5zL2d0ay9Q bHVnaW5JbmZvQ2FjaGUuY3BwIGIvU291cmNlL1dlYktpdDIvVUlQcm9jZXNzL1BsdWdpbnMvZ3Rr L1BsdWdpbkluZm9DYWNoZS5jcHAKaW5kZXggOTM0NTAzMy4uNjRiNGNhYyAxMDA2NDQKLS0tIGEv U291cmNlL1dlYktpdDIvVUlQcm9jZXNzL1BsdWdpbnMvZ3RrL1BsdWdpbkluZm9DYWNoZS5jcHAK KysrIGIvU291cmNlL1dlYktpdDIvVUlQcm9jZXNzL1BsdWdpbnMvZ3RrL1BsdWdpbkluZm9DYWNo ZS5jcHAKQEAgLTMwLDYgKzMwLDcgQEAKIAogI2luY2x1ZGUgIk5ldHNjYXBlUGx1Z2luTW9kdWxl LmgiCiAjaW5jbHVkZSA8V2ViQ29yZS9GaWxlU3lzdGVtLmg+CisjaW5jbHVkZSA8V2ViQ29yZS9Q bGF0Zm9ybURpc3BsYXkuaD4KICNpbmNsdWRlIDx3dGYvdGV4dC9DU3RyaW5nLmg+CiAKIG5hbWVz cGFjZSBXZWJLaXQgewpAQCAtNDIsNiArNDMsMjEgQEAgUGx1Z2luSW5mb0NhY2hlJiBQbHVnaW5J bmZvQ2FjaGU6OnNpbmdsZXRvbigpCiAgICAgcmV0dXJuIHBsdWdpbkluZm9DYWNoZTsKIH0KIAor c3RhdGljIGlubGluZSBjb25zdCBjaGFyKiBjYWNoZUZpbGVuYW1lRm9yQ3VycmVudERpc3BsYXko KQoreworI2lmIFBMQVRGT1JNKFgxMSkKKyAgICBpZiAoV2ViQ29yZTo6UGxhdGZvcm1EaXNwbGF5 OjpzaGFyZWREaXNwbGF5KCkudHlwZSgpID09IFdlYkNvcmU6OlBsYXRmb3JtRGlzcGxheTo6VHlw ZTo6WDExKQorICAgICAgICByZXR1cm4gInBsdWdpbnMteDExIjsKKyNlbmRpZgorI2lmIFBMQVRG T1JNKFdBWUxBTkQpCisgICAgaWYgKFdlYkNvcmU6OlBsYXRmb3JtRGlzcGxheTo6c2hhcmVkRGlz cGxheSgpLnR5cGUoKSA9PSBXZWJDb3JlOjpQbGF0Zm9ybURpc3BsYXk6OlR5cGU6OldheWxhbmQp CisgICAgICAgIHJldHVybiAicGx1Z2lucy13YXlsYW5kIjsKKyNlbmRpZgorCisgICAgQVNTRVJU X05PVF9SRUFDSEVEKCk7CisgICAgcmV0dXJuICJwbHVnaW5zIjsKK30KKwogUGx1Z2luSW5mb0Nh Y2hlOjpQbHVnaW5JbmZvQ2FjaGUoKQogICAgIDogbV9jYWNoZUZpbGUoZ19rZXlfZmlsZV9uZXco KSkKICAgICAsIG1fc2F2ZVRvRmlsZUlkbGUoUnVuTG9vcDo6bWFpbigpLCB0aGlzLCAmUGx1Z2lu SW5mb0NhY2hlOjpzYXZlVG9GaWxlKQpAQCAtNTEsNyArNjcsMTEgQEAgUGx1Z2luSW5mb0NhY2hl OjpQbHVnaW5JbmZvQ2FjaGUoKQogCiAgICAgR1VuaXF1ZVB0cjxjaGFyPiBjYWNoZURpcmVjdG9y eShnX2J1aWxkX2ZpbGVuYW1lKGdfZ2V0X3VzZXJfY2FjaGVfZGlyKCksICJ3ZWJraXRndGsiLCBu dWxscHRyKSk7CiAgICAgaWYgKFdlYkNvcmU6Om1ha2VBbGxEaXJlY3RvcmllcyhjYWNoZURpcmVj dG9yeS5nZXQoKSkpIHsKLSAgICAgICAgbV9jYWNoZVBhdGgucmVzZXQoZ19idWlsZF9maWxlbmFt ZShjYWNoZURpcmVjdG9yeS5nZXQoKSwgInBsdWdpbnMiLCBudWxscHRyKSk7CisgICAgICAgIC8v IERlbGV0ZSBvbGQgY2FjaGUgZmlsZS4KKyAgICAgICAgR1VuaXF1ZVB0cjxjaGFyPiBvbGRDYWNo ZVBhdGgoZ19idWlsZF9maWxlbmFtZShjYWNoZURpcmVjdG9yeS5nZXQoKSwgInBsdWdpbnMiLCBu dWxscHRyKSk7CisgICAgICAgIFdlYkNvcmU6OmRlbGV0ZUZpbGUoV2ViQ29yZTo6ZmlsZW5hbWVU b1N0cmluZyhvbGRDYWNoZVBhdGguZ2V0KCkpKTsKKworICAgICAgICBtX2NhY2hlUGF0aC5yZXNl dChnX2J1aWxkX2ZpbGVuYW1lKGNhY2hlRGlyZWN0b3J5LmdldCgpLCBjYWNoZUZpbGVuYW1lRm9y Q3VycmVudERpc3BsYXkoKSwgbnVsbHB0cikpOwogICAgICAgICBnX2tleV9maWxlX2xvYWRfZnJv bV9maWxlKG1fY2FjaGVGaWxlLmdldCgpLCBtX2NhY2hlUGF0aC5nZXQoKSwgR19LRVlfRklMRV9O T05FLCBudWxscHRyKTsKICAgICB9CiAK 288025 2016-09-06 08:41:16 -0700 2016-09-06 09:32:54 -0700 Patch wk2-tc-flaky-tests.diff text/plain 8934 cgarcia ZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL0NoYW5nZUxvZyBiL0xheW91dFRlc3RzL0NoYW5nZUxv ZwppbmRleCA5ZGJiNmJhLi4yZTNkYmM2IDEwMDY0NAotLS0gYS9MYXlvdXRUZXN0cy9DaGFuZ2VM b2cKKysrIGIvTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTQgQEAKKzIwMTYtMDkt MDYgIENhcmxvcyBHYXJjaWEgQ2FtcG9zICA8Y2dhcmNpYUBpZ2FsaWEuY29tPgorCisgICAgICAg IFtHVEtdW1RocmVhZGVkIENvbXBvc2l0b3JdIFNldmVyYWwgZmxha3kgdGVzdHMKKyAgICAgICAg aHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTE2MTI0MgorCisgICAgICAg IFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIFVuc2tpcCBjb21wb3NpdGlu Zy9maXhlZC13aXRoLWZpeGVkLWxheW91dC5odG1sIGFuZCBmYXN0L2ZpeGVkLWxheW91dC9maXhl ZC1sYXlvdXQuaHRtbC4KKworICAgICAgICAqIHBsYXRmb3JtL2d0ay9UZXN0RXhwZWN0YXRpb25z OgorCiAyMDE2LTA5LTA2ICBQaGlsaXBwZSBOb3JtYW5kICA8cG5vcm1hbmRAaWdhbGlhLmNvbT4K IAogICAgICAgICBVbnJldmlld2VkIEdUSyBnYXJkZW5pbmcKZGlmZiAtLWdpdCBhL0xheW91dFRl c3RzL3BsYXRmb3JtL2d0ay9UZXN0RXhwZWN0YXRpb25zIGIvTGF5b3V0VGVzdHMvcGxhdGZvcm0v Z3RrL1Rlc3RFeHBlY3RhdGlvbnMKaW5kZXggMmY3NTcyMy4uYTRhY2Q4YiAxMDA2NDQKLS0tIGEv TGF5b3V0VGVzdHMvcGxhdGZvcm0vZ3RrL1Rlc3RFeHBlY3RhdGlvbnMKKysrIGIvTGF5b3V0VGVz dHMvcGxhdGZvcm0vZ3RrL1Rlc3RFeHBlY3RhdGlvbnMKQEAgLTI4MDcsOSArMjgwNyw2IEBAIHdl YmtpdC5vcmcvYi8xNjAxMTkgc3RvcmFnZS9pbmRleGVkZGIvb2JqZWN0c3RvcmUtY3Vyc29yLmh0 bWwgWyBUaW1lb3V0IFBhc3MgXQogd2Via2l0Lm9yZy9iLzE2MDExOSBzdmcvcmVwYWludC9hZGQt b3V0bGluZS1wcm9wZXJ0eS1vbi1yb290Lmh0bWwgWyBJbWFnZU9ubHlGYWlsdXJlIF0KIHdlYmtp dC5vcmcvYi8xNjAxMTkgc3ZnL3JlcGFpbnQvcmVtb3ZlLW91dGxpbmUtcHJvcGVydHktb24tcm9v dC5odG1sIFsgSW1hZ2VPbmx5RmFpbHVyZSBdCiAKLXdlYmtpdC5vcmcvYi8xNjEyNDIgY29tcG9z aXRpbmcvZml4ZWQtd2l0aC1maXhlZC1sYXlvdXQuaHRtbCBbIFNraXAgXQotd2Via2l0Lm9yZy9i LzE2MTI0MiBmYXN0L2ZpeGVkLWxheW91dC9maXhlZC1sYXlvdXQuaHRtbCBbIFNraXAgXQotCiB3 ZWJraXQub3JnL2IvMTYxMjQyIGFuaW1hdGlvbnMvbmVnYXRpdmUtZGVsYXkuaHRtbCBbIFBhc3Mg RmFpbHVyZSBdCiAKICMvLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vCmRpZmYgLS1naXQg YS9Tb3VyY2UvV2ViS2l0Mi9DaGFuZ2VMb2cgYi9Tb3VyY2UvV2ViS2l0Mi9DaGFuZ2VMb2cKaW5k ZXggZGU0NDAwYS4uNjA1MDU4YSAxMDA2NDQKLS0tIGEvU291cmNlL1dlYktpdDIvQ2hhbmdlTG9n CisrKyBiL1NvdXJjZS9XZWJLaXQyL0NoYW5nZUxvZwpAQCAtMSw1ICsxLDMxIEBACiAyMDE2LTA5 LTA2ICBDYXJsb3MgR2FyY2lhIENhbXBvcyAgPGNnYXJjaWFAaWdhbGlhLmNvbT4KIAorICAgICAg ICBbR1RLXVtUaHJlYWRlZCBDb21wb3NpdG9yXSBTZXZlcmFsIGZsYWt5IHRlc3RzCisgICAgICAg IGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xNjEyNDIKKworICAgICAg ICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBSZXNldCB0aGUgdmlld3Bv cnQgYXR0cmlidXRlcyBvbiBTaW1wbGVWaWV3cG9ydENvbnRyb2xsZXIgd2hlbiB2aWV3cG9ydCBh dHRyaWJ1dGVzIGNoYW5nZSBhbmQgZml4ZWQgbGF5b3V0IGlzCisgICAgICAgIG5vdCB1c2VkLiBX ZSB3ZXJlIG9ubHkgdXBkYXRpbmcgdGhlIHZpZXdwb3J0IGF0dHJpYnV0ZXMgd2hlbiBmaXhlZCBs YXlvdXQgd2FzIHVzZWQsIGJ1dCBub3QgcmVzZXR0aW5nIHRoZW0gYWdhaW4KKyAgICAgICAgd2hl biBpdCdzIG5vIGxvbmdlciB1c2VkLiBUaGF0IGNhdXNlZCB0aGF0IHJlZmVyZW5jZSB0ZXN0cyBy dW4gYWZ0ZXIgZmFzdC9maXhlZC1sYXlvdXQvZml4ZWQtbGF5b3V0Lmh0bWwgb3IKKyAgICAgICAg Y29tcG9zaXRpbmcvZml4ZWQtd2l0aC1maXhlZC1sYXlvdXQuaHRtbCBpbiB0aGUgc2FtZSB3b3Jr ZXIgdGhyZWFkIHdlcmUgaW5jb3JyZWN0bHkgcmVuZGVyZWQuCisKKyAgICAgICAgKiBXZWJQcm9j ZXNzL1dlYkNvcmVTdXBwb3J0L1dlYkNocm9tZUNsaWVudC5jcHA6CisgICAgICAgIChXZWJLaXQ6 OldlYkNocm9tZUNsaWVudDo6ZGlzcGF0Y2hWaWV3cG9ydFByb3BlcnRpZXNEaWRDaGFuZ2UpOiBS ZW1vdmUgaWZkZWZzIGFuZCBjYWxsCisgICAgICAgIFdlYlBhZ2U6OnZpZXdwb3J0UHJvcGVydGll c0RpZENoYW5nZSgpIHVuY29uZGl0aW9uYWxseS4KKyAgICAgICAgKiBXZWJQcm9jZXNzL1dlYlBh Z2UvV2ViUGFnZS5jcHA6CisgICAgICAgIChXZWJLaXQ6OldlYlBhZ2U6OnNldFNpemUpOiBQYXNz IGN1cnJlbnQgcGFnZSB2aWV3cG9ydCBhcmd1bWVudHMgdG8gc2VuZFZpZXdwb3J0QXR0cmlidXRl c0NoYW5nZWQoKS4KKyAgICAgICAgKFdlYktpdDo6V2ViUGFnZTo6c2VuZFZpZXdwb3J0QXR0cmli dXRlc0NoYW5nZWQpOiBJdCBub3cgcmVjZWl2ZXMgdGhlIHZpZXdwb3J0IGFyZ3VtZW50cy4KKyAg ICAgICAgKFdlYktpdDo6V2ViUGFnZTo6dmlld3BvcnRQcm9wZXJ0aWVzRGlkQ2hhbmdlKTogTW92 ZSB0aGUgaU9TIGltcGxlbWVudGF0aW9uIGZyb20gV2ViUGFnZUlPUy5tbSBhbmQgZm9yCisgICAg ICAgIGNvb3JkaW5hdGVkIGdyYXBoaWNzIGNhbGwgc2VuZFZpZXdwb3J0QXR0cmlidXRlc0NoYW5n ZWQoKSB3aGVuIGZpeGVkIGxheW91dCBpcyB1c2VkIG9yIHJlc2V0IHRoZSB2aWV3cG9ydAorICAg ICAgICBhdHRyaWJ1dGVzIHdoZW4gbm90IHVzZWQgaW4gY2FzZSBvZiB0aHJlYWRlZCBjb21wb3Np dG9yLgorICAgICAgICAqIFdlYlByb2Nlc3MvV2ViUGFnZS9XZWJQYWdlLmg6CisgICAgICAgIChX ZWJLaXQ6OldlYlBhZ2U6OnZpZXdwb3J0UHJvcGVydGllc0RpZENoYW5nZSk6IE1vdmVkIG91dCBv ZiBpT1MgaWZkZWYuCisgICAgICAgICogV2ViUHJvY2Vzcy9XZWJQYWdlL2lvcy9XZWJQYWdlSU9T Lm1tOgorICAgICAgICAoV2ViS2l0OjpXZWJQYWdlOjp2aWV3cG9ydFByb3BlcnRpZXNEaWRDaGFu Z2UpOiBEZWxldGVkLgorCisyMDE2LTA5LTA2ICBDYXJsb3MgR2FyY2lhIENhbXBvcyAgPGNnYXJj aWFAaWdhbGlhLmNvbT4KKwogICAgICAgICBbR1RLXVtXYXlsYW5kXSBldmluY2UtYnJvd3Nlci1w bHVnaW4gcHJldmVudHMgdmlld2luZyBQREZzCiAgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQu b3JnL3Nob3dfYnVnLmNnaT9pZD0xNTg2OTcKIApkaWZmIC0tZ2l0IGEvU291cmNlL1dlYktpdDIv V2ViUHJvY2Vzcy9XZWJDb3JlU3VwcG9ydC9XZWJDaHJvbWVDbGllbnQuY3BwIGIvU291cmNlL1dl YktpdDIvV2ViUHJvY2Vzcy9XZWJDb3JlU3VwcG9ydC9XZWJDaHJvbWVDbGllbnQuY3BwCmluZGV4 IDQzY2ZmYjMuLjk4NjUzZWMgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQyL1dlYlByb2Nlc3Mv V2ViQ29yZVN1cHBvcnQvV2ViQ2hyb21lQ2xpZW50LmNwcAorKysgYi9Tb3VyY2UvV2ViS2l0Mi9X ZWJQcm9jZXNzL1dlYkNvcmVTdXBwb3J0L1dlYkNocm9tZUNsaWVudC5jcHAKQEAgLTkyNCwxNiAr OTI0LDcgQEAgRmxvYXRTaXplIFdlYkNocm9tZUNsaWVudDo6YXZhaWxhYmxlU2NyZWVuU2l6ZSgp IGNvbnN0CiAKIHZvaWQgV2ViQ2hyb21lQ2xpZW50OjpkaXNwYXRjaFZpZXdwb3J0UHJvcGVydGll c0RpZENoYW5nZShjb25zdCBWaWV3cG9ydEFyZ3VtZW50cyYgdmlld3BvcnRBcmd1bWVudHMpIGNv bnN0CiB7Ci0gICAgVU5VU0VEX1BBUkFNKHZpZXdwb3J0QXJndW1lbnRzKTsKLSNpZiBQTEFURk9S TShJT1MpCiAgICAgbV9wYWdlLT52aWV3cG9ydFByb3BlcnRpZXNEaWRDaGFuZ2Uodmlld3BvcnRB cmd1bWVudHMpOwotI2VuZGlmCi0jaWYgVVNFKENPT1JESU5BVEVEX0dSQVBISUNTKQotICAgIGlm ICghbV9wYWdlLT51c2VGaXhlZExheW91dCgpKQotICAgICAgICByZXR1cm47Ci0KLSAgICBtX3Bh Z2UtPnNlbmRWaWV3cG9ydEF0dHJpYnV0ZXNDaGFuZ2VkKCk7Ci0jZW5kaWYKIH0KIAogdm9pZCBX ZWJDaHJvbWVDbGllbnQ6Om5vdGlmeVNjcm9sbGVyVGh1bWJJc1Zpc2libGVJblJlY3QoY29uc3Qg SW50UmVjdCYgc2Nyb2xsZXJUaHVtYikKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQyL1dlYlBy b2Nlc3MvV2ViUGFnZS9XZWJQYWdlLmNwcCBiL1NvdXJjZS9XZWJLaXQyL1dlYlByb2Nlc3MvV2Vi UGFnZS9XZWJQYWdlLmNwcAppbmRleCA1Nzg0MzBkLi5hNjBmZTM1IDEwMDY0NAotLS0gYS9Tb3Vy Y2UvV2ViS2l0Mi9XZWJQcm9jZXNzL1dlYlBhZ2UvV2ViUGFnZS5jcHAKKysrIGIvU291cmNlL1dl YktpdDIvV2ViUHJvY2Vzcy9XZWJQYWdlL1dlYlBhZ2UuY3BwCkBAIC0xMzc4LDEyICsxMzc4LDEy IEBAIHZvaWQgV2ViUGFnZTo6c2V0U2l6ZShjb25zdCBXZWJDb3JlOjpJbnRTaXplJiB2aWV3U2l6 ZSkKIAogI2lmIFVTRShDT09SRElOQVRFRF9HUkFQSElDUykKICAgICBpZiAodmlldy0+dXNlRml4 ZWRMYXlvdXQoKSkKLSAgICAgICAgc2VuZFZpZXdwb3J0QXR0cmlidXRlc0NoYW5nZWQoKTsKKyAg ICAgICAgc2VuZFZpZXdwb3J0QXR0cmlidXRlc0NoYW5nZWQobV9wYWdlLT52aWV3cG9ydEFyZ3Vt ZW50cygpKTsKICNlbmRpZgogfQogCiAjaWYgVVNFKENPT1JESU5BVEVEX0dSQVBISUNTKQotdm9p ZCBXZWJQYWdlOjpzZW5kVmlld3BvcnRBdHRyaWJ1dGVzQ2hhbmdlZCgpCit2b2lkIFdlYlBhZ2U6 OnNlbmRWaWV3cG9ydEF0dHJpYnV0ZXNDaGFuZ2VkKGNvbnN0IFZpZXdwb3J0QXJndW1lbnRzJiB2 aWV3cG9ydEFyZ3VtZW50cykKIHsKICAgICBGcmFtZVZpZXcqIHZpZXcgPSBtX3BhZ2UtPm1haW5G cmFtZSgpLnZpZXcoKTsKICAgICBBU1NFUlQodmlldyAmJiB2aWV3LT51c2VGaXhlZExheW91dCgp KTsKQEAgLTE0MDEsNyArMTQwMSw3IEBAIHZvaWQgV2ViUGFnZTo6c2VuZFZpZXdwb3J0QXR0cmli dXRlc0NoYW5nZWQoKQogICAgIGludCBkZXZpY2VXaWR0aCA9IChzZXR0aW5ncy5kZXZpY2VXaWR0 aCgpID4gMCkgPyBzZXR0aW5ncy5kZXZpY2VXaWR0aCgpIDogbV92aWV3U2l6ZS53aWR0aCgpOwog ICAgIGludCBkZXZpY2VIZWlnaHQgPSAoc2V0dGluZ3MuZGV2aWNlSGVpZ2h0KCkgPiAwKSA/IHNl dHRpbmdzLmRldmljZUhlaWdodCgpIDogbV92aWV3U2l6ZS5oZWlnaHQoKTsKIAotICAgIFZpZXdw b3J0QXR0cmlidXRlcyBhdHRyID0gY29tcHV0ZVZpZXdwb3J0QXR0cmlidXRlcyhtX3BhZ2UtPnZp ZXdwb3J0QXJndW1lbnRzKCksIG1pbmltdW1MYXlvdXRGYWxsYmFja1dpZHRoLCBkZXZpY2VXaWR0 aCwgZGV2aWNlSGVpZ2h0LCAxLCBtX3ZpZXdTaXplKTsKKyAgICBWaWV3cG9ydEF0dHJpYnV0ZXMg YXR0ciA9IGNvbXB1dGVWaWV3cG9ydEF0dHJpYnV0ZXModmlld3BvcnRBcmd1bWVudHMsIG1pbmlt dW1MYXlvdXRGYWxsYmFja1dpZHRoLCBkZXZpY2VXaWR0aCwgZGV2aWNlSGVpZ2h0LCAxLCBtX3Zp ZXdTaXplKTsKIAogICAgIC8vIElmIG5vIGxheW91dCB3YXMgZG9uZSB5ZXQgc2V0IGNvbnRlbnRG aXhlZE9yaWdpbiB0byAoMCwwKS4KICAgICBJbnRQb2ludCBjb250ZW50Rml4ZWRPcmlnaW4gPSB2 aWV3LT5kaWRGaXJzdExheW91dCgpID8gdmlldy0+Zml4ZWRWaXNpYmxlQ29udGVudFJlY3QoKS5s b2NhdGlvbigpIDogSW50UG9pbnQoKTsKQEAgLTE3MzAsNiArMTczMCwyOCBAQCBJbnRTaXplIFdl YlBhZ2U6OmZpeGVkTGF5b3V0U2l6ZSgpIGNvbnN0CiAgICAgcmV0dXJuIHZpZXctPmZpeGVkTGF5 b3V0U2l6ZSgpOwogfQogCit2b2lkIFdlYlBhZ2U6OnZpZXdwb3J0UHJvcGVydGllc0RpZENoYW5n ZShjb25zdCBWaWV3cG9ydEFyZ3VtZW50cyYgdmlld3BvcnRBcmd1bWVudHMpCit7CisjaWYgUExB VEZPUk0oSU9TKQorICAgIGlmIChtX3ZpZXdwb3J0Q29uZmlndXJhdGlvbi5zZXRWaWV3cG9ydEFy Z3VtZW50cyh2aWV3cG9ydEFyZ3VtZW50cykpCisgICAgICAgIHZpZXdwb3J0Q29uZmlndXJhdGlv bkNoYW5nZWQoKTsKKyNlbmRpZgorCisjaWYgVVNFKENPT1JESU5BVEVEX0dSQVBISUNTKQorICAg IEZyYW1lVmlldyogdmlldyA9IG1fcGFnZS0+bWFpbkZyYW1lKCkudmlldygpOworICAgIGlmICh2 aWV3ICYmIHZpZXctPnVzZUZpeGVkTGF5b3V0KCkpCisgICAgICAgIHNlbmRWaWV3cG9ydEF0dHJp YnV0ZXNDaGFuZ2VkKHZpZXdwb3J0QXJndW1lbnRzKTsKKyNpZiBVU0UoQ09PUkRJTkFURURfR1JB UEhJQ1NfVEhSRUFERUQpCisgICAgZWxzZSBpZiAoYXV0byogbGF5ZXJUcmVlSG9zdCA9IG1fZHJh d2luZ0FyZWEtPmxheWVyVHJlZUhvc3QoKSkKKyAgICAgICAgbGF5ZXJUcmVlSG9zdC0+ZGlkQ2hh bmdlVmlld3BvcnRQcm9wZXJ0aWVzKFZpZXdwb3J0QXR0cmlidXRlcygpKTsKKyNlbmRpZgorI2Vu ZGlmCisKKyNpZiAhUExBVEZPUk0oSU9TKSAmJiAhVVNFKENPT1JESU5BVEVEX0dSQVBISUNTKQor ICAgIFVOVVNFRF9QQVJBTSh2aWV3cG9ydEFyZ3VtZW50cyk7CisjZW5kaWYKK30KKwogdm9pZCBX ZWJQYWdlOjpsaXN0ZW5Gb3JMYXlvdXRNaWxlc3RvbmVzKHVpbnQzMl90IG1pbGVzdG9uZXMpCiB7 CiAgICAgaWYgKCFtX3BhZ2UpCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0Mi9XZWJQcm9jZXNz L1dlYlBhZ2UvV2ViUGFnZS5oIGIvU291cmNlL1dlYktpdDIvV2ViUHJvY2Vzcy9XZWJQYWdlL1dl YlBhZ2UuaAppbmRleCAwYzc2ZjY1Li4wZGVlNDVhIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViS2l0 Mi9XZWJQcm9jZXNzL1dlYlBhZ2UvV2ViUGFnZS5oCisrKyBiL1NvdXJjZS9XZWJLaXQyL1dlYlBy b2Nlc3MvV2ViUGFnZS9XZWJQYWdlLmgKQEAgLTUwNCwxMSArNTA0LDEyIEBAIHB1YmxpYzoKICAg ICB2b2lkIGVsZW1lbnREaWRCbHVyKFdlYkNvcmU6Ok5vZGUqKTsKICAgICB2b2lkIHJlc2V0QXNz aXN0ZWROb2RlRm9yRnJhbWUoV2ViRnJhbWUqKTsKIAorICAgIHZvaWQgdmlld3BvcnRQcm9wZXJ0 aWVzRGlkQ2hhbmdlKGNvbnN0IFdlYkNvcmU6OlZpZXdwb3J0QXJndW1lbnRzJik7CisKICNpZiBQ TEFURk9STShJT1MpCiAgICAgV2ViQ29yZTo6RmxvYXRTaXplIHNjcmVlblNpemUoKSBjb25zdDsK ICAgICBXZWJDb3JlOjpGbG9hdFNpemUgYXZhaWxhYmxlU2NyZWVuU2l6ZSgpIGNvbnN0OwogICAg IGludDMyX3QgZGV2aWNlT3JpZW50YXRpb24oKSBjb25zdCB7IHJldHVybiBtX2RldmljZU9yaWVu dGF0aW9uOyB9Ci0gICAgdm9pZCB2aWV3cG9ydFByb3BlcnRpZXNEaWRDaGFuZ2UoY29uc3QgV2Vi Q29yZTo6Vmlld3BvcnRBcmd1bWVudHMmKTsKICAgICB2b2lkIGRpZFJlY2VpdmVNb2JpbGVEb2NU eXBlKGJvb2wpOwogCiAgICAgdm9pZCBzZXRVc2VUZXN0aW5nVmlld3BvcnRDb25maWd1cmF0aW9u KGJvb2wgdXNlVGVzdGluZ1ZpZXdwb3J0KSB7IG1fdXNlVGVzdGluZ1ZpZXdwb3J0Q29uZmlndXJh dGlvbiA9IHVzZVRlc3RpbmdWaWV3cG9ydDsgfQpAQCAtNTk3LDcgKzU5OCw2IEBAIHB1YmxpYzoK ICAgICB2b2lkIHBhZ2VEaWRTY3JvbGwoKTsKICNpZiBVU0UoQ09PUkRJTkFURURfR1JBUEhJQ1Mp CiAgICAgdm9pZCBwYWdlRGlkUmVxdWVzdFNjcm9sbChjb25zdCBXZWJDb3JlOjpJbnRQb2ludCYp OwotICAgIHZvaWQgc2VuZFZpZXdwb3J0QXR0cmlidXRlc0NoYW5nZWQoKTsKICNlbmRpZgogCiAj aWYgVVNFKENPT1JESU5BVEVEX0dSQVBISUNTX01VTFRJUFJPQ0VTUykKQEAgLTExMjcsNiArMTEy NywxMCBAQCBwcml2YXRlOgogICAgIHZvaWQgaGlkZUZpbmRVSSgpOwogICAgIHZvaWQgY291bnRT dHJpbmdNYXRjaGVzKGNvbnN0IFN0cmluZyYsIHVpbnQzMl90IGZpbmRPcHRpb25zLCB1aW50MzJf dCBtYXhNYXRjaENvdW50KTsKIAorI2lmIFVTRShDT09SRElOQVRFRF9HUkFQSElDUykKKyAgICB2 b2lkIHNlbmRWaWV3cG9ydEF0dHJpYnV0ZXNDaGFuZ2VkKGNvbnN0IFdlYkNvcmU6OlZpZXdwb3J0 QXJndW1lbnRzJik7CisjZW5kaWYKKwogI2lmIFVTRShDT09SRElOQVRFRF9HUkFQSElDU19NVUxU SVBST0NFU1MpCiAgICAgdm9pZCBmaW5kWm9vbWFibGVBcmVhRm9yUG9pbnQoY29uc3QgV2ViQ29y ZTo6SW50UG9pbnQmLCBjb25zdCBXZWJDb3JlOjpJbnRTaXplJiBhcmVhKTsKICNlbmRpZgpkaWZm IC0tZ2l0IGEvU291cmNlL1dlYktpdDIvV2ViUHJvY2Vzcy9XZWJQYWdlL2lvcy9XZWJQYWdlSU9T Lm1tIGIvU291cmNlL1dlYktpdDIvV2ViUHJvY2Vzcy9XZWJQYWdlL2lvcy9XZWJQYWdlSU9TLm1t CmluZGV4IDIzY2JmZGYuLmM4YmI3OGQgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQyL1dlYlBy b2Nlc3MvV2ViUGFnZS9pb3MvV2ViUGFnZUlPUy5tbQorKysgYi9Tb3VyY2UvV2ViS2l0Mi9XZWJQ cm9jZXNzL1dlYlBhZ2UvaW9zL1dlYlBhZ2VJT1MubW0KQEAgLTIwNywxMiArMjA3LDYgQEAgRmxv YXRTaXplIFdlYlBhZ2U6OmF2YWlsYWJsZVNjcmVlblNpemUoKSBjb25zdAogICAgIHJldHVybiBt X2F2YWlsYWJsZVNjcmVlblNpemU7CiB9CiAKLXZvaWQgV2ViUGFnZTo6dmlld3BvcnRQcm9wZXJ0 aWVzRGlkQ2hhbmdlKGNvbnN0IFZpZXdwb3J0QXJndW1lbnRzJiB2aWV3cG9ydEFyZ3VtZW50cykK LXsKLSAgICBpZiAobV92aWV3cG9ydENvbmZpZ3VyYXRpb24uc2V0Vmlld3BvcnRBcmd1bWVudHMo dmlld3BvcnRBcmd1bWVudHMpKQotICAgICAgICB2aWV3cG9ydENvbmZpZ3VyYXRpb25DaGFuZ2Vk KCk7Ci19Ci0KIHZvaWQgV2ViUGFnZTo6ZGlkUmVjZWl2ZU1vYmlsZURvY1R5cGUoYm9vbCBpc01v YmlsZURvY3R5cGUpCiB7CiAgICAgaWYgKGlzTW9iaWxlRG9jdHlwZSkK