190113 2018-09-29 15:01:12 -0700 ASAN failure in ~GCReachableRef() 2018-10-01 19:59:53 -0700 1 1 1 Unclassified WebKit DOM WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED InRadar P2 Normal --- 190115 1 rniwa rniwa ap cdumez darin dbates ddkilzer esprehn+autocc ews-watchlist ggaren kangil.han ryanhaddad oldest_to_newest 1464804 0 rniwa 2018-09-29 15:01:12 -0700 ~GCReachableRef can cause an ASAN failure if it's called after it had been WTFMove'd. 1464805 1 rniwa 2018-09-29 15:01:48 -0700 <rdar://problem/44866778> 1464806 2 rniwa 2018-09-29 15:10:06 -0700 Hm... it looks like custom-elements-reaction-queue-retains-js-wrapper.html would always timeout in ASAN builds :( Probably too much malloc involved with the test. Is there a way to skip a test only in ASAN builds? 1464808 3 351200 rniwa 2018-09-29 15:14:46 -0700 Created attachment 351200 Fixes the bug 1464810 4 ap 2018-09-29 16:13:24 -0700 ASan shouldn’t be orders of magnitude slower than release. I would expect some cause specific to this test. Does it ever finish with --no-timeout? 1464811 5 351200 ggaren 2018-09-29 16:22:02 -0700 Comment on attachment 351200 Fixes the bug View in context: https://bugs.webkit.org/attachment.cgi?id=351200&action=review > Source/WebCore/ChangeLog:10 > + The bug was caused by ~GCReachableRef accessing Ref after it had been poisoned for ASAN > + in Ref::leakRef via Ref(Ref&& other). Fixed the bug by using RefPtr instead since that's > + the simplest solution here although we could unpoison Ref temporarily as done in ~Ref. In ~GCReachableRef, who calls Ref::leakRef? 1464815 6 rniwa 2018-09-29 17:09:29 -0700 (In reply to Geoffrey Garen from comment #5) > Comment on attachment 351200 [details] > Fixes the bug > > View in context: > https://bugs.webkit.org/attachment.cgi?id=351200&action=review > > > Source/WebCore/ChangeLog:10 > > + The bug was caused by ~GCReachableRef accessing Ref after it had been poisoned for ASAN > > + in Ref::leakRef via Ref(Ref&& other). Fixed the bug by using RefPtr instead since that's > > + the simplest solution here although we could unpoison Ref temporarily as done in ~Ref. > > In ~GCReachableRef, who calls Ref::leakRef? GCReachableRef(GCReachableRef&&), which WTFMove's Ref, which invokes leakRef on Ref in the original / source GCReachableRef. 1464818 7 rniwa 2018-09-29 17:48:15 -0700 Hm... it looks like the timeout I'm experiencing is nothing to do with this code / patch or custom elements. WebKitTestRunner's WebContent process can end up stalling and sit there without doing anything, and the set of tests in which this problem reproduces shifts. 1464819 8 rniwa 2018-09-29 17:49:28 -0700 Maybe yet another fallout from https://trac.webkit.org/changeset/236512? 1464822 9 rniwa 2018-09-29 18:02:36 -0700 Man... our testing infrastructure isn't in a good shape lately. iOS EWS is still suffering from the same data migration issue: RuntimeError raised: Timed out while waiting for data migration Traceback (most recent call last): File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/layout_tests/run_webkit_tests.py", line 85, in main run_details = run(port, options, args, stderr) File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/layout_tests/run_webkit_tests.py", line 448, in run run_details = manager.run(args) File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/layout_tests/controllers/manager.py", line 246, in run if not self._set_up_run(tests_to_run): File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/layout_tests/controllers/manager.py", line 181, in _set_up_run self._port.setup_test_run(self._options.device_class) File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/port/ios.py", line 160, in setup_test_run self._create_devices(device_class) File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/port/ios_simulator.py", line 103, in _create_devices SimulatedDeviceManager.initialize_devices([request] * self.child_processes(), self.host) File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/xcode/simulated_device.py", line 370, in initialize_devices SimulatedDeviceManager.wait_until_data_migration_is_done(host, max(0, deadline - time.time())) File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/xcode/simulated_device.py", line 430, in wait_until_data_migration_is_done raise RuntimeError('Timed out while waiting for data migration') RuntimeError: Timed out while waiting for data migration Stopping HTTP server ... Stopping WebSocket server ... Stopping Web Platform Test server ... 1464827 10 rniwa 2018-09-29 18:59:34 -0700 Hm... I can still reproduce the stall at r236511 but whatever causing it is to do with WebKitTestRunner or run-webkit-tests. Weirdly, specifying --time-out-ms=3000 would cause the tests to timeout less frequently despite of the fact none of the tests are timing out. Anyhow, I don't think this is anything to do with this bug or the patch. 1464898 11 ggaren 2018-09-30 20:21:42 -0700 > > In ~GCReachableRef, who calls Ref::leakRef? > > GCReachableRef(GCReachableRef&&), which WTFMove's Ref, which invokes leakRef > on Ref in the original / source GCReachableRef. In ~GCReachableRef, who calls GCReachableRef(GCReachableRef&&)? :P 1464903 12 351200 darin 2018-09-30 20:52:51 -0700 Comment on attachment 351200 Fixes the bug View in context: https://bugs.webkit.org/attachment.cgi?id=351200&action=review > Source/WebCore/dom/GCReachableRef.h:66 > + : m_ptr(WTFMove(other.m_ptr)) This line of code is wrong and uses of this function template won’t compile. Since "other" is a Ref, it does not have an "m_ptr" member to move from. The reason we don’t see a compiler error is that there are no uses of this function template. Maybe we should delete it for now? Or we could add unit tests for it if we want to keep it. > Source/WebCore/dom/GCReachableRef.h:75 > GCReachableRef(GCReachableRef&& other) > - : m_ref(WTFMove(other.m_ref)) > + : m_ptr(WTFMove(other.m_ptr)) > { > } This is the same as the default implementation; we could get the same effect with "= default" here or maybe by omitting this entirely and letting it get generated. On reflection, though, I realize that one thing this lacks is an assertion that the "other" is not already null. Perhaps we should leave this explicitly written out, but also explicitly forbid moving out of the same object twice just as the move constructor in Ref does, by asserting the pointer is non-null in the function body. > Source/WebCore/dom/GCReachableRef.h:77 > template<typename X, typename Y> GCReachableRef(const GCReachableRef<X, Y>& other) = delete; It doesn't makes sense that we would have to delete this function template. Yes, we need to delete the automatically generated copy constructor, since the code it generates would be incorrect, but this copy-constructor-like function template should *not* be automatically generated so it should not need to be deleted. The same logic applies in the Ref class. I have no idea why the copy-constructor-like and assignment-operator-like template functions need to be deleted in that class. I believe those lines of code in Ref.h have no effect and are unnecessary. When GCReachableRef was using a Ref for a member, though, we did *not* need to delete its copy constructor, the Ref member already prevented it from being generated. But now that we are using RefPtr instead, we need to prevent the automatic generation of the copy constructor and copy assignment operator either directly with delete or indirectly by defining the move constructor and move assignment operator. So this line should go. And we have additional work to do to make sure we don’t automatically generate an incorrect copy constructor and assignment operator. > Source/WebCore/dom/GCReachableRef.h:80 > + T* operator->() const { ASSERT(m_ptr); return m_ptr.get(); } > + T* ptr() const RETURNS_NONNULL { ASSERT(m_ptr); return m_ptr.get(); } Would be nice to not have to write out the assertion. Maybe just call &get() in these functions? > Source/WebCore/dom/GCReachableRef.h:83 > + T& get() const { ASSERT(m_ptr); return *m_ptr; } > + operator T&() const { ASSERT(m_ptr); return *m_ptr; } > + bool operator!() const { ASSERT(m_ptr); return !*m_ptr; } RefPtr::operator* already asserts, so there is no need for additional assertion here 1464904 13 darin 2018-09-30 21:02:50 -0700 (In reply to Geoffrey Garen from comment #11) > > > In ~GCReachableRef, who calls Ref::leakRef? > > > > GCReachableRef(GCReachableRef&&), which WTFMove's Ref, which invokes leakRef > > on Ref in the original / source GCReachableRef. > > In ~GCReachableRef, who calls GCReachableRef(GCReachableRef&&)? :P The language Ryosuke was using was imprecise. The error in GCReachableRef before this patch is that ~GCReachableRef was calling GCReachableRef::isNull, which in turn was implemented with a call to Ref::isHashTableEmptyValue. It‘s not OK to call Ref::isHashTableEmptyValue on a Ref once Ref::leakRef has been called on it. Despite the fact that a moved-from or leakRef'd-from Ref uses the same value, nullptr, that hash table empty values do, the use of poisoning means we can't blur the distinction between these two. One way to fix this would have been to write a new GCReachableRef::isNull that uses some different function in Ref that knows how to answer the question in a way that works even on poisoned memory. 1464911 14 351200 rniwa 2018-09-30 22:56:19 -0700 Comment on attachment 351200 Fixes the bug View in context: https://bugs.webkit.org/attachment.cgi?id=351200&action=review >> Source/WebCore/dom/GCReachableRef.h:66 >> + : m_ptr(WTFMove(other.m_ptr)) > > This line of code is wrong and uses of this function template won’t compile. Since "other" is a Ref, it does not have an "m_ptr" member to move from. The reason we don’t see a compiler error is that there are no uses of this function template. Maybe we should delete it for now? Or we could add unit tests for it if we want to keep it. Sure, will remove. >> Source/WebCore/dom/GCReachableRef.h:75 >> } > > This is the same as the default implementation; we could get the same effect with "= default" here or maybe by omitting this entirely and letting it get generated. > > On reflection, though, I realize that one thing this lacks is an assertion that the "other" is not already null. Perhaps we should leave this explicitly written out, but also explicitly forbid moving out of the same object twice just as the move constructor in Ref does, by asserting the pointer is non-null in the function body. Oh weird. I thought I had added ASSERT here but clearly I forgot. Will add the assertion. >> Source/WebCore/dom/GCReachableRef.h:77 >> template<typename X, typename Y> GCReachableRef(const GCReachableRef<X, Y>& other) = delete; > > It doesn't makes sense that we would have to delete this function template. Yes, we need to delete the automatically generated copy constructor, since the code it generates would be incorrect, but this copy-constructor-like function template should *not* be automatically generated so it should not need to be deleted. > > The same logic applies in the Ref class. I have no idea why the copy-constructor-like and assignment-operator-like template functions need to be deleted in that class. I believe those lines of code in Ref.h have no effect and are unnecessary. > > When GCReachableRef was using a Ref for a member, though, we did *not* need to delete its copy constructor, the Ref member already prevented it from being generated. But now that we are using RefPtr instead, we need to prevent the automatic generation of the copy constructor and copy assignment operator either directly with delete or indirectly by defining the move constructor and move assignment operator. > > So this line should go. And we have additional work to do to make sure we don’t automatically generate an incorrect copy constructor and assignment operator. Hm... I don't quite follow what you're saying here. Isn't this the line to prevent generating an incorrect copy constructor?? >> Source/WebCore/dom/GCReachableRef.h:80 >> + T* ptr() const RETURNS_NONNULL { ASSERT(m_ptr); return m_ptr.get(); } > > Would be nice to not have to write out the assertion. Maybe just call &get() in these functions? Sure, will do. >> Source/WebCore/dom/GCReachableRef.h:83 >> + bool operator!() const { ASSERT(m_ptr); return !*m_ptr; } > > RefPtr::operator* already asserts, so there is no need for additional assertion here Sure, will remove. 1464912 15 ap 2018-10-01 00:28:17 -0700 (In reply to Ryosuke Niwa from comment #10) > Hm... I can still reproduce the stall at r236511 but whatever causing it is to > do with WebKitTestRunner or run-webkit-tests. Weirdly, specifying --time-out-ms=3000 > would cause the tests to timeout less frequently despite of the fact none of the > tests are timing out. Could you please file a new bug with steps to reproduce? I don't understand what you are describing in these comments. > Man... our testing infrastructure isn't in a good shape lately. iOS EWS is still suffering from the same data migration issue: > > RuntimeError raised: Timed out while waiting for data migration As you know, we just upgraded EWS to new major version of iOS SDK. It will take some tweaking to work around changed performance characteristics of the simulator. Either way, EWS eventually passed. 1465054 16 351200 darin 2018-10-01 09:58:43 -0700 Comment on attachment 351200 Fixes the bug View in context: https://bugs.webkit.org/attachment.cgi?id=351200&action=review >>> Source/WebCore/dom/GCReachableRef.h:77 >>> template<typename X, typename Y> GCReachableRef(const GCReachableRef<X, Y>& other) = delete; >> >> It doesn't makes sense that we would have to delete this function template. Yes, we need to delete the automatically generated copy constructor, since the code it generates would be incorrect, but this copy-constructor-like function template should *not* be automatically generated so it should not need to be deleted. >> >> The same logic applies in the Ref class. I have no idea why the copy-constructor-like and assignment-operator-like template functions need to be deleted in that class. I believe those lines of code in Ref.h have no effect and are unnecessary. >> >> When GCReachableRef was using a Ref for a member, though, we did *not* need to delete its copy constructor, the Ref member already prevented it from being generated. But now that we are using RefPtr instead, we need to prevent the automatic generation of the copy constructor and copy assignment operator either directly with delete or indirectly by defining the move constructor and move assignment operator. >> >> So this line should go. And we have additional work to do to make sure we don’t automatically generate an incorrect copy constructor and assignment operator. > > Hm... I don't quite follow what you're saying here. > Isn't this the line to prevent generating an incorrect copy constructor?? No. A template function like this, that is similar to the copy constructor and seems to cover a cast like it, will not prevent the language/compiler from generating the implicitly-declared and implicitly-defined copy constructor. 1465238 17 rniwa 2018-10-01 14:37:39 -0700 (In reply to Darin Adler from comment #16) > Comment on attachment 351200 [details] > Fixes the bug > > View in context: > https://bugs.webkit.org/attachment.cgi?id=351200&action=review > > >>> Source/WebCore/dom/GCReachableRef.h:77 > >>> template<typename X, typename Y> GCReachableRef(const GCReachableRef<X, Y>& other) = delete; > >> > >> It doesn't makes sense that we would have to delete this function template. Yes, we need to delete the automatically generated copy constructor, since the code it generates would be incorrect, but this copy-constructor-like function template should *not* be automatically generated so it should not need to be deleted. > >> > >> The same logic applies in the Ref class. I have no idea why the copy-constructor-like and assignment-operator-like template functions need to be deleted in that class. I believe those lines of code in Ref.h have no effect and are unnecessary. > >> > >> When GCReachableRef was using a Ref for a member, though, we did *not* need to delete its copy constructor, the Ref member already prevented it from being generated. But now that we are using RefPtr instead, we need to prevent the automatic generation of the copy constructor and copy assignment operator either directly with delete or indirectly by defining the move constructor and move assignment operator. > >> > >> So this line should go. And we have additional work to do to make sure we don’t automatically generate an incorrect copy constructor and assignment operator. > > > > Hm... I don't quite follow what you're saying here. > > Isn't this the line to prevent generating an incorrect copy constructor?? > > No. A template function like this, that is similar to the copy constructor > and seems to cover a cast like it, will not prevent the language/compiler > from generating the implicitly-declared and implicitly-defined copy > constructor. Oh, I see. Thanks for the clarification. 1465252 18 351200 rniwa 2018-10-01 14:50:19 -0700 Comment on attachment 351200 Fixes the bug I just noticed that GCReachableRef already uses WTF_MAKE_NONCOPYABLE so we just need to delete: template<typename X, typename Y> GCReachableRef(const GCReachableRef<X, Y>& other) = delete; We don't need to add new code to prevent copy constructor and operator=. 1465256 19 rniwa 2018-10-01 14:53:38 -0700 Committed r236693: <https://trac.webkit.org/changeset/236693> 1465373 20 rniwa 2018-10-01 19:59:53 -0700 (In reply to Alexey Proskuryakov from comment #15) > (In reply to Ryosuke Niwa from comment #10) > > Hm... I can still reproduce the stall at r236511 but whatever causing it is to > > do with WebKitTestRunner or run-webkit-tests. Weirdly, specifying --time-out-ms=3000 > > would cause the tests to timeout less frequently despite of the fact none of the > > tests are timing out. > > Could you please file a new bug with steps to reproduce? I don't understand > what you are describing in these comments. This is very strange but I can't reproduce these timeouts with trunk WebKit anymore. Maybe it was a temporary issue which existed at the revision I was testing. > > Man... our testing infrastructure isn't in a good shape lately. iOS EWS is still suffering from the same data migration issue: > > > > RuntimeError raised: Timed out while waiting for data migration > > As you know, we just upgraded EWS to new major version of iOS SDK. It will > take some tweaking to work around changed performance characteristics of the > simulator. Either way, EWS eventually passed. Yeah, I understand. I wasn't trying to blame anyone. 351200 2018-09-29 15:14:46 -0700 2018-09-30 20:52:51 -0700 Fixes the bug bug-190113-20180929151446.patch text/plain 3335 rniwa SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDIzNjY0NCkKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDIzIEBACisyMDE4LTA5LTI5ICBSeW9zdWtl IE5pd2EgIDxybml3YUB3ZWJraXQub3JnPgorCisgICAgICAgIEFTQU4gZmFpbHVyZSBpbiB+R0NS ZWFjaGFibGVSZWYoKQorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5j Z2k/aWQ9MTkwMTEzCisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAg ICAgICAgVGhlIGJ1ZyB3YXMgY2F1c2VkIGJ5IH5HQ1JlYWNoYWJsZVJlZiBhY2Nlc3NpbmcgUmVm IGFmdGVyIGl0IGhhZCBiZWVuIHBvaXNvbmVkIGZvciBBU0FOCisgICAgICAgIGluIFJlZjo6bGVh a1JlZiB2aWEgUmVmKFJlZiYmIG90aGVyKS4gRml4ZWQgdGhlIGJ1ZyBieSB1c2luZyBSZWZQdHIg aW5zdGVhZCBzaW5jZSB0aGF0J3MKKyAgICAgICAgdGhlIHNpbXBsZXN0IHNvbHV0aW9uIGhlcmUg YWx0aG91Z2ggd2UgY291bGQgdW5wb2lzb24gUmVmIHRlbXBvcmFyaWx5IGFzIGRvbmUgaW4gflJl Zi4KKworICAgICAgICAqIGRvbS9HQ1JlYWNoYWJsZVJlZi5oOgorICAgICAgICAoV2ViQ29yZTo6 R0NSZWFjaGFibGVSZWY6OkdDUmVhY2hhYmxlUmVmKToKKyAgICAgICAgKFdlYkNvcmU6OkdDUmVh Y2hhYmxlUmVmOjp+R0NSZWFjaGFibGVSZWYpOgorICAgICAgICAoV2ViQ29yZTo6R0NSZWFjaGFi bGVSZWY6Om9wZXJhdG9yLT4gY29uc3QpOgorICAgICAgICAoV2ViQ29yZTo6R0NSZWFjaGFibGVS ZWY6OmdldCBjb25zdCk6CisgICAgICAgIChXZWJDb3JlOjpHQ1JlYWNoYWJsZVJlZjo6b3BlcmF0 b3IgVCYgY29uc3QpOgorICAgICAgICAoV2ViQ29yZTo6R0NSZWFjaGFibGVSZWY6Om9wZXJhdG9y ISBjb25zdCk6CisgICAgICAgIChXZWJDb3JlOjpHQ1JlYWNoYWJsZVJlZjo6aXNOdWxsIGNvbnN0 KTogRGVsZXRlZC4KKwogMjAxOC0wOS0yOSAgT3Jpb2wgQnJ1ZmF1ICA8b2JydWZhdUBpZ2FsaWEu Y29tPgogCiAgICAgICAgIFtjc3MtZ3JpZF0gUHJvcGVybHkgYWxpZ24gaXRlbXMgbmV4dCB0byBj b2xsYXBzZWQgdHJhY2tzIHdpdGggZ3V0dGVycwpJbmRleDogU291cmNlL1dlYkNvcmUvZG9tL0dD UmVhY2hhYmxlUmVmLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291cmNlL1dlYkNvcmUvZG9tL0dDUmVhY2hh YmxlUmVmLmgJKHJldmlzaW9uIDIzNjY0NCkKKysrIFNvdXJjZS9XZWJDb3JlL2RvbS9HQ1JlYWNo YWJsZVJlZi5oCSh3b3JraW5nIGNvcHkpCkBAIC01MCw0MiArNTAsNDEgQEAgcHVibGljOgogCiAg ICAgdGVtcGxhdGU8dHlwZW5hbWUgPSBzdGQ6OmVuYWJsZV9pZl90PHN0ZDo6aXNfYmFzZV9vZjxO b2RlLCBUPjo6dmFsdWU+PgogICAgIEdDUmVhY2hhYmxlUmVmKFQmIG9iamVjdCkKLSAgICAgICAg OiBtX3JlZihvYmplY3QpCisgICAgICAgIDogbV9wdHIoJm9iamVjdCkKICAgICB7Ci0gICAgICAg IEdDUmVhY2hhYmxlUmVmTWFwOjphZGQobV9yZWYuZ2V0KCkpOworICAgICAgICBHQ1JlYWNoYWJs ZVJlZk1hcDo6YWRkKCptX3B0cik7CiAgICAgfQogCiAgICAgfkdDUmVhY2hhYmxlUmVmKCkKICAg ICB7Ci0gICAgICAgIGlmICghaXNOdWxsKCkpCi0gICAgICAgICAgICBHQ1JlYWNoYWJsZVJlZk1h cDo6cmVtb3ZlKG1fcmVmLmdldCgpKTsKKyAgICAgICAgaWYgKG1fcHRyKQorICAgICAgICAgICAg R0NSZWFjaGFibGVSZWZNYXA6OnJlbW92ZSgqbV9wdHIpOwogICAgIH0KIAogICAgIHRlbXBsYXRl PHR5cGVuYW1lIFgsIHR5cGVuYW1lIFksIHR5cGVuYW1lID0gc3RkOjplbmFibGVfaWZfdDxzdGQ6 OmlzX2Jhc2Vfb2Y8Tm9kZSwgVD46OnZhbHVlPj4KICAgICBHQ1JlYWNoYWJsZVJlZihSZWY8WCwg WT4mJiBvdGhlcikKLSAgICAgICAgOiBtX3JlZihXVEZNb3ZlKG90aGVyLm1fcmVmKSkKKyAgICAg ICAgOiBtX3B0cihXVEZNb3ZlKG90aGVyLm1fcHRyKSkKICAgICB7Ci0gICAgICAgIGlmICghaXNO dWxsKCkpCi0gICAgICAgICAgICBHQ1JlYWNoYWJsZVJlZk1hcDo6YWRkKG1fcmVmLmdldCgpKTsK KyAgICAgICAgaWYgKG1fcHRyKQorICAgICAgICAgICAgR0NSZWFjaGFibGVSZWZNYXA6OmFkZCgq bV9wdHIpOwogICAgIH0KIAogICAgIEdDUmVhY2hhYmxlUmVmKEdDUmVhY2hhYmxlUmVmJiYgb3Ro ZXIpCi0gICAgICAgIDogbV9yZWYoV1RGTW92ZShvdGhlci5tX3JlZikpCisgICAgICAgIDogbV9w dHIoV1RGTW92ZShvdGhlci5tX3B0cikpCiAgICAgewogICAgIH0KIAogICAgIHRlbXBsYXRlPHR5 cGVuYW1lIFgsIHR5cGVuYW1lIFk+IEdDUmVhY2hhYmxlUmVmKGNvbnN0IEdDUmVhY2hhYmxlUmVm PFgsIFk+JiBvdGhlcikgPSBkZWxldGU7CiAKLSAgICBUKiBvcGVyYXRvci0+KCkgY29uc3QgeyBB U1NFUlQoIWlzTnVsbCgpKTsgcmV0dXJuIG1fcmVmLnB0cigpOyB9Ci0gICAgVCogcHRyKCkgY29u c3QgUkVUVVJOU19OT05OVUxMIHsgQVNTRVJUKCFpc051bGwoKSk7IHJldHVybiBtX3JlZi5wdHIo KTsgfQotICAgIFQmIGdldCgpIGNvbnN0IHsgQVNTRVJUKCFpc051bGwoKSk7IHJldHVybiBtX3Jl Zi5nZXQoKTsgfQotICAgIG9wZXJhdG9yIFQmKCkgY29uc3QgeyBBU1NFUlQoIWlzTnVsbCgpKTsg cmV0dXJuIG1fcmVmLmdldCgpOyB9Ci0gICAgYm9vbCBvcGVyYXRvciEoKSBjb25zdCB7IEFTU0VS VCghaXNOdWxsKCkpOyByZXR1cm4gIW1fcmVmLmdldCgpOyB9CisgICAgVCogb3BlcmF0b3ItPigp IGNvbnN0IHsgQVNTRVJUKG1fcHRyKTsgcmV0dXJuIG1fcHRyLmdldCgpOyB9CisgICAgVCogcHRy KCkgY29uc3QgUkVUVVJOU19OT05OVUxMIHsgQVNTRVJUKG1fcHRyKTsgcmV0dXJuIG1fcHRyLmdl dCgpOyB9CisgICAgVCYgZ2V0KCkgY29uc3QgeyBBU1NFUlQobV9wdHIpOyByZXR1cm4gKm1fcHRy OyB9CisgICAgb3BlcmF0b3IgVCYoKSBjb25zdCB7IEFTU0VSVChtX3B0cik7IHJldHVybiAqbV9w dHI7IH0KKyAgICBib29sIG9wZXJhdG9yISgpIGNvbnN0IHsgQVNTRVJUKG1fcHRyKTsgcmV0dXJu ICEqbV9wdHI7IH0KIAogcHJpdmF0ZToKLSAgICBib29sIGlzTnVsbCgpIGNvbnN0IHsgcmV0dXJu IG1fcmVmLmlzSGFzaFRhYmxlRW1wdHlWYWx1ZSgpOyB9CiAKLSAgICBSZWY8VD4gbV9yZWY7Cisg ICAgUmVmUHRyPFQ+IG1fcHRyOwogfTsKIAogfQo=