summaryrefslogtreecommitdiffstats
path: root/chrome
diff options
context:
space:
mode:
authoragl@chromium.org <agl@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-05-01 00:29:29 +0000
committeragl@chromium.org <agl@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-05-01 00:29:29 +0000
commit36ecd4c22166a82091e86b6a295f86225fd022e0 (patch)
tree436c93fe646533483990be14dc4f802cd53c7309 /chrome
parent19063d3d42bedf9be6197ec575ece628129afc64 (diff)
downloadchromium_src-36ecd4c22166a82091e86b6a295f86225fd022e0.zip
chromium_src-36ecd4c22166a82091e86b6a295f86225fd022e0.tar.gz
chromium_src-36ecd4c22166a82091e86b6a295f86225fd022e0.tar.bz2
POSIX: Don't allow onunload handlers to hang a renderer forever.
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@15025 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome')
-rw-r--r--chrome/common/ipc_channel_proxy.cc3
-rw-r--r--chrome/common/ipc_channel_proxy.h4
-rw-r--r--chrome/renderer/render_thread.cc27
-rw-r--r--chrome/renderer/render_thread.h5
4 files changed, 39 insertions, 0 deletions
diff --git a/chrome/common/ipc_channel_proxy.cc b/chrome/common/ipc_channel_proxy.cc
index 47aa89b..c43f01f 100644
--- a/chrome/common/ipc_channel_proxy.cc
+++ b/chrome/common/ipc_channel_proxy.cc
@@ -81,6 +81,9 @@ void ChannelProxy::Context::OnChannelConnected(int32 peer_pid) {
// Called on the IPC::Channel thread
void ChannelProxy::Context::OnChannelError() {
+ for (size_t i = 0; i < filters_.size(); ++i)
+ filters_[i]->OnChannelError();
+
// See above comment about using listener_message_loop_ here.
listener_message_loop_->PostTask(FROM_HERE, NewRunnableMethod(
this, &Context::OnDispatchError));
diff --git a/chrome/common/ipc_channel_proxy.h b/chrome/common/ipc_channel_proxy.h
index 2263ea6..42cb865 100644
--- a/chrome/common/ipc_channel_proxy.h
+++ b/chrome/common/ipc_channel_proxy.h
@@ -64,6 +64,10 @@ class ChannelProxy : public Message::Sender {
// have received the internal Hello message from the peer.
virtual void OnChannelConnected(int32 peer_pid) {}
+ // Called when there is an error on the channel, typically that the channel
+ // has been closed.
+ virtual void OnChannelError() {}
+
// Called to inform the filter that the IPC channel will be destroyed.
// OnFilterRemoved is called immediately after this.
virtual void OnChannelClosing() {}
diff --git a/chrome/renderer/render_thread.cc b/chrome/renderer/render_thread.cc
index e372c2b..da8cc11 100644
--- a/chrome/renderer/render_thread.cc
+++ b/chrome/renderer/render_thread.cc
@@ -102,6 +102,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
@@ -123,6 +145,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() {
diff --git a/chrome/renderer/render_thread.h b/chrome/renderer/render_thread.h
index d50fd96..44e20e9 100644
--- a/chrome/renderer/render_thread.h
+++ b/chrome/renderer/render_thread.h
@@ -160,6 +160,11 @@ class RenderThread : public RenderThreadBase,
scoped_refptr<DevToolsAgentFilter> devtools_agent_filter_;
+#if defined(OS_POSIX)
+ scoped_refptr<IPC::ChannelProxy::MessageFilter>
+ suicide_on_channel_error_filter_;
+#endif
+
// If true, then a GetPlugins call is allowed to rescan the disk.
bool plugin_refresh_allowed_;