Enable LeakTracker on release builds.
This is intended to be temporary, so we can get data from the dev channel on why URLRequest objects are leaking at shutdown.
WARNING: it may cause a slight slowdown on page cycler.
Also as part of this change, I switched the order that we check URLFetcher / URLRequest.
This is simply so that if both URLFetcher and URLRequest have leaked, we will report the URLFetcher leak rather than the URLRequest leak.
BUG=http://crbug.com/21199, http://crbug.com/18372
Review URL: http://codereview.chromium.org/217005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26765 0039d316-1c4b-4281-b951-d872f2087c98
diff --git a/chrome/browser/browser_process_impl.cc b/chrome/browser/browser_process_impl.cc
index 68a3dc3..f971e807 100644
--- a/chrome/browser/browser_process_impl.cc
+++ b/chrome/browser/browser_process_impl.cc
@@ -106,8 +106,17 @@
protected:
virtual void CleanUp() {
// URLFetcher and URLRequest instances must NOT outlive the IO thread.
- base::LeakTracker<URLRequest>::CheckForLeaks();
+ //
+ // Strictly speaking, URLFetcher's CheckForLeaks() should be done on the
+ // UI thread. However, since there _shouldn't_ be any instances left
+ // at this point, it shouldn't be a race.
+ //
+ // We check URLFetcher first, since if it has leaked then an associated
+ // URLRequest will also have leaked. However it is more useful to
+ // crash showing the callstack of URLFetcher's allocation than its
+ // URLRequest member.
base::LeakTracker<URLFetcher>::CheckForLeaks();
+ base::LeakTracker<URLRequest>::CheckForLeaks();
BrowserProcessSubThread::CleanUp();
}
