Split up leak detector into two stages for better leak reporting.

content/public/test/render_view_test.cc

Index: content/public/test/render_view_test.cc
diff --git a/content/public/test/render_view_test.cc b/content/public/test/render_view_test.cc
index 9d546d8f7afbf8a1168351c9cbf096715aa529cb..3b28c02f556626c50fe7daacd85dd069dd587935 100644
--- a/content/public/test/render_view_test.cc
+++ b/content/public/test/render_view_test.cc
@@ -293,6 +293,7 @@ void RenderViewTest::TearDown() {
   scoped_ptr<blink::WebLeakDetector> leak_detector =
       make_scoped_ptr(blink::WebLeakDetector::create(this));
 
+  leak_detector->delayFinalGarbageCollection();

[haraken, 2015/11/24 23:54:51]

Would you elaborate on why we need to delay the GC?

[sof, 2015/11/25 06:20:50]

Clearing view_ below will trigger a close() on the frame _and_ its frame tree,
which will release (self-)Persistent<>s, allowing objects to be swept at the
next GC.

If we don't ensure/guarantee that any of the leak detector's GCs run after that
close() has gone ahead, we will see frame leaks reported.

[haraken, 2015/11/25 07:39:38]

Doesn't it mean just that we need to trigger another GC after clearing view_?
(i.e., don't need to delay the GC; we can just trigger another GC after clearing
view_.)

I'd prefer not introducing a complicated logic like delaying.

   leak_detector->collectGarbageAndGetDOMCounts(GetMainFrame());
 
   view_ = NULL;
@@ -308,6 +309,8 @@ void RenderViewTest::TearDown() {
   autorelease_pool_.reset(NULL);
 #endif
 
+  leak_detector->collectFinalGarbage();
+
   blink_platform_impl_.Shutdown();
   blink::shutdown();