Don't create a new profile when cleaning up stale ephemeral profiles.

chrome/browser/chrome_browser_main.cc

Index: chrome/browser/chrome_browser_main.cc
diff --git a/chrome/browser/chrome_browser_main.cc b/chrome/browser/chrome_browser_main.cc
index f6b138f5dfa30fefcfe83ad782a8547091fd9a34..65bd9843246fe1da484aaacad461bb07bf0cf343 100644
--- a/chrome/browser/chrome_browser_main.cc
+++ b/chrome/browser/chrome_browser_main.cc
@@ -234,6 +234,14 @@ using content::BrowserThread;
 
 namespace {
 
+#if !defined(OS_ANDROID)
+// Asserts in debug builds that we don't create a new profile when cleaning up
+// stale ephemeral profiles.
+void DidCreateProfile(Profile* profile, Profile::CreateStatus status) {
+  NOTREACHED();
+}
+#endif  // !defined(OS_ANDROID)
+
 // This function provides some ways to test crash and assertion handling
 // behavior of the program.
 void HandleTestParameters(const base::CommandLine& command_line) {
@@ -1092,15 +1100,10 @@ void ChromeBrowserMainParts::PreProfileInit() {
       profiles_to_delete.push_back(profile_cache.GetPathOfProfileAtIndex(i));
   }
 
-  if (profiles_to_delete.size()) {
-    for (size_t i = 0; i < profiles_to_delete.size(); ++i) {
-      profile_manager->ScheduleProfileForDeletion(
-          profiles_to_delete[i], ProfileManager::CreateCallback());
-    }
-    // Clean up stale profiles immediately after browser start.
-    BrowserThread::PostTask(

[Mike Lerman, 2015/05/05 13:44:45]

Why is CleanUpStaleProfiles no longer necessary? Is that because the
ProfileManager now calls NukeFromDisk for unloaded Profile*'s?

[Bernhard Bauer, 2015/05/05 14:33:21]

It already did that before (in FinishDeletingProfile), so I think this call was
simply unnecessary (but no one noticed, because deleting a directory is
idempotent).

-        BrowserThread::FILE, FROM_HERE,
-        base::Bind(&ProfileManager::CleanUpStaleProfiles, profiles_to_delete));
+  for (size_t i = 0; i < profiles_to_delete.size(); ++i) {

[Mike Lerman, 2015/05/05 13:44:45]

Can you put a comment above profiles_to_delete that we still need two loops,
rather than compressing this into one, because ScheduleProfileForDeletion will
muck around with the indices of the profiles in the ProfileInfoCache?

If only the ProfileInfoCache had a method like std::vector<std::string>
GetAllProfilePaths() const.

[Bernhard Bauer, 2015/05/05 14:33:21]

Done.

+    profile_manager->ScheduleProfileForDeletion(
+        profiles_to_delete[i], true /* suppress_profile_creation */,
+        base::Bind(&DidCreateProfile));

[Mike Lerman, 2015/05/05 13:44:45]

I think you can just put a ProfileManager::CreateCallback(), and trust that the
boolean supress_profile_creation does its job.

[Bernhard Bauer, 2015/05/05 14:33:21]

Done.

   }
 #endif  // !defined(OS_ANDROID)