237917 2022-03-15 13:15:02 -0700 [WPE][GTK] Fix a crash after r290360 2022-03-18 02:53:46 -0700 1 1 1 Unclassified WebKit WebKitGTK WebKit Nightly Build Unspecified Linux RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=217655 P2 Normal --- 1 psaavedra psaavedra achristensen aperez bfulgham bugs-noreply cdumez cgarcia mcatanzaro pvollan youennf oldest_to_newest 1851460 0 psaavedra 2022-03-15 13:15:02 -0700 When navigating from one website to another with a different domain with `JS location.replace("https://other.domain.foo")` there is chances to get this crash: ``` was generated by `/usr/libexec/wpe-webkit-1.0/WPEWebProcess 17 75'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x74eeb448 in WebKit::WebProcess::terminate() () from /webkit/usr/lib/libWPEWebKit-1.0.so.3.16.8 [Current thread is 1 (LWP 115)] (gdb) bt #0 0x74eeb448 in WebKit::WebProcess::terminate() () from /webkit/usr/lib/libWPEWebKit-1.0.so.3.16.8 #1 0x74eeb2dc in WebKit::WebProcess::removeWebPage(WTF::ObjectIdentifier<WebCore::PageIdentifierType>) () from /webkit/usr/lib/libWPEWebKit-1.0.so.3.16.8 #2 0x74f75554 in WebKit::WebPage::close() () from /webkit/usr/lib/libWPEWebKit-1.0.so.3.16.8 #3 0x74f94c96 in WebKit::WebProcess::stopRunLoop() () from /webkit/usr/lib/libWPEWebKit-1.0.so.3.16.8 #4 0x74d62986 in IPC::Connection::dispatchMessage(std::unique_ptr<IPC::Decoder, std::default_delete<IPC::Decoder> >) () from /webkit/usr/lib/libWPEWebKit-1.0.so.3.16.8 #5 0x74d62c22 in IPC::Connection::dispatchOneIncomingMessage() () from /webkit/usr/lib/libWPEWebKit-1.0.so.3.16.8 #6 0x7686b89a in WTF::RunLoop::performWork() () from /webkit/usr/lib/libWPEWebKit-1.0.so.3.16.8 #7 0x768a6f70 in WTF::RunLoop::RunLoop()::$_1::__invoke(void*) () from /webkit/usr/lib/libWPEWebKit-1.0.so.3.16.8 #8 0x768a6664 in WTF::RunLoop::$_0::__invoke(_GSource*, int (*)(void*), void*) () from /webkit/usr/lib/libWPEWebKit-1.0.so.3.16.8 #9 0x7453d7b6 in g_main_dispatch (context=0x19948c8) at ../glib-2.62.6/glib/gmain.c:3216 #10 g_main_context_dispatch (context=context@entry=0x19948c8) at ../glib-2.62.6/glib/gmain.c:3908 #11 0x7453da4c in g_main_context_iterate (context=0x19948c8, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib-2.62.6/glib/gmain.c:3981 #12 0x7453dcb8 in g_main_loop_run (loop=0x1995e58) at ../glib-2.62.6/glib/gmain.c:4175 #13 0x768a6ab0 in WTF::RunLoop::run() () from /webkit/usr/lib/libWPEWebKit-1.0.so.3.16.8 #14 0x74f95620 in int WebKit::AuxiliaryProcessMain<WebKit::WebProcessMainWPE>(int, char**) () from /webkit/usr/lib/libWPEWebKit-1.0.so.3.16.8 #15 0x748309fa in __libc_start_main (main=0x456fe0, argc=0, argv=0x0, init=<optimized out>, fini=0x455655 <__libc_csu_fini>, rtld_fini=0x76f13029 <_dl_fini>, stack_end=0x7eb164d4) at libc-start.c:308 #16 0x00455508 in _start () at start.S:112 Backtrace stopped: previous frame identical to this frame (corrupt stack?) ``` 1851463 1 psaavedra 2022-03-15 13:23:56 -0700 The segfault is because a doble-call to the WebProcess::terminate() method in the WebProcess::shutdown() path. ``` void WebProcess::terminate() { #ifndef NDEBUG GCController::singleton().garbageCollectNow(); FontCache::singleton().invalidate(); MemoryCache::singleton().setDisabled(true); #endif m_webConnection->invalidate(); <<<<<<<< invalid access during the second invocation m_webConnection = nullptr; <<<<<<<<< set null in the first invocation platformTerminate(); AuxiliaryProcess::terminate(); } ``` Here the stack method calls: AuxiliaryProcess::shutDown(): ``` -> terminate() -> WebProcess::terminate() -> AuxiliaryProcess::terminate() -> AuxiliaryProcess::terminate() -> stopRunLoop() -> WebProcess::stopRunLoop() (from glib/WebProcessGLib.cpp) -> WebPage::close() -> WebProcess::singleton().removeWebPage(m_identifier) -> AuxiliaryProcess::enableTermination() -- m_terminationCounter: 0 -> WebProcess::terminate() ``` 1851466 2 454750 psaavedra 2022-03-15 13:29:01 -0700 Created attachment 454750 patch 1851480 3 psaavedra 2022-03-15 13:45:44 -0700 With the proposed patch, the new stack could someth WebProcess::stopRunLoop() (from glib/WebProcessGLib.cpp) ``` -> WebPage::close() -> WebProcess::singleton().removeWebPage(m_identifier) -> WebProcess::removeWebPage() -> AuxiliaryProcess::enableTermination() -> WebProcess::terminate() <<<<<<<<<<< Called for each WebProcess associated to each WebPage ... -> WebPage::~WebPage() -> AuxiliaryProcess::stopRunLoop() -> platformStopRunLoop() ``` 1851490 4 454756 psaavedra 2022-03-15 14:02:54 -0700 Created attachment 454756 patch 1851591 5 mcatanzaro 2022-03-15 16:56:24 -0700 So many #ifs. I wonder if we can make other ports use the same implementation of AuxiliaryProcess::didClose that we do, where we call stopRunLoop. I know Apple was previously opposed to similar approaches, but I really doubt one run loop iteration should have a major performance impact on process termination speed. That would allow considerably reducing #ifs, and should hopefully make it safer to modify this code without introducing platform-specific problems. 1851695 6 454756 psaavedra 2022-03-16 02:15:38 -0700 Comment on attachment 454756 patch View in context: https://bugs.webkit.org/attachment.cgi?id=454756&action=review Notice that this change, even if could be good for avoiding redundant calls to the RunLoop::main().stop(), is not mandatory since it doesn't harms the shutDown logic. > Source/WebKit/Shared/AuxiliaryProcess.cpp:216 > +#if !PLATFORM(GTK) && !PLATFORM(WPE) Notice that this change, even if could be good for avoiding redundant calls to the RunLoop::main().stop(), is not mandatory since it doesn't harms the shutDown logic. 1851698 7 psaavedra 2022-03-16 02:51:54 -0700 (In reply to Michael Catanzaro from comment #5) > So many #ifs. > > I wonder if we can make other ports use the same implementation of > AuxiliaryProcess::didClose that we do, where we call stopRunLoop. I know > Apple was previously opposed to similar approaches, but I really doubt one > run loop iteration should have a major performance impact on process > termination speed. That would allow considerably reducing #ifs, and should > hopefully make it safer to modify this code without introducing > platform-specific problems. AFAIK, the major concern to move this to the WebProcess.cpp is the loop stop is too slow in some ports. This is the reason why didClose() is implemented with `_exit(EXIT_SUCCESS)`. I don't think that situation changed a lot since the last time this was discussed. 1851699 8 psaavedra 2022-03-16 02:56:32 -0700 BTW, a simple safe-guard like this also fix the crash: ``` void WebProcess::terminate() { #ifndef NDEBUG GCController::singleton().garbageCollectNow(); FontCache::singleton().invalidate(); MemoryCache::singleton().setDisabled(true); #endif if (m_webConnection) <<<<<<<<<<<<<<< safe-guarded access { m_webConnection->invalidate(); <<<<<<<< invalid access during the second invocation m_webConnection = nullptr; <<<<<<<<< set null in the first invocation } platformTerminate(); AuxiliaryProcess::terminate(); } ``` ; however I don't think the recursive logic followed by the terminate() could be considered strictly correct: ``` -> terminate() -> WebProcess::terminate() -> AuxiliaryProcess::terminate() -> AuxiliaryProcess::terminate() -> stopRunLoop() -> WebProcess::stopRunLoop() (from glib/WebProcessGLib.cpp) -> WebPage::close() -> WebProcess::singleton().removeWebPage(m_identifier) -> AuxiliaryProcess::enableTermination() -- m_terminationCounter: 0 -> WebProcess::terminate() ``` 1851720 9 cgarcia 2022-03-16 03:54:10 -0700 Checking m_webConnection was also my first idea, but returning early instead. However, I would like to understand how this can happen, because I would expect the page map to be empty when shutdown is called. 1851791 10 psaavedra 2022-03-16 07:43:12 -0700 ``` XXX ( thread &1844441728 pid &001) -- WebPageProxy::commitProvisionalPage() -- m_process->removeWebPage() XXX ( thread &1844441728 pid &001) -- WebProcessProxy::removeWebPage() XXX ( thread &1844441728 pid &001) -- WebProcessProxy::maybeShutDown() XXX ( thread &1844441728 pid &001) -- WebProcessProxy::canTerminateAuxiliaryProcess() [1] XXX WebProcessProxy::canTerminateAuxiliaryProcess: (pageCount=0, provisionalPageCount=0, m_suspendedPageCount=0, m_isInProcessCache=0, m_shutdownPreventingScopeCounter=0) XXX WebProcessProxy::canTerminateAuxiliaryProcess: true XXX ( thread &1844441728 pid &001) -- WebProcessProxy::maybeShutDown() -> shutDown() XXX ( thread &1844441728 pid &001) -- WebProcessProxy::shutDown() XXX ( thread &1887639264 pid &111) -- AuxiliaryProcess::shutDown() -> terminate() -- m_terminationCounter: 1 XXX ( thread &1887639264 pid &111) -- WebProcess::terminate() -- BEGIN -- this (&0x6fff6000) XXX ( thread &1887639264 pid &111) -- WebProcess::terminate() -- 1 -- this (&0x6fff6000) XXX ( thread &1887639264 pid &111) -- WebProcess::terminate() -- 1.1 -- this (&0x6fff6000) XXX ( thread &1887639264 pid &111) -- WebProcess::terminate() -- 2 -- this (&0x6fff6000) XXX ( thread &1887639264 pid &111) -- WebProcess::terminate() -- 3 -- this (&0x6fff6000) XXX ( thread &1887639264 pid &111) -- glib/WebProcessGLib.cpp -- WebProcess::stopRunLoop() [2] XXX ( thread &1887639264 pid &111) -- WebPage::close() --> This will lead in a 2nd terminate() czll ``` notice that: * in [1] pageCount is WebProcessProxy.m_pageMap.size() -> 0. * in [2] WebPage::close() is called because the m_WebProcess.pageMap is not empty At that point it looks like there is a desynchrony between the WebProcessState state and the WebProcess state 1851801 11 psaavedra 2022-03-16 08:05:10 -0700 (In reply to Carlos Garcia Campos from comment #9) > Checking m_webConnection was also my first idea, but returning early > instead. However, I would like to understand how this can happen, because I > would expect the page map to be empty when shutdown is called. Notice that a similar decision was taken in the WebProcessProxy: ``` void WebProcessProxy::shutDown() { ... if (m_webConnection) { m_webConnection->invalidate(); m_webConnection = nullptr; } ``` 1851850 12 psaavedra 2022-03-16 09:10:06 -0700 Coming back to the comment:10 This change could prevent the m_pageMap being not empty by calling for the page close() before the page being removed from the WebProcessProxy map: ``` diff --git a/Source/WebKit/UIProcess/WebPageProxy.cpp b/Source/WebKit/UIProcess/WebPageProxy.cpp index a7e19d46..745559a3 100644 --- a/Source/WebKit/UIProcess/WebPageProxy.cpp +++ b/Source/WebKit/UIProcess/WebPageProxy.cpp @@ -3607,6 +3615,11 @@ void WebPageProxy::commitProvisionalPage(FrameIdentifier frameID, FrameInfoData& m_process->removeMessageReceiver(Messages::WebPageProxy::messageReceiverName(), m_webPageID); auto* navigation = navigationState().navigation(m_provisionalPage->navigationID()); bool didSuspendPreviousPage = navigation && !m_provisionalPage->shouldClosePreviousPageAfterCommit() ? suspendCurrentPageIfPossible(*navigation, mainFrameIDInPreviousProcess, m_provisionalPage->processSwapRequestedByClient(), shouldDelayClosingUntilFirstLayerFlush) : false; + + RunLoop::current().dispatch([destinationID = messageSenderDestinationID(), protectedProcess = m_process.copyRef(), preventProcessShutdownScope = m_process->shutdownPreventingScope()] { + protectedProcess->send(Messages::WebPage::Close(), destinationID); + }); + m_process->removeWebPage(*this, m_websiteDataStore.ptr() == &m_provisionalPage->process().websiteDataStore() ? WebProcessProxy::EndsUsingDataStore::No : WebProcessProxy::EndsUsingDataStore::Yes); // There is no way we'll be able to return to the page in the previous page so close it. ``` Resulting in this workflow: ``` XXX ( layerFlush thread &1887233760) -- CoordinatedGraphicsLayer::~CoordinatedGraphicsLayer() -- END XXX ( ??? thread &1844441728 pid &1) -- WebProcessProxy::WebProcessProxy() -- m_shutdownPreventingScopeCounter XXX ( ??? thread &1844441728 pid &1) -- WebPageProxy::commitProvisionalPage() -- m_process->removeWebPage() XXX ( ??? thread &1844441728 pid &1) -- WebProcessProxy::removeWebPage() XXX ( ??? thread &1844441728 pid &1) -- WebProcessProxy::maybeShutDown() XXX ( ??? thread &1844441728 pid &1) -- WebProcessProxy::canTerminateAuxiliaryProcess() XXX WebProcessProxy::canTerminateAuxiliaryProcess: (pageCount=0, provisionalPageCount=0, m_suspendedPageCount=0, m_isInProcessCache=0, m_shutdownPreventingScopeCounter=1) XXX ( ??? thread &1844441728 pid &1) -- WebProcessProxy::addExistingWebPage() XXX ( ??? thread &1886918368 pid &168) -- WebPage::close() <<<<<<<<<<< [1] XXX ( ??? thread &1844441728 pid &1) -- WebProcessProxy::removeProvisionalPageProxy() XXX ( ??? thread &1844441728 pid &1) -- WebProcessProxy::maybeShutDown() XXX ( ??? thread &1844441728 pid &1) -- WebProcessProxy::canTerminateAuxiliaryProcess() XXX WebProcessProxy::canTerminateAuxiliaryProcess: (pageCount=1, provisionalPageCount=0, m_suspendedPageCount=0, m_isInProcessCache=0, m_shutdownPreventingScopeCounter=0) ... XXX ( ??? thread &1886918368 pid &168) -- WebPage::close() -> WebProcess::singleton().removeWebPage(m_identifier) XXX (? t:&1886918368 p:&:168) -- WebProcess::removeWebPage() -- BEGIN -- this (&0x6fef6000) XXX ( ??? thread &1886918368 pid &168) -- AuxiliaryProcess::enableTermination() -- m_terminationCounter: 0 XXX (? t:&1886918368 p:&:168) -- AuxiliaryProcess::terminationTimerFired()() (&0x6fef6000) XXX (? t:&1886918368 p:&:168) -- WebProcess::shouldTerminate() -- BEGIN -- this (&0x6fef6000) XXX ( ??? thread &1844441728 pid &1) -- WebProcessProxy::WebProcessProxy() -- m_shutdownPreventingScopeCounter XXX ( ??? thread &1844441728 pid &1) -- WebProcessProxy::maybeShutDown() XXX ( ??? thread &1844441728 pid &1) -- WebProcessProxy::canTerminateAuxiliaryProcess() XXX WebProcessProxy::canTerminateAuxiliaryProcess: (pageCount=0, provisionalPageCount=0, m_suspendedPageCount=0, m_isInProcessCache=0, m_shutdownPreventingScopeCounter=0) XXX WebProcessProxy::canTerminateAuxiliaryProcess: true XXX ( ??? thread &1844441728 pid &1) -- WebProcessProxy::maybeShutDown() -> shutDown() XXX ( ??? thread &1844441728 pid &1) -- WebProcessProxy::shutDown() XXX (? t:&1886918368 p:&:168) -- WebProcess::shouldTerminate() -- END -- true -- this (&0x6fef6000) XXX (? t:&1886918368 p:&:168) -- WebProcess::terminate() -- BEGIN -- this (&0x6fef6000) XXX ( ??? thread &1886918368 pid &168) -- glib/WebProcessGLib.cpp -- WebProcess::stopRunLoop() (no WebPage.close() because it was alrady called in [1] before the shutdown) ... ``` ; apparently more logically right. 1852231 13 454958 cgarcia 2022-03-17 04:37:54 -0700 Created attachment 454958 Patch 1852232 14 psaavedra 2022-03-17 04:45:53 -0700 (In reply to Carlos Garcia Campos from comment #13) > Created attachment 454958 [details] > Patch Yes, this patch also works. Moreover, this avoids shouldTerminate() being called and this again the shutdown() one more time. As, Carlos explained to me, in case of shutdown, we want to inconditionally terminate the WebProcess. We dont want ask to the UI-process if we should do it because it is the UI-process itself who is shutting down the WebProcess. This patch is clear r+ for me. Thanks Carlos. 1852331 15 454958 mcatanzaro 2022-03-17 09:44:05 -0700 Comment on attachment 454958 Patch I like that you managed this in a non-intrusive and cross-platform way. Needs owner approval, though. 1852666 16 cgarcia 2022-03-18 02:51:25 -0700 Committed r291475 (248591@trunk): <https://commits.webkit.org/248591@trunk> 454750 2022-03-15 13:29:01 -0700 2022-03-15 14:02:32 -0700 patch bug-237917-20220315212859.patch text/plain 1365 psaavedra U3VidmVyc2lvbiBSZXZpc2lvbjogMjkxMzA4CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0L0No YW5nZUxvZyBiL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCmluZGV4IDgxOTU1ZTFkYWM1NzJhMTM0 MDY2YmIyY2FhMDhhM2UzYjZjMTFjNmIuLmU0MjVlYmY5ZDFkZmQ1YTY1NmZlMjdmN2Q4NDA3NDE0 ZDgwMTIzMmYgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCisrKyBiL1NvdXJj ZS9XZWJLaXQvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTUgQEAKKzIwMjItMDMtMTUgIFBhYmxvIFNh YXZlZHJhICA8cHNhYXZlZHJhQGlnYWxpYS5jb20+CisKKyAgICAgICAgW1dQRV1bR1RLXSAgU3Rv cCB0aGUgcnVuIGxvb3AgaW4gdGhlIHNodXREb3duKCkgdG8gZW5zdXJlIGEgbm9ybWFsIGV4aXQK KyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTIzNzkxNwor CisgICAgICAgIFRoaXMgYWxzbyBmaXggYSBjcmFzaCBpbnRyb2R1Y2VkIGFmdGVyIHIyOTAzNjAK KworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICAqIFNoYXJl ZC9BdXhpbGlhcnlQcm9jZXNzLmNwcDoKKyAgICAgICAgKFdlYktpdDo6QXV4aWxpYXJ5UHJvY2Vz czo6c2h1dERvd24pOgorCiAyMDIyLTAzLTE1ICBBZGl0eWEgS2VlcnRoaSAgPGFrZWVydGhpQGFw cGxlLmNvbT4KIAogICAgICAgICBbaU9TXSBJbmRlZmluaXRlIGhhbmcgd2hlbiBwcmludGluZyB1 c2luZyBhIFVJUHJpbnRQYWdlUmVuZGVyZXIKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQvU2hh cmVkL0F1eGlsaWFyeVByb2Nlc3MuY3BwIGIvU291cmNlL1dlYktpdC9TaGFyZWQvQXV4aWxpYXJ5 UHJvY2Vzcy5jcHAKaW5kZXggNTJkZGU3M2M0NjQyZWM5NWU5YjEzOWRjM2YwNjQ1NzQ4ZGYxZGY3 Yi4uMTQ2Mzc1M2EyODlhMWFiMTY0MjRhN2QyMTIyNDlmY2MwZWY1ODA4OSAxMDA2NDQKLS0tIGEv U291cmNlL1dlYktpdC9TaGFyZWQvQXV4aWxpYXJ5UHJvY2Vzcy5jcHAKKysrIGIvU291cmNlL1dl YktpdC9TaGFyZWQvQXV4aWxpYXJ5UHJvY2Vzcy5jcHAKQEAgLTIxOCw3ICsyMTgsMTEgQEAgdm9p ZCBBdXhpbGlhcnlQcm9jZXNzOjp0ZXJtaW5hdGUoKQogCiB2b2lkIEF1eGlsaWFyeVByb2Nlc3M6 OnNodXREb3duKCkKIHsKKyNpZiBQTEFURk9STShHVEspIHx8IFBMQVRGT1JNKFdQRSkKKyAgICBz dG9wUnVuTG9vcCgpOworI2Vsc2UKICAgICB0ZXJtaW5hdGUoKTsKKyNlbmRpZgogfQogCiBzdGQ6 Om9wdGlvbmFsPHN0ZDo6cGFpcjxJUEM6OkNvbm5lY3Rpb246OklkZW50aWZpZXIsIElQQzo6QXR0 YWNobWVudD4+IEF1eGlsaWFyeVByb2Nlc3M6OmNyZWF0ZUlQQ0Nvbm5lY3Rpb25QYWlyKCkK 454756 2022-03-15 14:02:54 -0700 2022-03-17 04:37:54 -0700 patch bug-237917-20220315220252.patch text/plain 1473 psaavedra U3VidmVyc2lvbiBSZXZpc2lvbjogMjkxMzA4CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0L0No YW5nZUxvZyBiL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCmluZGV4IDgxOTU1ZTFkYWM1NzJhMTM0 MDY2YmIyY2FhMDhhM2UzYjZjMTFjNmIuLmU0MjVlYmY5ZDFkZmQ1YTY1NmZlMjdmN2Q4NDA3NDE0 ZDgwMTIzMmYgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCisrKyBiL1NvdXJj ZS9XZWJLaXQvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTUgQEAKKzIwMjItMDMtMTUgIFBhYmxvIFNh YXZlZHJhICA8cHNhYXZlZHJhQGlnYWxpYS5jb20+CisKKyAgICAgICAgW1dQRV1bR1RLXSAgU3Rv cCB0aGUgcnVuIGxvb3AgaW4gdGhlIHNodXREb3duKCkgdG8gZW5zdXJlIGEgbm9ybWFsIGV4aXQK KyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTIzNzkxNwor CisgICAgICAgIFRoaXMgYWxzbyBmaXggYSBjcmFzaCBpbnRyb2R1Y2VkIGFmdGVyIHIyOTAzNjAK KworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICAqIFNoYXJl ZC9BdXhpbGlhcnlQcm9jZXNzLmNwcDoKKyAgICAgICAgKFdlYktpdDo6QXV4aWxpYXJ5UHJvY2Vz czo6c2h1dERvd24pOgorCiAyMDIyLTAzLTE1ICBBZGl0eWEgS2VlcnRoaSAgPGFrZWVydGhpQGFw cGxlLmNvbT4KIAogICAgICAgICBbaU9TXSBJbmRlZmluaXRlIGhhbmcgd2hlbiBwcmludGluZyB1 c2luZyBhIFVJUHJpbnRQYWdlUmVuZGVyZXIKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQvU2hh cmVkL0F1eGlsaWFyeVByb2Nlc3MuY3BwIGIvU291cmNlL1dlYktpdC9TaGFyZWQvQXV4aWxpYXJ5 UHJvY2Vzcy5jcHAKaW5kZXggNTJkZGU3M2M0NjQyZWM5NWU5YjEzOWRjM2YwNjQ1NzQ4ZGYxZGY3 Yi4uNzc0OTllMjYzOGY1OTdkNDBmYTViYzFkMGY3YzU5MjE3YjY2YjFiMyAxMDA2NDQKLS0tIGEv U291cmNlL1dlYktpdC9TaGFyZWQvQXV4aWxpYXJ5UHJvY2Vzcy5jcHAKKysrIGIvU291cmNlL1dl YktpdC9TaGFyZWQvQXV4aWxpYXJ5UHJvY2Vzcy5jcHAKQEAgLTIxMywxMiArMjEzLDE4IEBAIHZv aWQgQXV4aWxpYXJ5UHJvY2Vzczo6dGVybWluYXRlKCkKIHsKICAgICBtX2Nvbm5lY3Rpb24tPmlu dmFsaWRhdGUoKTsKIAorI2lmICFQTEFURk9STShHVEspICYmICFQTEFURk9STShXUEUpCiAgICAg c3RvcFJ1bkxvb3AoKTsKKyNlbmRpZgogfQogCiB2b2lkIEF1eGlsaWFyeVByb2Nlc3M6OnNodXRE b3duKCkKIHsKKyNpZiBQTEFURk9STShHVEspIHx8IFBMQVRGT1JNKFdQRSkKKyAgICBzdG9wUnVu TG9vcCgpOworI2Vsc2UKICAgICB0ZXJtaW5hdGUoKTsKKyNlbmRpZgogfQogCiBzdGQ6Om9wdGlv bmFsPHN0ZDo6cGFpcjxJUEM6OkNvbm5lY3Rpb246OklkZW50aWZpZXIsIElQQzo6QXR0YWNobWVu dD4+IEF1eGlsaWFyeVByb2Nlc3M6OmNyZWF0ZUlQQ0Nvbm5lY3Rpb25QYWlyKCkK 454958 2022-03-17 04:37:54 -0700 2022-03-18 02:53:46 -0700 Patch wk2-shutdown.diff text/plain 2873 cgarcia ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nIGIvU291cmNlL1dlYktpdC9DaGFu Z2VMb2cKaW5kZXggMWI0MmQ3NWM1ZjVlLi4xNDExMjVjNGQ3MmIgMTAwNjQ0Ci0tLSBhL1NvdXJj ZS9XZWJLaXQvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCkBAIC0xLDMg KzEsMjIgQEAKKzIwMjItMDMtMTcgIENhcmxvcyBHYXJjaWEgQ2FtcG9zICA8Y2dhcmNpYUBpZ2Fs aWEuY29tPgorCisgICAgICAgIFtXUEVdW0dUS10gRml4IGEgY3Jhc2ggYWZ0ZXIgcjI5MDM2MAor ICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MjM3OTE3CisK KyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgV2hlbiBBdXhp bGlhcnlQcm9jZXNzOjpzaHV0RG93biBpcyBjYWxsZWQgZm9yIHRoZSBXZWJQcm9jZXNzIHRoZXJl IG1pZ2h0IGJlIHBhZ2VzIG5vdCBjbG9zZWQgeWV0LCBmb3IgZXhhbXBsZQorICAgICAgICB3aGVu IHN3YXBwaW5nIHByb2Nlc3Mgb24gbmF2aWdhdGlvbiwgdGhlIGNsb3NlIG1lc3NhZ2UgaXMgc2Vu dCB0byB0aGUgcGFnZSBhZnRlciB0aGUgc2h1dGRvd24uIEluIHRoZSBjYXNlIG9mCisgICAgICAg IEdUSyBhbmQgV1BFIHBvcnRzIHRoZSBwYWdlcyBhcmUgY2xvc2VkIGJlZm9yZSBzdG9wcGluZyB0 aGUgcnVuIGxvb3AgdG8gZW5zdXJlIGFzc29jaWF0ZWQgcmVzb3VyY2VzIChsaWtlIEdQVQorICAg ICAgICByZXNvdXJjZXMpIGFyZSByZWxlYXNlZC4gQ2xvc2luZyB0aGUgbGFzdCBwYWdlIG1ha2Vz IHRoZSBwcm9jZXNzIHRlcm1pbmF0aW9uIGFsbG93ZWQsIHdoaWNoIGVuZHMgdXAgY2FsbGluZwor ICAgICAgICBBdXhpbGlhcnlQcm9jZXNzOjp0ZXJtaW5hdGUgYWdhaW4uIEFsc28sIHdoZW4gdGhl IHNodXRkb3duIG1lc3NhZ2UgaXMgcmVjZWl2ZWQgd2UgZG9uJ3Qgd2FudCB0byBhc2sgYWdhaW4g dGhlIFVJCisgICAgICAgIHByb2Nlc3Mgd2hldGhlciB0aGUgcHJvY2VzcyBjYW4gYmUgdGVybWlu YXRlZCwgc2luY2UgdGhlIFVJIHByb2Nlc3MgYXNrZWQgaXQuCisKKyAgICAgICAgKiBTaGFyZWQv QXV4aWxpYXJ5UHJvY2Vzcy5jcHA6CisgICAgICAgIChXZWJLaXQ6OkF1eGlsaWFyeVByb2Nlc3M6 OmVuYWJsZVRlcm1pbmF0aW9uKTogUmV0dXJuIGVhcmx5IGlmIG1faXNJblNodXREb3duIGlzIHRy dWUuCisgICAgICAgIChXZWJLaXQ6OkF1eGlsaWFyeVByb2Nlc3M6OnNodXREb3duKTogU2V0IG1f aXNJblNodXREb3duIGZvciB0aGUgc2NvcGUuCisgICAgICAgICogU2hhcmVkL0F1eGlsaWFyeVBy b2Nlc3MuaDoKKwogMjAyMi0wMy0xNiAgQW50b2luZSBRdWludCAgPGdyYW91dHNAd2Via2l0Lm9y Zz4KIAogICAgICAgICBbbW9kZWxdIC1bQVNWSW5saW5lUHJldmlldyBzZXRSZW1vdGVDb250ZXh0 Ol0gc2hvdWxkIGJlIGNhbGxlZCBpbnNpZGUgdGhlIC1bQVNWSW5saW5lUHJldmlldyBzZXR1cFJl bW90ZUNvbm5lY3Rpb25XaXRoQ29tcGxldGlvbkhhbmRsZXI6XSBjYWxsYmFjawpkaWZmIC0tZ2l0 IGEvU291cmNlL1dlYktpdC9TaGFyZWQvQXV4aWxpYXJ5UHJvY2Vzcy5jcHAgYi9Tb3VyY2UvV2Vi S2l0L1NoYXJlZC9BdXhpbGlhcnlQcm9jZXNzLmNwcAppbmRleCA1MmRkZTczYzQ2NDIuLmUwY2Ji OTE5NGNmZCAxMDA2NDQKLS0tIGEvU291cmNlL1dlYktpdC9TaGFyZWQvQXV4aWxpYXJ5UHJvY2Vz cy5jcHAKKysrIGIvU291cmNlL1dlYktpdC9TaGFyZWQvQXV4aWxpYXJ5UHJvY2Vzcy5jcHAKQEAg LTM1LDYgKzM1LDcgQEAKICNpbmNsdWRlIDxXZWJDb3JlL0xvZ0luaXRpYWxpemF0aW9uLmg+CiAj aW5jbHVkZSA8cGFsL1Nlc3Npb25JRC5oPgogI2luY2x1ZGUgPHd0Zi9Mb2dJbml0aWFsaXphdGlv bi5oPgorI2luY2x1ZGUgPHd0Zi9TZXRGb3JTY29wZS5oPgogCiAjaWYgIU9TKFdJTkRPV1MpCiAj aW5jbHVkZSA8dW5pc3RkLmg+CkBAIC0xNjMsNyArMTY0LDcgQEAgdm9pZCBBdXhpbGlhcnlQcm9j ZXNzOjplbmFibGVUZXJtaW5hdGlvbigpCiAgICAgQVNTRVJUKG1fdGVybWluYXRpb25Db3VudGVy ID4gMCk7CiAgICAgbV90ZXJtaW5hdGlvbkNvdW50ZXItLTsKIAotICAgIGlmIChtX3Rlcm1pbmF0 aW9uQ291bnRlcikKKyAgICBpZiAobV90ZXJtaW5hdGlvbkNvdW50ZXIgfHwgbV9pc0luU2h1dERv d24pCiAgICAgICAgIHJldHVybjsKIAogICAgIGlmICghbV90ZXJtaW5hdGlvblRpbWVvdXQpIHsK QEAgLTIxOCw2ICsyMTksNyBAQCB2b2lkIEF1eGlsaWFyeVByb2Nlc3M6OnRlcm1pbmF0ZSgpCiAK IHZvaWQgQXV4aWxpYXJ5UHJvY2Vzczo6c2h1dERvd24oKQogeworICAgIFNldEZvclNjb3BlPGJv b2w+IGlzSW5TaHV0RG93bihtX2lzSW5TaHV0RG93biwgdHJ1ZSk7CiAgICAgdGVybWluYXRlKCk7 CiB9CiAKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQvU2hhcmVkL0F1eGlsaWFyeVByb2Nlc3Mu aCBiL1NvdXJjZS9XZWJLaXQvU2hhcmVkL0F1eGlsaWFyeVByb2Nlc3MuaAppbmRleCA2NmU1MTE0 ZjUwZTMuLjE0NWU5ZDgzZDM1ZiAxMDA2NDQKLS0tIGEvU291cmNlL1dlYktpdC9TaGFyZWQvQXV4 aWxpYXJ5UHJvY2Vzcy5oCisrKyBiL1NvdXJjZS9XZWJLaXQvU2hhcmVkL0F1eGlsaWFyeVByb2Nl c3MuaApAQCAtMTc1LDYgKzE3NSw4IEBAIHByaXZhdGU6CiAgICAgLy8gYWZ0ZXIgYSBnaXZlbiBw ZXJpb2Qgb2YgdGltZS4KICAgICB1bnNpZ25lZCBtX3Rlcm1pbmF0aW9uQ291bnRlcjsKIAorICAg IGJvb2wgbV9pc0luU2h1dERvd24geyBmYWxzZSB9OworCiAgICAgUnVuTG9vcDo6VGltZXI8QXV4 aWxpYXJ5UHJvY2Vzcz4gbV90ZXJtaW5hdGlvblRpbWVyOwogCiAgICAgUmVmUHRyPElQQzo6Q29u bmVjdGlvbj4gbV9jb25uZWN0aW9uOwo=