98505 2012-10-05 03:21:50 -0700 [EFL] Use ecore_main_loop_thread_safe_call_async() to wakeup main loop. 2012-11-18 23:44:31 -0800 1 1 1 Unclassified WebKit WebKit EFL 528+ (Nightly build) Unspecified Unspecified RESOLVED INVALID P2 Normal --- 98634 1 bw80.lee bw80.lee benjamin cdumez gyuyoung.kim kenneth laszlo.gombos lucas.de.marchi rakuco webkit.review.bot oldest_to_newest 735538 0 bw80.lee 2012-10-05 03:21:50 -0700 ecore provide ecore_main_loop_thread_safe_call_async() function to avoid deadlock or race condition. using this function will be more safe than using ecore_pipe_write(). 735892 1 167369 bw80.lee 2012-10-05 12:47:17 -0700 Created attachment 167369 Patch 735900 2 167369 bw80.lee 2012-10-05 13:02:27 -0700 Comment on attachment 167369 Patch ecore_main_loop_thread_safe_call_async() uses a lock internally, and this can make some dead lock status with the m_functionQueueLock in RunLoop. This patch need more check. 736183 3 bw80.lee 2012-10-05 20:46:25 -0700 There cannot be a dead lock between the two lock. In the callback flush function for ecore_main_loop_thread_safe_call, lock is used just for accessing callback item. (same for m_functionQueueLock) The accessing order of ecore internal lock and m_functionQueueLock will be always ok. 736325 4 167369 kenneth 2012-10-06 22:49:53 -0700 Comment on attachment 167369 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=167369&action=review > Source/WTF/ChangeLog:13 > + Instead of ecore_pipe_write(), > + use ecore_main_loop_thread_safe_call_async() to wakeup ecore main loop. > + > + According to the EFL API document, this function is designed to dispatch > + a function on ecore main loop by avoiding dead lock or race condition. > + With this function, webkit doesn't need to maintain ecore pipe also. So apart from this being a nicer implementation, does it actually improve performance or avoid some deadlocks you have been running in to? 736330 5 167369 cdumez 2012-10-06 23:09:33 -0700 Comment on attachment 167369 Patch Implementation seems nicer. Looks sane. 736473 6 bw80.lee 2012-10-07 20:18:41 -0700 (In reply to comment #4) > (From update of attachment 167369 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=167369&action=review > > > Source/WTF/ChangeLog:13 > > + Instead of ecore_pipe_write(), > > + use ecore_main_loop_thread_safe_call_async() to wakeup ecore main loop. > > + > > + According to the EFL API document, this function is designed to dispatch > > + a function on ecore main loop by avoiding dead lock or race condition. > > + With this function, webkit doesn't need to maintain ecore pipe also. > > So apart from this being a nicer implementation, does it actually improve performance or avoid some deadlocks you have been running in to? Yes~. Actually, this has some complicated history. I observed a lockup in UIProcess about the pipe write. (with WebKit2) (You can see the detail in the patch comment on bug 98580.) ecore_pipe_write() can be work as synchronously when pipe buffer is full. (The function will be wait until the buffer becomes writable.) Using ecore_pipe_write() can make some dead lock issue even though the bug 98580 is applied, because RunLoop::dispatch() can be invoked in the main thread run loop also. * When the pipe buffer is full, 1. in the IPC thread, RunLoop::dispatch() is called, ecore_pipe_write() will wait until pipe buffer is available. 2. in the Main thread, RunLoop::dispatch() can be invoked during the performWork() and ecore_pipe_write() will also wait. When this happens, the process also becomes lockup status because there is no chance to read pipe buffer. ecore_main_loop_thread_safe_call_async() also uses ecore_pipe_write() but it has a check logic for calling ecore_pipe_write(). (when ecore_pipe_write() for a pipe is called and the callback is not invoked yet, it will not call ecore_pipe_write() again) so with this function, the above issue can be prevented. But I want to ask your opinion about this. The root cause of this issue is, there can be some unnecessary pipe write. and the above API prevent the problem. But webkit also maintain the status whether the pipe callback is invoked or not. and this will be more clear than using ecore_main_loop_thread_safe_call_async() multiple calling for the function doesn't have a multiple pipe write, but it also has multiple callback invoke. With maintaining the status for callback invoked, redundant callback call can be removed. 736494 7 bw80.lee 2012-10-07 21:45:52 -0700 (In reply to comment #6) > (In reply to comment #4) > > (From update of attachment 167369 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=167369&action=review > > > > > Source/WTF/ChangeLog:13 > > > + Instead of ecore_pipe_write(), > > > + use ecore_main_loop_thread_safe_call_async() to wakeup ecore main loop. > > > + > > > + According to the EFL API document, this function is designed to dispatch > > > + a function on ecore main loop by avoiding dead lock or race condition. > > > + With this function, webkit doesn't need to maintain ecore pipe also. > > > > So apart from this being a nicer implementation, does it actually improve performance or avoid some deadlocks you have been running in to? > > Yes~. Actually, this has some complicated history. > > I observed a lockup in UIProcess about the pipe write. (with WebKit2) > (You can see the detail in the patch comment on bug 98580.) > > ecore_pipe_write() can be work as synchronously when pipe buffer is full. > (The function will be wait until the buffer becomes writable.) > > Using ecore_pipe_write() can make some dead lock issue > even though the bug 98580 is applied, because RunLoop::dispatch() can be invoked in the main thread run loop also. > * When the pipe buffer is full, > 1. in the IPC thread, RunLoop::dispatch() is called, ecore_pipe_write() will wait until pipe buffer is available. > 2. in the Main thread, RunLoop::dispatch() can be invoked during the performWork() and ecore_pipe_write() will also wait. > > When this happens, the process also becomes lockup status because there is no chance to read pipe buffer. > > ecore_main_loop_thread_safe_call_async() also uses ecore_pipe_write() but it has a check logic for calling ecore_pipe_write(). > (when ecore_pipe_write() for a pipe is called and the callback is not invoked yet, it will not call ecore_pipe_write() again) > > so with this function, the above issue can be prevented. > > But I want to ask your opinion about this. > > The root cause of this issue is, there can be some unnecessary pipe write. > and the above API prevent the problem. > > But webkit also maintain the status whether the pipe callback is invoked or not. and this will be more clear than using ecore_main_loop_thread_safe_call_async() > > multiple calling for the function doesn't have a multiple pipe write, but it also has multiple callback invoke. > > With maintaining the status for callback invoked, redundant callback call can be removed. The code block for the above will be as below. Source/WebCore/platform/RunLoop.cpp @@ -101,12 +101,23 @@ void RunLoop::performWork() function(); } + + { + MutexLocker locker(m_functionQueueLock); + if (m_functionQueue.isEmpty()) + return; + } + + wakeUp(); } void RunLoop::dispatch(const Function<void()>& function) { MutexLocker locker(m_functionQueueLock); + bool needWakeUp = m_functionQueue.isEmpty() m_functionQueue.append(function); + if (!needWakeUp) + return; wakeUp(); } And if this is ok, I think this can be merged with bug 98580 or can be a seperate patch or replace this patch. 736539 8 167369 webkit.review.bot 2012-10-08 00:20:12 -0700 Comment on attachment 167369 Patch Clearing flags on attachment: 167369 Committed r130619: <http://trac.webkit.org/changeset/130619> 736540 9 webkit.review.bot 2012-10-08 00:20:17 -0700 All reviewed patches have been landed. Closing bug. 736552 10 cdumez 2012-10-08 00:57:40 -0700 This patch caused major crashing on the bots: http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Debug/builds/6863 Please roll out. 736553 11 cdumez 2012-10-08 00:59:58 -0700 Backtraces: crash log for DumpRenderTree (pid 6382): STDOUT: <empty> STDERR: 1 0x7f6d83a206df STDERR: 2 0x7f6d7bf8ecb0 STDERR: 3 0x7f6d800e8848 WebCore::ResourceLoader::identifier() const STDERR: 4 0x7f6d80166ef4 WebCore::CachedRawResource::setResponse(WebCore::ResourceResponse const&) STDERR: 5 0x7f6d8012ae3b WebCore::SubresourceLoader::didReceiveResponse(WebCore::ResourceResponse const&) STDERR: 6 0x7f6d8012663b WebCore::ResourceLoader::didReceiveResponse(WebCore::ResourceHandle*, WebCore::ResourceResponse const&) STDERR: 7 0x7f6d8032e4cb WebCore::BlobResourceHandle::notifyResponseOnSuccess() STDERR: 8 0x7f6d8032e2be WebCore::BlobResourceHandle::notifyResponse() STDERR: 9 0x7f6d8032d11a WebCore::BlobResourceHandle::getSizeForNext() STDERR: 10 0x7f6d8032d3aa WebCore::BlobResourceHandle::didGetSize(long long) STDERR: 11 0x7f6d8032d1b5 WebCore::BlobResourceHandle::getSizeForNext() STDERR: 12 0x7f6d8032cfee WebCore::BlobResourceHandle::doStart() STDERR: 13 0x7f6d8032ce86 WebCore::delayedStartBlobResourceHandle(void*) STDERR: 14 0x7f6d83a51871 WTF::dispatchFunctionsFromMainThread() STDERR: 15 0x7f6d83a5bbcd STDERR: 16 0x7f6d83a5bbea WTF::scheduleDispatchFunctionsOnMainThread() STDERR: 17 0x7f6d83a5199d WTF::callOnMainThread(void (*)(void*), void*) STDERR: 18 0x7f6d8032ced2 WebCore::BlobResourceHandle::start() STDERR: 19 0x7f6d8032962e WebCore::BlobRegistryImpl::createResourceHandle(WebCore::ResourceRequest const&, WebCore::ResourceHandleClient*) STDERR: 20 0x7f6d803294a5 STDERR: 21 0x7f6d8033f8d4 WebCore::ResourceHandle::create(WebCore::NetworkingContext*, WebCore::ResourceRequest const&, WebCore::ResourceHandleClient*, bool, bool) STDERR: 22 0x7f6d801257fe WebCore::ResourceLoader::start() STDERR: 23 0x7f6d8012013e WebCore::ResourceLoadScheduler::servePendingRequests(WebCore::ResourceLoadScheduler::HostInformation*, WebCore::ResourceLoadPriority) STDERR: 24 0x7f6d8011fb7e WebCore::ResourceLoadScheduler::scheduleLoad(WebCore::ResourceLoader*, WebCore::ResourceLoadPriority) STDERR: 25 0x7f6d8011f8b3 WebCore::ResourceLoadScheduler::scheduleSubresourceLoad(WebCore::Frame*, WebCore::CachedResource*, WebCore::ResourceRequest const&, WebCore::ResourceLoadPriority, WebCore::ResourceLoaderOptions const&) STDERR: 26 0x7f6d80168540 WebCore::CachedResource::load(WebCore::CachedResourceLoader*, WebCore::ResourceLoaderOptions const&) STDERR: 27 0x7f6d80175881 WebCore::CachedResourceLoader::requestResource(WebCore::CachedResource::Type, WebCore::ResourceRequest&, WTF::String const&, WebCore::ResourceLoaderOptions const&, WebCore::ResourceLoadPriority, bool, WebCore::CachedResourceLoader::DeferOption) STDERR: 28 0x7f6d80174e49 WebCore::CachedResourceLoader::requestRawResource(WebCore::ResourceRequest&, WebCore::ResourceLoaderOptions const&) STDERR: 29 0x7f6d800e7df2 WebCore::DocumentThreadableLoader::loadRequest(WebCore::ResourceRequest const&, WebCore::SecurityCheckPolicy) STDERR: 30 0x7f6d800e5f0f WebCore::DocumentThreadableLoader::DocumentThreadableLoader(WebCore::Document*, WebCore::ThreadableLoaderClient*, WebCore::DocumentThreadableLoader::BlockingBehavior, WebCore::ResourceRequest const&, WebCore::ThreadableLoaderOptions const&) STDERR: 31 0x7f6d800e5c16 WebCore::DocumentThreadableLoader::create(WebCore::Document*, WebCore::ThreadableLoaderClient*, WebCore::ResourceRequest const&, WebCore::ThreadableLoaderOptions const&) STDERR: LEAK: 5 RenderObject STDERR: LEAK: 1 Page STDERR: LEAK: 1 Frame STDERR: LEAK: 4 CachedResource STDERR: LEAK: 2 SubresourceLoader STDERR: LEAK: 58 WebCoreNode ------ crash log for DumpRenderTree (pid 3766): STDOUT: CONSOLE MESSAGE: Application Cache download process was aborted. STDOUT: This tests that download process was aborted after downloading event although resource was not found. STDOUT: SUCCESS STDERR: ASSERTION FAILED: m_table STDERR: /home/buildslave-1/webkit-buildslave/efl-linux-64-debug/build/Source/WTF/wtf/HashTable.h(210) : void WTF::HashTableConstIterator<Key, Value, Extractor, HashFunctions, Traits, KeyTraits>::checkValidity() const [with Key = WebCore::DocumentLoader*, Value = WebCore::DocumentLoader*, Extractor = WTF::IdentityExtractor, HashFunctions = WTF::PtrHash<WebCore::DocumentLoader*>, Traits = WTF::HashTraits<WebCore::DocumentLoader*>, KeyTraits = WTF::HashTraits<WebCore::DocumentLoader*>] STDERR: 1 0x7f52434650a9 WTF::HashTableConstIterator<WebCore::DocumentLoader*, WebCore::DocumentLoader*, WTF::IdentityExtractor, WTF::PtrHash<WebCore::DocumentLoader*>, WTF::HashTraits<WebCore::DocumentLoader*>, WTF::HashTraits<WebCore::DocumentLoader*> >::checkValidity() const STDERR: 2 0x7f5243463b04 WTF::HashTableConstIterator<WebCore::DocumentLoader*, WebCore::DocumentLoader*, WTF::IdentityExtractor, WTF::PtrHash<WebCore::DocumentLoader*>, WTF::HashTraits<WebCore::DocumentLoader*>, WTF::HashTraits<WebCore::DocumentLoader*> >::operator++() STDERR: 3 0x7f52434628b2 WTF::HashTableConstIteratorAdapter<WTF::HashTable<WebCore::DocumentLoader*, WebCore::DocumentLoader*, WTF::IdentityExtractor, WTF::PtrHash<WebCore::DocumentLoader*>, WTF::HashTraits<WebCore::DocumentLoader*>, WTF::HashTraits<WebCore::DocumentLoader*> >, WebCore::DocumentLoader*>::operator++() STDERR: 4 0x7f524346128c WebCore::ApplicationCacheGroup::postListenerTask(WebCore::ApplicationCacheHost::EventID, int, int, WTF::HashSet<WebCore::DocumentLoader*, WTF::PtrHash<WebCore::DocumentLoader*>, WTF::HashTraits<WebCore::DocumentLoader*> > const&) STDERR: 5 0x7f52434615ab WebCore::ApplicationCacheGroup::postListenerTask(WebCore::ApplicationCacheHost::EventID, WTF::HashSet<WebCore::DocumentLoader*, WTF::PtrHash<WebCore::DocumentLoader*>, WTF::HashTraits<WebCore::DocumentLoader*> > const&) STDERR: 6 0x7f524345f70d WebCore::ApplicationCacheGroup::didFinishLoadingManifest() STDERR: 7 0x7f524345e4d1 WebCore::ApplicationCacheGroup::didFinishLoading(WebCore::ResourceHandle*, double) STDERR: 8 0x7f5243f76a1c STDERR: 9 0x7f523bb78765 STDERR: 10 0x7f523bb8d8cd g_simple_async_result_complete STDERR: 11 0x7f523bb8d9fc STDERR: 12 0x7f523bebfe53 g_main_context_dispatch STDERR: 13 0x7f524034323e STDERR: 14 0x7f524033d7b1 STDERR: 15 0x7f524033e245 STDERR: 16 0x7f524033e547 ecore_main_loop_begin STDERR: 17 0x47a82d STDERR: 18 0x47aa0b STDERR: 19 0x47b049 main STDERR: 20 0x7f523e9ed76d __libc_start_main STDERR: 21 0x468349 ------- crash log for DumpRenderTree (pid 6264): STDOUT: <empty> STDERR: ASSERTION FAILED: m_downloadingPendingMasterResourceLoadersCount > 0 STDERR: /home/buildslave-1/webkit-buildslave/efl-linux-64-debug/build/Source/WebCore/loader/appcache/ApplicationCacheGroup.cpp(275) : void WebCore::ApplicationCacheGroup::finishedLoadingMainResource(WebCore::DocumentLoader*) STDERR: 1 0x7f88e3be2209 WebCore::ApplicationCacheGroup::finishedLoadingMainResource(WebCore::DocumentLoader*) STDERR: 2 0x7f88e3be6cdd WebCore::ApplicationCacheGroup::deliverDelayedMainResources() STDERR: 3 0x7f88e3be5c63 WebCore::ApplicationCacheGroup::cacheUpdateFailed() STDERR: 4 0x7f88e3be2dff WebCore::ApplicationCacheGroup::stopLoadingInFrame(WebCore::Frame*) STDERR: 5 0x7f88e3bee020 WebCore::ApplicationCacheHost::stopLoadingInFrame(WebCore::Frame*) STDERR: 6 0x7f88e3b7cfe6 WebCore::DocumentLoader::stopLoading() STDERR: 7 0x7f88e3ba1659 WebCore::FrameLoader::stopAllLoaders(WebCore::ClearProvisionalItemPolicy) STDERR: 8 0x7f88e3ba4d2b WebCore::FrameLoader::frameDetached() STDERR: 9 0x7f88e3997d7c WebCore::HTMLFrameOwnerElement::disconnectContentFrame() STDERR: 10 0x7f88e3759c78 WebCore::ChildFrameDisconnector::Target::disconnect() STDERR: 11 0x7f88e3754cf4 WebCore::ChildFrameDisconnector::disconnect() STDERR: 12 0x7f88e3750f03 STDERR: 13 0x7f88e3751241 WebCore::ContainerNode::removeChild(WebCore::Node*, int&) STDERR: 14 0x7f88e3750abd WebCore::ContainerNode::replaceChild(WTF::PassRefPtr<WebCore::Node>, WebCore::Node*, int&, bool) STDERR: 15 0x7f88e381aed5 WebCore::Node::replaceChild(WTF::PassRefPtr<WebCore::Node>, WebCore::Node*, int&, bool) STDERR: 16 0x7f88e4285d93 WebCore::JSNode::replaceChild(JSC::ExecState*) STDERR: 17 0x7f88e43ae025 WebCore::jsNodePrototypeFunctionReplaceChild(JSC::ExecState*) STDERR: 18 0x7f889564d265 736600 12 bw80.lee 2012-10-08 02:48:37 -0700 Sorry for the regression and thanks for checking and rolling out. I'm checking the crash issue, and will update. 736610 13 bw80.lee 2012-10-08 03:32:22 -0700 (In reply to comment #12) > Sorry for the regression and thanks for checking and rolling out. > I'm checking the crash issue, and will update. ecore_main_loop_thread_safe_call_async() has a logic that it can call the callback function synchronously in the main thread. (If current thread is main thread, ecore_main_loop_thread_safe_call_async() will call the callback function directly.) I sent a mail to the EFL maintainer whether this is a bug or not. If this cannot be fixed, ecore_main_loop_thread_safe_call_async() cannot use for the wakeup purpose. 736638 14 bw80.lee 2012-10-08 05:45:37 -0700 (In reply to comment #13) > (In reply to comment #12) > > Sorry for the regression and thanks for checking and rolling out. > > I'm checking the crash issue, and will update. > > ecore_main_loop_thread_safe_call_async() has a logic that it can call the callback function synchronously in the main thread. > (If current thread is main thread, ecore_main_loop_thread_safe_call_async() will call the callback function directly.) > > I sent a mail to the EFL maintainer whether this is a bug or not. > If this cannot be fixed, ecore_main_loop_thread_safe_call_async() cannot use for the wakeup purpose. I received answer that the function was designed like the above. (in the main thread, it calls a callback function directly) According to the reply, it is recommended to use ecore idler or some other mechanism like ecore event. But using other mechanism can make some timing issue. (caused by a dispatching order of loop items (timer, pipe, idler...) in ecore main loop) Using ecore_pipe_write() will be the best way not to make side effects. To prevent lockup issue on pipe buffer full status, RunLoop needs additional check logic to prevent redundant pipe write. 167369 2012-10-05 12:47:17 -0700 2012-10-08 00:20:12 -0700 Patch bug-98505-20121006044625.patch text/plain 4928 bw80.lee U3VidmVyc2lvbiBSZXZpc2lvbjogMTMwNTIyCmRpZmYgLS1naXQgYS9Tb3VyY2UvV1RGL0NoYW5n ZUxvZyBiL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCmluZGV4IGIwMDVlMzFiNGJkMTRmMzJmNDA4NDVh ZGZmM2U0ZTJiOTZlMGZmNzMuLmUzNzYzOTE2ZWZhMjZiNTk5NzAxZjE1ZWY3ZTRiOWNlZWE4YmFl NWYgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9XVEYvQ2hh bmdlTG9nCkBAIC0xLDMgKzEsMjIgQEAKKzIwMTItMTAtMDUgIEJ5dW5nd29vIExlZSAgPGJ3ODAu bGVlQHNhbXN1bmcuY29tPgorCisgICAgICAgIFtFRkxdIFVzZSBlY29yZV9tYWluX2xvb3BfdGhy ZWFkX3NhZmVfY2FsbF9hc3luYygpIHRvIHdha2V1cCBtYWluIGxvb3AuCisgICAgICAgIGh0dHBz Oi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD05ODUwNQorCisgICAgICAgIFJldmll d2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIEluc3RlYWQgb2YgZWNvcmVfcGlwZV93 cml0ZSgpLAorICAgICAgICB1c2UgZWNvcmVfbWFpbl9sb29wX3RocmVhZF9zYWZlX2NhbGxfYXN5 bmMoKSB0byB3YWtldXAgZWNvcmUgbWFpbiBsb29wLgorCisgICAgICAgIEFjY29yZGluZyB0byB0 aGUgRUZMIEFQSSBkb2N1bWVudCwgdGhpcyBmdW5jdGlvbiBpcyBkZXNpZ25lZCB0byBkaXNwYXRj aAorICAgICAgICBhIGZ1bmN0aW9uIG9uIGVjb3JlIG1haW4gbG9vcCBieSBhdm9pZGluZyBkZWFk IGxvY2sgb3IgcmFjZSBjb25kaXRpb24uIAorICAgICAgICBXaXRoIHRoaXMgZnVuY3Rpb24sIHdl YmtpdCBkb2Vzbid0IG5lZWQgdG8gbWFpbnRhaW4gZWNvcmUgcGlwZSBhbHNvLgorCisgICAgICAg ICogd3RmL2VmbC9NYWluVGhyZWFkRWZsLmNwcDoKKyAgICAgICAgKFdURjo6bW9uaXRvckRpc3Bh dGNoRnVuY3Rpb25zKToKKyAgICAgICAgKFdURjo6aW5pdGlhbGl6ZU1haW5UaHJlYWRQbGF0Zm9y bSk6CisgICAgICAgIChXVEY6OnNjaGVkdWxlRGlzcGF0Y2hGdW5jdGlvbnNPbk1haW5UaHJlYWQp OgorCiAyMDEyLTEwLTA1ICBTaW1vbiBQZW5hICA8c3BlbmFAaWdhbGlhLmNvbT4KIAogICAgICAg ICBbR1RLXSBBZGQgc3VwcG9ydCBmb3IgR0J5dGVzIGluIEdSZWZQdHIKZGlmZiAtLWdpdCBhL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZyBiL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwppbmRleCAw ZTI4ZTUzOWMyNGRhZDMzNTFlM2UzYTM4NTQ2ZWE5MTI0OTBlNGY1Li5hMGQ5YmY4ZTJhMTRlYTY4 MTk0NGU5MzIzNjZiZTY5YzZhZWQ4MjI0IDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29yZS9DaGFu Z2VMb2cKKysrIGIvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMjYgQEAKKzIw MTItMTAtMDUgIEJ5dW5nd29vIExlZSAgPGJ3ODAubGVlQHNhbXN1bmcuY29tPgorCisgICAgICAg IFtFRkxdIFVzZSBlY29yZV9tYWluX2xvb3BfdGhyZWFkX3NhZmVfY2FsbF9hc3luYygpIHRvIHdh a2V1cCBtYWluIGxvb3AuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVn LmNnaT9pZD05ODUwNQorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisg ICAgICAgIEluc3RlYWQgb2YgZWNvcmVfcGlwZV93cml0ZSgpLAorICAgICAgICB1c2UgZWNvcmVf bWFpbl9sb29wX3RocmVhZF9zYWZlX2NhbGxfYXN5bmMoKSB0byB3YWtldXAgZWNvcmUgbWFpbiBs b29wLgorCisgICAgICAgIEFjY29yZGluZyB0byB0aGUgRUZMIEFQSSBkb2N1bWVudCwgdGhpcyBm dW5jdGlvbiBpcyBkZXNpZ25lZCB0byBkaXNwYXRjaAorICAgICAgICBhIGZ1bmN0aW9uIG9uIGVj b3JlIG1haW4gbG9vcCBieSBhdm9pZGluZyBkZWFkIGxvY2sgb3IgcmFjZSBjb25kaXRpb24uIAor ICAgICAgICBXaXRoIHRoaXMgZnVuY3Rpb24sIHdlYmtpdCBkb2Vzbid0IG5lZWQgdG8gbWFpbnRh aW4gZWNvcmUgcGlwZSBhbHNvLgorCisgICAgICAgIE5vIG5ldyB0ZXN0cy4gVGhlIGZ1bmN0aW9u IHRvIHdha2V1cCBtYWluIGxvb3AgaXMgY2hhbmdlZC4KKworICAgICAgICAqIHBsYXRmb3JtL1J1 bkxvb3AuaDoKKyAgICAgICAgKFJ1bkxvb3ApOgorICAgICAgICAqIHBsYXRmb3JtL2VmbC9SdW5M b29wRWZsLmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OlJ1bkxvb3A6OlJ1bkxvb3ApOgorICAgICAg ICAoV2ViQ29yZTo6UnVuTG9vcDo6d2FrZVVwRXZlbnQpOgorICAgICAgICAoV2ViQ29yZTo6UnVu TG9vcDo6d2FrZVVwKToKKwogMjAxMi0xMC0wNSAgVnNldm9sb2QgVmxhc292ICA8dnNldmlrQGNo cm9taXVtLm9yZz4KIAogICAgICAgICBVbnJldmlld2VkIGluc3BlY3RvciBmcm9udC1lbmQgY2xv c3VyZSBjb21waWxhaXRvbiBmaXhlcy4KZGlmZiAtLWdpdCBhL1NvdXJjZS9XVEYvd3RmL2VmbC9N YWluVGhyZWFkRWZsLmNwcCBiL1NvdXJjZS9XVEYvd3RmL2VmbC9NYWluVGhyZWFkRWZsLmNwcApp bmRleCA1M2FkY2IyYjFmOWUzNjZiM2M0MTJlOWU4MWQ0NGI1ODcyNWQyNTMxLi4wZGYzYTQxZTVk MDk1ZjA1NWYxZjQzMWEwNjNiOGRjYTc3NWJlZGFiIDEwMDY0NAotLS0gYS9Tb3VyY2UvV1RGL3d0 Zi9lZmwvTWFpblRocmVhZEVmbC5jcHAKKysrIGIvU291cmNlL1dURi93dGYvZWZsL01haW5UaHJl YWRFZmwuY3BwCkBAIC00MSwyNSArNDEsMTggQEAKIAogbmFtZXNwYWNlIFdURiB7CiAKLXN0YXRp YyBPd25QdHI8RWNvcmVfUGlwZT4mIHBpcGVPYmplY3QoKQotewotICAgIERFRklORV9TVEFUSUNf TE9DQUwoT3duUHRyPEVjb3JlX1BpcGU+LCBwaXBlT2JqZWN0LCAoKSk7Ci0gICAgcmV0dXJuIHBp cGVPYmplY3Q7Ci19Ci0KLXN0YXRpYyB2b2lkIG1vbml0b3JEaXNwYXRjaEZ1bmN0aW9ucyh2b2lk Kiwgdm9pZCosIHVuc2lnbmVkIGludCkKK3N0YXRpYyB2b2lkIG1vbml0b3JEaXNwYXRjaEZ1bmN0 aW9ucyh2b2lkKikKIHsKICAgICBkaXNwYXRjaEZ1bmN0aW9uc0Zyb21NYWluVGhyZWFkKCk7CiB9 CiAKIHZvaWQgaW5pdGlhbGl6ZU1haW5UaHJlYWRQbGF0Zm9ybSgpCiB7Ci0gICAgcGlwZU9iamVj dCgpID0gYWRvcHRQdHIoZWNvcmVfcGlwZV9hZGQobW9uaXRvckRpc3BhdGNoRnVuY3Rpb25zLCAw KSk7CiB9CiAKIHZvaWQgc2NoZWR1bGVEaXNwYXRjaEZ1bmN0aW9uc09uTWFpblRocmVhZCgpCiB7 Ci0gICAgZWNvcmVfcGlwZV93cml0ZShwaXBlT2JqZWN0KCkuZ2V0KCksICIiLCAwKTsKKyAgICBl Y29yZV9tYWluX2xvb3BfdGhyZWFkX3NhZmVfY2FsbF9hc3luYyhtb25pdG9yRGlzcGF0Y2hGdW5j dGlvbnMsIDApOwogfQogCiB9CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9wbGF0Zm9ybS9S dW5Mb29wLmggYi9Tb3VyY2UvV2ViQ29yZS9wbGF0Zm9ybS9SdW5Mb29wLmgKaW5kZXggY2U5ODQ1 ZTJhNTc1OTIxYTlmMTVmZTU1ZjliMWNiZWU4YWY0MWE4Ni4uMTU5Zjk1NWQ2YWQ4MzZmZTE5MDVk ZWQ2MmI5MjhiMWNmMjZlYWVhMSAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvcGxhdGZvcm0v UnVuTG9vcC5oCisrKyBiL1NvdXJjZS9XZWJDb3JlL3BsYXRmb3JtL1J1bkxvb3AuaApAQCAtMTY3 LDggKzE2Nyw3IEBAIHByaXZhdGU6CiAgICAgVmVjdG9yPEdSZWZQdHI8R01haW5Mb29wPiA+IG1f cnVuTG9vcE1haW5Mb29wczsKICNlbGlmIFBMQVRGT1JNKEVGTCkKICAgICBib29sIG1faW5pdEVm bDsKLSAgICBPd25QdHI8RWNvcmVfUGlwZT4gbV9waXBlOwotICAgIHN0YXRpYyB2b2lkIHdha2VV cEV2ZW50KHZvaWQqIGRhdGEsIHZvaWQqLCB1bnNpZ25lZCBpbnQpOworICAgIHN0YXRpYyB2b2lk IHdha2VVcEV2ZW50KHZvaWQqIGRhdGEpOwogI2VuZGlmCiB9OwogCmRpZmYgLS1naXQgYS9Tb3Vy Y2UvV2ViQ29yZS9wbGF0Zm9ybS9lZmwvUnVuTG9vcEVmbC5jcHAgYi9Tb3VyY2UvV2ViQ29yZS9w bGF0Zm9ybS9lZmwvUnVuTG9vcEVmbC5jcHAKaW5kZXggZjI5OWQ4ZWNmMjY4MjQwYmRkMjY2NmJh NTJhNDRiY2NiYTE5ZTIyZC4uYmU2NDI4OWMwNTU5MWE4MWM1ODkxM2JhZTM4NjQzYjc4OTkzNGVi MiAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vZWZsL1J1bkxvb3BFZmwuY3Bw CisrKyBiL1NvdXJjZS9XZWJDb3JlL3BsYXRmb3JtL2VmbC9SdW5Mb29wRWZsLmNwcApAQCAtMzQs OSArMzQsNiBAQAogI2luY2x1ZGUgPHd0Zi9Pd25QdHIuaD4KICNpbmNsdWRlIDx3dGYvUGFzc093 blB0ci5oPgogCi1zdGF0aWMgY29uc3QgaW50IGVjb3JlUGlwZU1lc3NhZ2VTaXplID0gMTsKLXN0 YXRpYyBjb25zdCBjaGFyIHdha3VwRWNvcmVQaXBlTWVzc2FnZVtdID0gIlciOwotCiBuYW1lc3Bh Y2UgV2ViQ29yZSB7CiAKIFJ1bkxvb3A6OlJ1bkxvb3AoKQpAQCAtNjIsNyArNTksNiBAQCBSdW5M b29wOjpSdW5Mb29wKCkKICAgICAgICAgZ290byBlcnJvckVkamU7CiAgICAgfQogCi0gICAgbV9w aXBlID0gYWRvcHRQdHIoZWNvcmVfcGlwZV9hZGQod2FrZVVwRXZlbnQsIHRoaXMpKTsKICAgICBt X2luaXRFZmwgPSB0cnVlOwogCiAgICAgcmV0dXJuOwpAQCAtOTUsMTQgKzkxLDE0IEBAIHZvaWQg UnVuTG9vcDo6c3RvcCgpCiAgICAgZWNvcmVfbWFpbl9sb29wX3F1aXQoKTsKIH0KIAotdm9pZCBS dW5Mb29wOjp3YWtlVXBFdmVudCh2b2lkKiBkYXRhLCB2b2lkKiwgdW5zaWduZWQgaW50KQordm9p ZCBSdW5Mb29wOjp3YWtlVXBFdmVudCh2b2lkKiBkYXRhKQogewogICAgIHN0YXRpY19jYXN0PFJ1 bkxvb3AqPihkYXRhKS0+cGVyZm9ybVdvcmsoKTsKIH0KIAogdm9pZCBSdW5Mb29wOjp3YWtlVXAo KQogewotICAgIGVjb3JlX3BpcGVfd3JpdGUobV9waXBlLmdldCgpLCB3YWt1cEVjb3JlUGlwZU1l c3NhZ2UsIGVjb3JlUGlwZU1lc3NhZ2VTaXplKTsKKyAgICBlY29yZV9tYWluX2xvb3BfdGhyZWFk X3NhZmVfY2FsbF9hc3luYyh3YWtlVXBFdmVudCwgdGhpcyk7CiB9CiAKIFJ1bkxvb3A6OlRpbWVy QmFzZTo6VGltZXJCYXNlKFJ1bkxvb3AqKQo=