Fix a memory leak of the renderer thread objects in single process mode....

chrome/browser/renderer_host/browser_render_process_host.cc

 // Copyright (c) 2006-2008 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // Represents the browser side of the browser <--> renderer communication
 // channel. There will be one RenderProcessHost per renderer process.
 
 #include "chrome/browser/renderer_host/browser_render_process_host.h"
 
 #include "build/build_config.h"
 
 #include <algorithm>
 
 #include "base/command_line.h"
 #include "base/debug_util.h"
+#include "base/linked_ptr.h"
 #include "base/logging.h"
 #include "base/path_service.h"
 #include "base/process_util.h"
 #include "base/rand_util.h"
 #include "base/shared_memory.h"
+#include "base/singleton.h"
 #include "base/string_util.h"
 #include "base/thread.h"
 #include "chrome/app/result_codes.h"
 #include "chrome/browser/browser_process.h"
 #include "chrome/browser/cache_manager_host.h"
 #include "chrome/browser/extensions/user_script_master.h"
 #include "chrome/browser/history/history.h"
 #include "chrome/browser/profile.h"
 #include "chrome/browser/renderer_host/render_widget_helper.h"
 #include "chrome/browser/renderer_host/renderer_security_policy.h"
@@ skipping 288 matching lines @@
     // Crank up a thread and run the initialization there.  With the way that
     // messages flow between the browser and renderer, this thread is required
     // to prevent a deadlock in single-process mode.  When using multiple
     // processes, the primordial thread in the renderer process has a message
     // loop which is used for sending messages asynchronously to the io thread
     // in the browser process.  If we don't create this thread, then the
     // RenderThread is both responsible for rendering and also for
     // communicating IO.  This can lead to deadlocks where the RenderThread is
     // waiting for the IO to complete, while the browsermain is trying to pass
     // an event to the RenderThread.
-    //
-    // TODO: We should consider how to better cleanup threads on exit.
-    base::Thread *render_thread = new RendererMainThread(channel_id);
+    RendererMainThread* render_thread = new RendererMainThread(channel_id);
+
+    // This singleton keeps track of our pointers to avoid a leak.
+    Singleton<std::vector<linked_ptr<RendererMainThread> > >::get()->push_back(
+        linked_ptr<RendererMainThread>(render_thread));
+
     base::Thread::Options options;
     options.message_loop_type = MessageLoop::TYPE_IO;
     render_thread->StartWithOptions(options);
   } else {
     if (g_browser_process->local_state() &&
         g_browser_process->local_state()->GetBoolean(
             prefs::kStartRenderersManually)) {
       RunStartRenderersManuallyDialog(cmd_line);
     } else {
 #if defined(OS_WIN)
@@ skipping 472 matching lines @@
   // child processes determine the pid of the parent.
   // Build the channel ID.  This is composed of a unique identifier for the
   // parent browser process, an identifier for the renderer/plugin instance,
   // and a random component. We use a random component so that a hacked child
   // process can't cause denial of service by causing future named pipe creation
   // to fail.
   return StringPrintf(L"%d.%x.%d",
                       base::GetCurrentProcId(), instance,
                       base::RandInt(0, std::numeric_limits<int>::max()));
 }