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

components/search_engines/template_url_service.cc

Index: components/search_engines/template_url_service.cc
diff --git a/components/search_engines/template_url_service.cc b/components/search_engines/template_url_service.cc
index 923fa557248e5806dda48f64eb23fcf2964009d9..935aa5fefa1c2ad85e801e256926f0e862ce5506 100644
--- a/components/search_engines/template_url_service.cc
+++ b/components/search_engines/template_url_service.cc
@@ -806,6 +806,11 @@ void TemplateURLService::Shutdown() {
     web_data_service_->CancelRequest(load_handle_);
   }
   web_data_service_ = NULL;
+
+  // Notify observers so they can unregister themselves.
+  // TODO(bauerb): Observers shouldn't outlive this class; see
+  // https://crbug.com/483528.
+  on_loaded_callbacks_.Notify();

[Peter Kasting, 2015/05/11 22:15:06]

This seems like a strange fix.  We're calling observers with an ostensible "TURL
service has loaded" message in response to shutting down?

Why does this fix the test you described in the earlier bug?  I would be more in
favor of a one-off fix to make that test pass, as the notification here seems
semantically incorrect.

[Bernhard Bauer, 2015/05/12 13:58:24]

This appears to be an existing issue in BrowsingDataRemover where it outlives
the TemplateURLService while removing data (which subsequently DCHECKs at
destruction that no callbacks are left). Because it depends on the timing of
BrowsingDataRemover, it surfaces somewhat nondeterministically, and apparently
this CL triggers it :-/

The reason this change fixes it is that BrowsingDataRemover unregisters its
subscription in its callback (and TemplateURLService has no way to directly
unregister the callbacks or avoid the DCHECK). One alternative would be to pass
an additional parameter that specifies whether the TemplateURLService has
actually loaded its data, but that would require updating all the additional
call sites as well.

The right long-term solution for this would be to make BrowsingDataRemover a
KeyedService like https://crbug.com/483528 says, but that's also a major change
:-/

[Peter Kasting, 2015/05/12 18:54:07]

Wouldn't another alternative be for TemplateURLService to explicitly clear the
callback list in its destructor, to avoid the DCHECK?  This would obviously be a
temporary fix that we'd remove later.
Are you going to be working on that change?  If not, who is?  I don't want to
bandaid things when there's no firm plan to fix correctly.

Is making BrowsingDataRemover a KeyedService really that difficult?  My
impression was that usually this is not a big deal.

 }
 
 syncer::SyncDataList TemplateURLService::GetAllSyncData(