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

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