Add checks to DEBUG mode that no instance of URLRequest or URLFetcher survives the destruction of the IO thread.

This checking is done by introducing a new helper class to base called LeakTracker. Classes that you want to check for leaks just need to extend LeakTracker.

The reason I am picking on URLFetcher / URLRequest, is I believe we have a bug that is making an instance of URLFetcher to outlive the IO thread.

This causes various sorts of badness.

For example:
If URLFetcher survives the IO thread, then URLRequestContext remains referenced and therefore also survives IO thread. In turn HostResolverImpl survives the IO thread, so any outstanding resolve requests are NOT cancelled before the IO thread is decomissioned. So now, when the worker thread doing the DNS resolve finally finishes (assuming it finishes before the rogue URLRequest is destroyed), it post the result to a defunct message loop. KAB00m! (http://crbug.com/15513)

Moreover, I believe we hit this same problem sporadically in AutomationProxyTest.AutocompleteGetSetText -- the test is flaky on the buildbots, and I've seen DCHECKs which suggest it is related to this issue.

BUG=http://crbug.com/18372
Review URL: http://codereview.chromium.org/160447

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23084 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 3 insertions, 0 deletions

diff --git a/chrome/browser/net/url_fetcher.h b/chrome/browser/net/url_fetcher.h
index 0ed4715..6b1c87c 100644
--- a/chrome/browser/net/url_fetcher.h
+++ b/chrome/browser/net/url_fetcher.h
@@ -10,6 +10,7 @@
 #ifndef CHROME_BROWSER_URL_FETCHER_H_
 #define CHROME_BROWSER_URL_FETCHER_H_
 
+#include "base/leak_tracker.h"
 #include "base/message_loop.h"
 #include "base/ref_counted.h"
 #include "chrome/browser/net/url_fetcher_protect.h"
@@ -163,6 +164,8 @@ class URLFetcher {
 
   static Factory* factory_;
 
+  base::LeakTracker<URLFetcher> leak_tracker_;
+
   DISALLOW_EVIL_CONSTRUCTORS(URLFetcher);
 };