ChildProcessSecurityPolicy::CanAccessDataForOrigin workaround to suppress bad kills

content/browser/child_process_security_policy_impl.cc

Index: content/browser/child_process_security_policy_impl.cc
diff --git a/content/browser/child_process_security_policy_impl.cc b/content/browser/child_process_security_policy_impl.cc
index 34bad5ad0e55ab8d4a4ce2b2b788f511271de1e8..9a57c24773e3181b5c0a242d84e74ff651f74bb3 100644
--- a/content/browser/child_process_security_policy_impl.cc
+++ b/content/browser/child_process_security_policy_impl.cc
@@ -817,8 +817,12 @@ bool ChildProcessSecurityPolicyImpl::CanAccessDataForOrigin(int child_id,
                                                             const GURL& gurl) {
   base::AutoLock lock(lock_);
   SecurityStateMap::iterator state = security_state_.find(child_id);
-  if (state == security_state_.end())
-    return false;
+  if (state == security_state_.end()) {
+    // TODO(nick): Returning true instead of false here is a temporary
+    // workaround for https://crbug.com/600441
+    NOTREACHED();

[Charlie Reis, 2016/05/04 19:38:17]

Let's remove the NOTREACHED.  Looks like this is hit in the tests, plus we know
it happens in practice today.  We'll just have to think about how to deal with
it or make it not possible after this CL.

[ncarter (slow), 2016/05/04 19:57:57]

The test that hits it, also fails if we remove the NOTREACHED(). I've edited the
test.

My hope was that the NOTREACHED() might help us track down repro steps.

+    return true;
+  }
   return state->second->CanAccessDataForOrigin(gurl);
 }