173407 2017-06-15 02:04:00 -0700 WTF::StringImpl::copyChars segfaults when built with GCC 7 2017-07-11 22:28:33 -0700 1 1 1 Unclassified WebKit Web Template Framework Other Unspecified Linux RESOLVED FIXED P2 Major --- 1 webkit.org ysuzuki annulen benjamin buildbot cdumez cmarcelo commit-queue darin dbates jfbastien kling msaboff ysuzuki oldest_to_newest 1319507 0 webkit.org 2017-06-15 02:04:00 -0700 I haven't tested this with WebKit trunk so far, only with https://github.com/annulen/webkit and WebKit2GTK 2.16.3 - but since the code in trunk looks the same, I'm guessing this applies too. After updating my packages on Archlinux, I noticed a lot of segfaults when navigating to pages, or e.g. when submitting a comment on Reddit. I was able to minimize it to this example which crashes when run in jsc: s = 'xxxxxxxxxxxxxxAxxxxxxxxxxxxxxxxxxxxA–'; s.replace(/A/g, 'b') (note the non-ASCII – at the end) Stack (with the original failure on reddit, with QtWebKit): #0 0x00007fffed413b65 in WTF::StringImpl::copyChars<char16_t>(char16_t*, char16_t const*, unsigned int) (destination=0x7ffefa9e0250 u"&lt;p ", source=0x7fff1baf0256 u"&lt;p class=\"parent\"&gt;&lt;a name=\"dircqkb\"&gt;&lt;/a&gt;&lt;/p&gt;&lt;div class=\"midcol likes\" &gt;&lt;div class=\"arrow upmod login-required access-required\" data-event-action=\"upvote\" role=\"button\""..., numCharacters=20) at /tmp/makepkg/qt5-webkit-ng-debug/src/webkit-qtwebkit-5.212.0-alpha/Source/WTF/wtf/text/StringImpl.h:634 #1 0x00007fffed420926 in JSC::jsSpliceSubstringsWithSeparators (separatorCount=251, separators=<optimized out>, rangeCount=<optimized out>, substringRanges=<optimized out>, source=..., sourceVal=<optimized out>, exec=0x7fffffffc6f0, this=<optimized out>) at /tmp/makepkg/qt5-webkit-ng-debug/src/webkit-qtwebkit-5.212.0-alpha/Source/JavaScriptCore/runtime/StringPrototype.cpp:431 #2 0x00007fffed420926 in JSC::replaceUsingRegExpSearch (replaceValue=..., replacementString=..., callType=<optimized out>, callData=..., searchValue=..., string=<optimized out>, exec=<optimized out>) at /tmp/makepkg/qt5-webkit-ng-debug/src/webkit-qtwebkit-5.212.0-alpha/Source/JavaScriptCore/runtime/StringPrototype.cpp:666 #3 0x00007fffed420926 in JSC::replaceUsingRegExpSearch (replaceValue=..., searchValue=..., string=<optimized out>, exec=<optimized out>) at /tmp/makepkg/qt5-webkit-ng-debug/src/webkit-qtwebkit-5.212.0-alpha/Source/JavaScriptCore/runtime/StringPrototype.cpp:708 #4 0x00007fffed420926 in JSC::replace(JSC::ExecState*, JSC::JSString*, JSC::JSValue, JSC::JSValue) (replaceValue=..., searchValue=..., string=<optimized out>, exec=<optimized out>) at /tmp/makepkg/qt5-webkit-ng-debug/src/webkit-qtwebkit-5.212.0-alpha/Source/JavaScriptCore/runtime/StringPrototype.cpp:829 #5 0x00007fffed420926 in JSC::replace(JSC::ExecState*, JSC::JSValue, JSC::JSValue, JSC::JSValue) (replaceValue=..., searchValue=..., thisValue=..., exec=<optimized out>) at /tmp/makepkg/qt5-webkit-ng-debug/src/webkit-qtwebkit-5.212.0-alpha/Source/JavaScriptCore/runtime/StringPrototype.cpp:841 #6 0x00007fffed420926 in JSC::stringProtoFuncReplace(JSC::ExecState*) (exec=<optimized out>) at /tmp/makepkg/qt5-webkit-ng-debug/src/webkit-qtwebkit-5.212.0-alpha/Source/JavaScriptCore/runtime/StringPrototype.cpp:846 #7 0x00007fff1bfff0c8 in () #8 0x00007fffffffc7b0 in () #9 0x00007fffed5c930d in llint_entry () at /usr/lib/libQt5WebKit.so.5 Stack (with jsc and WebKit2GTK, release build): #0 0x00007ffff7ac2c95 in void WTF::StringImpl::copyChars<char16_t>(char16_t*, char16_t const*, unsigned int) () at /usr/lib/libjavascriptcoregtk-4.0.so.18 #1 0x00007ffff7ac1d5e in JSC::stringProtoFuncReplaceUsingRegExp(JSC::ExecState*) () at /usr/lib/libjavascriptcoregtk-4.0.so.18 #2 0x00007fffb21ff028 in () #3 0x00007fffffffcfc0 in () #4 0x00007ffff77a4e42 in () at /usr/lib/libjavascriptcoregtk-4.0.so.18 #5 0x0000000000000000 in () So I looked into the implementation of WTF::StringImpl::copyChars: template <typename T> static void copyChars(T* destination, const T* source, unsigned numCharacters) { if (numCharacters == 1) { *destination = *source; return; } if (numCharacters <= s_copyCharsInlineCutOff) { unsigned i = 0; #if (CPU(X86) || CPU(X86_64)) const unsigned charsPerInt = sizeof(uint32_t) / sizeof(T); if (numCharacters > charsPerInt) { unsigned stopCount = numCharacters & ~(charsPerInt - 1); const uint32_t* srcCharacters = reinterpret_cast<const uint32_t*>(source); // aliasing uint32_t* destCharacters = reinterpret_cast<uint32_t*>(destination); // aliasing for (unsigned j = 0; i < stopCount; i += charsPerInt, ++j) destCharacters[j] = srcCharacters[j]; // CRASH } #endif for (; i < numCharacters; ++i) destination[i] = source[i]; } else memcpy(destination, source, numCharacters * sizeof(T)); } Removing the optimized #if block made things run fine. With some help from people in the #gcc IRC channel, I figured out that WebKit violates strict aliasing rules with the casts marked above (as T is an uint16_t, incompatible with uint32_t): https://www.cocoawithlove.com/2008/04/using-pointers-to-recast-in-c-is-bad.html http://dbp-consulting.com/tutorials/StrictAliasing.html WebKit should be built with -fno-strict-aliasing though, and at least with QtWebKit I verified this was the case. From what I understand, that should make it possible to do this kind of thing, yet with GCC 7.1.1 I get a crash there. I haven't looked at the generated assembler yet (and not sure I'll get to it anytime soon), but this might be a GCC 7 bug? But even if it's fixed there, I suppose WebKit should work around it in some way. I wonder whether the optimized inline copyChars is really needed nowadays (it was added in 2011, https://github.com/annulen/webkit/commit/0cb990be04a30870abb2a01e7f9fe5eea08b25a9 ) - I'd expect an inline memcpy() to generate equal if not better code nowadays, no? Downstream QtWebKit bug where I investigated this: https://github.com/annulen/webkit/issues/562 1319516 1 annulen 2017-06-15 02:29:01 -0700 I've run JSC benchmarks on Linux with GCC 7.1, performance results were neutral after change of copyChars to do just memcpy 1319517 2 webkit.org 2017-06-15 02:32:25 -0700 So then this essentially boils down to whether it should be replaced by a simple memcpy() only for GCC >= 7, or for other compilers as well? (Unless there's another solution to this I'm missing - right now the only option I see is to get rid of the "optimized" part) 1319521 3 ysuzuki 2017-06-15 02:46:26 -0700 (In reply to Konstantin Tokarev from comment #1) > I've run JSC benchmarks on Linux with GCC 7.1, performance results were > neutral after change of copyChars to do just memcpy I like to use memcpy if it does not hurt performance. Just out of curiosity, I wonder if we can use bitwise_cast here instead of reinterpret_cast. Maybe, JF knows much about strict-aliasing, type punning and memcpy. 1319533 4 annulen 2017-06-15 05:03:07 -0700 (In reply to Yusuke Suzuki from comment #3) > (In reply to Konstantin Tokarev from comment #1) > > I've run JSC benchmarks on Linux with GCC 7.1, performance results were > > neutral after change of copyChars to do just memcpy > > I like to use memcpy if it does not hurt performance. I've checked just one platform/compiler combination so far. I guess that initially this code path might have been added because of deficiency in old version of memcpy in macOS' libc, or gcc 4.2. Could you recommend any specific benchmark that is signficantly affected by performance of copyChars? > > Just out of curiosity, I wonder if we can use bitwise_cast here instead of > reinterpret_cast. > > Maybe, JF knows much about strict-aliasing, type punning and memcpy. 1319597 5 jfbastien 2017-06-15 09:33:12 -0700 (In reply to Yusuke Suzuki from comment #3) > (In reply to Konstantin Tokarev from comment #1) > > I've run JSC benchmarks on Linux with GCC 7.1, performance results were > > neutral after change of copyChars to do just memcpy > > I like to use memcpy if it does not hurt performance. > > Just out of curiosity, I wonder if we can use bitwise_cast here instead of > reinterpret_cast. > > Maybe, JF knows much about strict-aliasing, type punning and memcpy. bitwise_cast wouldn't help here, the pointers would still alias. Making the pointer type char* would fix the problem, because char* is magical in C++ and ca alias everything. memcpy sounds good if per isn't hurt. Can source ever be the same as destination though? I want to make sure we don't need memmove instead. 1319604 6 webkit.org 2017-06-15 09:58:12 -0700 If it's a char*, this would be equal to the "naive" bytewise copying below the #ifdef though, right? If it's more than 20 chars (> s_copyCharsInlineCutOff), memcpy is already used, so if anything used copyChars with the same source/destination, that'd have to be only with strings guaranteed to be shorter, which seems quite a stretch I think? 1319609 7 jfbastien 2017-06-15 10:01:47 -0700 (In reply to Florian Bruhin from comment #6) > If it's a char*, this would be equal to the "naive" bytewise copying below > the #ifdef though, right? Correct. > If it's more than 20 chars (> s_copyCharsInlineCutOff), memcpy is already > used, so if anything used copyChars with the same source/destination, that'd > have to be only with strings guaranteed to be shorter, which seems quite a > stretch I think? I'm not familiar with this part of the code, so it doesn't seem like a stretch to me :) 1321830 8 annulen 2017-06-22 04:22:50 -0700 For the record, optimization that avoids memcpy was initially added by Darin in https://bugs.webkit.org/show_bug.cgi?id=20671 (2008) 1321831 9 ysuzuki 2017-06-22 04:32:45 -0700 (In reply to Konstantin Tokarev from comment #8) > For the record, optimization that avoids memcpy was initially added by Darin > in https://bugs.webkit.org/show_bug.cgi?id=20671 (2008) OK, that note is very helpful because it clarifies that this optimization is driven by SunSpider. 1321834 10 ysuzuki 2017-06-22 04:45:53 -0700 (In reply to Yusuke Suzuki from comment #9) > (In reply to Konstantin Tokarev from comment #8) > > For the record, optimization that avoids memcpy was initially added by Darin > > in https://bugs.webkit.org/show_bug.cgi?id=20671 (2008) > > OK, that note is very helpful because it clarifies that this optimization is > driven by SunSpider. I've just tested it on my Linux box. VMs tested: "baseline" at /home/yusukesuzuki/dev/WebKit/WebKitBuild/string-copy-tot/Release/bin/jsc "patched" at /home/yusukesuzuki/dev/WebKit/WebKitBuild/string-copy/Release/bin/jsc Collected 100 samples per benchmark/VM, with 100 VM invocations per benchmark. Emitted a call to gc() between sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime() function to get microsecond-level timing. Reporting benchmark execution times with 95% confidence intervals in milliseconds. baseline patched string-base64 7.7544+-0.1761 7.6138+-0.2071 might be 1.0185x faster string-fasta 10.5429+-0.2746 ? 10.7500+-0.2669 ? might be 1.0196x slower string-tagcloud 14.8588+-0.2828 14.8039+-0.3039 string-unpack-code 36.1769+-0.4251 35.3397+-0.5398 might be 1.0237x faster string-validate-input 8.5182+-0.2206 8.3514+-0.2179 might be 1.0200x faster <arithmetic> 15.5702+-0.1239 15.3718+-0.1452 might be 1.0129x faster It seems there is no explicit difference right now. The compiler is GCC 5.4.0 I would like to see the difference in macOS's clang. 1322001 11 darin 2017-06-22 12:13:38 -0700 It’s great news if memcpy is now fast enough. I’d love to see my old awkward optimization removed if it no longer does any good. In fact, I’m not sure we need a copyChars function at all. We could use memcpy directly as we once did, or even better ICU has u_memcpy if we want something that prevents the need to do "* sizeof(UChar)" at each call site. As long as u_memcpy has great performance too; presumably it expands into memcpy as an inline. 1324415 12 annulen 2017-06-30 08:28:56 -0700 Ping? 1324926 13 webkit.org 2017-07-02 05:52:12 -0700 FWIW Archlinux now added a patch which just uses memcpy to its qt5-webkit package: https://git.archlinux.org/svntogit/packages.git/tree/trunk/qt5-webkit-gcc7.patch?h=packages/qt5-webkit Meanwhile, a Fedora packager told me they didn't notice any issues with GCC 7.1.1... no idea why. :-/ 1325544 14 314599 ysuzuki 2017-07-05 01:57:25 -0700 Created attachment 314599 Patch 1325545 15 314599 ysuzuki 2017-07-05 02:00:03 -0700 Comment on attachment 314599 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=314599&action=review > Source/WTF/wtf/text/StringImpl.h:631 > } We still keep StringImpl::copyChars() because it is very useful to copy characters based on the number of chars. If we use memcpy directly, we need to consider sizeof(UChar) and sizeof(LChar) carefully. And StringImpl::copyChars(UChar*, const LChar*, unsigned) override is also useful. 1325547 16 314599 annulen 2017-07-05 03:28:34 -0700 Comment on attachment 314599 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=314599&action=review > Source/WTF/wtf/text/StringImpl.h:-631 > - if (numCharacters <= s_copyCharsInlineCutOff) { I think we should also remove s_copyCharsInlineCutOff definition 1325549 17 314599 ysuzuki 2017-07-05 03:31:28 -0700 Comment on attachment 314599 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=314599&action=review >> Source/WTF/wtf/text/StringImpl.h:-631 >> - if (numCharacters <= s_copyCharsInlineCutOff) { > > I think we should also remove s_copyCharsInlineCutOff definition Nice catch! I'll update the patch. 1325550 18 314600 ysuzuki 2017-07-05 03:33:03 -0700 Created attachment 314600 Patch 1325557 19 jfbastien 2017-07-05 06:35:27 -0700 Did anyone run numbers on MacOS? 1325558 20 ysuzuki 2017-07-05 06:45:46 -0700 (In reply to JF Bastien from comment #19) > Did anyone run numbers on MacOS? I don't measure it yet. If nobody runs it until tomorrow's evening (JST), possibly I can run it ;) (my macOS box is placed at my office). 1325559 21 jfbastien 2017-07-05 06:46:29 -0700 Ok I can give it a try later today. 1325608 22 jfbastien 2017-07-05 09:55:53 -0700 On my iMac: before after 3d-cube 3.8573+-0.0502 3.7993+-0.0415 might be 1.0153x faster 3d-morph 4.2964+-0.0214 4.2933+-0.0245 3d-raytrace 3.9897+-0.0476 3.9794+-0.0589 access-binary-trees 1.8148+-0.0242 1.8113+-0.0155 access-fannkuch 4.5038+-0.0384 4.5000+-0.0476 access-nbody 2.2008+-0.0196 ? 2.2017+-0.0167 ? access-nsieve 1.9470+-0.0433 ? 1.9663+-0.0509 ? bitops-3bit-bits-in-byte 1.0725+-0.0117 1.0721+-0.0118 bitops-bits-in-byte 2.1698+-0.0342 2.1535+-0.0250 bitops-bitwise-and 1.8784+-0.0138 ? 1.8907+-0.0219 ? bitops-nsieve-bits 2.7890+-0.0119 ? 2.8228+-0.0349 ? might be 1.0121x slower controlflow-recursive 2.0770+-0.0207 2.0688+-0.0231 crypto-aes 3.5230+-0.0352 ? 3.5641+-0.0508 ? might be 1.0117x slower crypto-md5 2.1610+-0.0176 2.1448+-0.0139 crypto-sha1 2.2058+-0.0256 ? 2.2185+-0.0236 ? date-format-tofte 6.0776+-0.0427 ? 6.1917+-0.0917 ? might be 1.0188x slower date-format-xparb 4.8437+-0.0344 ^ 4.7681+-0.0408 ^ definitely 1.0159x faster math-cordic 2.4417+-0.0326 2.4224+-0.0170 math-partial-sums 3.3532+-0.0203 ? 3.3763+-0.0432 ? math-spectral-norm 1.6996+-0.0198 1.6885+-0.0164 regexp-dna 5.9056+-0.0450 5.8670+-0.0320 string-base64 3.6116+-0.0421 3.5795+-0.0302 string-fasta 5.0965+-0.0400 5.0413+-0.0540 might be 1.0110x faster string-tagcloud 7.0740+-0.0728 ? 7.0958+-0.0883 ? string-unpack-code 16.5066+-0.1147 ? 16.6307+-0.1750 ? string-validate-input 4.1960+-0.0615 4.1216+-0.0161 might be 1.0181x faster <arithmetic> 3.8959+-0.0079 3.8950+-0.0104 might be 1.0002x faster 1325632 23 314600 kling 2017-07-05 10:36:35 -0700 Comment on attachment 314600 Patch r=me 1325872 24 314600 ysuzuki 2017-07-05 19:03:32 -0700 Comment on attachment 314600 Patch Thanks! OK, let's go. 1325892 25 314600 commit-queue 2017-07-05 19:31:39 -0700 Comment on attachment 314600 Patch Clearing flags on attachment: 314600 Committed r219182: <http://trac.webkit.org/changeset/219182> 1325893 26 commit-queue 2017-07-05 19:31:40 -0700 All reviewed patches have been landed. Closing bug. 1327917 27 darin 2017-07-11 22:10:09 -0700 (In reply to Yusuke Suzuki from comment #15) > We still keep StringImpl::copyChars() because it is very useful to copy > characters based on the number of chars. > If we use memcpy directly, we need to consider sizeof(UChar) and > sizeof(LChar) carefully. But why not use u_memcpy directly? > And StringImpl::copyChars(UChar*, const LChar*, unsigned) override is also > useful. That makes sense. 1327919 28 ysuzuki 2017-07-11 22:28:33 -0700 (In reply to Darin Adler from comment #27) > (In reply to Yusuke Suzuki from comment #15) > > We still keep StringImpl::copyChars() because it is very useful to copy > > characters based on the number of chars. > > If we use memcpy directly, we need to consider sizeof(UChar) and > > sizeof(LChar) carefully. > > But why not use u_memcpy directly? The problem is that memcpy is not designed for LChar. It is designed for arbitrary bytes. Thus it's signature is `void* memcpy(void*, const void*, size_t)`. We cannot catch the case using memcpy for UChar as a compile error. I think offering copyChars is safer, its overloading and templates can select appropriate memcpy based implementation automatically. 314599 2017-07-05 01:57:25 -0700 2017-07-05 03:33:01 -0700 Patch bug-173407-20170705175724.patch text/plain 4341 ysuzuki U3VidmVyc2lvbiBSZXZpc2lvbjogMjE5MTI1CmRpZmYgLS1naXQgYS9Tb3VyY2UvV1RGL0NoYW5n ZUxvZyBiL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCmluZGV4IDJkZTRmOGI0NTZkNmQ2ZWMzMGM2ODNh YmNkNTU4MjMxMGQ5NGNjZTcuLjY0NDk0ZmMxZWY5NzI3YjIzOWY2NGU1ZmM4M2RjMTE2ZTEwYmE0 MWMgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9XVEYvQ2hh bmdlTG9nCkBAIC0xLDMgKzEsMjkgQEAKKzIwMTctMDctMDUgIFl1c3VrZSBTdXp1a2kgIDx1dGF0 YW5lLnRlYUBnbWFpbC5jb20+CisKKyAgICAgICAgV1RGOjpTdHJpbmdJbXBsOjpjb3B5Q2hhcnMg c2VnZmF1bHRzIHdoZW4gYnVpbHQgd2l0aCBHQ0MgNworICAgICAgICBodHRwczovL2J1Z3Mud2Vi a2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTczNDA3CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9C T0RZIChPT1BTISkuCisKKyAgICAgICAgV2l0aCBHQ0MgNywgU3RyaW5nSW1wbDo6Y29weUNoYXJz KCkgYmVoYXZlcyBhcyB1bmV4cGVjdGVkLgorICAgICAgICBUaGlzIGZ1bmN0aW9uIHZpb2xhdGVz IHN0cmljdCBhbGlhc2luZyBydWxlLgorCisgICAgICAgIFRoaXMgb3B0aW1pemF0aW9uIGlzIG9y aWdpbmFsbHkgaW50cm9kdWNlZCB0byBpbXByb3ZlIHBlcmZvcm1hbmNlCisgICAgICAgIGluIFN1 blNwaWRlcidzIHN0cmluZyB0ZXN0cyBpbiAyMDA4LiBXaGVuIHJ1bm5pbmcgaXQgaW4gbXkgTGlu dXgKKyAgICAgICAgYm94LCBpdCBubyBsb25nZXIgY2F1c2VzIGFueSBvYnNlcnZhYmxlIGRpZmZl cmVuY2UuIFNvLCB3ZSBqdXN0CisgICAgICAgIHJlbW92ZSB0aGlzIG9wdGltaXphdGlvbi4KKwor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJhc2VsaW5lICAgICAgICAg ICAgICAgICAgcGF0Y2hlZAorCisgICAgICAgIHN0cmluZy1iYXNlNjQgICAgICAgICAgICAgICAg Ny43NTQ0Ky0wLjE3NjEgICAgICAgICAgICA3LjYxMzgrLTAuMjA3MSAgICAgICAgICBtaWdodCBi ZSAxLjAxODV4IGZhc3RlcgorICAgICAgICBzdHJpbmctZmFzdGEgICAgICAgICAgICAgICAgMTAu NTQyOSstMC4yNzQ2ICAgICA/ICAgICAxMC43NTAwKy0wLjI2NjkgICAgICAgID8gbWlnaHQgYmUg MS4wMTk2eCBzbG93ZXIKKyAgICAgICAgc3RyaW5nLXRhZ2Nsb3VkICAgICAgICAgICAgIDE0Ljg1 ODgrLTAuMjgyOCAgICAgICAgICAgMTQuODAzOSstMC4zMDM5CisgICAgICAgIHN0cmluZy11bnBh Y2stY29kZSAgICAgICAgICAzNi4xNzY5Ky0wLjQyNTEgICAgICAgICAgIDM1LjMzOTcrLTAuNTM5 OCAgICAgICAgICBtaWdodCBiZSAxLjAyMzd4IGZhc3RlcgorICAgICAgICBzdHJpbmctdmFsaWRh dGUtaW5wdXQgICAgICAgIDguNTE4MistMC4yMjA2ICAgICAgICAgICAgOC4zNTE0Ky0wLjIxNzkg ICAgICAgICAgbWlnaHQgYmUgMS4wMjAweCBmYXN0ZXIKKworICAgICAgICAqIHd0Zi90ZXh0L1N0 cmluZ0ltcGwuaDoKKyAgICAgICAgKFdURjo6U3RyaW5nSW1wbDo6Y29weUNoYXJzKToKKwogMjAx Ny0wNy0wNCAgWXVzdWtlIFN1enVraSAgPHV0YXRhbmUudGVhQGdtYWlsLmNvbT4KIAogICAgICAg ICBbV1RGXSBNYWtlIGRvdWJsZS1jb252ZXJzaW9uJ3MgY2FjaGUgZGF0YSBjb25zdGFudCBhbmQg ZHJvcCBkb3VibGVfY29udmVyc2lvbjo6aW5pdGlhbGl6ZSgpCmRpZmYgLS1naXQgYS9Tb3VyY2Uv V1RGL3d0Zi90ZXh0L1N0cmluZ0ltcGwuaCBiL1NvdXJjZS9XVEYvd3RmL3RleHQvU3RyaW5nSW1w bC5oCmluZGV4IDFkMWEyNTQzYWZlNjMzZmViZTYxMGRmOTliMTE2YTMzNjdiZWE2MDUuLmZlYzg0 MjE0YzA0NzY4M2ViMzcwMjBiNzBhOTAyYTFlZmNkYWQ4OTcgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9X VEYvd3RmL3RleHQvU3RyaW5nSW1wbC5oCisrKyBiL1NvdXJjZS9XVEYvd3RmL3RleHQvU3RyaW5n SW1wbC5oCkBAIC02MjcsMjUgKzYyNyw3IEBAIGNsYXNzIFN0cmluZ0ltcGwgOiBwcml2YXRlIFN0 cmluZ0ltcGxTaGFwZSB7CiAgICAgICAgICAgICAqZGVzdGluYXRpb24gPSAqc291cmNlOwogICAg ICAgICAgICAgcmV0dXJuOwogICAgICAgICB9Ci0KLSAgICAgICAgaWYgKG51bUNoYXJhY3RlcnMg PD0gc19jb3B5Q2hhcnNJbmxpbmVDdXRPZmYpIHsKLSAgICAgICAgICAgIHVuc2lnbmVkIGkgPSAw OwotI2lmIChDUFUoWDg2KSB8fCBDUFUoWDg2XzY0KSkKLSAgICAgICAgICAgIGNvbnN0IHVuc2ln bmVkIGNoYXJzUGVySW50ID0gc2l6ZW9mKHVpbnQzMl90KSAvIHNpemVvZihUKTsKLQotICAgICAg ICAgICAgaWYgKG51bUNoYXJhY3RlcnMgPiBjaGFyc1BlckludCkgewotICAgICAgICAgICAgICAg IHVuc2lnbmVkIHN0b3BDb3VudCA9IG51bUNoYXJhY3RlcnMgJiB+KGNoYXJzUGVySW50IC0gMSk7 Ci0KLSAgICAgICAgICAgICAgICBjb25zdCB1aW50MzJfdCogc3JjQ2hhcmFjdGVycyA9IHJlaW50 ZXJwcmV0X2Nhc3Q8Y29uc3QgdWludDMyX3QqPihzb3VyY2UpOwotICAgICAgICAgICAgICAgIHVp bnQzMl90KiBkZXN0Q2hhcmFjdGVycyA9IHJlaW50ZXJwcmV0X2Nhc3Q8dWludDMyX3QqPihkZXN0 aW5hdGlvbik7Ci0gICAgICAgICAgICAgICAgZm9yICh1bnNpZ25lZCBqID0gMDsgaSA8IHN0b3BD b3VudDsgaSArPSBjaGFyc1BlckludCwgKytqKQotICAgICAgICAgICAgICAgICAgICBkZXN0Q2hh cmFjdGVyc1tqXSA9IHNyY0NoYXJhY3RlcnNbal07Ci0gICAgICAgICAgICB9Ci0jZW5kaWYKLSAg ICAgICAgICAgIGZvciAoOyBpIDwgbnVtQ2hhcmFjdGVyczsgKytpKQotICAgICAgICAgICAgICAg IGRlc3RpbmF0aW9uW2ldID0gc291cmNlW2ldOwotICAgICAgICB9IGVsc2UKLSAgICAgICAgICAg IG1lbWNweShkZXN0aW5hdGlvbiwgc291cmNlLCBudW1DaGFyYWN0ZXJzICogc2l6ZW9mKFQpKTsK KyAgICAgICAgbWVtY3B5KGRlc3RpbmF0aW9uLCBzb3VyY2UsIG51bUNoYXJhY3RlcnMgKiBzaXpl b2YoVCkpOwogICAgIH0KIAogICAgIEFMV0FZU19JTkxJTkUgc3RhdGljIHZvaWQgY29weUNoYXJz KFVDaGFyKiBkZXN0aW5hdGlvbiwgY29uc3QgTENoYXIqIHNvdXJjZSwgdW5zaWduZWQgbnVtQ2hh cmFjdGVycykKZGlmZiAtLWdpdCBhL0pTVGVzdHMvQ2hhbmdlTG9nIGIvSlNUZXN0cy9DaGFuZ2VM b2cKaW5kZXggMWFiYjU2YWJjY2MyODFlNGE2MDk5MmUxYzZmMWI5YTUxMjRjM2NhMy4uNzE2ZWM4 ZjkwMmY1NTI3ZDRhNWU2Nzc3ZTZjZjc1NTcxMDY1NDMwZiAxMDA2NDQKLS0tIGEvSlNUZXN0cy9D aGFuZ2VMb2cKKysrIGIvSlNUZXN0cy9DaGFuZ2VMb2cKQEAgLTEsMyArMSwxMyBAQAorMjAxNy0w Ny0wNSAgWXVzdWtlIFN1enVraSAgPHV0YXRhbmUudGVhQGdtYWlsLmNvbT4KKworICAgICAgICBX VEY6OlN0cmluZ0ltcGw6OmNvcHlDaGFycyBzZWdmYXVsdHMgd2hlbiBidWlsdCB3aXRoIEdDQyA3 CisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xNzM0MDcK KworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICAqIHN0cmVz cy9zdHJpbmctcmVwZWF0LWNvcHktY2hhcnMtY3Jhc2guanM6IEFkZGVkLgorICAgICAgICAoc2hv dWxkQmUpOgorCiAyMDE3LTA3LTAzICBTYWFtIEJhcmF0aSAgPHNiYXJhdGlAYXBwbGUuY29tPgog CiAgICAgICAgIFNraXAgdW5zaGlmdENvdW50U2xvd0Nhc2UtY29ycmVjdC1wb3N0Q2FwYWNpdHku anMgb24gZGVidWcgYnVpbGRzIHNpbmNlIGl0IHRha2VzIGEgbG9uZyB0aW1lIHRvIHJ1bi4KZGlm ZiAtLWdpdCBhL0pTVGVzdHMvc3RyZXNzL3N0cmluZy1yZXBlYXQtY29weS1jaGFycy1jcmFzaC5q cyBiL0pTVGVzdHMvc3RyZXNzL3N0cmluZy1yZXBlYXQtY29weS1jaGFycy1jcmFzaC5qcwpuZXcg ZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwLi42Mjc1OGEzZTYzYzhmZjRlNDA2YzY4NDQxZDRlNGIzN2ZmNzYzNzA2Ci0tLSAvZGV2 L251bGwKKysrIGIvSlNUZXN0cy9zdHJlc3Mvc3RyaW5nLXJlcGVhdC1jb3B5LWNoYXJzLWNyYXNo LmpzCkBAIC0wLDAgKzEsOCBAQAorZnVuY3Rpb24gc2hvdWxkQmUoYWN0dWFsLCBleHBlY3RlZCkg eworICAgIGlmIChhY3R1YWwgIT09IGV4cGVjdGVkKQorICAgICAgICB0aHJvdyBuZXcgRXJyb3Io J2JhZCB2YWx1ZTogJyArIGFjdHVhbCk7Cit9CisKK3ZhciBzID0gJ3h4eHh4eHh4eHh4eHh4QXh4 eHh4eHh4eHh4eHh4eHh4eHh4QeKAkyc7Cit2YXIgcmVzdWx0ID0gcy5yZXBsYWNlKC9BL2csICdi Jyk7CitzaG91bGRCZShyZXN1bHQsICd4eHh4eHh4eHh4eHh4eGJ4eHh4eHh4eHh4eHh4eHh4eHh4 eGLigJMnKTsK 314600 2017-07-05 03:33:03 -0700 2017-07-05 19:31:39 -0700 Patch bug-173407-20170705193302.patch text/plain 4835 ysuzuki U3VidmVyc2lvbiBSZXZpc2lvbjogMjE5MTI1CmRpZmYgLS1naXQgYS9Tb3VyY2UvV1RGL0NoYW5n ZUxvZyBiL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCmluZGV4IDJkZTRmOGI0NTZkNmQ2ZWMzMGM2ODNh YmNkNTU4MjMxMGQ5NGNjZTcuLjY0NDk0ZmMxZWY5NzI3YjIzOWY2NGU1ZmM4M2RjMTE2ZTEwYmE0 MWMgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9XVEYvQ2hh bmdlTG9nCkBAIC0xLDMgKzEsMjkgQEAKKzIwMTctMDctMDUgIFl1c3VrZSBTdXp1a2kgIDx1dGF0 YW5lLnRlYUBnbWFpbC5jb20+CisKKyAgICAgICAgV1RGOjpTdHJpbmdJbXBsOjpjb3B5Q2hhcnMg c2VnZmF1bHRzIHdoZW4gYnVpbHQgd2l0aCBHQ0MgNworICAgICAgICBodHRwczovL2J1Z3Mud2Vi a2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTczNDA3CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9C T0RZIChPT1BTISkuCisKKyAgICAgICAgV2l0aCBHQ0MgNywgU3RyaW5nSW1wbDo6Y29weUNoYXJz KCkgYmVoYXZlcyBhcyB1bmV4cGVjdGVkLgorICAgICAgICBUaGlzIGZ1bmN0aW9uIHZpb2xhdGVz IHN0cmljdCBhbGlhc2luZyBydWxlLgorCisgICAgICAgIFRoaXMgb3B0aW1pemF0aW9uIGlzIG9y aWdpbmFsbHkgaW50cm9kdWNlZCB0byBpbXByb3ZlIHBlcmZvcm1hbmNlCisgICAgICAgIGluIFN1 blNwaWRlcidzIHN0cmluZyB0ZXN0cyBpbiAyMDA4LiBXaGVuIHJ1bm5pbmcgaXQgaW4gbXkgTGlu dXgKKyAgICAgICAgYm94LCBpdCBubyBsb25nZXIgY2F1c2VzIGFueSBvYnNlcnZhYmxlIGRpZmZl cmVuY2UuIFNvLCB3ZSBqdXN0CisgICAgICAgIHJlbW92ZSB0aGlzIG9wdGltaXphdGlvbi4KKwor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJhc2VsaW5lICAgICAgICAg ICAgICAgICAgcGF0Y2hlZAorCisgICAgICAgIHN0cmluZy1iYXNlNjQgICAgICAgICAgICAgICAg Ny43NTQ0Ky0wLjE3NjEgICAgICAgICAgICA3LjYxMzgrLTAuMjA3MSAgICAgICAgICBtaWdodCBi ZSAxLjAxODV4IGZhc3RlcgorICAgICAgICBzdHJpbmctZmFzdGEgICAgICAgICAgICAgICAgMTAu NTQyOSstMC4yNzQ2ICAgICA/ICAgICAxMC43NTAwKy0wLjI2NjkgICAgICAgID8gbWlnaHQgYmUg MS4wMTk2eCBzbG93ZXIKKyAgICAgICAgc3RyaW5nLXRhZ2Nsb3VkICAgICAgICAgICAgIDE0Ljg1 ODgrLTAuMjgyOCAgICAgICAgICAgMTQuODAzOSstMC4zMDM5CisgICAgICAgIHN0cmluZy11bnBh Y2stY29kZSAgICAgICAgICAzNi4xNzY5Ky0wLjQyNTEgICAgICAgICAgIDM1LjMzOTcrLTAuNTM5 OCAgICAgICAgICBtaWdodCBiZSAxLjAyMzd4IGZhc3RlcgorICAgICAgICBzdHJpbmctdmFsaWRh dGUtaW5wdXQgICAgICAgIDguNTE4MistMC4yMjA2ICAgICAgICAgICAgOC4zNTE0Ky0wLjIxNzkg ICAgICAgICAgbWlnaHQgYmUgMS4wMjAweCBmYXN0ZXIKKworICAgICAgICAqIHd0Zi90ZXh0L1N0 cmluZ0ltcGwuaDoKKyAgICAgICAgKFdURjo6U3RyaW5nSW1wbDo6Y29weUNoYXJzKToKKwogMjAx Ny0wNy0wNCAgWXVzdWtlIFN1enVraSAgPHV0YXRhbmUudGVhQGdtYWlsLmNvbT4KIAogICAgICAg ICBbV1RGXSBNYWtlIGRvdWJsZS1jb252ZXJzaW9uJ3MgY2FjaGUgZGF0YSBjb25zdGFudCBhbmQg ZHJvcCBkb3VibGVfY29udmVyc2lvbjo6aW5pdGlhbGl6ZSgpCmRpZmYgLS1naXQgYS9Tb3VyY2Uv V1RGL3d0Zi90ZXh0L1N0cmluZ0ltcGwuaCBiL1NvdXJjZS9XVEYvd3RmL3RleHQvU3RyaW5nSW1w bC5oCmluZGV4IDFkMWEyNTQzYWZlNjMzZmViZTYxMGRmOTliMTE2YTMzNjdiZWE2MDUuLjRmZGZj OGMxMDkwMTZlMThjNDBhNGI2MDQ1OWExZjA4NjMyZTc3YTIgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9X VEYvd3RmL3RleHQvU3RyaW5nSW1wbC5oCisrKyBiL1NvdXJjZS9XVEYvd3RmL3RleHQvU3RyaW5n SW1wbC5oCkBAIC02MjcsMjUgKzYyNyw3IEBAIGNsYXNzIFN0cmluZ0ltcGwgOiBwcml2YXRlIFN0 cmluZ0ltcGxTaGFwZSB7CiAgICAgICAgICAgICAqZGVzdGluYXRpb24gPSAqc291cmNlOwogICAg ICAgICAgICAgcmV0dXJuOwogICAgICAgICB9Ci0KLSAgICAgICAgaWYgKG51bUNoYXJhY3RlcnMg PD0gc19jb3B5Q2hhcnNJbmxpbmVDdXRPZmYpIHsKLSAgICAgICAgICAgIHVuc2lnbmVkIGkgPSAw OwotI2lmIChDUFUoWDg2KSB8fCBDUFUoWDg2XzY0KSkKLSAgICAgICAgICAgIGNvbnN0IHVuc2ln bmVkIGNoYXJzUGVySW50ID0gc2l6ZW9mKHVpbnQzMl90KSAvIHNpemVvZihUKTsKLQotICAgICAg ICAgICAgaWYgKG51bUNoYXJhY3RlcnMgPiBjaGFyc1BlckludCkgewotICAgICAgICAgICAgICAg IHVuc2lnbmVkIHN0b3BDb3VudCA9IG51bUNoYXJhY3RlcnMgJiB+KGNoYXJzUGVySW50IC0gMSk7 Ci0KLSAgICAgICAgICAgICAgICBjb25zdCB1aW50MzJfdCogc3JjQ2hhcmFjdGVycyA9IHJlaW50 ZXJwcmV0X2Nhc3Q8Y29uc3QgdWludDMyX3QqPihzb3VyY2UpOwotICAgICAgICAgICAgICAgIHVp bnQzMl90KiBkZXN0Q2hhcmFjdGVycyA9IHJlaW50ZXJwcmV0X2Nhc3Q8dWludDMyX3QqPihkZXN0 aW5hdGlvbik7Ci0gICAgICAgICAgICAgICAgZm9yICh1bnNpZ25lZCBqID0gMDsgaSA8IHN0b3BD b3VudDsgaSArPSBjaGFyc1BlckludCwgKytqKQotICAgICAgICAgICAgICAgICAgICBkZXN0Q2hh cmFjdGVyc1tqXSA9IHNyY0NoYXJhY3RlcnNbal07Ci0gICAgICAgICAgICB9Ci0jZW5kaWYKLSAg ICAgICAgICAgIGZvciAoOyBpIDwgbnVtQ2hhcmFjdGVyczsgKytpKQotICAgICAgICAgICAgICAg IGRlc3RpbmF0aW9uW2ldID0gc291cmNlW2ldOwotICAgICAgICB9IGVsc2UKLSAgICAgICAgICAg IG1lbWNweShkZXN0aW5hdGlvbiwgc291cmNlLCBudW1DaGFyYWN0ZXJzICogc2l6ZW9mKFQpKTsK KyAgICAgICAgbWVtY3B5KGRlc3RpbmF0aW9uLCBzb3VyY2UsIG51bUNoYXJhY3RlcnMgKiBzaXpl b2YoVCkpOwogICAgIH0KIAogICAgIEFMV0FZU19JTkxJTkUgc3RhdGljIHZvaWQgY29weUNoYXJz KFVDaGFyKiBkZXN0aW5hdGlvbiwgY29uc3QgTENoYXIqIHNvdXJjZSwgdW5zaWduZWQgbnVtQ2hh cmFjdGVycykKQEAgLTg1OSw5ICs4NDEsNiBAQCBjbGFzcyBTdHJpbmdJbXBsIDogcHJpdmF0ZSBT dHJpbmdJbXBsU2hhcGUgewogICAgICAgICByZXR1cm4gKnRhaWxQb2ludGVyPFN0cmluZ0ltcGwq PigpOwogICAgIH0KIAotICAgIC8vIFRoaXMgbnVtYmVyIG11c3QgYmUgYXQgbGVhc3QgMiB0byBh dm9pZCBzaGFyaW5nIGVtcHR5LCBudWxsIGFzIHdlbGwgYXMgMSBjaGFyYWN0ZXIgc3RyaW5ncyBm cm9tIFNtYWxsU3RyaW5ncy4KLSAgICBzdGF0aWMgY29uc3QgdW5zaWduZWQgc19jb3B5Q2hhcnNJ bmxpbmVDdXRPZmYgPSAyMDsKLQogICAgIGVudW0gY2xhc3MgQ2FzZUNvbnZlcnRUeXBlIHsgVXBw ZXIsIExvd2VyIH07CiAgICAgdGVtcGxhdGU8Q2FzZUNvbnZlcnRUeXBlIHR5cGUsIHR5cGVuYW1l IENoYXJhY3RlclR5cGU+IHN0YXRpYyBSZWY8U3RyaW5nSW1wbD4gY29udmVydEFTQ0lJQ2FzZShT dHJpbmdJbXBsJiwgY29uc3QgQ2hhcmFjdGVyVHlwZSosIHVuc2lnbmVkKTsKIApkaWZmIC0tZ2l0 IGEvSlNUZXN0cy9DaGFuZ2VMb2cgYi9KU1Rlc3RzL0NoYW5nZUxvZwppbmRleCAxYWJiNTZhYmNj YzI4MWU0YTYwOTkyZTFjNmYxYjlhNTEyNGMzY2EzLi43MTZlYzhmOTAyZjU1MjdkNGE1ZTY3Nzdl NmNmNzU1NzEwNjU0MzBmIDEwMDY0NAotLS0gYS9KU1Rlc3RzL0NoYW5nZUxvZworKysgYi9KU1Rl c3RzL0NoYW5nZUxvZwpAQCAtMSwzICsxLDEzIEBACisyMDE3LTA3LTA1ICBZdXN1a2UgU3V6dWtp ICA8dXRhdGFuZS50ZWFAZ21haWwuY29tPgorCisgICAgICAgIFdURjo6U3RyaW5nSW1wbDo6Y29w eUNoYXJzIHNlZ2ZhdWx0cyB3aGVuIGJ1aWx0IHdpdGggR0NDIDcKKyAgICAgICAgaHR0cHM6Ly9i dWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTE3MzQwNworCisgICAgICAgIFJldmlld2Vk IGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgICogc3RyZXNzL3N0cmluZy1yZXBlYXQtY29w eS1jaGFycy1jcmFzaC5qczogQWRkZWQuCisgICAgICAgIChzaG91bGRCZSk6CisKIDIwMTctMDct MDMgIFNhYW0gQmFyYXRpICA8c2JhcmF0aUBhcHBsZS5jb20+CiAKICAgICAgICAgU2tpcCB1bnNo aWZ0Q291bnRTbG93Q2FzZS1jb3JyZWN0LXBvc3RDYXBhY2l0eS5qcyBvbiBkZWJ1ZyBidWlsZHMg c2luY2UgaXQgdGFrZXMgYSBsb25nIHRpbWUgdG8gcnVuLgpkaWZmIC0tZ2l0IGEvSlNUZXN0cy9z dHJlc3Mvc3RyaW5nLXJlcGVhdC1jb3B5LWNoYXJzLWNyYXNoLmpzIGIvSlNUZXN0cy9zdHJlc3Mv c3RyaW5nLXJlcGVhdC1jb3B5LWNoYXJzLWNyYXNoLmpzCm5ldyBmaWxlIG1vZGUgMTAwNjQ0Cmlu ZGV4IDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAuLjYyNzU4YTNlNjNj OGZmNGU0MDZjNjg0NDFkNGU0YjM3ZmY3NjM3MDYKLS0tIC9kZXYvbnVsbAorKysgYi9KU1Rlc3Rz L3N0cmVzcy9zdHJpbmctcmVwZWF0LWNvcHktY2hhcnMtY3Jhc2guanMKQEAgLTAsMCArMSw4IEBA CitmdW5jdGlvbiBzaG91bGRCZShhY3R1YWwsIGV4cGVjdGVkKSB7CisgICAgaWYgKGFjdHVhbCAh PT0gZXhwZWN0ZWQpCisgICAgICAgIHRocm93IG5ldyBFcnJvcignYmFkIHZhbHVlOiAnICsgYWN0 dWFsKTsKK30KKwordmFyIHMgPSAneHh4eHh4eHh4eHh4eHhBeHh4eHh4eHh4eHh4eHh4eHh4eHhB 4oCTJzsKK3ZhciByZXN1bHQgPSBzLnJlcGxhY2UoL0EvZywgJ2InKTsKK3Nob3VsZEJlKHJlc3Vs dCwgJ3h4eHh4eHh4eHh4eHh4Ynh4eHh4eHh4eHh4eHh4eHh4eHh4YuKAkycpOwo=