From 5be1cdf6de496491f78251328205ef2b13b28cc1 Mon Sep 17 00:00:00 2001 From: "jam@chromium.org" Date: Tue, 10 Apr 2012 00:44:58 +0000 Subject: Revert 131429 because content_unittests is early exiting- Moved SuicideOnChannelErrorFilter to content. BUG=none TEST=trybots Review URL: http://codereview.chromium.org/10027027 TBR=asharif@chromium.org Review URL: https://chromiumcodereview.appspot.com/9960057 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@131506 0039d316-1c4b-4281-b951-d872f2087c98 --- chrome/renderer/chrome_render_process_observer.cc | 27 ++++++++++++++++++++++ content/renderer/render_thread_impl.cc | 28 ----------------------- 2 files changed, 27 insertions(+), 28 deletions(-) diff --git a/chrome/renderer/chrome_render_process_observer.cc b/chrome/renderer/chrome_render_process_observer.cc index 833b84bb..293d50b 100644 --- a/chrome/renderer/chrome_render_process_observer.cc +++ b/chrome/renderer/chrome_render_process_observer.cc @@ -146,6 +146,29 @@ DWORD WINAPI GetFontDataPatch(HDC hdc, } #endif // OS_WIN +#if defined(OS_POSIX) +class SuicideOnChannelErrorFilter : public IPC::ChannelProxy::MessageFilter { + void OnChannelError() { + // On POSIX, at least, one can install an unload handler which loops + // forever and leave behind a renderer process which eats 100% CPU forever. + // + // This is because the terminate signals (ViewMsg_ShouldClose and the error + // from the IPC channel) are routed to the main message loop but never + // processed (because that message loop is stuck in V8). + // + // One could make the browser SIGKILL the renderers, but that leaves open a + // large window where a browser failure (or a user, manually terminating + // the browser because "it's stuck") will leave behind a process eating all + // the CPU. + // + // So, we install a filter on the channel so that we can process this event + // here and kill the process. + + _exit(0); + } +}; +#endif // OS_POSIX + } // namespace bool ChromeRenderProcessObserver::is_incognito_process_ = false; @@ -167,6 +190,10 @@ ChromeRenderProcessObserver::ChromeRenderProcessObserver( resource_delegate_.reset(new RendererResourceDelegate()); thread->SetResourceDispatcherDelegate(resource_delegate_.get()); +#if defined(OS_POSIX) + thread->AddFilter(new SuicideOnChannelErrorFilter()); +#endif + // Configure modules that need access to resources. net::NetModule::SetResourceProvider(chrome_common_net::NetResourceProvider); diff --git a/content/renderer/render_thread_impl.cc b/content/renderer/render_thread_impl.cc index 9acb852..320c820 100644 --- a/content/renderer/render_thread_impl.cc +++ b/content/renderer/render_thread_impl.cc @@ -179,30 +179,6 @@ RenderThreadImpl::RenderThreadImpl(const std::string& channel_name) Init(); } -#if defined(OS_POSIX) -class SuicideOnChannelErrorFilter : public IPC::ChannelProxy::MessageFilter { - void OnChannelError() { - // On POSIX, at least, one can install an unload handler which loops - // forever and leave behind a renderer process which eats 100% CPU forever. - // - // This is because the terminate signals (ViewMsg_ShouldClose and the error - // from the IPC channel) are routed to the main message loop but never - // processed (because that message loop is stuck in V8). - // - // One could make the browser SIGKILL the renderers, but that leaves open a - // large window where a browser failure (or a user, manually terminating - // the browser because "it's stuck") will leave behind a process eating all - // the CPU. - // - // So, we install a filter on the channel so that we can process this event - // here and kill the process. - - _exit(0); - } -}; -#endif // OS_POSIX - - void RenderThreadImpl::Init() { TRACE_EVENT_BEGIN_ETW("RenderThreadImpl::Init", 0, ""); @@ -256,10 +232,6 @@ void RenderThreadImpl::Init() { AddFilter(new IndexedDBMessageFilter); -#if defined(OS_POSIX) - AddFilter(new SuicideOnChannelErrorFilter()); -#endif - content::GetContentClient()->renderer()->RenderThreadStarted(); // Note that under Linux, the media library will normally already have -- cgit v1.1