From 5fa1c542119e3976128c1de3692262292d105ffe Mon Sep 17 00:00:00 2001 From: "agl@chromium.org" Date: Tue, 5 May 2009 20:36:07 +0000 Subject: POSIX: Don't allow onunload handlers to hang a renderer forever. (Reland of r15025 which was reverted in r15095. |exit| has been changed to |_exit| to save running the onexit handlers while another thread is still in V8 code.) On POSIX 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 processes (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. On Windows we don't have this issue because all the processes are in a job so when the parent dies, all the children are killed too. http://codereview.chromium.org/100222 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15332 0039d316-1c4b-4281-b951-d872f2087c98 --- chrome/renderer/render_thread.cc | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) (limited to 'chrome/renderer/render_thread.cc') diff --git a/chrome/renderer/render_thread.cc b/chrome/renderer/render_thread.cc index afe3f38..7bf055e 100644 --- a/chrome/renderer/render_thread.cc +++ b/chrome/renderer/render_thread.cc @@ -103,6 +103,28 @@ static WebAppCacheContext* CreateAppCacheContextForRenderer() { return new AppCacheContextImpl(RenderThread::current()); } +#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 + void RenderThread::Init() { #if defined(OS_WIN) // If you are running plugins in this thread you need COM active but in @@ -124,6 +146,11 @@ void RenderThread::Init() { WebAppCacheContext::SetFactory(CreateAppCacheContextForRenderer); devtools_agent_filter_ = new DevToolsAgentFilter(); AddFilter(devtools_agent_filter_.get()); + +#if defined(OS_POSIX) + suicide_on_channel_error_filter_ = new SuicideOnChannelErrorFilter; + AddFilter(suicide_on_channel_error_filter_.get()); +#endif } void RenderThread::CleanUp() { -- cgit v1.1