Wait until a new profile has been created before deleting the active profile.

chrome/browser/app_controller_mac.mm

Index: chrome/browser/app_controller_mac.mm
diff --git a/chrome/browser/app_controller_mac.mm b/chrome/browser/app_controller_mac.mm
index 01feef4dbf749ac126f1cc56fec71712c3104fd7..437637f979528887392c5194ebd7ffbe266570d2 100644
--- a/chrome/browser/app_controller_mac.mm
+++ b/chrome/browser/app_controller_mac.mm
@@ -897,7 +897,7 @@ class AppControllerProfileObserver : public ProfileInfoCacheObserver {
   // already loaded a new one, so the pointer needs to be updated;
   // otherwise we will try to start up a browser window with a pointer
   // to the old profile.
-  if (lastProfile_ && profilePath == lastProfile_->GetPath())
+  if (!lastProfile_ || profilePath == lastProfile_->GetPath())

[noms (inactive), 2015/02/24 19:37:37]

i'm confused. is this a real change or a test? :(

[Bernhard Bauer, 2015/02/24 22:28:24]

Allow me to explain: |lastProfile_| starts out as null and is set when a browser
window becomes active, or the application is brought to the front, which is
guaranteed to happen during regular browser startup. In a browser_test, the
application is never brought to front though (see
https://groups.google.com/a/chromium.org/d/topic/chromium-dev/_QA9sH_UEnw/dis...),
so this would stay null. Doing this change will make sure that
GetLastUsedProfile() is called in the next line, which is what CHECKS if an
uninitialized profile is returned. The effect is that this tests the code path
that is failing in the linked bug.

[Mike Lerman, 2015/02/25 18:32:10]

Makes sense - can you modify the above comment block to reflect this? 

[Bernhard Bauer, 2015/02/25 18:42:34]

Done.

     lastProfile_ = g_browser_process->profile_manager()->GetLastUsedProfile();
 
   auto it = profileBookmarkMenuBridgeMap_.find(profilePath);