153422 2016-01-25 05:19:00 -0800 [B3] REGRESSION(r195395): testComplex(64, 128) asserts on Linux with GCC 2016-01-28 21:37:54 -0800 1 1 1 Unclassified WebKit JavaScriptCore Other Unspecified Unspecified RESOLVED FIXED P2 Normal --- 150279 151624 152248 153200 1 ossy ysuzuki benjamin commit-queue fpizlo keith_miller mark.lam msaboff ossy saam ysuzuki oldest_to_newest 1158288 0 ossy 2016-01-25 05:19:00 -0800 testComplex(64, 128) asserts at least on X86_64 Linux. I don't know if it is a regression or not and if it fails on Mac or not. 1158289 1 ossy 2016-01-25 05:21:37 -0800 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffae1ff700 (LWP 13525)] 0x00007ffff6efbb99 in WTFCrash () at ../../Source/WTF/wtf/Assertions.cpp:321 321 *(int *)(uintptr_t)0xbbadbeef = 0; (gdb) bt #0 0x00007ffff6efbb99 in WTFCrash () at ../../Source/WTF/wtf/Assertions.cpp:321 #1 0x00000000006316a8 in WTF::CrashOnOverflow::crash () at ../../Source/WTF/wtf/CheckedArithmetic.h:85 #2 0x000000000063169f in WTF::CrashOnOverflow::overflowed () at ../../Source/WTF/wtf/CheckedArithmetic.h:78 #3 0x00007ffff645266d in WTF::Vector<std::unique_ptr<JSC::B3::Value, std::default_delete<JSC::B3::Value> >, 0ul, WTF::CrashOnOverflow, 16ul>::at (this=0x7fffaeb908a0, i=164) at ../../Source/WTF/wtf/Vector.h:665 #4 0x00007ffff6451451 in WTF::Vector<std::unique_ptr<JSC::B3::Value, std::default_delete<JSC::B3::Value> >, 0ul, WTF::CrashOnOverflow, 16ul>::operator[] (this=0x7fffaeb908a0, i=164) at ../../Source/WTF/wtf/Vector.h:680 #5 0x00007ffff645100e in JSC::B3::Procedure::ValuesCollection::at (this=0x7fffae1fe490, index=164) at ../../Source/JavaScriptCore/b3/B3Procedure.h:222 #6 0x00007ffff64516b1 in JSC::B3::IndexSet<JSC::B3::Value>::Iterable<JSC::B3::Procedure::ValuesCollection>::iterator::operator* ( this=0x7fffae1fe3c0) at ../../Source/JavaScriptCore/b3/B3IndexSet.h:96 #7 0x00007ffff644eb07 in JSC::B3::demoteValues (proc=..., values=...) at ../../Source/JavaScriptCore/b3/B3FixSSA.cpp:59 #8 0x00007ffff6438993 in JSC::B3::(anonymous namespace)::DuplicateTails::run (this=0x7fffae1fe770) at ../../Source/JavaScriptCore/b3/B3DuplicateTails.cpp:87 #9 0x00007ffff6438db7 in JSC::B3::duplicateTails (proc=...) at ../../Source/JavaScriptCore/b3/B3DuplicateTails.cpp:142 #10 0x00007ffff646221a in JSC::B3::generateToAir (procedure=..., optLevel=1) at ../../Source/JavaScriptCore/b3/B3Generate.cpp:84 #11 0x00007ffff64620c6 in JSC::B3::prepareForGeneration (procedure=..., optLevel=1) at ../../Source/JavaScriptCore/b3/B3Generate.cpp:56 #12 0x00007ffff643053d in JSC::B3::Compilation::Compilation (this=0x7fffaeb99b40, vm=..., proc=..., optLevel=1) at ../../Source/JavaScriptCore/b3/B3Compilation.cpp:45 #13 0x0000000000636e9a in std::make_unique<JSC::B3::Compilation, JSC::VM&, JSC::B3::Procedure&, unsigned int&> () at ../../Source/WTF/wtf/StdLibExtras.h:311 #14 0x0000000000454162 in (anonymous namespace)::compile (procedure=..., optLevel=1) at ../../Source/JavaScriptCore/b3/testb3.cpp:89 #15 0x000000000048b44c in (anonymous namespace)::testComplex (numVars=64, numConstructs=128) at ../../Source/JavaScriptCore/b3/testb3.cpp:5945 #16 0x00000000004bca19 in (anonymous namespace)::<lambda()>::operator()(void) const (__closure=0x7fffaef81d4c) at ../../Source/JavaScriptCore/b3/testb3.cpp:10337 #17 0x000000000062cb56 in WTF::SharedTaskFunctor<void(), (anonymous namespace)::run(char const*)::<lambda()> >::run(void) ( this=0x7fffaef81d40) at ../../Source/WTF/wtf/SharedTask.h:90 #18 0x00000000004c475e in (anonymous namespace)::<lambda()>::operator()(void) const (__closure=0x7fffae1fee90) at ../../Source/JavaScriptCore/b3/testb3.cpp:10939 #19 0x00000000005b7190 in std::_Function_handler<void(), (anonymous namespace)::run(char const*)::<lambda()> >::_M_invoke(const std::_Any_data &) (__functor=...) at /usr/include/c++/5/functional:1871 #20 0x00007ffff69480a4 in std::function<void ()>::operator()() const (this=0x7fffae1fee90) at /usr/include/c++/5/functional:2271 #21 0x00007ffff6f18b43 in WTF::threadEntryPoint (contextData=0x7fffae7d0050) at ../../Source/WTF/wtf/Threading.cpp:58 #22 0x00007ffff6f5016a in WTF::wtfThreadEntryPoint (param=0x7fffae3c6db0) at ../../Source/WTF/wtf/ThreadingPthreads.cpp:164 #23 0x00007ffff347e6aa in start_thread (arg=0x7fffae1ff700) at pthread_create.c:333 #24 0x00007ffff43d0eed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 1158302 2 ossy 2016-01-25 07:19:53 -0800 I bisected this bug, it is a regression caused by https://trac.webkit.org/changeset/195395 . - on r195394 all testb3 tests passed (debug and release too) - on r195395 testComplex(64, 128) asserts in debug mode and testDiamond() crashes in release mode. ( I disabled parallel test running. ) 1158313 3 ossy 2016-01-25 07:38:33 -0800 Could you possibly check if this regression is valid on Mac too? 1158345 4 fpizlo 2016-01-25 09:17:51 -0800 Seems bad, I'll look today. 1158508 5 fpizlo 2016-01-25 14:32:56 -0800 I investigated this on r195553. I cannot reproduce any version of this crash on Mac. On trunk on Mac, I see: - testb3 passes in debug without asserting or crashing, both in parallel and sequential mode, and both with JSC_validateGraphAtEachPhase=true and =false (note that we usually run these tests with that flag set to true). - testb3 passes in release without asserting or crashing, both in parallel and sequential mode, both with and without validateGraphBlahBlah. Assigning back to Ossy sine this is probably a platform-specific issue. 1158785 6 ossy 2016-01-26 03:55:32 -0800 (In reply to comment #5) > I investigated this on r195553. I cannot reproduce any version of this > crash on Mac. On trunk on Mac, I see: > > - testb3 passes in debug without asserting or crashing, both in parallel and > sequential mode, and both with JSC_validateGraphAtEachPhase=true and =false > (note that we usually run these tests with that flag set to true). > > - testb3 passes in release without asserting or crashing, both in parallel > and sequential mode, both with and without validateGraphBlahBlah. Thanks for checking it. It seems it is a Linux specific issue. Unfortunately there are zillion JSC stress tests crashes too. > Assigning back to Ossy sine this is probably a platform-specific issue. Set to unassigned, probably I won't have time to investigate it in the near future. 1158788 7 ossy 2016-01-26 04:28:35 -0800 Additionally it caused 3624 JSC test crashes (from 30762 tests) 1159781 8 ossy 2016-01-28 10:52:32 -0800 I found an interesting thing here. This bug isn't valid if I build JSC with Clang (3.6). But crash happens with GCC 4.9 and 5.2 too. It might be a compiler bug or maybe the new code introduced in r195395 relies some non standard Clang behaviour. By the way, it's not "good" that we try to get the 164th element from a null-sized vector. The question is why is it null-sized. 1159787 9 fpizlo 2016-01-28 10:57:07 -0800 (In reply to comment #8) > I found an interesting thing here. This bug isn't valid if I build > JSC with Clang (3.6). But crash happens with GCC 4.9 and 5.2 too. > > It might be a compiler bug or maybe the new code introduced > in r195395 relies some non standard Clang behaviour. > > By the way, it's not "good" that we try to get the 164th element > from a null-sized vector. The question is why is it null-sized. Fascinating. We'll need to get a bot to run testb3 and testair so that we can catch these things. It would be great to have such a bot on Linux, compiling with GCC. I'm really curious what causes this bug. 1159886 10 ysuzuki 2016-01-28 14:45:27 -0800 (In reply to comment #9) > (In reply to comment #8) > > I found an interesting thing here. This bug isn't valid if I build > > JSC with Clang (3.6). But crash happens with GCC 4.9 and 5.2 too. > > > > It might be a compiler bug or maybe the new code introduced > > in r195395 relies some non standard Clang behaviour. > > > > By the way, it's not "good" that we try to get the 164th element > > from a null-sized vector. The question is why is it null-sized. > > Fascinating. We'll need to get a bot to run testb3 and testair so that we > can catch these things. It would be great to have such a bot on Linux, > compiling with GCC. > > I'm really curious what causes this bug. I've found the issue. Seeing B3FixSSA.cpp's `for (Value* value : values.values(proc.values())) {` proc.values() returns ValuesCollection (Not reference!). But values.values takes const ValueCollection&. And later it produces IndexSet<Value>::Iterable<Procedure::ValuesCollection>, it holds const ValueCollection& as its member. But IndexSet<Value>::Iterable<Procedure::ValuesCollection> is just an instance. So after creating this, the lifetime of the ValueCollection const reference finished! Easy example, class A { A(const std::string& value) : m_string(value) { } const std::string& m_string; }; A a(std::string("Value")); // Here, the lifetime of the const reference to the std::string is ended. So I think the behavior of the GCC is correct. 1159903 11 270152 ysuzuki 2016-01-28 15:04:40 -0800 Created attachment 270152 Patch 1159906 12 270152 fpizlo 2016-01-28 15:12:27 -0800 Comment on attachment 270152 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=270152&action=review > Source/JavaScriptCore/b3/B3IndexSet.h:137 > + // Procedure::ValuesCollection valuesCollection = procedure.values(); > + // indexSet.values(valuesCollection); > + // > + // Don't call it like indexSet.values(proceduce.values()). collection will be touched by const reference. > + // Since procedure.values() creates ValuesCollection (not reference), this lifetime will be finished immediately > + // after Iterable<ValuesCollection> is constructed. I really don't like this idiom. Can we change it so that procedure.values() returns a long-lived value? For example it can have a ValuesCollection instance sitting around inside Procedure. 1159908 13 270152 ysuzuki 2016-01-28 15:16:20 -0800 Comment on attachment 270152 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=270152&action=review >> Source/JavaScriptCore/b3/B3IndexSet.h:137 >> + // after Iterable<ValuesCollection> is constructed. > > I really don't like this idiom. Can we change it so that procedure.values() returns a long-lived value? For example it can have a ValuesCollection instance sitting around inside Procedure. OK, I'll change it soon :) Thanks! 1159917 14 270155 ysuzuki 2016-01-28 15:31:08 -0800 Created attachment 270155 Patch 1159920 15 ysuzuki 2016-01-28 15:34:23 -0800 After this fix, testb3 and testair pass on GTK environment. 1160014 16 ysuzuki 2016-01-28 21:37:20 -0800 Thanks for reviewing! 1160015 17 ysuzuki 2016-01-28 21:37:54 -0800 Committed r195800: <http://trac.webkit.org/changeset/195800> 270152 2016-01-28 15:04:40 -0800 2016-01-28 15:31:03 -0800 Patch bug-153422-20160129080414.patch text/plain 2998 ysuzuki U3VidmVyc2lvbiBSZXZpc2lvbjogMTk1NzgxCmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlw dENvcmUvQ2hhbmdlTG9nIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwppbmRleCA5 MzRjNDJmZDk3NzFjNWE0YjM5NTg0MDNlYzMzY2Q5NWY5Nzc1NjIyLi5hMzNlYjM4NzE5ZWEzNTZh MTRkMmM2NDEyMWM4OGRjMGZiNDJhYzdiIDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNjcmlwdENv cmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKQEAgLTEs MyArMSwyMSBAQAorMjAxNi0wMS0yOCAgWXVzdWtlIFN1enVraSAgPHV0YXRhbmUudGVhQGdtYWls LmNvbT4KKworICAgICAgICBbQjNdIFJFR1JFU1NJT04ocjE5NTM5NSk6IHRlc3RDb21wbGV4KDY0 LCAxMjgpIGFzc2VydHMgb24gTGludXggd2l0aCBHQ0MKKyAgICAgICAgaHR0cHM6Ly9idWdzLndl YmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTE1MzQyMgorCisgICAgICAgIFJldmlld2VkIGJ5IE5P Qk9EWSAoT09QUyEpLgorCisgICAgICAgIHByb2MudmFsdWVzKCkgcmV0dXJucyBWYWx1ZXNDb2xs ZWN0aW9uIChOb3QgcmVmZXJlbmNlISkuCisgICAgICAgIHZhbHVlcy52YWx1ZXMgdGFrZXMgY29u c3QgVmFsdWVDb2xsZWN0aW9uJi4KKyAgICAgICAgQW5kIGxhdGVyIGl0IHByb2R1Y2VzIEluZGV4 U2V0PFZhbHVlPjo6SXRlcmFibGU8UHJvY2VkdXJlOjpWYWx1ZXNDb2xsZWN0aW9uPiwKKyAgICAg ICAgaXQgaG9sZHMgY29uc3QgVmFsdWVDb2xsZWN0aW9uJiBhcyBpdHMgbWVtYmVyLgorICAgICAg ICBCdXQgSW5kZXhTZXQ8VmFsdWU+OjpJdGVyYWJsZTxQcm9jZWR1cmU6OlZhbHVlc0NvbGxlY3Rp b24+IGlzIGp1c3QgYW4gaW5zdGFuY2UuCisgICAgICAgIFNvIGFmdGVyIGNyZWF0aW5nIHRoaXMs IHRoZSBsaWZldGltZSBvZiB0aGUgVmFsdWVDb2xsZWN0aW9uIGNvbnN0IHJlZmVyZW5jZSBmaW5p c2hlZC4KKworICAgICAgICAqIGIzL0IzRml4U1NBLmNwcDoKKyAgICAgICAgKEpTQzo6QjM6OmRl bW90ZVZhbHVlcyk6CisgICAgICAgICogYjMvQjNJbmRleFNldC5oOgorCiAyMDE2LTAxLTI4ICBG aWxpcCBQaXpsbyAgPGZwaXpsb0BhcHBsZS5jb20+CiAKICAgICAgICAgTG93ZXJUb0Fpcjo6cHJl ZmVyUmlnaHRGb3JSZXN1bHQoKSBzaG91bGQgcmVzb2x2ZSB1c2UgY291bnQgdGllcyBieSBzZWxl Y3RpbmcgdGhlIGNoaWxkIHRoYXQgaXMgY2xvc2VzdCBpbiBhbiBpZG9tIHdhbGsKZGlmZiAtLWdp dCBhL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9iMy9CM0ZpeFNTQS5jcHAgYi9Tb3VyY2UvSmF2YVNj cmlwdENvcmUvYjMvQjNGaXhTU0EuY3BwCmluZGV4IDhjNzQyMTlhY2VhYTI4NzU1MDcxMjUxYTUy ZmVmOGRjN2Q1NTQ0MjYuLmM5YWMyOTE2NjRhYzJiMzA4N2E0NTIxZTMyM2I0Nzg0OWMyODc1MWQg MTAwNjQ0Ci0tLSBhL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9iMy9CM0ZpeFNTQS5jcHAKKysrIGIv U291cmNlL0phdmFTY3JpcHRDb3JlL2IzL0IzRml4U1NBLmNwcApAQCAtNTcsNyArNTcsOCBAQCB2 b2lkIGRlbW90ZVZhbHVlcyhQcm9jZWR1cmUmIHByb2MsIGNvbnN0IEluZGV4U2V0PFZhbHVlPiYg dmFsdWVzKQogCiAgICAgLy8gQ3JlYXRlIHN0YWNrIHNsb3RzLgogICAgIEluc2VydGlvblNldCBp bnNlcnRpb25TZXQocHJvYyk7Ci0gICAgZm9yIChWYWx1ZSogdmFsdWUgOiB2YWx1ZXMudmFsdWVz KHByb2MudmFsdWVzKCkpKSB7CisgICAgUHJvY2VkdXJlOjpWYWx1ZXNDb2xsZWN0aW9uIHZhbHVl c0NvbGxlY3Rpb24gPSBwcm9jLnZhbHVlcygpOworICAgIGZvciAoVmFsdWUqIHZhbHVlIDogdmFs dWVzLnZhbHVlcyh2YWx1ZXNDb2xsZWN0aW9uKSkgewogICAgICAgICBTbG90QmFzZVZhbHVlKiBz dGFjayA9IGluc2VydGlvblNldC5pbnNlcnQ8U2xvdEJhc2VWYWx1ZT4oCiAgICAgICAgICAgICAw LCB2YWx1ZS0+b3JpZ2luKCksIHByb2MuYWRkQW5vbnltb3VzU3RhY2tTbG90KHZhbHVlLT50eXBl KCkpKTsKICAgICAgICAgbWFwLmFkZCh2YWx1ZSwgc3RhY2spOwpkaWZmIC0tZ2l0IGEvU291cmNl L0phdmFTY3JpcHRDb3JlL2IzL0IzSW5kZXhTZXQuaCBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9i My9CM0luZGV4U2V0LmgKaW5kZXggZTVjNmRlZGRiNGRiNjZjYzM2ZTI0MzYxNWRiYTdhNDBmNmU0 ODFhMy4uMjY1YzRhNjhhMWU3OGJhNTIzMmRjOTM5OWVjMWRjNzQ4MzkxMTg5ZCAxMDA2NDQKLS0t IGEvU291cmNlL0phdmFTY3JpcHRDb3JlL2IzL0IzSW5kZXhTZXQuaAorKysgYi9Tb3VyY2UvSmF2 YVNjcmlwdENvcmUvYjMvQjNJbmRleFNldC5oCkBAIC0xMjksNyArMTI5LDEyIEBAIGNsYXNzIElu ZGV4U2V0IHsKICAgICAvLyBpbmRleFNldC52YWx1ZXMocHJvY2VkdXJlKTsKICAgICAvLwogICAg IC8vIEZvciB2YWx1ZXMsIHlvdSBkbzoKLSAgICAvLyBpbmRleFNldC52YWx1ZXMocHJvY2VkdXJl LnZhbHVlcygpKTsKKyAgICAvLyBQcm9jZWR1cmU6OlZhbHVlc0NvbGxlY3Rpb24gdmFsdWVzQ29s bGVjdGlvbiA9IHByb2NlZHVyZS52YWx1ZXMoKTsKKyAgICAvLyBpbmRleFNldC52YWx1ZXModmFs dWVzQ29sbGVjdGlvbik7CisgICAgLy8KKyAgICAvLyBEb24ndCBjYWxsIGl0IGxpa2UgaW5kZXhT ZXQudmFsdWVzKHByb2NlZHVjZS52YWx1ZXMoKSkuIGNvbGxlY3Rpb24gd2lsbCBiZSB0b3VjaGVk IGJ5IGNvbnN0IHJlZmVyZW5jZS4KKyAgICAvLyBTaW5jZSBwcm9jZWR1cmUudmFsdWVzKCkgY3Jl YXRlcyBWYWx1ZXNDb2xsZWN0aW9uIChub3QgcmVmZXJlbmNlKSwgdGhpcyBsaWZldGltZSB3aWxs IGJlIGZpbmlzaGVkIGltbWVkaWF0ZWx5CisgICAgLy8gYWZ0ZXIgSXRlcmFibGU8VmFsdWVzQ29s bGVjdGlvbj4gaXMgY29uc3RydWN0ZWQuCiAgICAgdGVtcGxhdGU8dHlwZW5hbWUgQ29sbGVjdGlv blR5cGU+CiAgICAgSXRlcmFibGU8Q29sbGVjdGlvblR5cGU+IHZhbHVlcyhjb25zdCBDb2xsZWN0 aW9uVHlwZSYgY29sbGVjdGlvbikgY29uc3QKICAgICB7Cg== 270155 2016-01-28 15:31:08 -0800 2016-01-28 21:23:03 -0800 Patch bug-153422-20160129083042.patch text/plain 2718 ysuzuki U3VidmVyc2lvbiBSZXZpc2lvbjogMTk1Nzg4CmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlw dENvcmUvQ2hhbmdlTG9nIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwppbmRleCA5 MGJjNzA4MTI2ZTg3YThhM2NjOWJhY2YzMWQ4YWVhNjEwNWUzOWMyLi5hNjIyZTIxODQ1YTIyNzZi ODcwZWQzNDFmYzZjOGU4OWRjY2FlNTg1IDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNjcmlwdENv cmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKQEAgLTEs NSArMSwyNyBAQAogMjAxNi0wMS0yOCAgWXVzdWtlIFN1enVraSAgPHV0YXRhbmUudGVhQGdtYWls LmNvbT4KIAorICAgICAgICBbQjNdIFJFR1JFU1NJT04ocjE5NTM5NSk6IHRlc3RDb21wbGV4KDY0 LCAxMjgpIGFzc2VydHMgb24gTGludXggd2l0aCBHQ0MKKyAgICAgICAgaHR0cHM6Ly9idWdzLndl YmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTE1MzQyMgorCisgICAgICAgIFJldmlld2VkIGJ5IE5P Qk9EWSAoT09QUyEpLgorCisgICAgICAgIFByZXZpb3VzbHkgcHJvYy52YWx1ZXMoKSByZXR1cm5z IFZhbHVlc0NvbGxlY3Rpb24gKE5vdCByZWZlcmVuY2UhKS4KKyAgICAgICAgdmFsdWVzLnZhbHVl cyB0YWtlcyBjb25zdCBWYWx1ZUNvbGxlY3Rpb24mLgorICAgICAgICBBbmQgbGF0ZXIgaXQgcHJv ZHVjZXMgSW5kZXhTZXQ8VmFsdWU+OjpJdGVyYWJsZTxQcm9jZWR1cmU6OlZhbHVlc0NvbGxlY3Rp b24+LAorICAgICAgICBpdCBob2xkcyBjb25zdCBWYWx1ZUNvbGxlY3Rpb24mIGFzIGl0cyBtZW1i ZXIuCisgICAgICAgIEJ1dCBJbmRleFNldDxWYWx1ZT46Okl0ZXJhYmxlPFByb2NlZHVyZTo6VmFs dWVzQ29sbGVjdGlvbj4gaXMganVzdCBhbiBpbnN0YW5jZS4KKyAgICAgICAgU28gYWZ0ZXIgY3Jl YXRpbmcgdGhpcywgdGhlIGxpZmV0aW1lIG9mIHRoZSBWYWx1ZUNvbGxlY3Rpb24gY29uc3QgcmVm ZXJlbmNlIGZpbmlzaGVkLgorCisgICAgICAgIFRvIGZpeCB0aGF0LCB3ZSBob2xkIFZhbHVlc0Nv bGxlY3Rpb24gYXMgYSBtZW1iZXIgb2YgUHJvY2VkdXJlLgorICAgICAgICBBbmQgY2hhbmdlIHRo ZSBzaWduYXR1cmUgdG8gY29uc3QgVmFsdWVzQ29sbGVjdGlvbiYgUHJvY2VkdXJlOjp2YWx1ZXMo KS4KKworICAgICAgICAqIGIzL0IzUHJvY2VkdXJlLmNwcDoKKyAgICAgICAgKEpTQzo6QjM6OlBy b2NlZHVyZTo6UHJvY2VkdXJlKToKKyAgICAgICAgKiBiMy9CM1Byb2NlZHVyZS5oOgorICAgICAg ICAoSlNDOjpCMzo6UHJvY2VkdXJlOjp2YWx1ZXMpOgorCisyMDE2LTAxLTI4ICBZdXN1a2UgU3V6 dWtpICA8dXRhdGFuZS50ZWFAZ21haWwuY29tPgorCiAgICAgICAgIEZpeCB0aGUgQjMgYnVpbGQg d2l0aCBHQ0MgNC45LjMKICAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcu Y2dpP2lkPTE1MTYyNAogCmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvYjMvQjNQ cm9jZWR1cmUuY3BwIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL2IzL0IzUHJvY2VkdXJlLmNwcApp bmRleCAzNTAyNDg2Mzk2Yzg3ZjVjMmMxNTkxZmM5ZTI0NTJmMDk5OTYyYmIyLi43ZGViYWVkNzQ3 ODYyYjJlNDVkZTIxMGYyZjRkYWRlNzc1NWU1ODNlIDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNj cmlwdENvcmUvYjMvQjNQcm9jZWR1cmUuY3BwCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9i My9CM1Byb2NlZHVyZS5jcHAKQEAgLTQ2LDYgKzQ2LDcgQEAKICAgICAsIG1fbGFzdFBoYXNlTmFt ZSgiaW5pdGlhbCIpCiAgICAgLCBtX2J5cHJvZHVjdHMoc3RkOjptYWtlX3VuaXF1ZTxPcGFxdWVC eXByb2R1Y3RzPigpKQogICAgICwgbV9jb2RlKG5ldyBBaXI6OkNvZGUoKnRoaXMpKQorICAgICwg bV92YWx1ZXNDb2xsZWN0aW9uKCp0aGlzKQogewogfQogCmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2 YVNjcmlwdENvcmUvYjMvQjNQcm9jZWR1cmUuaCBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9iMy9C M1Byb2NlZHVyZS5oCmluZGV4IGM3NmU3ZjFiOWJkZTZlNjM2N2JiM2RmOGQwZGQxODkyODU3NmI4 YjEuLjI1NTczMDI1ZjNhZjYyMWZlYWQ3NGQxN2IyMjFjZGJmOWYxNmZiYmIgMTAwNjQ0Ci0tLSBh L1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9iMy9CM1Byb2NlZHVyZS5oCisrKyBiL1NvdXJjZS9KYXZh U2NyaXB0Q29yZS9iMy9CM1Byb2NlZHVyZS5oCkBAIC0zMTIsNyArMzEyLDcgQEAgY2xhc3MgUHJv Y2VkdXJlIHsKICAgICAgICAgY29uc3QgUHJvY2VkdXJlJiBtX3Byb2NlZHVyZTsKICAgICB9Owog Ci0gICAgVmFsdWVzQ29sbGVjdGlvbiB2YWx1ZXMoKSBjb25zdCB7IHJldHVybiBWYWx1ZXNDb2xs ZWN0aW9uKCp0aGlzKTsgfQorICAgIGNvbnN0IFZhbHVlc0NvbGxlY3Rpb24mIHZhbHVlcygpIGNv bnN0IHsgcmV0dXJuIG1fdmFsdWVzQ29sbGVjdGlvbjsgfQogCiAgICAgdm9pZCBkZWxldGVWYWx1 ZShWYWx1ZSopOwogCkBAIC0zODIsNiArMzgyLDcgQEAgY2xhc3MgUHJvY2VkdXJlIHsKICAgICBz dGQ6OnVuaXF1ZV9wdHI8QWlyOjpDb2RlPiBtX2NvZGU7CiAgICAgUmVmUHRyPFNoYXJlZFRhc2s8 dm9pZChQcmludFN0cmVhbSYsIE9yaWdpbik+PiBtX29yaWdpblByaW50ZXI7CiAgICAgY29uc3Qg dm9pZCogbV9mcm9udGVuZERhdGE7CisgICAgVmFsdWVzQ29sbGVjdGlvbiBtX3ZhbHVlc0NvbGxl Y3Rpb247CiB9OwogCiB9IH0gLy8gbmFtZXNwYWNlIEpTQzo6QjMK