174507 2017-07-14 09:40:29 -0700 Potential null-dereference under NetworkRTCProvider::resolvedName() 2017-07-15 20:03:48 -0700 1 1 1 Unclassified WebKit WebKit2 WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED InRadar P2 Normal --- 1 cdumez cdumez commit-queue darin webkit-bug-importer youennf oldest_to_newest 1328809 0 cdumez 2017-07-14 09:40:29 -0700 Potential null-dereference under NetworkRTCProvider::resolvedName(): Thread[0] EXC_BAD_ACCESS (SIGSEGV) (KERN_INVALID_ADDRESS at 0x0000000000000010) [ 0] 0x000000019250582c WebKit`WebKit::NetworkRTCProvider::resolvedName(__CFHost*, CFHostInfoType, CFStreamError const*, void*) [inlined] WTF::Ref<IPC::Connection>::get() const at Ref.h:138:45 0x000000019250581c: b.ne 0xcd7d8 ; <+164> at NetworkRTCProvider.cpp:199 0x0000000192505820: ldr x8, [sp, #0x28] 0x0000000192505824: ldr x9, [x8, #0x8] 0x0000000192505828: ldr x9, [x9, #0x40] -> 0x000000019250582c: ldr x0, [x9, #0x10] 0x0000000192505830: add x9, sp, #0x10 ; =0x10 0x0000000192505834: str x9, [sp, #0x8] 0x0000000192505838: ldr x2, [x8] 0x000000019250583c: add x1, sp, #0x8 ; =0x8 [ 0] 0x000000019250582c WebKit`WebKit::NetworkRTCProvider::resolvedName(__CFHost*, CFHostInfoType, CFStreamError const*, void*) [inlined] WebKit::NetworkConnectionToWebProcess::connection() at NetworkConnectionToWebProcess.h:59 55 public: 56 static Ref<NetworkConnectionToWebProcess> create(IPC::Connection::Identifier); 57 virtual ~NetworkConnectionToWebProcess(); 58 -> 59 IPC::Connection& connection() { return m_connection.get(); } 60 61 void didCleanupResourceLoader(NetworkResourceLoader&); 62 63 bool captureExtraNetworkLoadMetricsEnabled() const { return m_captureExtraNetworkLoadMetricsEnabled; } [ 0] 0x000000019250582c WebKit`WebKit::NetworkRTCProvider::resolvedName(__CFHost*, CFHostInfoType, CFStreamError const*, void*) + 248 at NetworkRTCProvider.cpp:204 200 auto* address = reinterpret_cast<const struct sockaddr_in*>(CFDataGetBytePtr(data)); 201 addresses.uncheckedAppend(RTCNetwork::IPAddress(rtc::IPAddress(address->sin_addr))); 202 } 203 ASSERT(resolver->rtcProvider.m_connection); -> 204 resolver->rtcProvider.m_connection->connection().send(Messages::WebRTCResolver::SetResolvedAddress(addresses), resolver->identifier); 205 } 206 207 struct NetworkMessageData : public rtc::MessageData { 208 NetworkMessageData(Ref<NetworkRTCProvider>&& rtcProvider, Function<void()>&& callback) [ 1] 0x00000001925057e7 WebKit`WebKit::NetworkRTCProvider::resolvedName(__CFHost*, CFHostInfoType, CFStreamError const*, void*) + 179 at NetworkRTCProvider.cpp:200:69 196 addresses.reserveInitialCapacity(count); 197 198 for (size_t index = 0; index < count; ++index) { 199 CFDataRef data = (CFDataRef)CFArrayGetValueAtIndex(resolvedAddresses, index); -> 200 auto* address = reinterpret_cast<const struct sockaddr_in*>(CFDataGetBytePtr(data)); 201 addresses.uncheckedAppend(RTCNetwork::IPAddress(rtc::IPAddress(address->sin_addr))); 202 } 203 ASSERT(resolver->rtcProvider.m_connection); 204 resolver->rtcProvider.m_connection->connection().send(Messages::WebRTCResolver::SetResolvedAddress(addresses), resolver->identifier); [ 2] 0x00000001896ae99f CFNetwork`ClassicHostDelegate::hostInfoCallback(HostBase*, __CFString const*, __CFError*) + 227 at HostBase.cpp:75:3 [ 3] 0x00000001896ae31b CFNetwork`HostBase::invokeCallback(__CFString const*) + 203 at HostBase.cpp:230:6 [ 4] 0x00000001896ada83 CFNetwork`DispatchHost::processPending() + 119 at DispatchHost.cpp:412:4 [ 5] 0x000000018a12d19f CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 23 at CFRunLoop.c:1960:9 [ 6] 0x000000018a12ca83 CoreFoundation`__CFRunLoopDoSources0 + 451 at CFRunLoop.c:2025:25 [ 7] 0x000000018a12a57b CoreFoundation`__CFRunLoopRun + 831 at CFRunLoop.c:2842:41 [ 8] 0x000000018a04503b CoreFoundation`CFRunLoopRunSpecific + 435 at CFRunLoop.c:3148:11 [ 9] 0x000000018bd61f9f Foundation`-[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 303 at NSRunLoop.m:367:5 [ 10] 0x000000018bdb5e0f Foundation`-[NSRunLoop(NSRunLoop) run] + 87 at NSRunLoop.m:389:12 [ 11] 0x00000001ada469eb libxpc.dylib`_xpc_objc_main + 451 at main.m:198:3 [ 12] 0x00000001ada4884f libxpc.dylib`xpc_main + 163 at init.c:1460:2 [ 13] 0x00000001010e759b com.apple.WebKit.Networking`main + 379 [ 14] 0x00000001ad7d7d1b libdyld.dylib`start + 3 1328811 1 cdumez 2017-07-14 09:41:17 -0700 <rdar://problem/32597868> 1328817 2 315436 cdumez 2017-07-14 09:49:45 -0700 Created attachment 315436 Patch 1328845 3 315436 youennf 2017-07-14 10:38:41 -0700 Comment on attachment 315436 Patch Might want to move back cancel DNS outside of the destructor. 1328855 4 315446 cdumez 2017-07-14 10:48:20 -0700 Created attachment 315446 Patch 1328920 5 315446 commit-queue 2017-07-14 11:55:44 -0700 Comment on attachment 315446 Patch Clearing flags on attachment: 315446 Committed r219514: <http://trac.webkit.org/changeset/219514> 1328921 6 commit-queue 2017-07-14 11:55:45 -0700 All reviewed patches have been landed. Closing bug. 1329201 7 315446 darin 2017-07-15 09:53:37 -0700 Comment on attachment 315446 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=315446&action=review > Source/WebKit/NetworkProcess/webrtc/NetworkRTCProvider.cpp:189 > + ASSERT(identifier); > + if (auto resolver = m_resolvers.take(identifier)) I understand why you added this assertion, after all the hash table implementation here can’t handle a key of "0". But HashMap already does this assertion, so it’s not necessary to add one at this level before calling take. Specifically, in the case of this call, the assertion is in HashTable::checkKey, called by HashTable::inlineLookup. And it checks not just for 0 but also for the deleted value, which is also needed in this case. Maybe you added this because you didn’t know HashMap would take care of asserting? Or maybe you added this assertion to make the issue clearer to someone reading the source code? Or maybe the HashTable assertion is tricky to understand when it fires and this one is easier to understand? I did notice a problem in HashTable::find and HashTable::contains; if the hash table is empty then it won’t check the key, which is not good. We want the key checked in that case. I think we can probably just remove the m_table null checks from those functions; lookup already has a null check. Maybe the earlier check is an important performance optimization? Or more likely it is just redundant code that doesn’t really significantly speed anything up and causes us to lose the key assertion. 1329227 8 cdumez 2017-07-15 12:42:52 -0700 (In reply to Darin Adler from comment #7) > Comment on attachment 315446 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=315446&action=review > > > Source/WebKit/NetworkProcess/webrtc/NetworkRTCProvider.cpp:189 > > + ASSERT(identifier); > > + if (auto resolver = m_resolvers.take(identifier)) > > I understand why you added this assertion, after all the hash table > implementation here can’t handle a key of "0". But HashMap already does this > assertion, so it’s not necessary to add one at this level before calling > take. Specifically, in the case of this call, the assertion is in > HashTable::checkKey, called by HashTable::inlineLookup. And it checks not > just for 0 but also for the deleted value, which is also needed in this case. > > Maybe you added this because you didn’t know HashMap would take care of > asserting? Or maybe you added this assertion to make the issue clearer to > someone reading the source code? Or maybe the HashTable assertion is tricky > to understand when it fires and this one is easier to understand? > > I did notice a problem in HashTable::find and HashTable::contains; if the > hash table is empty then it won’t check the key, which is not good. We want > the key checked in that case. I think we can probably just remove the > m_table null checks from those functions; lookup already has a null check. > Maybe the earlier check is an important performance optimization? Or more > likely it is just redundant code that doesn’t really significantly speed > anything up and causes us to lose the key assertion. I did not know HashTable already had this assertion. We have been burned by this recently which is why I added the assertion. I can drop it though given the HashMap implementation. 1329276 9 darin 2017-07-15 20:03:48 -0700 (In reply to Chris Dumez from comment #8) > We have been burned by this recently which is why I added the assertion. Makes me wonder if the HashTable assertion is working. > > I did notice a problem in HashTable::find and HashTable::contains; if the > > hash table is empty then it won’t check the key, which is not good. We want > > the key checked in that case. I think we can probably just remove the > > m_table null checks from those functions; lookup already has a null check. > > Maybe the earlier check is an important performance optimization? Or more > > likely it is just redundant code that doesn’t really significantly speed > > anything up and causes us to lose the key assertion. I guess I should follow up on this at some point. 315436 2017-07-14 09:49:45 -0700 2017-07-14 10:48:19 -0700 Patch bug-174507-20170714095017.patch text/plain 2943 cdumez U3VidmVyc2lvbiBSZXZpc2lvbjogMjE5NTAzCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0L0No YW5nZUxvZyBiL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCmluZGV4IGUxN2MwZjczNWQxOTIwZTgy YTZkZmYwZThmMTU4NTNjMDM5YzIxMDkuLmMyZjQ1Y2FiZWEzODM2MGZmOWMwNjJmZjJkYWFhYTAw YTMzNjU5NTggMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCisrKyBiL1NvdXJj ZS9XZWJLaXQvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMjQgQEAKKzIwMTctMDctMTQgIENocmlzIER1 bWV6ICA8Y2R1bWV6QGFwcGxlLmNvbT4KKworICAgICAgICBQb3RlbnRpYWwgbnVsbC1kZXJlZmVy ZW5jZSB1bmRlciBOZXR3b3JrUlRDUHJvdmlkZXI6OnJlc29sdmVkTmFtZSgpCisgICAgICAgIGh0 dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xNzQ1MDcKKyAgICAgICAgPHJk YXI6Ly9wcm9ibGVtLzMyNTk3ODY4PgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09Q UyEpLgorCisgICAgICAgIE5ldHdvcmtSVENQcm92aWRlcjo6cmVzb2x2ZWROYW1lKCkgY291bGQg ZG8gYSBudWxsIGRlcmVmZXJlbmNlIG9mIG1fY29ubmVjdGlvbgorICAgICAgICBiZWNhdXNlIG1f Y29ubmVjdGlvbiBpcyBudWxsaWZpZWQgaW4gTmV0d29ya1JUQ1Byb3ZpZGVyOjpjbG9zZSgpIGJ1 dCByZXNvbHZlcnMKKyAgICAgICAgd2VyZSBvbmx5IGNsb3NlZCBsYXRlciBvbiBpbiB0aGUgTmV0 d29ya1JUQ1Byb3ZpZGVyIGRlc3RydWN0b3IuCisKKyAgICAgICAgVG8gYWRkcmVzcyB0aGUgaXNz dWUsIHdlIG5vdyBzdG9wIEROUyByZXNvbHZlcnMgZWFybGllciwgaW4gTmV0d29ya1JUQ1Byb3Zp ZGVyOjpjbG9zZSgpLgorICAgICAgICBBbHNvIGZpeCB1bnNhZmUgbW9kaWZpY2F0aW9uIG9mIG1f cmVzb2x2ZXJzIEhhc2hNYXAgd2hlbiBpdGVyYXRpbmcgb3ZlciBpdC4KKworICAgICAgICAqIE5l dHdvcmtQcm9jZXNzL3dlYnJ0Yy9OZXR3b3JrUlRDUHJvdmlkZXIuY3BwOgorICAgICAgICAoV2Vi S2l0OjpOZXR3b3JrUlRDUHJvdmlkZXI6On5OZXR3b3JrUlRDUHJvdmlkZXIpOgorICAgICAgICAo V2ViS2l0OjpOZXR3b3JrUlRDUHJvdmlkZXI6OmNsb3NlKToKKyAgICAgICAgKFdlYktpdDo6TmV0 d29ya1JUQ1Byb3ZpZGVyOjpSZXNvbHZlcjo6flJlc29sdmVyKToKKyAgICAgICAgKFdlYktpdDo6 TmV0d29ya1JUQ1Byb3ZpZGVyOjpzdG9wUmVzb2x2ZXIpOgorCiAyMDE3LTA3LTEzICBDaHJpcyBE dW1leiAgPGNkdW1lekBhcHBsZS5jb20+CiAKICAgICAgICAgQmV0dGVyIGRlYWwgd2l0aCBjaGFu Z2VzIHRvIHRoZSBSZXNvdXJjZUxvYWRTdGF0aXN0aWNzU3RvcmUgZmlsZSBvbiBkaXNrCmRpZmYg LS1naXQgYS9Tb3VyY2UvV2ViS2l0L05ldHdvcmtQcm9jZXNzL3dlYnJ0Yy9OZXR3b3JrUlRDUHJv dmlkZXIuY3BwIGIvU291cmNlL1dlYktpdC9OZXR3b3JrUHJvY2Vzcy93ZWJydGMvTmV0d29ya1JU Q1Byb3ZpZGVyLmNwcAppbmRleCAwZjNmYmVmZGE2MTU5OWU3MDEwODE4YzE1MWU0ZTliMjBhZWM4 YTMyLi5jZDIxNmI0Nzc4Yzk0YmE1MmRiM2E0YTllM2RhZmVlMWUyMmFiNDU3IDEwMDY0NAotLS0g YS9Tb3VyY2UvV2ViS2l0L05ldHdvcmtQcm9jZXNzL3dlYnJ0Yy9OZXR3b3JrUlRDUHJvdmlkZXIu Y3BwCisrKyBiL1NvdXJjZS9XZWJLaXQvTmV0d29ya1Byb2Nlc3Mvd2VicnRjL05ldHdvcmtSVENQ cm92aWRlci5jcHAKQEAgLTY5LDEzICs2OSwxMyBAQCBOZXR3b3JrUlRDUHJvdmlkZXI6On5OZXR3 b3JrUlRDUHJvdmlkZXIoKQogICAgIEFTU0VSVCghbV9jb25uZWN0aW9uKTsKICAgICBBU1NFUlQo IW1fc29ja2V0cy5zaXplKCkpOwogICAgIEFTU0VSVCghbV9ydGNNb25pdG9yLmlzU3RhcnRlZCgp KTsKLQotICAgIGZvciAoYXV0byBpZGVudGlmaWVyIDogbV9yZXNvbHZlcnMua2V5cygpKQotICAg ICAgICBzdG9wUmVzb2x2ZXIoaWRlbnRpZmllcik7CiB9CiAKIHZvaWQgTmV0d29ya1JUQ1Byb3Zp ZGVyOjpjbG9zZSgpCiB7CisgICAgLy8gQ2FuY2VsIGFsbCBwZW5kaW5nIEROUyByZXNvbHV0aW9u cy4KKyAgICBtX3Jlc29sdmVycy5jbGVhcigpOworCiAgICAgbV9jb25uZWN0aW9uID0gbnVsbHB0 cjsKICAgICBtX3J0Y01vbml0b3Iuc3RvcFVwZGF0aW5nKCk7CiAKQEAgLTE3OCwxNSArMTc4LDE1 IEBAIHZvaWQgTmV0d29ya1JUQ1Byb3ZpZGVyOjpjcmVhdGVSZXNvbHZlcih1aW50NjRfdCBpZGVu dGlmaWVyLCBjb25zdCBTdHJpbmcmIGFkZHJlCiAKIE5ldHdvcmtSVENQcm92aWRlcjo6UmVzb2x2 ZXI6On5SZXNvbHZlcigpCiB7CisgICAgQ0ZIb3N0Q2FuY2VsSW5mb1Jlc29sdXRpb24oaG9zdC5n ZXQoKSwgQ0ZIb3N0SW5mb1R5cGU6OmtDRkhvc3RBZGRyZXNzZXMpOwogICAgIENGSG9zdFVuc2No ZWR1bGVGcm9tUnVuTG9vcChob3N0LmdldCgpLCBDRlJ1bkxvb3BHZXRDdXJyZW50KCksIGtDRlJ1 bkxvb3BEZWZhdWx0TW9kZSk7CiAgICAgQ0ZIb3N0U2V0Q2xpZW50KGhvc3QuZ2V0KCksIG51bGxw dHIsIG51bGxwdHIpOwogfQogCiB2b2lkIE5ldHdvcmtSVENQcm92aWRlcjo6c3RvcFJlc29sdmVy KHVpbnQ2NF90IGlkZW50aWZpZXIpCiB7Ci0gICAgYXV0byByZXNvbHZlciA9IG1fcmVzb2x2ZXJz LnRha2UoaWRlbnRpZmllcik7Ci0gICAgaWYgKHJlc29sdmVyKQotICAgICAgICBDRkhvc3RDYW5j ZWxJbmZvUmVzb2x1dGlvbihyZXNvbHZlci0+aG9zdC5nZXQoKSwgQ0ZIb3N0SW5mb1R5cGU6OmtD Rkhvc3RBZGRyZXNzZXMpOworICAgIEFTU0VSVChpZGVudGlmaWVyKTsKKyAgICBtX3Jlc29sdmVy cy5yZW1vdmUoaWRlbnRpZmllcik7CiB9CiAKIHZvaWQgTmV0d29ya1JUQ1Byb3ZpZGVyOjpyZXNv bHZlZE5hbWUoQ0ZIb3N0UmVmIGhvc3RSZWYsIENGSG9zdEluZm9UeXBlIHR5cGVJbmZvLCBjb25z dCBDRlN0cmVhbUVycm9yICplcnJvciwgdm9pZCAqaW5mbykK 315446 2017-07-14 10:48:20 -0700 2017-07-14 11:55:44 -0700 Patch bug-174507-20170714104853.patch text/plain 2584 cdumez U3VidmVyc2lvbiBSZXZpc2lvbjogMjE5NTAzCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0L0No YW5nZUxvZyBiL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCmluZGV4IGUxN2MwZjczNWQxOTIwZTgy YTZkZmYwZThmMTU4NTNjMDM5YzIxMDkuLjBkNzliMzA1YTJkYzVjN2I4OGJmYjBjYzI0ZDVjZWZk ZTBiMGMwY2EgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCisrKyBiL1NvdXJj ZS9XZWJLaXQvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMjQgQEAKKzIwMTctMDctMTQgIENocmlzIER1 bWV6ICA8Y2R1bWV6QGFwcGxlLmNvbT4KKworICAgICAgICBQb3RlbnRpYWwgbnVsbC1kZXJlZmVy ZW5jZSB1bmRlciBOZXR3b3JrUlRDUHJvdmlkZXI6OnJlc29sdmVkTmFtZSgpCisgICAgICAgIGh0 dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xNzQ1MDcKKyAgICAgICAgPHJk YXI6Ly9wcm9ibGVtLzMyNTk3ODY4PgorCisgICAgICAgIFJldmlld2VkIGJ5IFlvdWVubiBGYWJs ZXQuCisKKyAgICAgICAgTmV0d29ya1JUQ1Byb3ZpZGVyOjpyZXNvbHZlZE5hbWUoKSBjb3VsZCBk byBhIG51bGwgZGVyZWZlcmVuY2Ugb2YgbV9jb25uZWN0aW9uCisgICAgICAgIGJlY2F1c2UgbV9j b25uZWN0aW9uIGlzIG51bGxpZmllZCBpbiBOZXR3b3JrUlRDUHJvdmlkZXI6OmNsb3NlKCkgYnV0 IHJlc29sdmVycworICAgICAgICB3ZXJlIG9ubHkgY2xvc2VkIGxhdGVyIG9uIGluIHRoZSBOZXR3 b3JrUlRDUHJvdmlkZXIgZGVzdHJ1Y3Rvci4KKworICAgICAgICBUbyBhZGRyZXNzIHRoZSBpc3N1 ZSwgd2Ugbm93IHN0b3AgRE5TIHJlc29sdmVycyBlYXJsaWVyLCBpbiBOZXR3b3JrUlRDUHJvdmlk ZXI6OmNsb3NlKCkuCisgICAgICAgIEFsc28gZml4IHVuc2FmZSBtb2RpZmljYXRpb24gb2YgbV9y ZXNvbHZlcnMgSGFzaE1hcCB3aGVuIGl0ZXJhdGluZyBvdmVyIGl0LgorCisgICAgICAgICogTmV0 d29ya1Byb2Nlc3Mvd2VicnRjL05ldHdvcmtSVENQcm92aWRlci5jcHA6CisgICAgICAgIChXZWJL aXQ6Ok5ldHdvcmtSVENQcm92aWRlcjo6fk5ldHdvcmtSVENQcm92aWRlcik6CisgICAgICAgIChX ZWJLaXQ6Ok5ldHdvcmtSVENQcm92aWRlcjo6Y2xvc2UpOgorICAgICAgICAoV2ViS2l0OjpOZXR3 b3JrUlRDUHJvdmlkZXI6OlJlc29sdmVyOjp+UmVzb2x2ZXIpOgorICAgICAgICAoV2ViS2l0OjpO ZXR3b3JrUlRDUHJvdmlkZXI6OnN0b3BSZXNvbHZlcik6CisKIDIwMTctMDctMTMgIENocmlzIER1 bWV6ICA8Y2R1bWV6QGFwcGxlLmNvbT4KIAogICAgICAgICBCZXR0ZXIgZGVhbCB3aXRoIGNoYW5n ZXMgdG8gdGhlIFJlc291cmNlTG9hZFN0YXRpc3RpY3NTdG9yZSBmaWxlIG9uIGRpc2sKZGlmZiAt LWdpdCBhL1NvdXJjZS9XZWJLaXQvTmV0d29ya1Byb2Nlc3Mvd2VicnRjL05ldHdvcmtSVENQcm92 aWRlci5jcHAgYi9Tb3VyY2UvV2ViS2l0L05ldHdvcmtQcm9jZXNzL3dlYnJ0Yy9OZXR3b3JrUlRD UHJvdmlkZXIuY3BwCmluZGV4IDBmM2ZiZWZkYTYxNTk5ZTcwMTA4MThjMTUxZTRlOWIyMGFlYzhh MzIuLjQwZTBkZDA4YzgwMmJkMmRlMjdkODVhNDFlM2ZlNDNhMzQ1N2U2ODEgMTAwNjQ0Ci0tLSBh L1NvdXJjZS9XZWJLaXQvTmV0d29ya1Byb2Nlc3Mvd2VicnRjL05ldHdvcmtSVENQcm92aWRlci5j cHAKKysrIGIvU291cmNlL1dlYktpdC9OZXR3b3JrUHJvY2Vzcy93ZWJydGMvTmV0d29ya1JUQ1By b3ZpZGVyLmNwcApAQCAtNjksMTMgKzY5LDE0IEBAIE5ldHdvcmtSVENQcm92aWRlcjo6fk5ldHdv cmtSVENQcm92aWRlcigpCiAgICAgQVNTRVJUKCFtX2Nvbm5lY3Rpb24pOwogICAgIEFTU0VSVCgh bV9zb2NrZXRzLnNpemUoKSk7CiAgICAgQVNTRVJUKCFtX3J0Y01vbml0b3IuaXNTdGFydGVkKCkp OwotCi0gICAgZm9yIChhdXRvIGlkZW50aWZpZXIgOiBtX3Jlc29sdmVycy5rZXlzKCkpCi0gICAg ICAgIHN0b3BSZXNvbHZlcihpZGVudGlmaWVyKTsKIH0KIAogdm9pZCBOZXR3b3JrUlRDUHJvdmlk ZXI6OmNsb3NlKCkKIHsKKyAgICAvLyBDYW5jZWwgYWxsIHBlbmRpbmcgRE5TIHJlc29sdXRpb25z LgorICAgIHdoaWxlICghbV9yZXNvbHZlcnMuaXNFbXB0eSgpKQorICAgICAgICBzdG9wUmVzb2x2 ZXIoKm1fcmVzb2x2ZXJzLmtleXMoKS5iZWdpbigpKTsKKwogICAgIG1fY29ubmVjdGlvbiA9IG51 bGxwdHI7CiAgICAgbV9ydGNNb25pdG9yLnN0b3BVcGRhdGluZygpOwogCkBAIC0xODQsOCArMTg1 LDggQEAgTmV0d29ya1JUQ1Byb3ZpZGVyOjpSZXNvbHZlcjo6flJlc29sdmVyKCkKIAogdm9pZCBO ZXR3b3JrUlRDUHJvdmlkZXI6OnN0b3BSZXNvbHZlcih1aW50NjRfdCBpZGVudGlmaWVyKQogewot ICAgIGF1dG8gcmVzb2x2ZXIgPSBtX3Jlc29sdmVycy50YWtlKGlkZW50aWZpZXIpOwotICAgIGlm IChyZXNvbHZlcikKKyAgICBBU1NFUlQoaWRlbnRpZmllcik7CisgICAgaWYgKGF1dG8gcmVzb2x2 ZXIgPSBtX3Jlc29sdmVycy50YWtlKGlkZW50aWZpZXIpKQogICAgICAgICBDRkhvc3RDYW5jZWxJ bmZvUmVzb2x1dGlvbihyZXNvbHZlci0+aG9zdC5nZXQoKSwgQ0ZIb3N0SW5mb1R5cGU6OmtDRkhv c3RBZGRyZXNzZXMpOwogfQogCg==