This is paging the trooper and causes overload on a CQ trybot https://ci.chromium.org/p/chromium/builders/luci.chromium.try/fuchsia_x64 due to retries without patch.

+current sheriffs FYI

Could not find clear culprit in the build range. I'm disabling it on Fuchsia.
https://chromium-review.googlesource.com/c/chromium/src/+/1415052

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/97250d12107aa37ca1fcc68b6d0d252525d0aaaf

commit 97250d12107aa37ca1fcc68b6d0d252525d0aaaf
Author: Kunihiko Sakamoto <ksakamoto@chromium.org>
Date: Thu Jan 17 01:20:38 2019

Disable ChildProcessSecurityPolicyTest.DynamicIsolatedOrigins on Fuchsia

TBR=alexmos@chromium.org,creis@chromium.org,lukasza@chromium.org

No-Try: true
Bug:  922732 
Change-Id: Ic3d35731508e7d8e1365e317a31a787526a3e220
Reviewed-on: https://chromium-review.googlesource.com/c/1415052
Reviewed-by: Kunihiko Sakamoto <ksakamoto@chromium.org>
Commit-Queue: Kunihiko Sakamoto <ksakamoto@chromium.org>
Cr-Commit-Position: refs/heads/master@{#623496}
[modify] https://crrev.com/97250d12107aa37ca1fcc68b6d0d252525d0aaaf/content/browser/child_process_security_policy_unittest.cc

Assigning alexmos@ (author of the test case) for further investigation.

 Issue 922763  has been merged into this issue.

The failure logs indicate that when this tests runs on Fuchsia, something has already created a BrowsingInstance and bumped the global ID counter before the test starts to run.  That could happen from a navigation or creating a SiteInstance.  Anyone know if there's any extra setup that's done for content_unittests only for Fuchsia?  Or maybe a SiteInstance leaks from a previous test?

I suppose I could change the test to not depend on the starting BrowsingInstance having ID 1, though it'd be nice to understand where the extra startup BrowsingInstance is coming from, and why it's not present on other platforms.

Re #7: We run tests in batches of ten tests per batch-process, by default, so if you're depending on nothing every having created a BrowsingInstance in the same process in this test then yes, the test should be updated to tolerate running in a process that has already run other tests. :)

Yup, I'll go ahead and update the test.  I see that there's only one other ChildProcessSecurityPolicyTest that creates a SiteInstance and hence BrowsingInstance,  ChildProcessSecurityPolicyTest.CanAccessDataForOrigin (added shortly after my test), and on the Fuchsia bot it ran just before the DynamicIsolatedOrigins test, likely in the same batch.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/67bc07353c83b1d85e51a4acb97214ef6f41f92a

commit 67bc07353c83b1d85e51a4acb97214ef6f41f92a
Author: Alex Moshchuk <alexmos@chromium.org>
Date: Fri Jan 18 21:23:33 2019

Fix flakiness in ChildProcessSecurityPolicyTest.DynamicIsolatedOrigins

This test assumed that the initial BrowsingInstance ID will always be
1, but this won't hold if another unit test ran before this test in
the same batch and created a BrowsingInstance that bumped up the
global ID counter.  This CL changes the test to look up the first
BrowsingInstanceID and use it as a base for the other relevant checks.

Bug:  922732 
Change-Id: I037acc06144032b29e021e22f1fdd2cdc714f4a2
Reviewed-on: https://chromium-review.googlesource.com/c/1422499
Commit-Queue: Charlie Reis <creis@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#624285}
[modify] https://crrev.com/67bc07353c83b1d85e51a4acb97214ef6f41f92a/content/browser/child_process_security_policy_unittest.cc