144155 2015-04-24 11:12:48 -0700 fast/frames/flattening/iframe-flattening-resize-event-count.html times out on Yosemite WK2 2015-08-28 15:58:23 -0700 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=144308 P2 Normal --- 1 ap webkit-unassigned barraclough cdumez darin kling oldest_to_newest 1088271 0 ap 2015-04-24 11:12:48 -0700 fast/frames/flattening/iframe-flattening-resize-event-count.html very frequently times out on Yosemite WK2 bot. It's quite fast when it doesn't time out. 1088283 1 251563 ap 2015-04-24 11:52:31 -0700 Created attachment 251563 add some logging 1088285 2 ap 2015-04-24 11:56:52 -0700 Landed in r183272. This can't fix the issue though. 1088572 3 ap 2015-04-25 12:25:57 -0700 The logging is interesting! Every time the test fails, it only fires the timer exactly 7 times instead of 100. This makes me suspect that nested timer throttling goes wrong, and stops the timer completely. Note that the new 20-second watchdog timer fires anyway, so the process is not frozen, only the 0-delay timer is. I cannot reproduce locally yet. 1088578 4 ap 2015-04-25 13:21:57 -0700 Added more temporary logging for timers in r183312. 1088658 5 ap 2015-04-25 19:25:19 -0700 The logging says: CONSOLE MESSAGE: line 36: Test timed out. Resized 7 times, got 7 events. CONSOLE MESSAGE: line 40: Timers were scheduled at: 37.944230949506164,556.3224649522454,1564.046156941913,2555.3537160158157,3563.0944420117885,4561.856752960011,20164.311336935498 When I test locally, and print the timing data even on success, the output is: CONSOLE MESSAGE: line 31: Timers were scheduled at: 125.79913299850887,128.9805999986129,141.93081700068433,146.540253997955,152.07373299926985,155.34578100050567,162.11933999875328,177.24060999898938,183.70886299817357,190.41601500066463,197.25199999811593,203.73337699857075,210.3919910005061,218.73386399965966,225.48055100196507,250.12134900316596,258.89310300408397,265.5821590014966,272.1203940018313,278.9613470013137,285.7946400035871,292.5488300024881,303.734835004434,310.7598240021616,319.68921900261194,326.54779400036205,335.85378299903823,342.9574070032686,353.57211700465996,360.1231889988412,370.0214600030449,377.03421500191325,387.11607600271236,400.0187960045878,407.9218039987609,416.8596780000371,423.3271519988193,429.7157410037471,435.7981600041967,442.50050999835366,454.3809640017571,461.1590260028606,470.320073000039,477.19982400303707,487.3991450003814,494.21547100064345,503.9252940041479,510.3242820041487,520.7717220037011,527.4011189976591,537.5356279982952,544.4351370024378,553.9757229998941,560.8028060014476,570.4738330023247,577.4468419986079,587.4084050010424,594.3376850045752,603.7952970000333,610.804048999853,620.8505680042435,627.6742940026452,637.7976470030262,644.5893909985898,653.4063369981595,660.498393997841,671.2844819994643,678.3023910029442,687.6440220003133,694.384695001645,703.5507379987394,710.1908699987689,721.123487004661,728.1277980000596,738.0604470017715,745.0514209995163,754.0727090017754,761.0254570026882,771.0709820021293,777.9118559992639,788.0212250020122,794.822378004028,804.5823670036043,811.569422003231,821.8013090008753,828.3847080019768,837.5335410019034,844.372765001026,854.4278589979513,861.4545880045625,871.3724330009427,878.4461210016161,887.7621720021125,894.8069830003078,904.3407959979959,911.3547460001428,921.1714140037657,928.0214230020647,938.36195699987 This means that when the test fails, the 0-delay timers first get throttled to fire once a second, and then stall completely until the 20-second watchdog timer fires. At the same time, WebCore doesn't think that the timers are ever throttled. Given that this happens on Yosemite only, and that WebCore doesn't know about the throttling, it smells like an issue below WebKit. At the same time, it is difficult to see how the 20-second timer could fire at exact time if the issue were below us - all these DOM timers are served by a single shared CF timer. 1088675 6 ap 2015-04-25 20:20:06 -0700 Looks like the only way WebCore would clamp timers to 1 second is when it thinks that the timer causes a repaint of something that's not user visible (it won't do that when there is no repainting at all). And there seems to be no way that we'd clamp to 15 seconds, short of a timer heap bug. 1088716 7 ap 2015-04-25 23:44:35 -0700 Found something interesting in system logs. Every time the test fails, there is this logging while it runs: Apr 25 18:55:31 bot185.apple.com WindowServer[147]: WSGetSurfaceInWindow : Invalid surface 734273305 for window 38598 Apr 25 18:55:32 --- last message repeated 3 times --- Apr 25 18:55:32 bot185.apple.com WindowServer[147]: WSGetSurfaceInWindow : Invalid surface 656102528 for window 38600 Apr 25 18:55:32 --- last message repeated 3 times --- And when the test passes, the same logging occurs slightly later. 1088719 8 ap 2015-04-26 00:17:12 -0700 I can reproduce this logging by running fast/events/popup-allowed-from-gesture-initiated-event.html (and there is another test that also causes it). However, running it in parallel with fast/frames/flattening/iframe-flattening-resize-event-count.html doesn't reproduce the problem, so it's not directly related. 1089126 9 251766 ap 2015-04-27 12:14:59 -0700 Created attachment 251766 disable App Nap Talked to Gavin, who suggested that this might be an effect of App Nap. The mechanism is not quite clear, but it certainly seems worth trying. 1089162 10 ap 2015-04-27 13:36:06 -0700 Committed the patch for disabling App Nap in r183418, let's see what happens. 1089296 11 ap 2015-04-27 17:34:43 -0700 Disabling App Nap made a difference, but the test is still flaky. We got rid of the super long stall, but the 0-delay timer is still taking 1 second to fire: +CONSOLE MESSAGE: line 40: Timers were scheduled at: 43.86900598183274,548.0330429272726,1556.697802967392,2549.8486949363723,3549.5337379397824,4556.125045986846,5548.013246967457,6556.058387970552,7554.3883389327675,8552.839554962702,9547.597624943592,10548.691916977987,11550.223996979184,12547.692796913907,13549.164323951118,14547.859265003353,15556.478225975297,16549.75908191409,17550.117639941163,18548.79687190987,19555.410598986782 1089297 12 ap 2015-04-27 17:41:14 -0700 Oh, I wonder if 1 second is this: static double hiddenPageAlignmentInterval() { return 1.0; } // 1 second. 1089418 13 ap 2015-04-27 23:34:45 -0700 Confirmed that WebKitTestRunner doesn't bring back the window if a preceding test calls testRunner.setPageVisibility("hidden") without a subsequent testRunner.resetPageVisibility() or testRunner.setPageVisibility("visible"). I couldn't find any direct evidence of this being the culprit in this case yet, but it seems like it has to be. 1089515 14 darin 2015-04-28 08:13:38 -0700 So does that mean we could fix this by adding code to TestController::resetStateToConsistentValues? 1089604 15 ap 2015-04-28 10:40:19 -0700 Yes, probably just call TestController::setHidden(false). I'd like to look into a few things before that: - which test leaves the window hidden (couldn't find it yet); - how we get away with TestController::setHidden(false) calling -makeKeyAndOrderFront - why doesn't that steal focus? - how DumpRenderTree works (it doesn't seem to ever hide or unhide windows, maybe it doesn't test page visibility properly?) 1089917 16 251931 ap 2015-04-29 00:46:29 -0700 Created attachment 251931 unhide the window between tests > - which test leaves the window hidden (couldn't find it yet); Still couldn't catch anything like this in action. If this patch doesn't help, my next theory is that the window is actually visible, but a CoreIPC issue akin to bug 141122 confuses WebProcess into getting out of sync. That would be pretty much impossible to verify without a locally reproducible case. - how we get away with TestController::setHidden(false) calling -makeKeyAndOrderFront - why doesn't that steal focus? A mystery. I patched WKTR to not move the window offscreen, and ran a test that hides/shows the window in a loop. The window does appear and disappear, but it always stays below the currently active window, not stealing focus and not obscuring it. - how DumpRenderTree works (it doesn't seem to ever hide or unhide windows, maybe it doesn't test page visibility properly?) DumpRenderTree calls directly into WebKit to fool it about the current visibility state. [webView _setVisibilityState:WebPageVisibilityStateHidden isInitialState:NO]; 1090063 17 ap 2015-04-29 10:44:32 -0700 Committed the patch for unhiding the window in r183558, will keep watching. 1090325 18 ap 2015-04-29 20:05:59 -0700 This is still happening, no change. Added more logging in r183607, it will now print out visibility state as WebProcess sees it. 1090376 19 ap 2015-04-29 23:50:06 -0700 Strange. CONSOLE MESSAGE: line 40: Timers were scheduled at: 38.54244900867343,634.1223609633744,1630.6184619897977,2633.0562729854137,3635.5311119696125,4630.785787943751,5634.050983935595,6638.653066940606,7635.863823001273,8635.53286192473,9633.291222970001,10638.184183975682,11632.18399696052,12640.454213949852,13631.606793962419,14630.80570299644,15635.705446940847,16635.929689975455,17632.111273007467,18637.691960902885,19631.200731964782 CONSOLE MESSAGE: line 41: document.hidden = false; document.visibilityState = visible 1091118 20 ap 2015-05-02 12:05:31 -0700 testRunner.setPageVisibility is somewhat broken in WebKitTestRunner, creating an opportunity for races. It is asynchronous, and there are tests that just call the function and terminate without waiting for a visibility change event, thus leaving the following test to handle the message in UI process. But once again, there is no indication that this is somehow breaking this particular test - in a failing run on the bot, no preceding tests call setPageVisibility. 1091125 21 ap 2015-05-02 12:20:56 -0700 Added some debug-only logging to WebCore in r183720, will roll out as soon as there are results from the bots. 1091190 22 ap 2015-05-03 00:09:51 -0700 Yes, there are spurious calls to setDOMTimerAlignmentInterval. They sometimes happen during this test, which makes it fail, and sometimes during other tests. This doesn't look like a race though. Will see if I can reproduce this slightly more broad condition locally. 1094195 23 ap 2015-05-12 10:32:56 -0700 This is taking way too long to keep the bots red, marked as flaky in r184205. 1115586 24 ap 2015-08-06 18:32:14 -0700 The remaining issues are quite likely fixed in bug 147718. Will keep an eye on the bots. 1121874 25 ap 2015-08-28 15:58:23 -0700 fast/frames/flattening/iframe-flattening-resize-event-count.html hasn't failed since. So, these fixes plus bug 147718 took care of it. 251563 2015-04-24 11:52:31 -0700 2015-04-24 11:54:03 -0700 add some logging FrameFlattening.txt text/plain 2511 ap SW5kZXg6IExheW91dFRlc3RzL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBMYXlvdXRUZXN0cy9D aGFuZ2VMb2cJKHJldmlzaW9uIDE4MzI3MSkKKysrIExheW91dFRlc3RzL0NoYW5nZUxvZwkod29y a2luZyBjb3B5KQpAQCAtMSwzICsxLDE2IEBACisyMDE1LTA0LTI0ICBBbGV4ZXkgUHJvc2t1cnlh a292ICA8YXBAYXBwbGUuY29tPgorCisgICAgICAgIGZhc3QvZnJhbWVzL2ZsYXR0ZW5pbmcvaWZy YW1lLWZsYXR0ZW5pbmctcmVzaXplLWV2ZW50LWNvdW50Lmh0bWwgdGltZXMgb3V0IG9uIFlvc2Vt aXRlIFdLMgorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9 MTQ0MTU1CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAg Q2xlYW5lZCB0aGUgdGVzdCB1cCBhIGxpdHRsZSwgYW5kIGFkZGVkIGxvZ2dpbmcgdG8gY29sbGVj dCBzb21lIGluZm9ybWF0aW9uIGFib3V0CisgICAgICAgIHdoeSBpdCBmYWlscy4KKworICAgICAg ICAqIGZhc3QvZnJhbWVzL2ZsYXR0ZW5pbmcvaWZyYW1lLWZsYXR0ZW5pbmctcmVzaXplLWV2ZW50 LWNvdW50Lmh0bWw6CisgICAgICAgICogZmFzdC9mcmFtZXMvZmxhdHRlbmluZy9yZXNvdXJjZXMv aWZyYW1lLXRvLXJlc2l6ZS5odG1sOgorCiAyMDE1LTA0LTI0ICBEb3VnIFJ1c3NlbGwgIDxkX3J1 c3NlbGxAYXBwbGUuY29tPgogCiAgICAgICAgIEFYOiByaWNoZXIgdGV4dCBjaGFuZ2Ugbm90aWZp Y2F0aW9ucyAoMTQyNzE5KQpJbmRleDogTGF5b3V0VGVzdHMvZmFzdC9mcmFtZXMvZmxhdHRlbmlu Zy9pZnJhbWUtZmxhdHRlbmluZy1yZXNpemUtZXZlbnQtY291bnQuaHRtbAo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSBMYXlvdXRUZXN0cy9mYXN0L2ZyYW1lcy9mbGF0dGVuaW5nL2lmcmFtZS1mbGF0dGVuaW5nLXJl c2l6ZS1ldmVudC1jb3VudC5odG1sCShyZXZpc2lvbiAxODMxODcpCisrKyBMYXlvdXRUZXN0cy9m YXN0L2ZyYW1lcy9mbGF0dGVuaW5nL2lmcmFtZS1mbGF0dGVuaW5nLXJlc2l6ZS1ldmVudC1jb3Vu dC5odG1sCSh3b3JraW5nIGNvcHkpCkBAIC0yLDIwICsyLDE4IEBACiA8aHRtbD4KIDxoZWFkPgog PHNjcmlwdD4KLSAgZnVuY3Rpb24gc3RhcnQoKSB7Ci0gICAgaWYgKHdpbmRvdy5pbnRlcm5hbHMp Ci0gICAgICBpbnRlcm5hbHMuc2V0dGluZ3Muc2V0RnJhbWVGbGF0dGVuaW5nRW5hYmxlZCh0cnVl KTsKLSAgICAgIAotICAgIGlmICh3aW5kb3cudGVzdFJ1bm5lcikgewotICAgICAgdGVzdFJ1bm5l ci5kdW1wQXNUZXh0KCk7Ci0gICAgICB0ZXN0UnVubmVyLndhaXRVbnRpbERvbmUoKTsKLSAgICB9 Ci0gIH0KK2lmICh3aW5kb3cuaW50ZXJuYWxzKQorICAgIGludGVybmFscy5zZXR0aW5ncy5zZXRG cmFtZUZsYXR0ZW5pbmdFbmFibGVkKHRydWUpOworICAKK2lmICh3aW5kb3cudGVzdFJ1bm5lcikg eworICAgIHRlc3RSdW5uZXIuZHVtcEFzVGV4dCgpOworICAgIHRlc3RSdW5uZXIud2FpdFVudGls RG9uZSgpOworfQogPC9zY3JpcHQ+CiA8L2hlYWQ+CiA8Ym9keT4KICAgPHA+VGhpcyB0ZXN0cyB0 aGUgbnVtYmVyIG9mIHJlc2l6ZSBldmVudHMgZGlzcGF0Y2hlZCB0byBKYXZhU2NyaXB0LjwvcD4K ICAgPHAgaWQ9J3Jlc3VsdCc+PC9wPgotICA8aWZyYW1lIG9ubG9hZD0nc3RhcnQoKTsnIGZyYW1l Ym9yZGVyPTA7IHNyYz0ncmVzb3VyY2VzL2lmcmFtZS10by1yZXNpemUuaHRtbCc+CisgIDxpZnJh bWUgZnJhbWVib3JkZXI9JzAnIHNyYz0ncmVzb3VyY2VzL2lmcmFtZS10by1yZXNpemUuaHRtbCc+ PC9pZnJhbWU+CiA8L2JvZHk+CiA8L2h0bWw+CkluZGV4OiBMYXlvdXRUZXN0cy9mYXN0L2ZyYW1l cy9mbGF0dGVuaW5nL3Jlc291cmNlcy9pZnJhbWUtdG8tcmVzaXplLmh0bWwKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot LS0gTGF5b3V0VGVzdHMvZmFzdC9mcmFtZXMvZmxhdHRlbmluZy9yZXNvdXJjZXMvaWZyYW1lLXRv LXJlc2l6ZS5odG1sCShyZXZpc2lvbiAxODMxODcpCisrKyBMYXlvdXRUZXN0cy9mYXN0L2ZyYW1l cy9mbGF0dGVuaW5nL3Jlc291cmNlcy9pZnJhbWUtdG8tcmVzaXplLmh0bWwJKHdvcmtpbmcgY29w eSkKQEAgLTI1LDYgKzI1LDEwIEBACiAgICAgICAgIHRlc3RSdW5uZXIubm90aWZ5RG9uZSgpOwog ICAgIH0KICAgfQorCisgIHNldFRpbWVvdXQoZnVuY3Rpb24oKSB7CisgICAgcGFyZW50LmRvY3Vt ZW50LmdldEVsZW1lbnRCeUlkKCdyZXN1bHQnKS5pbm5lckhUTUwgPSAiVGVzdCB0aW1lZCBvdXQu IFJlc2l6ZWQgIiArIHJlc2l6ZUNvdW50ZXIgKyAiIHRpbWVzLCBnb3QgIiArIHJlc2l6ZUV2ZW50 Q291bnRlciArICIgZXZlbnRzLiI7CisgIH0sIDIwMDAwKTsKICAgCiA8L3NjcmlwdD4KIDwvaGVh ZD4K 251766 2015-04-27 12:14:59 -0700 2015-04-27 13:32:32 -0700 disable App Nap AppNap.txt text/plain 1621 ap SW5kZXg6IFRvb2xzL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBUb29scy9DaGFuZ2VMb2cJKHJl dmlzaW9uIDE4MzQwNykKKysrIFRvb2xzL0NoYW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwz ICsxLDE0IEBACisyMDE1LTA0LTI3ICBBbGV4ZXkgUHJvc2t1cnlha292ICA8YXBAYXBwbGUuY29t PgorCisgICAgICAgIGZhc3QvZnJhbWVzL2ZsYXR0ZW5pbmcvaWZyYW1lLWZsYXR0ZW5pbmctcmVz aXplLWV2ZW50LWNvdW50Lmh0bWwgdGltZXMgb3V0IG9uIFlvc2VtaXRlIFdLMgorICAgICAgICBo dHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTQ0MTU1CisKKyAgICAgICAg UmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgKiBXZWJLaXRUZXN0UnVubmVy L1Rlc3RDb250cm9sbGVyLmNwcDogKFdUUjo6VGVzdENvbnRyb2xsZXI6OnJlc2V0UHJlZmVyZW5j ZXNUb0NvbnNpc3RlbnRWYWx1ZXMpOgorICAgICAgICBEaXNhYmxlIEFwcCBOYXAuIEkgZG9uJ3Qg aGF2ZSBwb3NpdGl2ZSBldmlkZW5jZSB0aGF0IGl0J3MgdGhlIGN1bHByaXQsIGJ1dCBpdCBjb3Vs ZCBiZSwKKyAgICAgICAgYW5kIHdlIGNsZWFybHkgZG9uJ3Qgd2FudCBBcHAgTmFwIHdoaWxlIHRl c3RpbmcuCisKIDIwMTUtMDQtMjcgIEJyZW50IEZ1bGdoYW0gIDxiZnVsZ2hhbUBhcHBsZS5jb20+ CiAKICAgICAgICAgUkVHUkVTU0lPTihyMTgyODc5KTogSW1hZ2VzIGFuZCB2aWRlbyBjYW4gbm8g bG9uZ2VyIGJlIGRvd25sb2FkZWQKSW5kZXg6IFRvb2xzL1dlYktpdFRlc3RSdW5uZXIvVGVzdENv bnRyb2xsZXIuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFRvb2xzL1dlYktpdFRlc3RSdW5uZXIvVGVzdENv bnRyb2xsZXIuY3BwCShyZXZpc2lvbiAxODMxODcpCisrKyBUb29scy9XZWJLaXRUZXN0UnVubmVy L1Rlc3RDb250cm9sbGVyLmNwcAkod29ya2luZyBjb3B5KQpAQCAtNTU4LDYgKzU1OCw3IEBAIHZv aWQgVGVzdENvbnRyb2xsZXI6OnJlc2V0UHJlZmVyZW5jZXNUb0MKICAgICAvLyBSZXNldCBwcmVm ZXJlbmNlcwogICAgIFdLUHJlZmVyZW5jZXNSZWYgcHJlZmVyZW5jZXMgPSBXS1BhZ2VHcm91cEdl dFByZWZlcmVuY2VzKG1fcGFnZUdyb3VwLmdldCgpKTsKICAgICBXS1ByZWZlcmVuY2VzUmVzZXRU ZXN0UnVubmVyT3ZlcnJpZGVzKHByZWZlcmVuY2VzKTsKKyAgICBXS1ByZWZlcmVuY2VzU2V0UGFn ZVZpc2liaWxpdHlCYXNlZFByb2Nlc3NTdXBwcmVzc2lvbkVuYWJsZWQocHJlZmVyZW5jZXMsIGZh bHNlKTsKICAgICBXS1ByZWZlcmVuY2VzU2V0T2ZmbGluZVdlYkFwcGxpY2F0aW9uQ2FjaGVFbmFi bGVkKHByZWZlcmVuY2VzLCB0cnVlKTsKICAgICBXS1ByZWZlcmVuY2VzU2V0Rm9udFNtb290aGlu Z0xldmVsKHByZWZlcmVuY2VzLCBrV0tGb250U21vb3RoaW5nTGV2ZWxOb1N1YnBpeGVsQW50aUFs aWFzaW5nKTsKICAgICBXS1ByZWZlcmVuY2VzU2V0QW50aWFsaWFzZWRGb250RGlsYXRpb25FbmFi bGVkKHByZWZlcmVuY2VzLCBmYWxzZSk7Cg== 251931 2015-04-29 00:46:29 -0700 2015-04-29 10:39:52 -0700 unhide the window between tests ShowWindow.txt text/plain 1528 ap SW5kZXg6IFRvb2xzL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBUb29scy9DaGFuZ2VMb2cJKHJl dmlzaW9uIDE4MzUzNCkKKysrIFRvb2xzL0NoYW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwz ICsxLDE2IEBACisyMDE1LTA0LTI5ICBBbGV4ZXkgUHJvc2t1cnlha292ICA8YXBAYXBwbGUuY29t PgorCisgICAgICAgIGZhc3QvZnJhbWVzL2ZsYXR0ZW5pbmcvaWZyYW1lLWZsYXR0ZW5pbmctcmVz aXplLWV2ZW50LWNvdW50Lmh0bWwgdGltZXMgb3V0IG9uIFlvc2VtaXRlIFdLMgorICAgICAgICBo dHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTQ0MTU1CisKKyAgICAgICAg UmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgKiBXZWJLaXRUZXN0UnVubmVy L1Rlc3RDb250cm9sbGVyLmNwcDogKFdUUjo6VGVzdENvbnRyb2xsZXI6OnJlc2V0U3RhdGVUb0Nv bnNpc3RlbnRWYWx1ZXMpOgorICAgICAgICBNYWtlIHN1cmUgdGhhdCB0ZXN0IHdpbmRvdyBpcyAi dmlzaWJsZSIgYmVmb3JlIGVhY2ggdGVzdC4gV2hpbGUgdGhlcmUgaXMgbm8gY29uY3JldGUKKyAg ICAgICAgZXZpZGVuY2UgdGhhdCB0aGlzIGlzIHRoZSBwcm9ibGVtIGluZGVlZCwgdGhlIGJlaGF2 aW9yIGlzIGNvbnNpc3RlbnQgd2l0aCB3aGF0IHdvdWxkCisgICAgICAgIGhhcHBlbiBmb3IgYW4g aW52aXNpYmxlIHdpbmRvdy4gQWxzbywgV0tUUiBvYnZpb3VzbHkgbmVlZHMgdG8gZG8gdGhpcyB0 byBwcm90ZWN0CisgICAgICAgIGFnYWluc3QgcG90ZW50aWFsIGJ1Z2d5IHRlc3RzIHRoYXQgaGlk ZSB0aGUgd2luZG93IGFuZCBkb24ndCBzaG93IGl0LgorCiAyMDE1LTA0LTI4ICBSeXVhbiBDaG9p ICA8cnl1YW4uY2hvaUBuYXZlcmNvcnAuY29tPgogCiAgICAgICAgIFtDb29yZGluYXRlZEdyYXBo aWNzXSBNZXJnZSBUSUxFRF9CQUNLSU5HX1NUT1JFIGd1YXJkIHdpdGggQ09PUkRJTkFURURfR1JB UEhJQ1MKSW5kZXg6IFRvb2xzL1dlYktpdFRlc3RSdW5uZXIvVGVzdENvbnRyb2xsZXIuY3BwCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIFRvb2xzL1dlYktpdFRlc3RSdW5uZXIvVGVzdENvbnRyb2xsZXIuY3BwCShy ZXZpc2lvbiAxODM0NTgpCisrKyBUb29scy9XZWJLaXRUZXN0UnVubmVyL1Rlc3RDb250cm9sbGVy LmNwcAkod29ya2luZyBjb3B5KQpAQCAtNjk1LDYgKzY5NSw4IEBAIGJvb2wgVGVzdENvbnRyb2xs ZXI6OnJlc2V0U3RhdGVUb0NvbnNpc3QKIAogICAgIFdLUGFnZUdyb3VwUmVtb3ZlQWxsVXNlckNv bnRlbnRGaWx0ZXJzKFdLUGFnZUdldFBhZ2VHcm91cChtX21haW5XZWJWaWV3LT5wYWdlKCkpKTsK IAorICAgIHNldEhpZGRlbihmYWxzZSk7CisKICAgICAvLyBSZXNldCBtYWluIHBhZ2UgYmFjayB0 byBhYm91dDpibGFuawogICAgIG1fZG9uZVJlc2V0dGluZyA9IGZhbHNlOwogCg==