bbudge: It looks like we're seeing some insufficient randomness, at least on Windows 7, perhaps? Any thoughts?

FWIW, Microsoft's documentation for RtlGenRandom (used in the Win RandBytes implementation https://codesearch.chromium.org/chromium/src/base/rand_util_win.cc?gsn=RandUint64&l=13) 

recommends to use the CryptGenRandom function instead.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa387694(v=vs.85).aspx

It's kind of arbitrary how we test the randomness - generating 100 addresses and expecting no collisions. It may be that we should allow for a small number of collisions (say 1 or 2) instead of failing on the first one. Since the likelihood of no collisions is non-zero, this test is in theory flakey (though perhaps with a very low failure rate.) On Windows, with the larger allocation granularity, the test is slightly more likely to be flakey. 

In this case, it failed four times consecutively? 

I couldn't find those consecutive failures. Link?

https://logs.chromium.org/v/?s=chromium%2Fbb%2Ftryserver.chromium.win%2Fwin7_chromium_rel_ng%2F52811%2F%2B%2Frecipes%2Fsteps%2Fbase_unittests__with_patch_%2F0%2Flogs%2FAddressSpaceRandomizationTest.Unpredictable%2F0

A new instance https://uberchromegw.corp.google.com/i/chromium.win/builders/Win7%20Tests%20%281%29/builds/74307

Re: #2: Apparently RtlGenRandom is also cryptographically strong. https://blogs.msdn.microsoft.com/michael_howard/2005/01/14/cryptographically-secure-random-number-on-windows-without-using-cryptoapi/ So I don't think that's the problem.

Another instance:
https://uberchromegw.corp.google.com/i/chromium.win/builders/Win7%20Tests%20%281%29/builds/76156

[ RUN      ] AddressSpaceRandomizationTest.Unpredictable
[3484:752:0123/133052.956:10179283:FATAL:address_space_randomization_unittest.cc(81)] Check failed: 0ULL == addresses.count(address) (0 vs. 1)
Backtrace:
	base::debug::StackTrace::StackTrace [0x0129E160+32]
	base::debug::StackTrace::StackTrace [0x0129D9DD+13]
	logging::LogMessage::~LogMessage [0x01275290+80]
	base::AddressSpaceRandomizationTest_Unpredictable_Test::TestBody [0x01239210+608]
	testing::Test::Run [0x0126BDF2+178]
	testing::TestInfo::Run [0x0126C495+203]
	testing::TestCase::Run [0x0126C84D+237]
	testing::internal::UnitTestImpl::RunAllTests [0x012706A3+627]
	testing::UnitTest::Run [0x0127034B+153]
	base::TestSuite::Run [0x014389F6+102]
	base::LaunchUnitTests [0x014397F9+413]
	base::LaunchUnitTests [0x014396D2+118]
	main [0x01438919+97]
	__scrt_common_main_seh [0x0146ED9A+248] (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:283)
	BaseThreadInitThunk [0x7697338A+18]
	RtlInitializeExceptionChain [0x77089902+99]
	RtlInitializeExceptionChain [0x770898D5+54]
[3050/3050] AddressSpaceRandomizationTest.Unpredictable (CRASHED)

 Issue 805388  has been merged into this issue.

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

commit 9d94df31c926ba5e8f02f85e88686ee1482cf560
Author: Bill Budge <bbudge@chromium.org>
Date: Tue Feb 06 03:09:29 2018

[page_allocator] Rework ASLR tests.

- Refactors tests into simpler subtests.
- Replaces flaky collision testing with proper randomness tests, copied
  from V8's PRNG tests.

Bug:  chromium:788948 
Change-Id: I39597dcdde591e5102dbac6e5a706681615073d0
Reviewed-on: https://chromium-review.googlesource.com/894268
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#534606}
[modify] https://crrev.com/9d94df31c926ba5e8f02f85e88686ee1482cf560/base/allocator/partition_allocator/address_space_randomization_unittest.cc

Marking as fixed, though the new test is flaky in a different way (timeouts). Will be continuing on that bug:

https://bugs.chromium.org/p/chromium/issues/detail?id=809367