60881 2011-05-16 05:23:21 -0700 Inspector may close at the start of the next inspector test in DRT 2011-06-23 05:04:10 -0700 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) All All RESOLVED FIXED Qt, QtTriaged P1 Blocker --- 60802 62278 1 ossy webkit-unassigned apavlov cmarcelo kent.hansen lars.knoll loislo loki noam ossy pfeldman robert zherczeg oldest_to_newest 404423 0 ossy 2011-05-16 05:23:21 -0700 After r86499 inspector/styles/styles-url-linkify.html fails on 32 bit debug mode: --- /ramdisk/qt-linux-32-debug/build/layout-test-results/inspector/styles/styles-url-linkify-expected.txt 2011-05-14 16:06:23.691172055 -0700 +++ /ramdisk/qt-linux-32-debug/build/layout-test-results/inspector/styles/styles-url-linkify-actual.txt 2011-05-14 16:06:23.691172055 -0700 @@ -1,19 +1,4 @@ +FAIL: Timed out waiting for notifyDone to be called Tests that URLs are linked to and completed correctly. Bugs 51663, 53171 -Partial URLs completed: -http://example.com/ -http://example.com/moo -https://secure.com/moo -https://secure.com/moo -http://example.com/moo -http://example.com/foo/zoo/moo -http://example.com/foo/boo/moo -http://example.com/moo -http://example.com/foo?a=b -http://example.com/foo?a=b -Link for a URI from CSS document: -inspector/styles/resources/fromcss.png -Link for a URI from iframe inline stylesheet: -inspector/styles/resources/iframed.png - 404432 1 ossy 2011-05-16 05:48:11 -0700 Unfortunately inspector/styles/styles-url-linkify.html doesn't fail on its own, but if you run all tests. 404449 2 ossy 2011-05-16 06:44:27 -0700 I can reproduce the fail with executing the 21 tests run after the last DumpRenderTree restart: inspector/profiler/heap-snapshot.html inspector/protocol/console-agent.html inspector/protocol/runtime-agent.html inspector/styles/get-set-stylesheet-text.html inspector/styles/metrics-box-sizing.html inspector/styles/parse-utf8-bom.html inspector/styles/styles-add-invalid-property.html inspector/styles/styles-cancel-editing.html inspector/styles/styles-commit-editing.html inspector/styles/styles-computed-trace.html inspector/styles/styles-disable-inherited.html inspector/styles/styles-disable-then-change.html inspector/styles/styles-disable-then-delete.html inspector/styles/styles-history.html inspector/styles/styles-iframe.html inspector/styles/styles-new-API.html inspector/styles/styles-source-lines-inline.html inspector/styles/styles-source-lines.html inspector/styles/styles-source-offsets.html inspector/styles/styles-update-from-js.html inspector/styles/styles-url-linkify.html --> FAIL 404452 3 ossy 2011-05-16 07:18:01 -0700 After r86499 fast/js/array-sort-modifying-tostring.html fails on Qt WK2 bot. It doesn't fail on its own, but fail if you run all fast/js tests. --- /tmp/layout-test-results/fast/js/array-sort-modifying-tostring-expected.txt 2011-05-16 14:17:02.487090658 +0000 +++ /tmp/layout-test-results/fast/js/array-sort-modifying-tostring-actual.txt 2011-05-16 14:17:02.487090658 +0000 @@ -1,11 +1 @@ -Test of array with toString() override that truncates array. - -On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE". - - -PASS Array length is unchanged. -PASS Array values are correct. -PASS successfullyParsed is true - -TEST COMPLETE - +Timed out waiting for final message from web process 405540 4 ossy 2011-05-18 00:05:11 -0700 Are Nokia interested to fix this regression? Or you specifically want to keep this regression in trunk forever? :( 405546 5 zherczeg 2011-05-18 00:13:19 -0700 I have investigated this bug. When JIT is enabled, two tests fails in the inspector in the same way: the testing itself does not start (function test() does never called, but the timeout mechanism is installed, which yields the error message). When JIT is disabled, there is a crash in inspector/styles/metrics-box-sizing.html. I think these issues are connected (likely a GC related issue). 405558 6 zherczeg 2011-05-18 00:36:03 -0700 The crash happens in ASSERT_GC_OBJECT_LOOKS_VALID(cell); JSCell.cpp:226 407047 7 zherczeg 2011-05-20 06:36:44 -0700 Here is what I found so far (after 3 days of debugging): In inspector-test.js, layoutTestController.evaluateInWebInspector starts some kind of asyncron execution of function runTestInFrontend(), which does not happen for styles-disable-then-delete.html and styles-url-linkify.html in some unknown circumstances. The question now: why does it fail to start the script execution? 407075 8 zherczeg 2011-05-20 07:11:27 -0700 Source/WebKit/qt/WebCoreSupport/InspectorClientQt.cpp bool InspectorClientQt::sendMessageToFrontend(const String& message) { #if ENABLE(INSPECTOR) if (m_inspectedWebPage->d->inspector->d->remoteFrontend) { // Code not enters here. } if (!m_frontendWebPage) // <--- EARLY RETURN HERE! return false; Page* frontendPage = QWebPagePrivate::core(m_frontendWebPage); return doDispatchMessageOnFrontendPage(frontendPage, message); #else return false; #endif } If I run it alone, the m_frontendWebPage does exists. When I run it with run-layout-tests, it does not exists, and there is an early return. 407868 9 zherczeg 2011-05-23 04:25:26 -0700 Now I have a theory what cause this error, and why it is a flakey test: After every tests: 1) LayoutTestControllerQt.cpp:382 calls closeWebInspector() 2) which calls close() in InspectorController.cpp 3) which calls disconnectFromBackend() in WebCore/generated/InspectorFrontend.cpp 4) which calls WebInspector.dispatchMessageFromBackend in WebCore/inspector/front-end/inspector.js (this is JavaScript now!) 5) which calls setTimeout() with "Inspector.disconnectFromBackend" argument The issue here is the setTimeout() behaviour, which may happen AFTER the next test is started by DumpRenderTree. Hence, the next test starts with closing the WebInspector. From that point, the test will fail with timeout. WebInspector experts, please help me to solve this issue. 407923 10 zherczeg 2011-05-23 06:26:36 -0700 inspector-test.js : function closeInspectorAndNotifyDone() { if (window._watchDogTimer) clearTimeout(window._watchDogTimer); layoutTestController.closeWebInspector(); // A helper function should be called here which would check // whether the inspector exists, and call notifyDone only if not. setTimeout(function() { layoutTestController.notifyDone(); }, 0); } 411305 11 loislo 2011-05-27 03:17:04 -0700 (In reply to comment #10) > inspector-test.js : > > function closeInspectorAndNotifyDone() > { > if (window._watchDogTimer) > clearTimeout(window._watchDogTimer); > > layoutTestController.closeWebInspector(); > > // A helper function should be called here which would check > // whether the inspector exists, and call notifyDone only if not. > setTimeout(function() { > layoutTestController.notifyDone(); > }, 0); > } Seems to me it just slow. The same test on chromium-debug usually requires 15 seconds. We are trying to speed up our tests, but it is very tricky process because we are loading our front-end which has 50kloc of js. http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=styles-url-linkify.html&group=%40ToT%20-%20chromium.org 411321 12 zherczeg 2011-05-27 04:08:18 -0700 > Seems to me it just slow. The same test on chromium-debug usually requires 15 seconds. We are trying to speed up our tests, but it is very tricky process because we are loading our front-end which has 50kloc of js. > > http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=styles-url-linkify.html&group=%40ToT%20-%20chromium.org I feel the story is not that simple. Both layoutTestController.closeWebInspector() and and layoutTestController.notifyDone() start an async operation, which adds a new event to an event queue. The event queue is allowed to execute the events in any order, hence the layoutTestController.notifyDone() can be performed earlier than layoutTestController.closeWebInspector(). When layoutTestController.notifyDone() is executed, the next test is started by DRT. There is a substring comparison in the begining of the main loop of the DRT, which checks whether the test is an inspector test, and if so, it starts the inspector (even though the previous one was not even closed! -> leaking an inspector here). Right after the test starts, events in the queue are processed again. The next event closes the WebInspector. Thus, the test fail with timeout. Does this make sense? 417295 13 zherczeg 2011-06-08 09:36:55 -0700 I think it is very important to fix this bug. Today it caused new flakey tests! I tried to raise the visibility of the bug, and contacted the inspector developers. Basically the issue is: setTimeout(A, 0); setTimeout(B, 0) -> in this case, nothing guarantees, that A runs first, B later. It is likely, but not necessary. The setTimeout only guarantees, that the function will eventually be called. Both "layoutTestController.closeWebInspector()" and "setTimeout(function() { layoutTestController.notifyDone(); }, 0)" starts a setTimeout async call. If layoutTestController.notifyDone() comes first, the next test is starting to run. It opens, an inspector (without closing the previous one, etc.) However, the first processed message will be closeInspector(). Later the runInInspector or something fails, since there is no inspector. Since it has no return value, you don't even know that the call is failed. After that, the test stops, and wait for a watchdog timeout event. Short, but stupid fix: setTimeout(function() { layoutTestController.notifyDone(); }, 100 /* much bigger than 0 */); It will slow down the inspector tests, but will likely works. More clever idea: Add a new bool function to DRT, which returns true, if the inspector exists. Before layoutTestController.notifyDone(), check this value, and if it is true, start another setTimeout() call. This is difficult solution, since affects all inspectors, but I feel this is the correct one. However, I don't want to start working on it until someone says this is the best solution. Any better idea is welcome. 418137 14 robert 2011-06-09 11:37:02 -0700 If I'm reading your comments correctly Zoltan, the fix may be to ensure that EventSender sends events in the order they were received. This is a problem with EventSender that affects other tests too, particularly Drag n Drop, and cases where EventSender.skipForward() (or whatever it's called) is used. 418141 15 zherczeg 2011-06-09 11:41:36 -0700 (In reply to comment #14) > If I'm reading your comments correctly Zoltan, the fix may be to ensure that EventSender sends events in the order they were received. This is a problem with EventSender that affects other tests too, particularly Drag n Drop, and cases where EventSender.skipForward() (or whatever it's called) is used. http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#dom-windowtimers-settimeout says: 8. Wait until any invocations of this algorithm started before this one whose timeout is equal to or less than this one's have completed. It seems this behaviour might be expected by the standard as well, although I am not sure what "Living Standard" means, and how trustworthy the link above. 418470 16 ossy 2011-06-09 19:35:08 -0700 I skipped all inspector/profiler tests on Qt: http://trac.webkit.org/changeset/88514 418476 17 ossy 2011-06-09 19:52:52 -0700 Nowadays Qt buildbot is absolutely useless because of this crazy bug. :-((( I tried to find a subset of inspector tests and disable them to make buildbot green again, but I didn't manage after a day digging. I had to disable all inspector tests until fix: http://trac.webkit.org/changeset/88516 420389 18 zherczeg 2011-06-14 06:58:42 -0700 I spent another day for debugging this. It seems the issue is little more complex than I thought. It seems there is another way of calling closeWebInspector() in styles-disable-then-change.html , which affects the next test: styles-disable-then-delete.html . This different closeWebInspector() hits the m_nestingLevel >= maxTimerNestingLevel condition in WebCore/page/DOMTimer.cpp, which increase the minimum 1 ms timeout to 10 ms. However, the notifyDone does not called from here, and the normal code path does not reach this treshold, so the timeout is still 1 ms. 10 ms is way bigger than 1 ms, and the timer fires after the next test is started. Debugging the inspector is really difficult because it is half JavaScript, half C++, and full of setTimeout async calls. 420409 19 loislo 2011-06-14 07:52:42 -0700 got a pair of tests where second is constantly failing inspector/profiler/detailed-heapshots-dominators-shown-node-count-preserved-when-sorting.html inspector/styles/styles-commit-editing.html 424439 20 zherczeg 2011-06-21 07:13:50 -0700 InspectorBackendStub.js : dispatcher[functionName].apply(dispatcher, params); calls jsInspectorFrontendHostPrototypeFunctionDisconnectFromBackend However, it seems DOM.hideNodeHighlight starts the timer. Would it be possible, that the message content changes when the new test starts? 425156 21 zherczeg 2011-06-22 05:28:56 -0700 Finally, I solved this stupid bug. Heh, it nearly turned out to be the first bug that I cannot solve, but it isn't. Here is the culprit: inspector.js var messagesToDispatch = []; WebInspector.dispatch = function(message) { messagesToDispatch.push(message); setTimeout(function() { InspectorBackend.dispatch(messagesToDispatch.shift()); }, 0); } "messagesToDispatch" is basically a FIFO queue, which means the messages are processed in order, regardless of how the unnamed sub-function is called. Naturally, the lastly appended message in this queue is the closeWebInspector for each test case. However, depending on the test case the setTimeout depth can be increased to 5 to some messages, which increases the minimum timeout to 10 ms to that particular call. This call may be processed after(!) the next test is started, which means the last item in the queue is processed there. Possible fix: check messagesToDispatch.length() == 0 before reporting the test case finish. 425175 22 98160 zherczeg 2011-06-22 06:19:09 -0700 Created attachment 98160 patch Finally! A fix! 425181 23 98160 pfeldman 2011-06-22 06:41:58 -0700 Comment on attachment 98160 patch View in context: https://bugs.webkit.org/attachment.cgi?id=98160&action=review > LayoutTests/http/tests/inspector/inspector-test.js:18 > + if (!WebInspector.dispatchQueueIsEmpty()) { This looks sane. Before we land this, could you try calling InspectorTest.runAfterPendingDispatches(<didEvaluateForTestInFrontend>) instead? We maintain dispatch counter and can tell at any moment whether all of them are served. 426044 24 zherczeg 2011-06-23 02:21:03 -0700 > This looks sane. Before we land this, could you try calling InspectorTest.runAfterPendingDispatches(<didEvaluateForTestInFrontend>) instead? We maintain dispatch counter and can tell at any moment whether all of them are served. No, I still get "FAIL: Timed out waiting for notifyDone to be called" for styles-url-linkify.html 426084 25 zherczeg 2011-06-23 05:04:10 -0700 Landed in http://trac.webkit.org/changeset/89556 98160 2011-06-22 06:19:09 -0700 2011-06-23 04:30:29 -0700 patch 0001-inspector.patch text/plain 3520 zherczeg RnJvbSA0YTFmMjZkOWVlODEzNTU0NzFlNDI3ZDVlODVhNjgwYzY1NjUzZGNlIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBab2x0YW4gSGVyY3plZyA8emhlcmN6ZWdAaW5mLnUtc3plZ2Vk Lmh1PgpEYXRlOiBXZWQsIDIyIEp1biAyMDExIDA2OjE3OjA5IC0wNzAwClN1YmplY3Q6IFtQQVRD SF0gaW5zcGVjdG9yCgotLS0KIExheW91dFRlc3RzL0NoYW5nZUxvZyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAxMyArKysrKysrKysrKysrCiBMYXlvdXRUZXN0cy9odHRwL3Rlc3Rz L2luc3BlY3Rvci9pbnNwZWN0b3ItdGVzdC5qcyB8ICAgMTAgKysrKysrKysrLQogU291cmNlL1dl YkNvcmUvQ2hhbmdlTG9nICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDEzICsrKysrKysr KysrKysKIFNvdXJjZS9XZWJDb3JlL2luc3BlY3Rvci9mcm9udC1lbmQvaW5zcGVjdG9yLmpzICAg IHwgICAgNCArKysrCiA0IGZpbGVzIGNoYW5nZWQsIDM5IGluc2VydGlvbnMoKyksIDEgZGVsZXRp b25zKC0pCgpkaWZmIC0tZ2l0IGEvTGF5b3V0VGVzdHMvQ2hhbmdlTG9nIGIvTGF5b3V0VGVzdHMv Q2hhbmdlTG9nCmluZGV4IGM1NWQ4ZDMuLmY1NDUxNjcgMTAwNjQ0Ci0tLSBhL0xheW91dFRlc3Rz L0NoYW5nZUxvZworKysgYi9MYXlvdXRUZXN0cy9DaGFuZ2VMb2cKQEAgLTEsMyArMSwxNiBAQAor MjAxMS0wNi0yMiAgWm9sdGFuIEhlcmN6ZWcgIDx6aGVyY3plZ0BpbmYudS1zemVnZWQuaHU+CisK KyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgW1F0XSBJbnNw ZWN0b3IgbWF5IGNsb3NlIGF0IHRoZSBzdGFydCBvZiB0aGUgbmV4dCBpbnNwZWN0b3IgdGVzdCBp biBEUlQKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTYw ODgxCisKKyAgICAgICAgVGhlIGRpZEV2YWx1YXRlRm9yVGVzdEluRnJvbnRlbmQgZnVuY3Rpb24g Y2FsbCBpcyBwb3N0cG9uZWQgdW50aWwKKyAgICAgICAgYWxsIG1lc3NhZ2VzIGluIHRoZSBkaXNw YXRjaCBxdWV1ZSBpcyBwcm9jZXNzZWQuCisKKyAgICAgICAgKiBodHRwL3Rlc3RzL2luc3BlY3Rv ci9pbnNwZWN0b3ItdGVzdC5qczoKKyAgICAgICAgKGluaXRpYWxpemVfSW5zcGVjdG9yVGVzdC5J bnNwZWN0b3JUZXN0LmNvbXBsZXRlVGVzdCk6CisKIDIwMTEtMDUtMTQgIEFuZHJldyBXaWxzb24g IDxhdHdpbHNvbkBjaHJvbWl1bS5vcmc+CiAKICAgICAgICAgVW5yZXZpZXdlZCBjaHJvbWl1bSBl eHBlY3RhdGlvbnMgY2hhbmdlLgpkaWZmIC0tZ2l0IGEvTGF5b3V0VGVzdHMvaHR0cC90ZXN0cy9p bnNwZWN0b3IvaW5zcGVjdG9yLXRlc3QuanMgYi9MYXlvdXRUZXN0cy9odHRwL3Rlc3RzL2luc3Bl Y3Rvci9pbnNwZWN0b3ItdGVzdC5qcwppbmRleCA1YzI2N2Q5Li40NTliMWMzIDEwMDY0NAotLS0g YS9MYXlvdXRUZXN0cy9odHRwL3Rlc3RzL2luc3BlY3Rvci9pbnNwZWN0b3ItdGVzdC5qcworKysg Yi9MYXlvdXRUZXN0cy9odHRwL3Rlc3RzL2luc3BlY3Rvci9pbnNwZWN0b3ItdGVzdC5qcwpAQCAt MTQsNyArMTQsMTUgQEAgY29uc29sZS5pbmZvID0gY29uc29sZU91dHB1dEhvb2suYmluZChJbnNw ZWN0b3JUZXN0LCAiaW5mbyIpOwogCiBJbnNwZWN0b3JUZXN0LmNvbXBsZXRlVGVzdCA9IGZ1bmN0 aW9uKCkKIHsKLSAgICBSdW50aW1lQWdlbnQuZXZhbHVhdGUoImRpZEV2YWx1YXRlRm9yVGVzdElu RnJvbnRlbmQoIiArIEluc3BlY3RvclRlc3QuY29tcGxldGVUZXN0Q2FsbElkICsgIiwgXCJcIiki LCAidGVzdCIpOworICAgIGZ1bmN0aW9uIHRlc3REaXNwYXRjaFF1ZXVlSXNFbXB0eSgpIHsKKyAg ICAgICAgaWYgKCFXZWJJbnNwZWN0b3IuZGlzcGF0Y2hRdWV1ZUlzRW1wdHkoKSkgeworICAgICAg ICAgICAgLy8gV2FpdCBmb3IgdW5wcm9jZXNzZWQgbWVzc2FnZXMuCisgICAgICAgICAgICBzZXRU aW1lb3V0KHRlc3REaXNwYXRjaFF1ZXVlSXNFbXB0eSwgMTApOworICAgICAgICAgICAgcmV0dXJu OworICAgICAgICB9CisgICAgICAgIFJ1bnRpbWVBZ2VudC5ldmFsdWF0ZSgiZGlkRXZhbHVhdGVG b3JUZXN0SW5Gcm9udGVuZCgiICsgSW5zcGVjdG9yVGVzdC5jb21wbGV0ZVRlc3RDYWxsSWQgKyAi LCBcIlwiKSIsICJ0ZXN0Iik7CisgICAgfQorICAgIHRlc3REaXNwYXRjaFF1ZXVlSXNFbXB0eSgp OwogfQogCiBJbnNwZWN0b3JUZXN0LmV2YWx1YXRlSW5Db25zb2xlID0gZnVuY3Rpb24oY29kZSwg Y2FsbGJhY2spCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cgYi9Tb3VyY2Uv V2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggYjYwYzY4Yi4uY2E5YjU3OCAxMDA2NDQKLS0tIGEvU291 cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAt MSwzICsxLDE2IEBACisyMDExLTA2LTIyICBab2x0YW4gSGVyY3plZyAgPHpoZXJjemVnQGluZi51 LXN6ZWdlZC5odT4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAg ICAgICBbUXRdIEluc3BlY3RvciBtYXkgY2xvc2UgYXQgdGhlIHN0YXJ0IG9mIHRoZSBuZXh0IGlu c3BlY3RvciB0ZXN0IGluIERSVAorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93 X2J1Zy5jZ2k/aWQ9NjA4ODEKKworICAgICAgICBBZGQgYSBuZXcgZnVuY3Rpb24gdG8gdGhlIGlu c3BlY3Rvciwgd2hpY2ggdGVzdHMgd2hldGhlciB0aGUKKyAgICAgICAgZGlzcGF0Y2ggcXVldWUg aXMgZW1wdHkuCisKKyAgICAgICAgKiBpbnNwZWN0b3IvZnJvbnQtZW5kL2luc3BlY3Rvci5qczoK KyAgICAgICAgKFdlYkluc3BlY3Rvci5kaXNwYXRjaFF1ZXVlSXNFbXB0eSk6CisKIDIwMTEtMDUt MTMgIE9saXZlciBIdW50ICA8b2xpdmVyQGFwcGxlLmNvbT4KIAogICAgICAgICBSZXZpZXdlZCBi eSBHZW9mZnJleSBHYXJlbi4KZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL2luc3BlY3Rvci9m cm9udC1lbmQvaW5zcGVjdG9yLmpzIGIvU291cmNlL1dlYkNvcmUvaW5zcGVjdG9yL2Zyb250LWVu ZC9pbnNwZWN0b3IuanMKaW5kZXggZGFjYjVjZi4uY2ViYzY4NSAxMDA2NDQKLS0tIGEvU291cmNl L1dlYkNvcmUvaW5zcGVjdG9yL2Zyb250LWVuZC9pbnNwZWN0b3IuanMKKysrIGIvU291cmNlL1dl YkNvcmUvaW5zcGVjdG9yL2Zyb250LWVuZC9pbnNwZWN0b3IuanMKQEAgLTUzNCw2ICs1MzQsMTAg QEAgd2luZG93LmFkZEV2ZW50TGlzdGVuZXIoIkRPTUNvbnRlbnRMb2FkZWQiLCB3aW5kb3dMb2Fk ZWQsIGZhbHNlKTsKIAogdmFyIG1lc3NhZ2VzVG9EaXNwYXRjaCA9IFtdOwogCitXZWJJbnNwZWN0 b3IuZGlzcGF0Y2hRdWV1ZUlzRW1wdHkgPSBmdW5jdGlvbigpIHsKKyAgICByZXR1cm4gbWVzc2Fn ZXNUb0Rpc3BhdGNoLmxlbmd0aCA9PSAwOworfQorCiBXZWJJbnNwZWN0b3IuZGlzcGF0Y2ggPSBm dW5jdGlvbihtZXNzYWdlKSB7CiAgICAgbWVzc2FnZXNUb0Rpc3BhdGNoLnB1c2gobWVzc2FnZSk7 CiAgICAgc2V0VGltZW91dChmdW5jdGlvbigpIHsKLS0gCjEuNy4yLjMKCg==