121972 2013-09-26 13:31:33 -0700 testapi test crashes on Windows in WTF::Vector<wchar_t,64,WTF::UnsafeVectorOverflow>::size() 2013-12-03 18:17:43 -0800 1 1 1 Unclassified WebKit JavaScriptCore 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED InRadar P2 Normal --- 123585 1 mark.lam mark.lam benjamin bfulgham cmarcelo commit-queue fpizlo ggaren mark.lam mhahnenberg msaboff oliver peavo webkit-bug-importer oldest_to_newest 933657 0 mark.lam 2013-09-26 13:31:33 -0700 On the Windows build, the latest JSC (since before r156490) crashes when running testapi. The crash stack trace looks like this: JavaScriptCore.dll!WTF::Vector<wchar_t,64,WTF::UnsafeVectorOverflow>::size() Line 569 + 0x11 bytes C++ JavaScriptCore.dll!JSC::MarkedAllocator::forEachBlock<JSC::Free>(JSC::Free & functor) Line 141 + 0x8 bytes C++ JavaScriptCore.dll!JSC::MarkedSpace::forEachBlock<JSC::Free>(JSC::Free & functor) Line 230 C++ JavaScriptCore.dll!JSC::MarkedSpace::~MarkedSpace() Line 106 C++ JavaScriptCore.dll!JSC::Heap::~Heap() Line 282 + 0xee bytes C++ JavaScriptCore.dll!JSC::VM::~VM() Line 356 + 0x399 bytes C++ JavaScriptCore.dll!JSC::VM::`scalar deleting destructor'() + 0x16 bytes C++ JavaScriptCore.dll!WTF::ThreadSafeRefCounted<JSC::VM>::deref() Line 137 + 0x1c bytes C++ JavaScriptCore.dll!WTF::derefIfNotNull<JSC::VM>(JSC::VM * ptr) Line 45 C++ JavaScriptCore.dll!WTF::RefPtr<JSC::VM>::clear() Line 102 + 0x9 bytes C++ JavaScriptCore.dll!JSC::JSLockHolder::~JSLockHolder() Line 84 C++ JavaScriptCore.dll!JSGlobalContextRelease(OpaqueJSContext * ctx) Line 179 C++ testapi.exe!main(int argc, char * * argv) Line 1176 + 0xf bytes C++ testapi.exe!__tmainCRTStartup() Line 555 + 0x17 bytes C kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes This crash is reproducible every time we run testapi.exe. 933662 1 mhahnenberg 2013-09-26 13:36:33 -0700 That backtrace makes no sense. We don't access a Vector in MarkedAllocator::forEachBlock. Is this a debug backtrace? 933665 2 mark.lam 2013-09-26 13:41:43 -0700 (In reply to comment #1) > That backtrace makes no sense. We don't access a Vector in MarkedAllocator::forEachBlock. Is this a debug backtrace? This was run on a debug build. When it crashed, it gave me the opportunity to attach Visual Studio, and that's how I grabbed the stack trace. 933669 3 mhahnenberg 2013-09-26 13:47:19 -0700 Hmm, the only object I can find that uses a Vector<wchar_t,64,WTF::UnsafeVectorOverflow> is the JSStringBuilder. So maybe there's something weird going on there. Can you attach a full stack trace (e.g. with error code)? 933673 4 mark.lam 2013-09-26 13:49:51 -0700 (In reply to comment #3) > Hmm, the only object I can find that uses a Vector<wchar_t,64,WTF::UnsafeVectorOverflow> is the JSStringBuilder. So maybe there's something weird going on there. Can you attach a full stack trace (e.g. with error code)? That is the full stack trace. 933674 5 mhahnenberg 2013-09-26 13:50:47 -0700 > That is the full stack trace. There's no crash log anywhere? Not even something to tell you what happened (e.g. segfault, etc.)? 938970 6 webkit-bug-importer 2013-10-11 14:28:16 -0700 <rdar://problem/15211539> 939561 7 ggaren 2013-10-14 11:31:11 -0700 Seems like the JSC::Free must have called a bad function pointer. My guess is that the top stack frame is just bogus -- a tools bug that happens when there's a PC in the backtrace that doesn't correspond to real code with debug info. 955891 8 218294 peavo 2013-12-03 07:44:06 -0800 Created attachment 218294 Patch 955892 9 peavo 2013-12-03 07:45:39 -0800 The reason for the crash is that the wrong memory block is decommitted. This can happen if no memory has been committed in the reserved block before the JSStack object is destroyed. In the JSStack destructor, the pointer to decommit then points to the end of the block (or the start of the next), and the decommit size is zero. If there is a block just after the block we are trying to decommit, this block will be decommitted, since Windows will decommit the whole block, if the decommit size is zero (see VirtualFree). When somebody tries to read/write to this block later, we crash. 955918 10 218294 commit-queue 2013-12-03 09:07:05 -0800 Comment on attachment 218294 Patch Clearing flags on attachment: 218294 Committed r160004: <http://trac.webkit.org/changeset/160004> 955919 11 commit-queue 2013-12-03 09:07:09 -0800 All reviewed patches have been landed. Closing bug. 955920 12 bfulgham 2013-12-03 09:07:34 -0800 (In reply to comment #9) > The reason for the crash is that the wrong memory block is decommitted. > This can happen if no memory has been committed in the reserved block before the JSStack object is destroyed. > In the JSStack destructor, the pointer to decommit then points to the end of the block (or the start of the next), and the decommit size is zero. > If there is a block just after the block we are trying to decommit, this block will be decommitted, since Windows will decommit the whole block, > if the decommit size is zero (see VirtualFree). When somebody tries to read/write to this block later, we crash. Nice work! 956078 13 mark.lam 2013-12-03 13:43:34 -0800 (In reply to comment #9) > The reason for the crash is that the wrong memory block is decommitted. > This can happen if no memory has been committed in the reserved block before the JSStack object is destroyed. > In the JSStack destructor, the pointer to decommit then points to the end of the block (or the start of the next), and the decommit size is zero. > If there is a block just after the block we are trying to decommit, this block will be decommitted, since Windows will decommit the whole block, > if the decommit size is zero (see VirtualFree). When somebody tries to read/write to this block later, we crash. Nice catch. However, I think the better fix would be to make OSAllocator::decommit() handle a 0 size as one would expect i.e. do nothing. The behavior of Window's VirtualFree() in terms of its interpretation of what a 0 size means is not intuitive. I'll look into fixing this in separate patch + bug. Fixing the interpretation of size 0 in OSAllocator will also help avoid future surprises like this from manifesting. 956224 14 mark.lam 2013-12-03 17:38:56 -0800 Reopening this bug to apply the better fix in OSAllocatorWin. 956226 15 218367 mark.lam 2013-12-03 17:40:14 -0800 Created attachment 218367 Fixing OSAllocatorWin instead. 956227 16 218367 bfulgham 2013-12-03 17:41:09 -0800 Comment on attachment 218367 Fixing OSAllocatorWin instead. r=me 956233 17 218367 mhahnenberg 2013-12-03 17:52:36 -0800 Comment on attachment 218367 Fixing OSAllocatorWin instead. View in context: https://bugs.webkit.org/attachment.cgi?id=218367&action=review > Source/WTF/wtf/OSAllocatorWin.cpp:69 > + return; // Nothing to do. This comment seems unnecessary. > Source/WTF/wtf/OSAllocatorWin.cpp:78 > + return; // Nothing to do. Ditto. 956234 18 218367 mhahnenberg 2013-12-03 17:53:32 -0800 Comment on attachment 218367 Fixing OSAllocatorWin instead. View in context: https://bugs.webkit.org/attachment.cgi?id=218367&action=review >> Source/WTF/wtf/OSAllocatorWin.cpp:69 >> + return; // Nothing to do. > > This comment seems unnecessary. Instead, I would comment on how Windows does odd things when the size is 0 and refer them to this bug. 956239 19 218367 mark.lam 2013-12-03 18:01:50 -0800 Comment on attachment 218367 Fixing OSAllocatorWin instead. I'll update the comments based on Mark H's suggestion and land the patch manually. 956242 20 mark.lam 2013-12-03 18:17:43 -0800 Update patch landed in r160063: <http://trac.webkit.org/r160063>. 218294 2013-12-03 07:44:06 -0800 2013-12-03 17:40:14 -0800 Patch bug-121972-20131203164336.patch text/plain 2474 peavo SW5kZXg6IFNvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291 cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwkocmV2aXNpb24gMTYwMDAyKQorKysgU291cmNl L0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE5IEBA CisyMDEzLTEyLTAzICBwZWF2b0BvdXRsb29rLmNvbSAgPHBlYXZvQG91dGxvb2suY29tPgorCisg ICAgICAgIHRlc3RhcGkgdGVzdCBjcmFzaGVzIG9uIFdpbmRvd3MgaW4gV1RGOjpWZWN0b3I8d2No YXJfdCw2NCxXVEY6OlVuc2FmZVZlY3Rvck92ZXJmbG93Pjo6c2l6ZSgpCisgICAgICAgIGh0dHBz Oi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xMjE5NzIKKworICAgICAgICBSZXZp ZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBUaGUgcmVhc29uIGZvciB0aGUgY3Jh c2ggaXMgdGhhdCB0aGUgd3JvbmcgbWVtb3J5IGJsb2NrIGlzIGRlY29tbWl0dGVkLgorICAgICAg ICBUaGlzIGNhbiBoYXBwZW4gaWYgbm8gbWVtb3J5IGhhcyBiZWVuIGNvbW1pdHRlZCBpbiB0aGUg cmVzZXJ2ZWQgYmxvY2sgYmVmb3JlIHRoZSBKU1N0YWNrIG9iamVjdCBpcyBkZXN0cm95ZWQuCisg ICAgICAgIEluIHRoZSBKU1N0YWNrIGRlc3RydWN0b3IsIHRoZSBwb2ludGVyIHRvIGRlY29tbWl0 IHRoZW4gcG9pbnRzIHRvIHRoZSBlbmQgb2YgdGhlIGJsb2NrIChvciB0aGUgc3RhcnQgb2YgdGhl IG5leHQpLCBhbmQgdGhlIGRlY29tbWl0IHNpemUgaXMgemVyby4KKyAgICAgICAgSWYgdGhlcmUg aXMgYSBibG9jayBqdXN0IGFmdGVyIHRoZSBibG9jayB3ZSBhcmUgdHJ5aW5nIHRvIGRlY29tbWl0 LCB0aGlzIGJsb2NrIHdpbGwgYmUgZGVjb21taXR0ZWQsIHNpbmNlIFdpbmRvd3Mgd2lsbCBkZWNv bW1pdCB0aGUgd2hvbGUgYmxvY2ssCisgICAgICAgIGlmIHRoZSBkZWNvbW1pdCBzaXplIGlzIHpl cm8gKHNlZSBWaXJ0dWFsRnJlZSkuIFdoZW4gc29tZWJvZHkgdHJpZXMgdG8gcmVhZC93cml0ZSB0 byB0aGlzIGJsb2NrIGxhdGVyLCB3ZSBjcmFzaC4KKworICAgICAgICAqIGludGVycHJldGVyL0pT U3RhY2suY3BwOgorICAgICAgICAoSlNDOjpKU1N0YWNrOjp+SlNTdGFjayk6IERvbid0IGRlY29t bWl0IG1lbW9yeSBpZiBub3RoaW5nIGhhcyBiZWVuIGNvbW1pdHRlZC4KKwogMjAxMy0xMi0wMyAg SnVsaWVuIEJyaWFuY2VhdSAgPGpicmlhbmNlQGNpc2NvLmNvbT4KIAogICAgICAgICBNZXJnZSBt aXBzIGFuZCBhcm0vc2g0IHBhdGhzIGluIG5hdGl2ZUZvckdlbmVyYXRvciBhbmQgcHJpdmF0ZUNv bXBpbGVDVElOYXRpdmVDYWxsIGZ1bmN0aW9ucy4KSW5kZXg6IFNvdXJjZS9KYXZhU2NyaXB0Q29y ZS9pbnRlcnByZXRlci9KU1N0YWNrLmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvSmF2YVNjcmlw dENvcmUvaW50ZXJwcmV0ZXIvSlNTdGFjay5jcHAJKHJldmlzaW9uIDE2MDAwMikKKysrIFNvdXJj ZS9KYXZhU2NyaXB0Q29yZS9pbnRlcnByZXRlci9KU1N0YWNrLmNwcAkod29ya2luZyBjb3B5KQpA QCAtNjMsOCArNjMsMTAgQEAgSlNTdGFjazo6SlNTdGFjayhWTSYgdm0sIHNpemVfdCBjYXBhY2l0 eQogSlNTdGFjazo6fkpTU3RhY2soKQogewogICAgIHZvaWQqIGhpZ2hBZGRyZXNzID0gcmVpbnRl cnByZXRfY2FzdDx2b2lkKj4oc3RhdGljX2Nhc3Q8Y2hhcio+KG1fcmVzZXJ2YXRpb24uYmFzZSgp KSArIG1fcmVzZXJ2YXRpb24uc2l6ZSgpKTsKLSAgICBtX3Jlc2VydmF0aW9uLmRlY29tbWl0KHJl aW50ZXJwcmV0X2Nhc3Q8dm9pZCo+KG1fY29tbWl0RW5kKSwgcmVpbnRlcnByZXRfY2FzdDxpbnRw dHJfdD4oaGlnaEFkZHJlc3MpIC0gcmVpbnRlcnByZXRfY2FzdDxpbnRwdHJfdD4obV9jb21taXRF bmQpKTsKLSAgICBhZGRUb0NvbW1pdHRlZEJ5dGVDb3VudCgtKHJlaW50ZXJwcmV0X2Nhc3Q8aW50 cHRyX3Q+KGhpZ2hBZGRyZXNzKSAtIHJlaW50ZXJwcmV0X2Nhc3Q8aW50cHRyX3Q+KG1fY29tbWl0 RW5kKSkpOworICAgIGlmIChoaWdoQWRkcmVzcyA+IG1fY29tbWl0RW5kKSB7CisgICAgICAgIG1f cmVzZXJ2YXRpb24uZGVjb21taXQocmVpbnRlcnByZXRfY2FzdDx2b2lkKj4obV9jb21taXRFbmQp LCByZWludGVycHJldF9jYXN0PGludHB0cl90PihoaWdoQWRkcmVzcykgLSByZWludGVycHJldF9j YXN0PGludHB0cl90PihtX2NvbW1pdEVuZCkpOworICAgICAgICBhZGRUb0NvbW1pdHRlZEJ5dGVD b3VudCgtKHJlaW50ZXJwcmV0X2Nhc3Q8aW50cHRyX3Q+KGhpZ2hBZGRyZXNzKSAtIHJlaW50ZXJw cmV0X2Nhc3Q8aW50cHRyX3Q+KG1fY29tbWl0RW5kKSkpOworICAgIH0KICAgICBtX3Jlc2VydmF0 aW9uLmRlYWxsb2NhdGUoKTsKIH0KIAo= 218367 2013-12-03 17:40:14 -0800 2013-12-03 18:01:50 -0800 Fixing OSAllocatorWin instead. bug-121972.patch text/plain 3753 mark.lam SW5kZXg6IFNvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291 cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwkocmV2aXNpb24gMTYwMDYyKQorKysgU291cmNl L0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE1IEBA CisyMDEzLTEyLTAzICBNYXJrIExhbSAgPG1hcmsubGFtQGFwcGxlLmNvbT4KKworICAgICAgICB0 ZXN0YXBpIHRlc3QgY3Jhc2hlcyBvbiBXaW5kb3dzIGluIFdURjo6VmVjdG9yPHdjaGFyX3QsNjQs V1RGOjpVbnNhZmVWZWN0b3JPdmVyZmxvdz46OnNpemUoKS4KKyAgICAgICAgaHR0cHM6Ly9idWdz LndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTEyMTk3Mi4KKworICAgICAgICBSZXZpZXdlZCBi eSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICAqIGludGVycHJldGVyL0pTU3RhY2suY3BwOgor ICAgICAgICAoSlNDOjpKU1N0YWNrOjp+SlNTdGFjayk6CisgICAgICAgIC0gUmV2ZXJ0aW5nIHRo ZSBjaGFuZ2UgZnJvbSByMTYwMDA0IHNpbmNlIGl0J3MgYmV0dGVyIHRvIGZpeCBPU0FsbG9jYXRv cldpbgorICAgICAgICAgIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCBPU0FsbG9jYXRvclBvc2l4Lgor CiAyMDEzLTEyLTAzICBNYXJrIExhbSAgPG1hcmsubGFtQGFwcGxlLmNvbT4KIAogICAgICAgICBG aXggTExJTlRfQ19MT09QIGJ1aWxkIGZvciBXaW42NC4KSW5kZXg6IFNvdXJjZS9KYXZhU2NyaXB0 Q29yZS9pbnRlcnByZXRlci9KU1N0YWNrLmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvSmF2YVNj cmlwdENvcmUvaW50ZXJwcmV0ZXIvSlNTdGFjay5jcHAJKHJldmlzaW9uIDE2MDA2MSkKKysrIFNv dXJjZS9KYXZhU2NyaXB0Q29yZS9pbnRlcnByZXRlci9KU1N0YWNrLmNwcAkod29ya2luZyBjb3B5 KQpAQCAtNjMsMTAgKzYzLDggQEAgSlNTdGFjazo6SlNTdGFjayhWTSYgdm0sIHNpemVfdCBjYXBh Y2l0eQogSlNTdGFjazo6fkpTU3RhY2soKQogewogICAgIHZvaWQqIGhpZ2hBZGRyZXNzID0gcmVp bnRlcnByZXRfY2FzdDx2b2lkKj4oc3RhdGljX2Nhc3Q8Y2hhcio+KG1fcmVzZXJ2YXRpb24uYmFz ZSgpKSArIG1fcmVzZXJ2YXRpb24uc2l6ZSgpKTsKLSAgICBpZiAoaGlnaEFkZHJlc3MgPiBtX2Nv bW1pdEVuZCkgewotICAgICAgICBtX3Jlc2VydmF0aW9uLmRlY29tbWl0KHJlaW50ZXJwcmV0X2Nh c3Q8dm9pZCo+KG1fY29tbWl0RW5kKSwgcmVpbnRlcnByZXRfY2FzdDxpbnRwdHJfdD4oaGlnaEFk ZHJlc3MpIC0gcmVpbnRlcnByZXRfY2FzdDxpbnRwdHJfdD4obV9jb21taXRFbmQpKTsKLSAgICAg ICAgYWRkVG9Db21taXR0ZWRCeXRlQ291bnQoLShyZWludGVycHJldF9jYXN0PGludHB0cl90Piho aWdoQWRkcmVzcykgLSByZWludGVycHJldF9jYXN0PGludHB0cl90PihtX2NvbW1pdEVuZCkpKTsK LSAgICB9CisgICAgbV9yZXNlcnZhdGlvbi5kZWNvbW1pdChyZWludGVycHJldF9jYXN0PHZvaWQq PihtX2NvbW1pdEVuZCksIHJlaW50ZXJwcmV0X2Nhc3Q8aW50cHRyX3Q+KGhpZ2hBZGRyZXNzKSAt IHJlaW50ZXJwcmV0X2Nhc3Q8aW50cHRyX3Q+KG1fY29tbWl0RW5kKSk7CisgICAgYWRkVG9Db21t aXR0ZWRCeXRlQ291bnQoLShyZWludGVycHJldF9jYXN0PGludHB0cl90PihoaWdoQWRkcmVzcykg LSByZWludGVycHJldF9jYXN0PGludHB0cl90PihtX2NvbW1pdEVuZCkpKTsKICAgICBtX3Jlc2Vy dmF0aW9uLmRlYWxsb2NhdGUoKTsKIH0KIApJbmRleDogU291cmNlL1dURi9DaGFuZ2VMb2cKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQotLS0gU291cmNlL1dURi9DaGFuZ2VMb2cJKHJldmlzaW9uIDE2MDA2MikKKysrIFNv dXJjZS9XVEYvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMTkgQEAKKzIwMTMt MTItMDMgIE1hcmsgTGFtICA8bWFyay5sYW1AYXBwbGUuY29tPgorCisgICAgICAgIHRlc3RhcGkg dGVzdCBjcmFzaGVzIG9uIFdpbmRvd3MgaW4gV1RGOjpWZWN0b3I8d2NoYXJfdCw2NCxXVEY6OlVu c2FmZVZlY3Rvck92ZXJmbG93Pjo6c2l6ZSgpLgorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0 Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTIxOTcyLgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9E WSAoT09QUyEpLgorCisgICAgICAgICogd3RmL09TQWxsb2NhdG9yV2luLmNwcDoKKyAgICAgICAg KFdURjo6T1NBbGxvY2F0b3I6OmRlY29tbWl0KToKKyAgICAgICAgKFdURjo6T1NBbGxvY2F0b3I6 OnJlbGVhc2VEZWNvbW1pdHRlZCk6CisgICAgICAgIC0gQWRkZWQgYSBjaGVjayB0byBlbnN1cmUg dGhhdCB0aGUgYnl0ZXMgdG8gZGVjb21taXQgLyByZWxlYXNlIGlzIG5vdCAwLgorICAgICAgICAg IE9uIFdpbmRvd3MsIGEgMCBsZW5ndGggcGFzc2VkIHRvIFZpcnR1YWxGcmVlKCkgaGFzIGEgc3Bl Y2lhbCBtZWFuaW5nLAorICAgICAgICAgIGFuZCBpdCdzIG5vdCAiZGVjb21taXQgLyByZWxlYXNl IG5vdGhpbmciIGFzIG9uZSB3b3VsZCBleHBlY3QuIEFkZGluZworICAgICAgICAgIHRoaXMgY2hl Y2sgbWFrZXMgT1NBbGxvY2F0b3JXaW4gY29uc2lzdGVudCB3aXRoIE9TQWxsb2NhdG9yUG9zaXgg Zm9yCisgICAgICAgICAgdGhlc2UgMiBmdW5jdGlvbnMuCisKIDIwMTMtMTItMDIgIE1hcmsgTGFt ICA8bWFyay5sYW1AYXBwbGUuY29tPgogCiAgICAgICAgIEJ1aWxkIGZhaWx1cmUgd2hlbiBkaXNh YmxpbmcgSklULCBZQVJSX0pJVCwgYW5kIEFTU0VNQkxFUi4KSW5kZXg6IFNvdXJjZS9XVEYvd3Rm L09TQWxsb2NhdG9yV2luLmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV1RGL3d0Zi9PU0FsbG9j YXRvcldpbi5jcHAJKHJldmlzaW9uIDE2MDA2MSkKKysrIFNvdXJjZS9XVEYvd3RmL09TQWxsb2Nh dG9yV2luLmNwcAkod29ya2luZyBjb3B5KQpAQCAtNjUsNiArNjUsOCBAQCB2b2lkIE9TQWxsb2Nh dG9yOjpjb21taXQodm9pZCogYWRkcmVzcywgCiAKIHZvaWQgT1NBbGxvY2F0b3I6OmRlY29tbWl0 KHZvaWQqIGFkZHJlc3MsIHNpemVfdCBieXRlcykKIHsKKyAgICBpZiAoIWJ5dGVzKQorICAgICAg ICByZXR1cm47IC8vIE5vdGhpbmcgdG8gZG8uCiAgICAgYm9vbCByZXN1bHQgPSBWaXJ0dWFsRnJl ZShhZGRyZXNzLCBieXRlcywgTUVNX0RFQ09NTUlUKTsKICAgICBpZiAoIXJlc3VsdCkKICAgICAg ICAgQ1JBU0goKTsKQEAgLTcyLDYgKzc0LDggQEAgdm9pZCBPU0FsbG9jYXRvcjo6ZGVjb21taXQo dm9pZCogYWRkcmVzcwogCiB2b2lkIE9TQWxsb2NhdG9yOjpyZWxlYXNlRGVjb21taXR0ZWQodm9p ZCogYWRkcmVzcywgc2l6ZV90IGJ5dGVzKQogeworICAgIGlmICghYnl0ZXMpCisgICAgICAgIHJl dHVybjsgLy8gTm90aGluZyB0byBkby4KICAgICAvLyBBY2NvcmRpbmcgdG8gaHR0cDovL21zZG4u bWljcm9zb2Z0LmNvbS9lbi11cy9saWJyYXJ5L2FhMzY2ODkyKFZTLjg1KS5hc3B4LAogICAgIC8v IGR3U2l6ZSBtdXN0IGJlIDAgaWYgZHdGcmVlVHlwZSBpcyBNRU1fUkVMRUFTRS4KICAgICBib29s IHJlc3VsdCA9IFZpcnR1YWxGcmVlKGFkZHJlc3MsIDAsIE1FTV9SRUxFQVNFKTsK