160403 2016-08-01 07:41:29 -0700 [bmalloc] Merging of XLargeRanges can leak the upper range 2016-08-04 03:22:28 -0700 1 1 1 Unclassified WebKit bmalloc WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED InRadar P2 Normal --- 1 zan zan ap cgarcia ddkilzer ggaren kling mrobinson msaboff webkit-bug-importer oldest_to_newest 1216102 0 zan 2016-08-01 07:41:29 -0700 merge in XLargeRange.h first deduces the lower range and then checks if the size of the lower range matches the physical size. If so, the two ranges are merged into one, summing both logical and physical sizes. But if the logical size of the lower range does not match the physical size, the returned range discards any physical size for the upper range. At least on Linux systems, this results in leaking pages that are described in the upper XLargeRange. Using memfds and some simple tagging, I was able to get bmalloc to differentiate between small, large and misc allocations (Vector and Cache). This helped properly measure which types of allocations used the largest amount of memory, along with verbosely outlining memory mappings for any process using bmalloc. The JetStream benchmark was used to analyze the issue. After completing, on the GTK+ port, the WebProcess was using over 500MB there. Investigating the mappings, over 200MB was used for large allocations, even when m_largeAllocated map in the bmalloc::Heap object was reporting only 47MB of large allocations. Further inspection then led to the XLargeRange merging, showing that the upper range can have its physical size information ignored if the lower range is not fully allocated. 1216110 1 285013 zan 2016-08-01 08:19:25 -0700 Created attachment 285013 Patch 1216530 2 285013 ggaren 2016-08-02 11:05:20 -0700 Comment on attachment 285013 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=285013&action=review > Source/bmalloc/ChangeLog:18 > + ignored. At least on Linux systems, this resulted in such > + memory allocations being leaked. Can you explain in more detail why we end up with a leak on Linux? On Mac and Windows, at least, it's OK to call vmAllocatePhysicalPages twice for the same address range. > Source/bmalloc/bmalloc/XLargeRange.h:70 > { > - if (a.end() == b.begin()) > + if (a.end() == b.begin() && (a.size() == a.physicalSize() || (!a.physicalSize() && !b.physicalSize()))) > return true; > > - if (b.end() == a.begin()) > + if (b.end() == a.begin() && (b.size() == b.physicalSize() || (!a.physicalSize() && !b.physicalSize()))) > return true; > This will cause serious virtual memory fragmentation, triggering jetsam on iOS. 1216806 3 ggaren 2016-08-02 22:52:40 -0700 I think I understand what you're reporting now: If we merge(A, B), and B has physicalSize and A doesn't, we produce an XLargeRange with no physicalSize. In principle, this is OK: physicalSize is just an optimization to remember the contiguous committed space at the head of a range, and the optimization has failed since there is none. The problem happens later, in Heap::scavengeLargeObjects. We scavenge by calling XLargeMap::removePhysical -- but the [A, B] range has no physicalSize, so we never scavenge it. I still don't think we want to change the behavior of merge() -- instead, we want to change the behavior of Heap::scavengeLargeObjects. 1216907 4 zan 2016-08-03 07:13:02 -0700 (In reply to comment #2) > Comment on attachment 285013 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=285013&action=review > > > Source/bmalloc/ChangeLog:18 > > + ignored. At least on Linux systems, this resulted in such > > + memory allocations being leaked. > > Can you explain in more detail why we end up with a leak on Linux? > > On Mac and Windows, at least, it's OK to call vmAllocatePhysicalPages twice > for the same address range. > It's OK on Linux as well. The problem I'm trying to address here is that right-hand XLargeRanges with some physical size can get ignored during merging if the left-hand ranges have partial physical size or no physical size. So the merged range only has information on any physical allocation that was done for the left-hand range, while the allocated memory from the right-hand range doesn't get deallocated during scavenging, but instead relies on some future allocation to reuse that range. (In reply to comment #3) > I think I understand what you're reporting now: > > If we merge(A, B), and B has physicalSize and A doesn't, we produce an > XLargeRange with no physicalSize. > Also if A has physicalSize that's less that its size, which can be the case if A was previously merged from A1 that had physicalSize matching its size, and A2 that had no physicalSize. > In principle, this is OK: physicalSize is just an optimization to remember > the contiguous committed space at the head of a range, and the optimization > has failed since there is none. > > The problem happens later, in Heap::scavengeLargeObjects. We scavenge by > calling XLargeMap::removePhysical -- but the [A, B] range has no > physicalSize, so we never scavenge it. > > I still don't think we want to change the behavior of merge() -- instead, we > want to change the behavior of Heap::scavengeLargeObjects. How exactly? Would it be acceptable to delay merging of ranges until after all the large allocations have been scavenged? 1217025 5 ggaren 2016-08-03 11:17:30 -0700 > > If we merge(A, B), and B has physicalSize and A doesn't, we produce an > > XLargeRange with no physicalSize. > > > > Also if A has physicalSize that's less that its size, which can be the case > if A was previously merged from A1 that had physicalSize matching its size, > and A2 that had no physicalSize. If we merge(A, B), and B has no physicalSize and A has physicalSize less than its size, we'll do this: return XLargeRange( left.begin(), a.size() + b.size(), left.physicalSize()); So, A's physicalSize is not lost. 1217028 6 285252 ggaren 2016-08-03 11:22:18 -0700 Created attachment 285252 Patch 1217033 7 285252 msaboff 2016-08-03 11:32:37 -0700 Comment on attachment 285252 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=285252&action=review r=me > Source/bmalloc/ChangeLog:11 > + Recorded physical size is a performance optimization is not the truth, > + so depending on it can cause you to forget physical ranges. Wording seems awkward. Should the second "is" be "and"? The second part of the sentence probably needs some work as well. > Source/bmalloc/ChangeLog:16 > + Be careful each time through the loop to decrement our iterator if > + the map shrunk while we released the lock. Seems awkward as well. 1217043 8 ggaren 2016-08-03 11:44:35 -0700 Committed r204091: <http://trac.webkit.org/changeset/204091> 1217044 9 ggaren 2016-08-03 11:45:34 -0700 > > Source/bmalloc/ChangeLog:11 > > + Recorded physical size is a performance optimization is not the truth, > > + so depending on it can cause you to forget physical ranges. > > Wording seems awkward. Should the second "is" be "and"? The second part of > the sentence probably needs some work as well. (bmalloc::Heap::scavengeLargeObjects): Don't use removePhysical(). Recorded physical size is a performance optimization. It is not the truth. So it might be zero even if a range contains physical pages. > > Source/bmalloc/ChangeLog:16 > > + Be careful each time through the loop to decrement our iterator if > > + the map shrunk while we released the lock. > The map can shrink when we release the lock, so we must clamp our iterator each time through the loop. 1217077 10 zan 2016-08-03 12:49:01 -0700 (In reply to comment #5) > > > If we merge(A, B), and B has physicalSize and A doesn't, we produce an > > > XLargeRange with no physicalSize. > > > > > > > Also if A has physicalSize that's less that its size, which can be the case > > if A was previously merged from A1 that had physicalSize matching its size, > > and A2 that had no physicalSize. > > If we merge(A, B), and B has no physicalSize and A has physicalSize less > than its size, we'll do this: > > return XLargeRange( > left.begin(), > a.size() + b.size(), > left.physicalSize()); > > So, A's physicalSize is not lost. Right, I misread your comment. What I was writing about was that if A has some physicalSize that doesn't match its whole size, and B has some physicalSize as well, then B's physicalSize would be lost. Shouldn't be a problem anymore though, thanks for the quick fix. 1217356 11 ddkilzer 2016-08-04 03:22:28 -0700 <rdar://problem/27696655> 285013 2016-08-01 08:19:25 -0700 2016-08-03 11:22:14 -0700 Patch bug-160403-20160801081805.patch text/plain 2765 zan U3VidmVyc2lvbiBSZXZpc2lvbjogMjAzOTczCmRpZmYgLS1naXQgYS9Tb3VyY2UvYm1hbGxvYy9D aGFuZ2VMb2cgYi9Tb3VyY2UvYm1hbGxvYy9DaGFuZ2VMb2cKaW5kZXggYjU3NmY5MzhmMjA2YjNi NjZjNTFlZGZjYjY1MjJhY2Q3NWFhNjY3Ny4uYjkzN2RiZDAyOWIyMmJiZGZjYjE0ODQ4Mjg0NTk1 ODBjMTdiNDg5MSAxMDA2NDQKLS0tIGEvU291cmNlL2JtYWxsb2MvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9ibWFsbG9jL0NoYW5nZUxvZwpAQCAtMSwzICsxLDI2IEBACisyMDE2LTA4LTAxICBaYW4g RG9iZXJzZWsgIDx6ZG9iZXJzZWtAaWdhbGlhLmNvbT4KKworICAgICAgICBbYm1hbGxvY10gTWVy Z2luZyBvZiBYTGFyZ2VSYW5nZXMgY2FuIGxlYWsgdGhlIHVwcGVyIHJhbmdlCisgICAgICAgIGh0 dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xNjA0MDMKKworICAgICAgICBS ZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBPbmx5IGFsbG93IG1lcmdlIG9m IHR3byBYTGFyZ2VSYW5nZXMgaWYgdGhleSBhcmUgY29udGlndW91cworICAgICAgICBhbmQgZWl0 aGVyIHRoZSB3aG9sZSBsb3dlciByYW5nZSBjb3ZlcnMgYWxsb2NhdGVkIG1lbW9yeSBvcgorICAg ICAgICBib3RoIHJhbmdlcyBjb3ZlciBubyBhbGxvY2F0ZWQgbWVtb3J5LgorCisgICAgICAgIFBy ZXZpb3VzbHksIHRoZSBtZXJnZSB3YXMgZG9uZSBpZiB0aGUgcmFuZ2VzIHdlcmUgY29udGlndW91 cy4KKyAgICAgICAgSWYgdGhlIHdob2xlIGxvd2VyIHJhbmdlIGNvdmVyZWQgYWxsb2NhdGVkIG1l bW9yeSB0aGlzIHdvcmtlZAorICAgICAgICBhcyBpbnRlbmRlZCwgbWVyZ2luZyBhbnkgYWxsb2Nh dGVkIG1lbW9yeSBvZiB0aGUgdXBwZXIgcmFuZ2UuCisgICAgICAgIElmIHRoZSBsb3dlciByYW5n ZSBkaWRuJ3QgY292ZXIgYWxsb2NhdGVkIG1lbW9yeSBjb21wbGV0ZWx5LAorICAgICAgICB0aGUg aW5mb3JtYXRpb24gYWJvdXQgYWxsb2NhdGVkIG1lbW9yeSBpbiB0aGUgdXBwZXIgcmFuZ2Ugd2Fz CisgICAgICAgIGlnbm9yZWQuIEF0IGxlYXN0IG9uIExpbnV4IHN5c3RlbXMsIHRoaXMgcmVzdWx0 ZWQgaW4gc3VjaAorICAgICAgICBtZW1vcnkgYWxsb2NhdGlvbnMgYmVpbmcgbGVha2VkLgorCisg ICAgICAgICogYm1hbGxvYy9YTGFyZ2VSYW5nZS5oOgorICAgICAgICAoYm1hbGxvYzo6Y2FuTWVy Z2UpOgorICAgICAgICAoYm1hbGxvYzo6bWVyZ2UpOgorCiAyMDE2LTA3LTEzICBFbnJpY2EgQ2Fz dWNjaSAgPGVucmljYUBhcHBsZS5jb20+CiAKICAgICAgICAgVXBkYXRlIHN1cHBvcnRlZCBwbGF0 Zm9ybXMgaW4geGNjb25maWcgZmlsZXMgdG8gbWF0Y2ggdGhlIHNkayBuYW1lcy4KZGlmZiAtLWdp dCBhL1NvdXJjZS9ibWFsbG9jL2JtYWxsb2MvWExhcmdlUmFuZ2UuaCBiL1NvdXJjZS9ibWFsbG9j L2JtYWxsb2MvWExhcmdlUmFuZ2UuaAppbmRleCA0NTAxM2UxYzI4MDU0YWY4ZTAwNGVhMjQwMzVh NjZlNzBmYjMxMGViLi41NzkxNDlmNWIyMWJhZGZhNDU3YmEzOWE1N2RjMWZlMjA0ZWY4ZWI4IDEw MDY0NAotLS0gYS9Tb3VyY2UvYm1hbGxvYy9ibWFsbG9jL1hMYXJnZVJhbmdlLmgKKysrIGIvU291 cmNlL2JtYWxsb2MvYm1hbGxvYy9YTGFyZ2VSYW5nZS5oCkBAIC02MiwxMCArNjIsMTAgQEAgcHJp dmF0ZToKIAogaW5saW5lIGJvb2wgY2FuTWVyZ2UoY29uc3QgWExhcmdlUmFuZ2UmIGEsIGNvbnN0 IFhMYXJnZVJhbmdlJiBiKQogewotICAgIGlmIChhLmVuZCgpID09IGIuYmVnaW4oKSkKKyAgICBp ZiAoYS5lbmQoKSA9PSBiLmJlZ2luKCkgJiYgKGEuc2l6ZSgpID09IGEucGh5c2ljYWxTaXplKCkg fHwgKCFhLnBoeXNpY2FsU2l6ZSgpICYmICFiLnBoeXNpY2FsU2l6ZSgpKSkpCiAgICAgICAgIHJl dHVybiB0cnVlOwogICAgIAotICAgIGlmIChiLmVuZCgpID09IGEuYmVnaW4oKSkKKyAgICBpZiAo Yi5lbmQoKSA9PSBhLmJlZ2luKCkgJiYgKGIuc2l6ZSgpID09IGIucGh5c2ljYWxTaXplKCkgfHwg KCFhLnBoeXNpY2FsU2l6ZSgpICYmICFiLnBoeXNpY2FsU2l6ZSgpKSkpCiAgICAgICAgIHJldHVy biB0cnVlOwogICAgIAogICAgIHJldHVybiBmYWxzZTsKQEAgLTczLDE4ICs3MywxMCBAQCBpbmxp bmUgYm9vbCBjYW5NZXJnZShjb25zdCBYTGFyZ2VSYW5nZSYgYSwgY29uc3QgWExhcmdlUmFuZ2Um IGIpCiAKIGlubGluZSBYTGFyZ2VSYW5nZSBtZXJnZShjb25zdCBYTGFyZ2VSYW5nZSYgYSwgY29u c3QgWExhcmdlUmFuZ2UmIGIpCiB7Ci0gICAgY29uc3QgWExhcmdlUmFuZ2UmIGxlZnQgPSBzdGQ6 Om1pbihhLCBiKTsKLSAgICBpZiAobGVmdC5zaXplKCkgPT0gbGVmdC5waHlzaWNhbFNpemUoKSkg ewotICAgICAgICByZXR1cm4gWExhcmdlUmFuZ2UoCi0gICAgICAgICAgICBsZWZ0LmJlZ2luKCks Ci0gICAgICAgICAgICBhLnNpemUoKSArIGIuc2l6ZSgpLAotICAgICAgICAgICAgYS5waHlzaWNh bFNpemUoKSArIGIucGh5c2ljYWxTaXplKCkpOwotICAgIH0KLQogICAgIHJldHVybiBYTGFyZ2VS YW5nZSgKLSAgICAgICAgbGVmdC5iZWdpbigpLAorICAgICAgICBzdGQ6Om1pbihhLCBiKS5iZWdp bigpLAogICAgICAgICBhLnNpemUoKSArIGIuc2l6ZSgpLAotICAgICAgICBsZWZ0LnBoeXNpY2Fs U2l6ZSgpKTsKKyAgICAgICAgYS5waHlzaWNhbFNpemUoKSArIGIucGh5c2ljYWxTaXplKCkpOwog fQogCiBpbmxpbmUgc3RkOjpwYWlyPFhMYXJnZVJhbmdlLCBYTGFyZ2VSYW5nZT4gWExhcmdlUmFu Z2U6OnNwbGl0KHNpemVfdCBzaXplKSBjb25zdAo= 285252 2016-08-03 11:22:18 -0700 2016-08-03 11:32:37 -0700 Patch bug-160403-20160803112057.patch text/plain 3453 ggaren SW5kZXg6IFNvdXJjZS9ibWFsbG9jL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvYm1h bGxvYy9DaGFuZ2VMb2cJKHJldmlzaW9uIDIwNDA4OCkKKysrIFNvdXJjZS9ibWFsbG9jL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDMxIEBACisyMDE2LTA4LTAzICBHZW9mZnJl eSBHYXJlbiAgPGdnYXJlbkBhcHBsZS5jb20+CisKKyAgICAgICAgW2JtYWxsb2NdIE1lcmdpbmcg b2YgWExhcmdlUmFuZ2VzIGNhbiBsZWFrIHRoZSB1cHBlciByYW5nZQorICAgICAgICBodHRwczov L2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTYwNDAzCisKKyAgICAgICAgUmV2aWV3 ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgKiBibWFsbG9jL0hlYXAuY3BwOgorICAg ICAgICAoYm1hbGxvYzo6SGVhcDo6c2NhdmVuZ2VMYXJnZU9iamVjdHMpOiBEb24ndCB1c2UgcmVt b3ZlUGh5c2ljYWwoKS4KKyAgICAgICAgUmVjb3JkZWQgcGh5c2ljYWwgc2l6ZSBpcyBhIHBlcmZv cm1hbmNlIG9wdGltaXphdGlvbiBpcyBub3QgdGhlIHRydXRoLAorICAgICAgICBzbyBkZXBlbmRp bmcgb24gaXQgY2FuIGNhdXNlIHlvdSB0byBmb3JnZXQgcGh5c2ljYWwgcmFuZ2VzLgorCisgICAg ICAgIEluc3RlYWQsIGl0ZXJhdGUgZWFjaCByYW5nZSBpbiB0aGUgbWFwLgorCisgICAgICAgIEJl IGNhcmVmdWwgZWFjaCB0aW1lIHRocm91Z2ggdGhlIGxvb3AgdG8gZGVjcmVtZW50IG91ciBpdGVy YXRvciBpZgorICAgICAgICB0aGUgbWFwIHNocnVuayB3aGlsZSB3ZSByZWxlYXNlZCB0aGUgbG9j ay4KKworICAgICAgICBJdCdzIE9LIGlmIHRoZSBtYXAgZ3Jvd3MgLS0gc2NhdmVuaW5nIHdpbGwg c3RhcnQgb3ZlciBmcm9tIHRoZSBzdGFydCBpbgorICAgICAgICB0aGF0IGNhc2UuCisKKyAgICAg ICAgKiBibWFsbG9jL1hMYXJnZU1hcC5jcHA6CisgICAgICAgIChibWFsbG9jOjpYTGFyZ2VNYXA6 OnJlbW92ZVBoeXNpY2FsKTogRGVsZXRlZC4gTm90IHVzZWQgYW55bW9yZS4KKworICAgICAgICAq IGJtYWxsb2MvWExhcmdlTWFwLmg6CisgICAgICAgIChibWFsbG9jOjpYTGFyZ2VNYXA6OnJhbmdl cyk6IEFkZGVkIGRpcmVjdCBhY2Nlc3MgZm9yIHRoZSBzYWtlIG9mCisgICAgICAgIHNjYXZlbmdl TGFyZ2VPYmplY3RzLiAoVGhpcyB2aW9sYXRlcyBvdXIgbmFtaW5nIGNvbnZlbnRpb25zIC0tIEkn bGwgZG8KKyAgICAgICAgYSByZW5hbWUgaW4gYSBmb2xsb3ctdXAgcGF0Y2guKQorCiAyMDE2LTA3 LTEzICBFbnJpY2EgQ2FzdWNjaSAgPGVucmljYUBhcHBsZS5jb20+CiAKICAgICAgICAgVXBkYXRl IHN1cHBvcnRlZCBwbGF0Zm9ybXMgaW4geGNjb25maWcgZmlsZXMgdG8gbWF0Y2ggdGhlIHNkayBu YW1lcy4KSW5kZXg6IFNvdXJjZS9ibWFsbG9jL2JtYWxsb2MvSGVhcC5jcHAKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot LS0gU291cmNlL2JtYWxsb2MvYm1hbGxvYy9IZWFwLmNwcAkocmV2aXNpb24gMjAzNjcyKQorKysg U291cmNlL2JtYWxsb2MvYm1hbGxvYy9IZWFwLmNwcAkod29ya2luZyBjb3B5KQpAQCAtMTMxLDEz ICsxMzEsMTYgQEAgdm9pZCBIZWFwOjpzY2F2ZW5nZVNtYWxsUGFnZXMoc3RkOjp1bmlxdQogCiB2 b2lkIEhlYXA6OnNjYXZlbmdlTGFyZ2VPYmplY3RzKHN0ZDo6dW5pcXVlX2xvY2s8U3RhdGljTXV0 ZXg+JiBsb2NrLCBzdGQ6OmNocm9ubzo6bWlsbGlzZWNvbmRzIHNsZWVwRHVyYXRpb24pCiB7Ci0g ICAgd2hpbGUgKFhMYXJnZVJhbmdlIHJhbmdlID0gbV9sYXJnZUZyZWUucmVtb3ZlUGh5c2ljYWwo KSkgeworICAgIGF1dG8mIHJhbmdlcyA9IG1fbGFyZ2VGcmVlLnJhbmdlcygpOworICAgIGZvciAo c2l6ZV90IGkgPSByYW5nZXMuc2l6ZSgpOyBpLS0gPiAwOyBpID0gc3RkOjptaW4oaSwgcmFuZ2Vz LnNpemUoKSkpIHsKKyAgICAgICAgYXV0byByYW5nZSA9IHJhbmdlcy5wb3AoaSk7CisKICAgICAg ICAgbG9jay51bmxvY2soKTsKICAgICAgICAgdm1EZWFsbG9jYXRlUGh5c2ljYWxQYWdlc1Nsb3Bw eShyYW5nZS5iZWdpbigpLCByYW5nZS5zaXplKCkpOwogICAgICAgICBsb2NrLmxvY2soKTsKLSAg ICAgICAgCisKICAgICAgICAgcmFuZ2Uuc2V0UGh5c2ljYWxTaXplKDApOwotICAgICAgICBtX2xh cmdlRnJlZS5hZGQocmFuZ2UpOworICAgICAgICByYW5nZXMucHVzaChyYW5nZSk7CiAKICAgICAg ICAgd2FpdFVudGlsRmFsc2UobG9jaywgc2xlZXBEdXJhdGlvbiwgbV9pc0FsbG9jYXRpbmdQYWdl cyk7CiAgICAgfQpJbmRleDogU291cmNlL2JtYWxsb2MvYm1hbGxvYy9YTGFyZ2VNYXAuY3BwCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIFNvdXJjZS9ibWFsbG9jL2JtYWxsb2MvWExhcmdlTWFwLmNwcAkocmV2aXNp b24gMjAzNjcyKQorKysgU291cmNlL2JtYWxsb2MvYm1hbGxvYy9YTGFyZ2VNYXAuY3BwCSh3b3Jr aW5nIGNvcHkpCkBAIC03NiwxNiArNzYsNCBAQCB2b2lkIFhMYXJnZU1hcDo6YWRkKGNvbnN0IFhM YXJnZVJhbmdlJiByCiAgICAgbV9mcmVlLnB1c2gobWVyZ2VkKTsKIH0KIAotWExhcmdlUmFuZ2Ug WExhcmdlTWFwOjpyZW1vdmVQaHlzaWNhbCgpCi17Ci0gICAgYXV0byBpdCA9IHN0ZDo6ZmluZF9p ZihtX2ZyZWUuYmVnaW4oKSwgbV9mcmVlLmVuZCgpLCBbXShjb25zdCBYTGFyZ2VSYW5nZSYgcmFu Z2UpIHsKLSAgICAgICAgcmV0dXJuIHJhbmdlLnBoeXNpY2FsU2l6ZSgpOwotICAgIH0pOwotCi0g ICAgaWYgKGl0ID09IG1fZnJlZS5lbmQoKSkKLSAgICAgICAgcmV0dXJuIFhMYXJnZVJhbmdlKCk7 Ci0KLSAgICByZXR1cm4gbV9mcmVlLnBvcChpdCk7Ci19Ci0KIH0gLy8gbmFtZXNwYWNlIGJtYWxs b2MKSW5kZXg6IFNvdXJjZS9ibWFsbG9jL2JtYWxsb2MvWExhcmdlTWFwLmgKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot LS0gU291cmNlL2JtYWxsb2MvYm1hbGxvYy9YTGFyZ2VNYXAuaAkocmV2aXNpb24gMjAzNjcyKQor KysgU291cmNlL2JtYWxsb2MvYm1hbGxvYy9YTGFyZ2VNYXAuaAkod29ya2luZyBjb3B5KQpAQCAt MzYsNyArMzYsNyBAQCBjbGFzcyBYTGFyZ2VNYXAgewogcHVibGljOgogICAgIHZvaWQgYWRkKGNv bnN0IFhMYXJnZVJhbmdlJik7CiAgICAgWExhcmdlUmFuZ2UgcmVtb3ZlKHNpemVfdCBhbGlnbm1l bnQsIHNpemVfdCk7Ci0gICAgWExhcmdlUmFuZ2UgcmVtb3ZlUGh5c2ljYWwoKTsKKyAgICBWZWN0 b3I8WExhcmdlUmFuZ2U+JiByYW5nZXMoKSB7IHJldHVybiBtX2ZyZWU7IH0KIAogcHJpdmF0ZToK ICAgICBWZWN0b3I8WExhcmdlUmFuZ2U+IG1fZnJlZTsK