POSIX: Don't allow onunload handlers to hang a renderer forever.

chrome/renderer/render_thread.cc

Index: chrome/renderer/render_thread.cc
diff --git a/chrome/renderer/render_thread.cc b/chrome/renderer/render_thread.cc
index e372c2b3a5806b755e9cda2bc001e548998f81ff..0d14b09f0f35a2e03808a798b06f66ab3167ed67 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 {

[Evan Stade, 2009/04/30 21:40:43]

lol at this name

+  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,10 @@ void RenderThread::Init() {
   WebAppCacheContext::SetFactory(CreateAppCacheContextForRenderer);
   devtools_agent_filter_ = new DevToolsAgentFilter();
   AddFilter(devtools_agent_filter_.get());
+
+#if defined(OS_POSIX)
+  AddFilter(new SuicideOnChannelErrorFilter);
+#endif
 }
 
 void RenderThread::CleanUp() {