Can I see your /tmp/blah flagfile?

Here is what I get:

```
chromium/src $ cat out/Default/args.gn 
is_debug = true
is_component_build = true
use_afl = false
is_asan = false
enable_nacl = false
use_goma = true

chromium/src $ ./out/Default/base_unittests --single-process-tests --gtest_filter=PartitionAllocTest.*
...
[       OK ] PartitionAllocTest.RepeatedReturnNullDirect (4926 ms)
...
```

Note that these tests are inherently, and necessarily?, aggressive and weird:

```
// Unit tests that check if an allocation fails in "return null" mode,
// repeating it doesn't crash, and still returns null. The tests need to
// stress memory subsystem limits to do so, hence they try to allocate
// 6 GB of memory, each with a different per-allocation block sizes.
//
// On 64-bit POSIX systems, the address space is limited to 6 GB using
// setrlimit() first.

// Test "return null" for larger, direct-mapped allocations first. As a
// direct-mapped allocation's pages are unmapped and freed on release, this
// test is performd first for these "return null" tests in order to leave
// sufficient unreserved virtual memory around for the later one(s).
```

and:

```
static void DoReturnNullTest(size_t allocSize) {
  // TODO(crbug.com/678782): Where necessary and possible, disable the
  // platform's OOM-killing behavior. OOM-killing makes this test flaky on
  // low-memory devices.
  if (!IsLargeMemoryDevice()) {
    LOG(WARNING) << "Skipping test on this device because of crbug.com/678782";
    return;
  } 

  TestSetup();

  EXPECT_TRUE(SetAddressSpaceLimit());

  // Work out the number of allocations for 6 GB of memory.
  const int numAllocations = (6 * 1024 * 1024) / (allocSize / 1024);

  void** ptrs = reinterpret_cast<void**>(PartitionAllocGeneric(
      generic_allocator.root(), numAllocations * sizeof(void*), type_name));
  int i;

  for (i = 0; i < numAllocations; ++i) {
    ptrs[i] = PartitionAllocGenericFlags(generic_allocator.root(),
                                         PartitionAllocReturnNull, allocSize,
                                         type_name);
    if (!i)
      EXPECT_TRUE(ptrs[0]);
    if (!ptrs[i]) {
      ptrs[i] = PartitionAllocGenericFlags(generic_allocator.root(),
                                           PartitionAllocReturnNull, allocSize,
                                           type_name);
      EXPECT_FALSE(ptrs[i]);
      break;
    }
  }

  // We shouldn't succeed in allocating all 6 GB of memory. If we do, then
  // we're not actually testing anything here.
  EXPECT_LT(i, numAllocations);

  // Free, reallocate and free again each block we allocated. We do this to
  // check that freeing memory also works correctly after a failed allocation.
  for (--i; i >= 0; --i) {
    PartitionFreeGeneric(generic_allocator.root(), ptrs[i]);
    ptrs[i] = PartitionAllocGenericFlags(generic_allocator.root(),
                                         PartitionAllocReturnNull, allocSize,
                                         type_name);
    EXPECT_TRUE(ptrs[i]);
    PartitionFreeGeneric(generic_allocator.root(), ptrs[i]);
  }

  PartitionFreeGeneric(generic_allocator.root(), ptrs);

  EXPECT_TRUE(ClearAddressSpaceLimit());
}
```

These tests have always been this way; what's new (as of late 2016) is that they're in base_unittests. So, I think this might be WontFix, unless the slowness is a huge problem?

Slowness and/or timing out. Are they timing out on our bots on a regular basis?

It looks like rharrison fixed this in https://chromium-review.googlesource.com/1106602, and that  issue 851148  was a duplicate of this one. Thanks rharrison! That's the bug of record now, so duping this one into that one.