171800 2017-05-08 03:21:48 -0700 [Win] StaticStringImpl in HTMLNames.cpp aren't constructed 2017-05-10 00:23:03 -0700 1 1 1 Unclassified WebKit Web Template Framework WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED P2 Normal --- 171586 171702 171861 1 fujii pvollan achristensen benjamin bfulgham buildbot cdumez cmarcelo commit-queue dbates esprehn+autocc kangil.han mark.lam pvollan ysuzuki oldest_to_newest 1305831 0 fujii 2017-05-08 03:21:48 -0700 Since Bug 171586, when I start MiniBrowser of WinCairo port, the following assertion fails: > ASSERTION FAILED: hasHash() > C:\webkit\ga\WebKitBuild\Debug\DerivedSources\ForwardingHeaders\wtf/text/StringImpl.h(883) : WTF::StringImpl::assertHashIsCorrect Callstack: > WTF.dll!WTFCrash() Line 292 C++ > WebKit.dll!WTF::StringImpl::assertHashIsCorrect() Line 883 C++ > WebKit.dll!WebCore::HTMLNames::init() Line 1666 C++ > WebKit.dll!WebCore::Frame::Frame(WebCore::Page & page, WebCore::HTMLFrameOwnerElement * ownerElement, WebCore::FrameLoaderClient & frameLoaderClient) Line 175 C++ > WebKit.dll!WebCore::MainFrame::MainFrame(WebCore::Page & page, WebCore::PageConfiguration & configuration) Line 56 C++ > WebKit.dll!WebCore::MainFrame::create(WebCore::Page & page, WebCore::PageConfiguration & configuration) Line 68 C++ > WebKit.dll!WebCore::Page::Page(WebCore::PageConfiguration && pageConfiguration) Line 271 C++ > WebKit.dll!WebView::initWithFrame(tagRECT frame, wchar_t * frameName, wchar_t * groupName) Line 3122 C++ > MiniBrowserLib.dll!MiniBrowser::prepareViews(HWND__ * mainWnd, const tagRECT & clientRect, wchar_t * const & requestedURL, HWND__ * & viewHwnd) Line 100 C++ > MiniBrowserLib.dll!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpstrCmdLine, int nCmdShow) Line 160 C++ > MiniBrowserLib.dll!dllLauncherEntryPoint(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpstrCmdLine, int nCmdShow) Line 857 C++ > MiniBrowser.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpstrCmdLine, int nCmdShow) Line 249 C++ > [External Code] All layout test of AppleWin port also fail: https://build.webkit.org/builders/Apple%20Win%207%20Release%20%28Tests%29/builds/593 1306293 1 309479 pvollan 2017-05-09 00:12:21 -0700 Created attachment 309479 Patch 1306296 2 309480 pvollan 2017-05-09 00:15:19 -0700 Created attachment 309480 Patch 1306302 3 309480 ysuzuki 2017-05-09 00:35:40 -0700 Comment on attachment 309480 Patch Hmm, I think we should fix this issue by ensuring StaticStringImpl is correctly initialized at compile time in Windows even in it is a global variable. Current fix is moving it to static variables in functions. It does not work well for StringImpl::empty()'s static string. And we don't want to make it static string inside function because we cannot make StringImpl::empty() inline-function. Since assertHashIsCorrect() exists before Bug 171586, I guess Bug 171586 change makes these strings non-compile-time-initialized in Windows. Can you ensure that this `assertHashIsCorrect()` does not fire before Bug 171586? We can guarantee that they are compile-time-initialized in OSX since we fail to compile if the code includes global constructor invocations. If we can ensure that this `assertHashIsCorrect()` does not fire before Bug 171586, we can assume that Bug 171586 changes these strings non-compile-time-initialized thing in Windows. And I think the right fix is changing them compile-time-string again (as is in OSX). I guess non-constexpr StringImplShape is called from StaticStringImpl constructor. 1306319 4 309486 pvollan 2017-05-09 02:12:11 -0700 Created attachment 309486 Patch 1306320 5 pvollan 2017-05-09 02:13:26 -0700 (In reply to Yusuke Suzuki from comment #3) > Comment on attachment 309480 [details] > Patch > > Hmm, I think we should fix this issue by ensuring StaticStringImpl is > correctly initialized at compile time in Windows even in it is a global > variable. > Current fix is moving it to static variables in functions. It does not work > well for StringImpl::empty()'s static string. > And we don't want to make it static string inside function because we cannot > make StringImpl::empty() inline-function. > > Since assertHashIsCorrect() exists before Bug 171586, I guess Bug 171586 > change makes these strings non-compile-time-initialized in Windows. > Can you ensure that this `assertHashIsCorrect()` does not fire before Bug > 171586? > We can guarantee that they are compile-time-initialized in OSX since we fail > to compile if the code includes global constructor invocations. > > If we can ensure that this `assertHashIsCorrect()` does not fire before Bug > 171586, we can assume that Bug 171586 changes these strings > non-compile-time-initialized thing in Windows. And I think the right fix is > changing them compile-time-string again (as is in OSX). > I guess non-constexpr StringImplShape is called from StaticStringImpl > constructor. Thanks for reviewing! Updated patch. 1306323 6 309486 ysuzuki 2017-05-09 02:47:35 -0700 Comment on attachment 309486 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=309486&action=review > Source/WebCore/dom/make_names.pl:577 > + print F "#undef SKIP_STATIC_CONSTRUCTORS_ON_MSVC\n\n"; Oops, sorry for my misleading comment. We should not allow static constructors here. I mean that we should ensure that Windows works before Bug 171586. Not invoking static constructors is fine. (so above change is not correct). But these variables should be initialized because these variables invokes `constexpr` constructors. I suspect that Bug 171586 change makes these variables uninitialized. 1306330 7 pvollan 2017-05-09 03:55:36 -0700 (In reply to Yusuke Suzuki from comment #6) > Comment on attachment 309486 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=309486&action=review > > > Source/WebCore/dom/make_names.pl:577 > > + print F "#undef SKIP_STATIC_CONSTRUCTORS_ON_MSVC\n\n"; > > Oops, sorry for my misleading comment. > > We should not allow static constructors here. > I mean that we should ensure that Windows works before Bug 171586. > Not invoking static constructors is fine. (so above change is not correct). > > But these variables should be initialized because these variables invokes > `constexpr` constructors. > I suspect that Bug 171586 change makes these variables uninitialized. Yes, I believe this was working before Bug 171586. When SKIP_STATIC_CONSTRUCTORS_ON_MSVC is defined on Windows, not only static constructors are skipped, but also compile time initialization of objects is incorrect. When not defining SKIP_STATIC_CONSTRUCTORS_ON_MSVC, the compile time initialization of these objects seem to be correct. From StaticConstructors.h: #ifdef SKIP_STATIC_CONSTRUCTORS_ON_MSVC // - Assume that all includes of this header want ALL of their static // initializers ignored. This is currently the case. This means that if // a .cc includes this header (or it somehow gets included), all static // initializers after the include will not be executed. // - We do this with a pragma, so that all of the static initializer pointers // go into our own section, and the CRT won't call them. Eventually it would // be nice if the section was discarded, because we don't want the pointers. // See: http://msdn.microsoft.com/en-us/library/7977wcck(VS.80).aspx #pragma warning(disable:4075) #pragma init_seg(".unwantedstaticinits") #endif This will skip static constructors as expected, but also seem to have the side effect of not initializing the objects in HTMLNames.cpp at compile time. Please correct me if I am wrong. Perhaps we should investigate whether this pragma should be used at all? 1306332 8 309486 ysuzuki 2017-05-09 04:06:21 -0700 Comment on attachment 309486 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=309486&action=review >>> Source/WebCore/dom/make_names.pl:577 >>> + print F "#undef SKIP_STATIC_CONSTRUCTORS_ON_MSVC\n\n"; >> >> Oops, sorry for my misleading comment. >> >> We should not allow static constructors here. >> I mean that we should ensure that Windows works before Bug 171586. >> Not invoking static constructors is fine. (so above change is not correct). >> >> But these variables should be initialized because these variables invokes `constexpr` constructors. >> I suspect that Bug 171586 change makes these variables uninitialized. > > Yes, I believe this was working before Bug 171586. > When SKIP_STATIC_CONSTRUCTORS_ON_MSVC is defined on Windows, not only static constructors are skipped, but also compile time initialization of objects is incorrect. When not defining SKIP_STATIC_CONSTRUCTORS_ON_MSVC, the compile time initialization of these objects seem to be correct. > > From StaticConstructors.h: > > #ifdef SKIP_STATIC_CONSTRUCTORS_ON_MSVC > // - Assume that all includes of this header want ALL of their static > // initializers ignored. This is currently the case. This means that if > // a .cc includes this header (or it somehow gets included), all static > // initializers after the include will not be executed. > // - We do this with a pragma, so that all of the static initializer pointers > // go into our own section, and the CRT won't call them. Eventually it would > // be nice if the section was discarded, because we don't want the pointers. > // See: http://msdn.microsoft.com/en-us/library/7977wcck(VS.80).aspx > #pragma warning(disable:4075) > #pragma init_seg(".unwantedstaticinits") > #endif > > This will skip static constructors as expected, but also seem to have the side effect of not initializing the objects in HTMLNames.cpp at compile time. Please correct me if I am wrong. Perhaps we should investigate whether this pragma should be used at all? If this was working before Bug 171586, should we fix StaticStringImpl side instead of adding the above undef? This is because our StaticStringImpl work fine even if SKIP_STATIC_CONSTRUCTORS_ON_MSVC is defined before Bug 171586. 1306335 9 309486 ysuzuki 2017-05-09 04:19:45 -0700 Comment on attachment 309486 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=309486&action=review >>>> Source/WebCore/dom/make_names.pl:577 >>>> + print F "#undef SKIP_STATIC_CONSTRUCTORS_ON_MSVC\n\n"; >>> >>> Oops, sorry for my misleading comment. >>> >>> We should not allow static constructors here. >>> I mean that we should ensure that Windows works before Bug 171586. >>> Not invoking static constructors is fine. (so above change is not correct). >>> >>> But these variables should be initialized because these variables invokes `constexpr` constructors. >>> I suspect that Bug 171586 change makes these variables uninitialized. >> >> Yes, I believe this was working before Bug 171586. >> When SKIP_STATIC_CONSTRUCTORS_ON_MSVC is defined on Windows, not only static constructors are skipped, but also compile time initialization of objects is incorrect. When not defining SKIP_STATIC_CONSTRUCTORS_ON_MSVC, the compile time initialization of these objects seem to be correct. >> >> From StaticConstructors.h: >> >> #ifdef SKIP_STATIC_CONSTRUCTORS_ON_MSVC >> // - Assume that all includes of this header want ALL of their static >> // initializers ignored. This is currently the case. This means that if >> // a .cc includes this header (or it somehow gets included), all static >> // initializers after the include will not be executed. >> // - We do this with a pragma, so that all of the static initializer pointers >> // go into our own section, and the CRT won't call them. Eventually it would >> // be nice if the section was discarded, because we don't want the pointers. >> // See: http://msdn.microsoft.com/en-us/library/7977wcck(VS.80).aspx >> #pragma warning(disable:4075) >> #pragma init_seg(".unwantedstaticinits") >> #endif >> >> This will skip static constructors as expected, but also seem to have the side effect of not initializing the objects in HTMLNames.cpp at compile time. Please correct me if I am wrong. Perhaps we should investigate whether this pragma should be used at all? > > If this was working before Bug 171586, should we fix StaticStringImpl side instead of adding the above undef? > This is because our StaticStringImpl work fine even if SKIP_STATIC_CONSTRUCTORS_ON_MSVC is defined before Bug 171586. I guess, StaticStringImpl should call StringImplShape base constructor with the form like `StringImplShape<charactersCount>(...)`. And maybe, constexpr StringImplShape constructor needs changes. 1306336 10 fujii 2017-05-09 04:26:02 -0700 I tested a following code with VS2015Update3. > #include "stdio.h" > > class Foo { > public: > Foo(int x, int y) : m_x(x), m_y(y) { } > constexpr Foo(int x) : m_x(x), m_y(0) { } > int m_x; > int m_y; > }; > > Foo f1(1, 2); > Foo f2(2); > > #pragma init_seg(".hoge") > > Foo f3(1, 2); > Foo f4(2); > > int main() > { > printf("%d\n", f1 .m_x); > printf("%d\n", f2 .m_x); > printf("%d\n", f3 .m_x); > printf("%d\n", f4 .m_x); > return 0; > } Result: > 1 > 2 > 0 > 2 The init_seg trick skips only non-constexpr constructor. 1306337 11 pvollan 2017-05-09 04:33:48 -0700 (In reply to Yusuke Suzuki from comment #8) > Comment on attachment 309486 [details] > Patch > > If this was working before Bug 171586, should we fix StaticStringImpl side > instead of adding the above undef? > This is because our StaticStringImpl work fine even if > SKIP_STATIC_CONSTRUCTORS_ON_MSVC is defined before Bug 171586. Sorry, I might be misunderstanding here :) Instead of adding the undef, perhaps we should look into removing #pragma init_seg(".unwantedstaticinits") from StaticConstructors.h, since it seems to break compile time initialization? Thanks for reviewing! 1306338 12 ysuzuki 2017-05-09 05:06:00 -0700 (In reply to Per Arne Vollan from comment #11) > (In reply to Yusuke Suzuki from comment #8) > > Comment on attachment 309486 [details] > > Patch > > > > If this was working before Bug 171586, should we fix StaticStringImpl side > > instead of adding the above undef? > > This is because our StaticStringImpl work fine even if > > SKIP_STATIC_CONSTRUCTORS_ON_MSVC is defined before Bug 171586. > > Sorry, I might be misunderstanding here :) > > Instead of adding the undef, perhaps we should look into removing #pragma > init_seg(".unwantedstaticinits") from StaticConstructors.h, since it seems > to break compile time initialization? Ah, no. Instead of adding undef / changing pragma init_seg, we should fix the current implementation of StaticStringImpl. If this was working before Bug 171586, the patch introduced in Bug 171586 breaks the StaticStringImpl. > > Thanks for reviewing! 1306392 13 mark.lam 2017-05-09 08:49:02 -0700 @Per, thanks for investigating and identifying what is going wrong here. I agree with Yusuke's point that StaticStringImpl should use the constexpr forms of StringImplShape's constructors. However, I'm not 100% certain that that's all there is to it. So, I'll file a separate bug to implement Yusuke's solution, and we'll see how the bots fare thereafter. If the issue is resolved, we can close this bug as a dupe. If not, we'll use this bug to investigate the next issue. 1306396 14 pvollan 2017-05-09 08:57:47 -0700 (In reply to Mark Lam from comment #13) > @Per, thanks for investigating and identifying what is going wrong here. I > agree with Yusuke's point that StaticStringImpl should use the constexpr > forms of StringImplShape's constructors. However, I'm not 100% certain that > that's all there is to it. > > So, I'll file a separate bug to implement Yusuke's solution, and we'll see > how the bots fare thereafter. If the issue is resolved, we can close this > bug as a dupe. If not, we'll use this bug to investigate the next issue. Sounds good, thanks guys! 1306535 15 mark.lam 2017-05-09 13:41:28 -0700 @Per, the fix for https://bugs.webkit.org/show_bug.cgi?id=171861 has landed in r216512, but from the looks of the bot, I suspect that it didn't work. Can you investigate further and see whether VC++ is honoring constexprs at all? Thanks. 1306714 16 fujii 2017-05-09 20:10:12 -0700 A lot of compilation warnings are output while compiling HTMLNames.cpp of WinCairo port: >------ Build started: Project: WebCoreDerivedSources, Configuration: Debug x64 ------ > HTMLNames.cpp >C:\webkit\ga\WebKitBuild\Debug\DerivedSources\WebCore\HTMLNames.cpp(54): warning C4592: 'WebCore::HTMLNames::aData': symbol will be dynamically initialized (implementation limitation) >C:\webkit\ga\WebKitBuild\Debug\DerivedSources\WebCore\HTMLNames.cpp(55): warning C4592: 'WebCore::HTMLNames::abbrData': symbol will be dynamically initialized (implementation limitation) >C:\webkit\ga\WebKitBuild\Debug\DerivedSources\WebCore\HTMLNames.cpp(56): warning C4592: 'WebCore::HTMLNames::acceptData': symbol will be dynamically initialized (implementation limitation) >C:\webkit\ga\WebKitBuild\Debug\DerivedSources\WebCore\HTMLNames.cpp(57): warning C4592: 'WebCore::HTMLNames::accept_charsetData': symbol will be dynamically initialized (implementation limitation) >C:\webkit\ga\WebKitBuild\Debug\DerivedSources\WebCore\HTMLNames.cpp(58): warning C4592: 'WebCore::HTMLNames::accesskeyData': symbol will be dynamically initialized (implementation limitation) >(...) Supprisingly, these warnings had been output even before Bug 171586 change. 1306730 17 309578 fujii 2017-05-09 21:29:48 -0700 Created attachment 309578 WIP patch > constexpr StringImplShape(unsigned refCount, unsigned length, const char (&characters)[charactersCount], unsigned hashAndFlags, ConstructWithConstExprTag) > : m_refCount(refCount) > , m_length(length) > , m_data8(reinterpret_cast<const LChar*>(characters)) > , m_hashAndFlags(hashAndFlags) > { } It seems that this reinterpret_cast prevents the compile-time-initialization. This reinterpret_cast has been introduced in Bug 171586. I removed the reinterpret_cast in the WIP patch. It works fine. 1306734 18 309579 fujii 2017-05-09 22:26:35 -0700 Created attachment 309579 Patch 1306745 19 309579 ysuzuki 2017-05-09 23:54:42 -0700 Comment on attachment 309579 Patch r=me. Right, reinterpret_cast is not constexpr. 1306751 20 pvollan 2017-05-10 00:22:32 -0700 (In reply to Fujii Hironori from comment #18) > Created attachment 309579 [details] > Patch Great work! 1306752 21 309579 commit-queue 2017-05-10 00:23:00 -0700 Comment on attachment 309579 Patch Clearing flags on attachment: 309579 Committed r216566: <http://trac.webkit.org/changeset/216566> 1306753 22 commit-queue 2017-05-10 00:23:03 -0700 All reviewed patches have been landed. Closing bug. 309479 2017-05-09 00:12:21 -0700 2017-05-09 00:15:15 -0700 Patch bug-171800-20170509001221.patch text/plain 2975 pvollan SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDIxNjQ4MCkKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE5IEBACisyMDE3LTA1LTA5ICBQZXIgQXJu ZSBWb2xsYW4gIDxwdm9sbGFuQGFwcGxlLmNvbT4KKworICAgICAgICBbV2luXSBTdGF0aWNTdHJp bmdJbXBsIGluIEhUTUxOYW1lcy5jcHAgYXJlbid0IGNvbnN0cnVjdGVkCisgICAgICAgIGh0dHBz Oi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xNzE4MDAKKworICAgICAgICBSZXZp ZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBGb3IgdW5rbm93biByZWFzb25zLCB0 aGUgY29uc3RydWN0b3JzIG9mIHRoZSBTdGF0aWNTdHJpbmdJbXBsIG9iamVjdHMgYXJlIGN1cnJl bnRseSBub3QgY2FsbGVkLAorICAgICAgICB0aGlzIGlzIHBvc3NpYmx5IGEgY29tcGlsZXIgaXNz dWVzLiBBZnRlciBtb3ZpbmcgdGhlIGRlZmluaXRpb24gb2YgdGhlc2Ugb2JqZWN0cyBpbnRvIHRo ZSBpbml0KCkKKyAgICAgICAgbWV0aG9kLCB0aGUgY29uc3RydWN0b3JzIGFyZSBjYWxsZWQuCisK KyAgICAgICAgKiBiaW5kaW5ncy9zY3JpcHRzL1N0YXRpY1N0cmluZy5wbToKKyAgICAgICAgKEdl bmVyYXRlU3RyaW5ncyk6CisgICAgICAgICogZG9tL21ha2VfbmFtZXMucGw6CisgICAgICAgIChw cmludE5hbWVzQ3BwRmlsZSk6CisKIDIwMTctMDUtMDggIENocmlzIER1bWV6ICA8Y2R1bWV6QGFw cGxlLmNvbT4KIAogICAgICAgICBSZWZhY3RvciAvIENsZWFuIHVwIERPTVdpbmRvdy5pZGwKSW5k ZXg6IFNvdXJjZS9XZWJDb3JlL2JpbmRpbmdzL3NjcmlwdHMvU3RhdGljU3RyaW5nLnBtCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KLS0tIFNvdXJjZS9XZWJDb3JlL2JpbmRpbmdzL3NjcmlwdHMvU3RhdGljU3RyaW5nLnBt CShyZXZpc2lvbiAyMTY0NzgpCisrKyBTb3VyY2UvV2ViQ29yZS9iaW5kaW5ncy9zY3JpcHRzL1N0 YXRpY1N0cmluZy5wbQkod29ya2luZyBjb3B5KQpAQCAtNDMsNyArNDMsNyBAQCBFTkQKIAogICAg IGZvciBteSAkbmFtZSAoc29ydCBrZXlzICVzdHJpbmdzKSB7CiAgICAgICAgIG15ICR2YWx1ZSA9 ICRzdHJpbmdzeyRuYW1lfTsKLSAgICAgICAgcHVzaChAcmVzdWx0LCAic3RhdGljIFN0cmluZ0lt cGw6OlN0YXRpY1N0cmluZ0ltcGwgJHtuYW1lfURhdGEoXCIke3ZhbHVlfVwiKTtcbiIpOworICAg ICAgICBwdXNoKEByZXN1bHQsICIgICAgc3RhdGljIFN0cmluZ0ltcGw6OlN0YXRpY1N0cmluZ0lt cGwgJHtuYW1lfURhdGEoXCIke3ZhbHVlfVwiKTtcbiIpOwogICAgIH0KIAogICAgIHB1c2goQHJl c3VsdCwgPDxFTkQpOwpJbmRleDogU291cmNlL1dlYkNvcmUvZG9tL21ha2VfbmFtZXMucGwKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQotLS0gU291cmNlL1dlYkNvcmUvZG9tL21ha2VfbmFtZXMucGwJKHJldmlzaW9uIDIx NjQ3OCkKKysrIFNvdXJjZS9XZWJDb3JlL2RvbS9tYWtlX25hbWVzLnBsCSh3b3JraW5nIGNvcHkp CkBAIC0xMjUsOCArMTI1LDYgQEAgaWYgKGxlbmd0aCgkZm9udE5hbWVzSW4pKSB7CiAgICAgcHJp bnRMaWNlbnNlSGVhZGVyKCRGKTsKICAgICBwcmludENwcEhlYWQoJEYsICJDU1MiLCAkZmFtaWx5 TmFtZXNGaWxlQmFzZSwgIldURiIpOwogCi0gICAgcHJpbnQgRiBTdGF0aWNTdHJpbmc6OkdlbmVy YXRlU3RyaW5ncyhcJXBhcmFtZXRlcnMpOwotCiAgICAgZm9yIG15ICRuYW1lIChzb3J0IGtleXMg JXBhcmFtZXRlcnMpIHsKICAgICAgICAgcHJpbnQgRiAiREVGSU5FX0dMT0JBTChBdG9taWNTdHJp bmcsICRuYW1lKVxuIjsKICAgICB9CkBAIC0xMzQsNiArMTMyLDkgQEAgaWYgKGxlbmd0aCgkZm9u dE5hbWVzSW4pKSB7CiAgICAgcHJpbnRJbml0KCRGLCAwKTsKIAogICAgIHByaW50IEYgIlxuIjsK KworICAgIHByaW50IEYgU3RhdGljU3RyaW5nOjpHZW5lcmF0ZVN0cmluZ3MoXCVwYXJhbWV0ZXJz KTsKKwogICAgIHByaW50IEYgU3RhdGljU3RyaW5nOjpHZW5lcmF0ZVN0cmluZ0Fzc2VydHMoXCVw YXJhbWV0ZXJzKTsKIAogICAgIGZvciBteSAkbmFtZSAoc29ydCBrZXlzICVwYXJhbWV0ZXJzKSB7 CkBAIC03NjMsOCArNzY0LDYgQEAgc3ViIHByaW50TmFtZXNDcHBGaWxlCiAKICAgICBwcmludCBG ICJXRUJDT1JFX0VYUE9SVCBERUZJTkVfR0xPQkFMKEF0b21pY1N0cmluZywgJHtsb3dlcmNhc2VO YW1lc3BhY2VQcmVmaXh9TmFtZXNwYWNlVVJJKVxuXG4iOwogCi0gICAgcHJpbnQgRiBTdGF0aWNT dHJpbmc6OkdlbmVyYXRlU3RyaW5ncyhcJWFsbFN0cmluZ3MpOwotCiAgICAgaWYgKGtleXMgJWFs bFRhZ3MpIHsKICAgICAgICAgcHJpbnQgRiAiLy8gVGFnc1xuIjsKICAgICAgICAgZm9yIG15ICRu YW1lIChzb3J0IGtleXMgJWFsbFRhZ3MpIHsKQEAgLTgwMyw2ICs4MDIsOSBAQCBzdWIgcHJpbnRO YW1lc0NwcEZpbGUKICAgICBwcmludChGICIgICAgLy8gTmFtZXNwYWNlXG4iKTsKICAgICBwcmlu dChGICIgICAgbmV3IChOb3ROdWxsLCAodm9pZCopJiR7bG93ZXJjYXNlTmFtZXNwYWNlUHJlZml4 fU5hbWVzcGFjZVVSSSkgQXRvbWljU3RyaW5nKCR7bG93ZXJjYXNlTmFtZXNwYWNlUHJlZml4fU5T KTtcbiIpOwogICAgIHByaW50KEYgIlxuIik7CisKKyAgICBwcmludCBGIFN0YXRpY1N0cmluZzo6 R2VuZXJhdGVTdHJpbmdzKFwlYWxsU3RyaW5ncyk7CisKICAgICBwcmludCBGIFN0YXRpY1N0cmlu Zzo6R2VuZXJhdGVTdHJpbmdBc3NlcnRzKFwlYWxsU3RyaW5ncyk7CiAKICAgICBpZiAoa2V5cyAl YWxsVGFncykgewo= 309480 2017-05-09 00:15:19 -0700 2017-05-09 02:12:07 -0700 Patch bug-171800-20170509001518.patch text/plain 2974 pvollan SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDIxNjQ4MCkKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE5IEBACisyMDE3LTA1LTA5ICBQZXIgQXJu ZSBWb2xsYW4gIDxwdm9sbGFuQGFwcGxlLmNvbT4KKworICAgICAgICBbV2luXSBTdGF0aWNTdHJp bmdJbXBsIGluIEhUTUxOYW1lcy5jcHAgYXJlbid0IGNvbnN0cnVjdGVkCisgICAgICAgIGh0dHBz Oi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xNzE4MDAKKworICAgICAgICBSZXZp ZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBGb3IgdW5rbm93biByZWFzb25zLCB0 aGUgY29uc3RydWN0b3JzIG9mIHRoZSBTdGF0aWNTdHJpbmdJbXBsIG9iamVjdHMgYXJlIGN1cnJl bnRseSBub3QgY2FsbGVkLAorICAgICAgICB0aGlzIGlzIHBvc3NpYmx5IGEgY29tcGlsZXIgaXNz dWUuIEFmdGVyIG1vdmluZyB0aGUgZGVmaW5pdGlvbiBvZiB0aGVzZSBvYmplY3RzIGludG8gdGhl IGluaXQoKQorICAgICAgICBtZXRob2QsIHRoZSBjb25zdHJ1Y3RvcnMgYXJlIGNhbGxlZC4KKwor ICAgICAgICAqIGJpbmRpbmdzL3NjcmlwdHMvU3RhdGljU3RyaW5nLnBtOgorICAgICAgICAoR2Vu ZXJhdGVTdHJpbmdzKToKKyAgICAgICAgKiBkb20vbWFrZV9uYW1lcy5wbDoKKyAgICAgICAgKHBy aW50TmFtZXNDcHBGaWxlKToKKwogMjAxNy0wNS0wOCAgQ2hyaXMgRHVtZXogIDxjZHVtZXpAYXBw bGUuY29tPgogCiAgICAgICAgIFJlZmFjdG9yIC8gQ2xlYW4gdXAgRE9NV2luZG93LmlkbApJbmRl eDogU291cmNlL1dlYkNvcmUvYmluZGluZ3Mvc2NyaXB0cy9TdGF0aWNTdHJpbmcucG0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gU291cmNlL1dlYkNvcmUvYmluZGluZ3Mvc2NyaXB0cy9TdGF0aWNTdHJpbmcucG0J KHJldmlzaW9uIDIxNjQ3OCkKKysrIFNvdXJjZS9XZWJDb3JlL2JpbmRpbmdzL3NjcmlwdHMvU3Rh dGljU3RyaW5nLnBtCSh3b3JraW5nIGNvcHkpCkBAIC00Myw3ICs0Myw3IEBAIEVORAogCiAgICAg Zm9yIG15ICRuYW1lIChzb3J0IGtleXMgJXN0cmluZ3MpIHsKICAgICAgICAgbXkgJHZhbHVlID0g JHN0cmluZ3N7JG5hbWV9OwotICAgICAgICBwdXNoKEByZXN1bHQsICJzdGF0aWMgU3RyaW5nSW1w bDo6U3RhdGljU3RyaW5nSW1wbCAke25hbWV9RGF0YShcIiR7dmFsdWV9XCIpO1xuIik7CisgICAg ICAgIHB1c2goQHJlc3VsdCwgIiAgICBzdGF0aWMgU3RyaW5nSW1wbDo6U3RhdGljU3RyaW5nSW1w bCAke25hbWV9RGF0YShcIiR7dmFsdWV9XCIpO1xuIik7CiAgICAgfQogCiAgICAgcHVzaChAcmVz dWx0LCA8PEVORCk7CkluZGV4OiBTb3VyY2UvV2ViQ29yZS9kb20vbWFrZV9uYW1lcy5wbAo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ci0tLSBTb3VyY2UvV2ViQ29yZS9kb20vbWFrZV9uYW1lcy5wbAkocmV2aXNpb24gMjE2 NDc4KQorKysgU291cmNlL1dlYkNvcmUvZG9tL21ha2VfbmFtZXMucGwJKHdvcmtpbmcgY29weSkK QEAgLTEyNSw4ICsxMjUsNiBAQCBpZiAobGVuZ3RoKCRmb250TmFtZXNJbikpIHsKICAgICBwcmlu dExpY2Vuc2VIZWFkZXIoJEYpOwogICAgIHByaW50Q3BwSGVhZCgkRiwgIkNTUyIsICRmYW1pbHlO YW1lc0ZpbGVCYXNlLCAiV1RGIik7CiAKLSAgICBwcmludCBGIFN0YXRpY1N0cmluZzo6R2VuZXJh dGVTdHJpbmdzKFwlcGFyYW1ldGVycyk7Ci0KICAgICBmb3IgbXkgJG5hbWUgKHNvcnQga2V5cyAl cGFyYW1ldGVycykgewogICAgICAgICBwcmludCBGICJERUZJTkVfR0xPQkFMKEF0b21pY1N0cmlu ZywgJG5hbWUpXG4iOwogICAgIH0KQEAgLTEzNCw2ICsxMzIsOSBAQCBpZiAobGVuZ3RoKCRmb250 TmFtZXNJbikpIHsKICAgICBwcmludEluaXQoJEYsIDApOwogCiAgICAgcHJpbnQgRiAiXG4iOwor CisgICAgcHJpbnQgRiBTdGF0aWNTdHJpbmc6OkdlbmVyYXRlU3RyaW5ncyhcJXBhcmFtZXRlcnMp OworCiAgICAgcHJpbnQgRiBTdGF0aWNTdHJpbmc6OkdlbmVyYXRlU3RyaW5nQXNzZXJ0cyhcJXBh cmFtZXRlcnMpOwogCiAgICAgZm9yIG15ICRuYW1lIChzb3J0IGtleXMgJXBhcmFtZXRlcnMpIHsK QEAgLTc2Myw4ICs3NjQsNiBAQCBzdWIgcHJpbnROYW1lc0NwcEZpbGUKIAogICAgIHByaW50IEYg IldFQkNPUkVfRVhQT1JUIERFRklORV9HTE9CQUwoQXRvbWljU3RyaW5nLCAke2xvd2VyY2FzZU5h bWVzcGFjZVByZWZpeH1OYW1lc3BhY2VVUkkpXG5cbiI7CiAKLSAgICBwcmludCBGIFN0YXRpY1N0 cmluZzo6R2VuZXJhdGVTdHJpbmdzKFwlYWxsU3RyaW5ncyk7Ci0KICAgICBpZiAoa2V5cyAlYWxs VGFncykgewogICAgICAgICBwcmludCBGICIvLyBUYWdzXG4iOwogICAgICAgICBmb3IgbXkgJG5h bWUgKHNvcnQga2V5cyAlYWxsVGFncykgewpAQCAtODAzLDYgKzgwMiw5IEBAIHN1YiBwcmludE5h bWVzQ3BwRmlsZQogICAgIHByaW50KEYgIiAgICAvLyBOYW1lc3BhY2VcbiIpOwogICAgIHByaW50 KEYgIiAgICBuZXcgKE5vdE51bGwsICh2b2lkKikmJHtsb3dlcmNhc2VOYW1lc3BhY2VQcmVmaXh9 TmFtZXNwYWNlVVJJKSBBdG9taWNTdHJpbmcoJHtsb3dlcmNhc2VOYW1lc3BhY2VQcmVmaXh9TlMp O1xuIik7CiAgICAgcHJpbnQoRiAiXG4iKTsKKworICAgIHByaW50IEYgU3RhdGljU3RyaW5nOjpH ZW5lcmF0ZVN0cmluZ3MoXCVhbGxTdHJpbmdzKTsKKwogICAgIHByaW50IEYgU3RhdGljU3RyaW5n OjpHZW5lcmF0ZVN0cmluZ0Fzc2VydHMoXCVhbGxTdHJpbmdzKTsKIAogICAgIGlmIChrZXlzICVh bGxUYWdzKSB7Cg== 309486 2017-05-09 02:12:11 -0700 2017-05-09 22:26:30 -0700 Patch bug-171800-20170509021210.patch text/plain 1266 pvollan SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDIxNjQ4MCkKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE2IEBACisyMDE3LTA1LTA5ICBQZXIgQXJu ZSBWb2xsYW4gIDxwdm9sbGFuQGFwcGxlLmNvbT4KKworICAgICAgICBbV2luXSBTdGF0aWNTdHJp bmdJbXBsIGluIEhUTUxOYW1lcy5jcHAgYXJlbid0IGNvbnN0cnVjdGVkCisgICAgICAgIGh0dHBz Oi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xNzE4MDAKKworICAgICAgICBSZXZp ZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBHbG9iYWwgU3RhdGljU3RyaW5nSW1w bCBvYmplY3RzIGFyZSBub3QgaW5pdGlhbGl6ZWQgYXQgY29tcGlsZSB0aW1lIGJlY2F1c2Ugd2Ug ZGlzYWJsZSBpbXBsaWNpdAorICAgICAgICBjb25zdHJ1Y3Rpb24gb2YgZ2xvYmFsIHN0YXRpYyBv YmplY3RzIHdoZW4gU0tJUF9TVEFUSUNfQ09OU1RSVUNUT1JTX09OX01TVkMgaXMgZGVmaW5lZC4K KworICAgICAgICAqIGRvbS9tYWtlX25hbWVzLnBsOgorICAgICAgICAocHJpbnRDcHBIZWFkKToK KwogMjAxNy0wNS0wOCAgQ2hyaXMgRHVtZXogIDxjZHVtZXpAYXBwbGUuY29tPgogCiAgICAgICAg IFJlZmFjdG9yIC8gQ2xlYW4gdXAgRE9NV2luZG93LmlkbApJbmRleDogU291cmNlL1dlYkNvcmUv ZG9tL21ha2VfbmFtZXMucGwKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291cmNlL1dlYkNvcmUvZG9tL21ha2Vf bmFtZXMucGwJKHJldmlzaW9uIDIxNjQ3OCkKKysrIFNvdXJjZS9XZWJDb3JlL2RvbS9tYWtlX25h bWVzLnBsCSh3b3JraW5nIGNvcHkpCkBAIC01NzQsNiArNTc0LDcgQEAgc3ViIHByaW50Q3BwSGVh ZAogICAgIHByaW50IEYgIiNlbmRpZlxuXG4iOwogCiAgICAgcHJpbnQgRiAiI2luY2x1ZGUgXCIk e25hbWVzcGFjZX1OYW1lcy5oXCJcblxuIjsKKyAgICBwcmludCBGICIjdW5kZWYgU0tJUF9TVEFU SUNfQ09OU1RSVUNUT1JTX09OX01TVkNcblxuIjsKICAgICBwcmludCBGICIjaW5jbHVkZSA8d3Rm L1N0YXRpY0NvbnN0cnVjdG9ycy5oPlxuIjsKIAogICAgIHByaW50IEYgIm5hbWVzcGFjZSBXZWJD b3JlIHtcblxuIjsK 309578 2017-05-09 21:29:48 -0700 2017-05-09 22:26:32 -0700 WIP patch a.patch text/plain 814 fujii ZGlmZiAtLWdpdCBhL1NvdXJjZS9XVEYvd3RmL3RleHQvU3RyaW5nSW1wbC5oIGIvU291cmNlL1dU Ri93dGYvdGV4dC9TdHJpbmdJbXBsLmgKaW5kZXggNDhkZTcyYmFkZTIuLjdiODgzNDAxN2EwIDEw MDY0NAotLS0gYS9Tb3VyY2UvV1RGL3d0Zi90ZXh0L1N0cmluZ0ltcGwuaAorKysgYi9Tb3VyY2Uv V1RGL3d0Zi90ZXh0L1N0cmluZ0ltcGwuaApAQCAtMTUyLDcgKzE1Miw3IEBAIHByb3RlY3RlZDoK ICAgICBjb25zdGV4cHIgU3RyaW5nSW1wbFNoYXBlKHVuc2lnbmVkIHJlZkNvdW50LCB1bnNpZ25l ZCBsZW5ndGgsIGNvbnN0IGNoYXIgKCZjaGFyYWN0ZXJzKVtjaGFyYWN0ZXJzQ291bnRdLCB1bnNp Z25lZCBoYXNoQW5kRmxhZ3MsIENvbnN0cnVjdFdpdGhDb25zdEV4cHJUYWcpCiAgICAgICAgIDog bV9yZWZDb3VudChyZWZDb3VudCkKICAgICAgICAgLCBtX2xlbmd0aChsZW5ndGgpCi0gICAgICAg ICwgbV9kYXRhOChyZWludGVycHJldF9jYXN0PGNvbnN0IExDaGFyKj4oY2hhcmFjdGVycykpCisg ICAgICAgICwgbV9kYXRhOF9jaGFyKGNoYXJhY3RlcnMpCiAgICAgICAgICwgbV9oYXNoQW5kRmxh Z3MoaGFzaEFuZEZsYWdzKQogICAgIHsgfQogICAgIApAQCAtMTY4LDYgKzE2OCw3IEBAIHByb3Rl Y3RlZDoKICAgICB1bnNpZ25lZCBtX2xlbmd0aDsKICAgICB1bmlvbiB7CiAgICAgICAgIGNvbnN0 IExDaGFyKiBtX2RhdGE4OworICAgICAgICBjb25zdCBjaGFyKiBtX2RhdGE4X2NoYXI7CiAgICAg ICAgIGNvbnN0IFVDaGFyKiBtX2RhdGExNjsKICAgICB9OwogICAgIG11dGFibGUgdW5zaWduZWQg bV9oYXNoQW5kRmxhZ3M7Cg== 309579 2017-05-09 22:26:35 -0700 2017-05-10 00:23:00 -0700 Patch bug-171800-20170510142628.patch text/plain 2528 fujii U3VidmVyc2lvbiBSZXZpc2lvbjogMjE2NTYyCmRpZmYgLS1naXQgYS9Tb3VyY2UvV1RGL0NoYW5n ZUxvZyBiL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCmluZGV4IDQzZDQzY2VmMjkwYzUyYjgyZTQ1ZDY0 YWQ1MjFlODMxMDNmZjU4MWYuLjc4NmZhZGMyYmU5OTJlMTYxOGI2ZTk3MTkzZWY2MzUxNTdjZjBl YjcgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9XVEYvQ2hh bmdlTG9nCkBAIC0xLDMgKzEsMjAgQEAKKzIwMTctMDUtMDkgIEZ1amlpIEhpcm9ub3JpICA8SGly b25vcmkuRnVqaWlAc29ueS5jb20+CisKKyAgICAgICAgW1dpbl0gU3RhdGljU3RyaW5nSW1wbCBp biBIVE1MTmFtZXMuY3BwIGFyZW4ndCBjb25zdHJ1Y3RlZAorICAgICAgICBodHRwczovL2J1Z3Mu d2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTcxODAwCisKKyAgICAgICAgUmV2aWV3ZWQgYnkg Tk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgR2xvYmFsIHZhcmlhYmxlcyBvZiBTdGF0aWNTdHJp bmdJbXBsIGluIEhUTUxOYW1lcy5jcHAgYXJlbid0CisgICAgICAgIGNvbnN0cnVjdGVkIG9uIFdp bmRvd3Mgc2luY2UgQnVnIDE3MTU4Ni4gSXQgc2VlbXMgdGhhdAorICAgICAgICByZWludGVycHJl dF9jYXN0IHByZXZlbnRzIGNvbnN0ZXhwcidzIGNvbXBpbGUgdGltZSBpbml0aWFsaXphdGlvbgor ICAgICAgICBpbiBWQysrLgorCisgICAgICAgICogd3RmL3RleHQvU3RyaW5nSW1wbC5oOgorICAg ICAgICAoV1RGOjpTdHJpbmdJbXBsU2hhcGU6OlN0cmluZ0ltcGxTaGFwZSk6IEFkZGVkIGNvbnN0 IGNoYXIqIGFuZAorICAgICAgICBjb25zdCBjaGFyMTZfdCogbWVtYmVycyBpbiB0aGUgdW5pb24u IERvIG5vdCB1c2UgcmVpbnRlcnByZXRfY2FzdAorICAgICAgICBpbiBjb25zdGV4cHIgY29uc3Ry dWN0b3JzLgorCiAyMDE3LTA1LTA5ICBNYXJrIExhbSAgPG1hcmsubGFtQGFwcGxlLmNvbT4KIAog ICAgICAgICBGb3JjZSBTdGF0aWNTdHJpbmdJbXBsIGNvbnN0cnVjdG9yIHRvIHVzZSB0aGUgY29u c3RleHByIHZlcnNpb25zIG9mIFN0cmluZ0ltcGxTaGFwZSBjb25zdHJ1Y3RvcnMuCmRpZmYgLS1n aXQgYS9Tb3VyY2UvV1RGL3d0Zi90ZXh0L1N0cmluZ0ltcGwuaCBiL1NvdXJjZS9XVEYvd3RmL3Rl eHQvU3RyaW5nSW1wbC5oCmluZGV4IDQ4ZGU3MmJhZGUyNWEyNzM3MzQ3ZThmNzk4NGY2OTY2YTFj OTlmNGMuLjViZWMyNGFmZTQ4YzdkNjMxMDk2ZDdiZTcwMWE4MjVjNTQwN2JkN2YgMTAwNjQ0Ci0t LSBhL1NvdXJjZS9XVEYvd3RmL3RleHQvU3RyaW5nSW1wbC5oCisrKyBiL1NvdXJjZS9XVEYvd3Rm L3RleHQvU3RyaW5nSW1wbC5oCkBAIC0xNTIsNyArMTUyLDcgQEAgcHJvdGVjdGVkOgogICAgIGNv bnN0ZXhwciBTdHJpbmdJbXBsU2hhcGUodW5zaWduZWQgcmVmQ291bnQsIHVuc2lnbmVkIGxlbmd0 aCwgY29uc3QgY2hhciAoJmNoYXJhY3RlcnMpW2NoYXJhY3RlcnNDb3VudF0sIHVuc2lnbmVkIGhh c2hBbmRGbGFncywgQ29uc3RydWN0V2l0aENvbnN0RXhwclRhZykKICAgICAgICAgOiBtX3JlZkNv dW50KHJlZkNvdW50KQogICAgICAgICAsIG1fbGVuZ3RoKGxlbmd0aCkKLSAgICAgICAgLCBtX2Rh dGE4KHJlaW50ZXJwcmV0X2Nhc3Q8Y29uc3QgTENoYXIqPihjaGFyYWN0ZXJzKSkKKyAgICAgICAg LCBtX2RhdGE4Q2hhcihjaGFyYWN0ZXJzKQogICAgICAgICAsIG1faGFzaEFuZEZsYWdzKGhhc2hB bmRGbGFncykKICAgICB7IH0KICAgICAKQEAgLTE2MCw3ICsxNjAsNyBAQCBwcm90ZWN0ZWQ6CiAg ICAgY29uc3RleHByIFN0cmluZ0ltcGxTaGFwZSh1bnNpZ25lZCByZWZDb3VudCwgdW5zaWduZWQg bGVuZ3RoLCBjb25zdCBjaGFyMTZfdCAoJmNoYXJhY3RlcnMpW2NoYXJhY3RlcnNDb3VudF0sIHVu c2lnbmVkIGhhc2hBbmRGbGFncywgQ29uc3RydWN0V2l0aENvbnN0RXhwclRhZykKICAgICAgICAg OiBtX3JlZkNvdW50KHJlZkNvdW50KQogICAgICAgICAsIG1fbGVuZ3RoKGxlbmd0aCkKLSAgICAg ICAgLCBtX2RhdGExNihyZWludGVycHJldF9jYXN0PGNvbnN0IFVDaGFyKj4oY2hhcmFjdGVycykp CisgICAgICAgICwgbV9kYXRhMTZDaGFyKGNoYXJhY3RlcnMpCiAgICAgICAgICwgbV9oYXNoQW5k RmxhZ3MoaGFzaEFuZEZsYWdzKQogICAgIHsgfQogCkBAIC0xNjksNiArMTY5LDEwIEBAIHByb3Rl Y3RlZDoKICAgICB1bmlvbiB7CiAgICAgICAgIGNvbnN0IExDaGFyKiBtX2RhdGE4OwogICAgICAg ICBjb25zdCBVQ2hhciogbV9kYXRhMTY7CisgICAgICAgIC8vIEl0IHNlZW1zIHRoYXQgcmVpbnRl cnByZXRfY2FzdCBwcmV2ZW50cyBjb25zdGV4cHIncyBjb21waWxlIHRpbWUgaW5pdGlhbGl6YXRp b24gaW4gVkMrKy4KKyAgICAgICAgLy8gVGhlc2UgYXJlIG5lZWRlZCB0byBhdm9pZCByZWludGVy cHJldF9jYXN0LgorICAgICAgICBjb25zdCBjaGFyKiBtX2RhdGE4Q2hhcjsKKyAgICAgICAgY29u c3QgY2hhcjE2X3QqIG1fZGF0YTE2Q2hhcjsKICAgICB9OwogICAgIG11dGFibGUgdW5zaWduZWQg bV9oYXNoQW5kRmxhZ3M7CiB9Owo=