Ot sounds like this too blocks a roll. We really need to get one out, so thanks for taking a look.

First bad: https://build.chromium.org/p/chromium.fyi/builders/ClangToTLinuxUBSanVptr%20tester/builds/972

That has got_clang revision 289657, prior good build has 289636

Looking at https://build.chromium.org/p/chromium.fyi/builders/ClangToTLinuxUBSanVptr%20tester/
it seems like

Last good Clang: r289636
First bad: r289657

svn log -r289636:289657 https://nico@llvm.org/svn/llvm-project

Nothing obvious

I am building r289645 right now.

r289645 is bad. I am now building 289651.

r289651 is bad, but that's certainly expected, as I went the wrong side.

I am now building r289640

I rolled back llvm, clang and compiler-rt to r289636 but still get that failure :-/

Could this be due to a Chromium change?

Last good: 5fb8c41aea7e2a5a7ec8f33a3c6bee46eb86d95d
First bad: a20ca9fe5726b33fb6b0d9f3b10b545fd6e6b195

There's only one change to base/ in that range:
https://codereview.chromium.org/2518253002
"Move Partition Allocator into Chromium base."

Incidentally, that's the test that's failing.

r289640 is bad.

Actually, yes, the ToT was not running wtf_unittests which is where these tests were before that move. I will now try r289600

krasin: I think Hans is saying that it might be bad at 289575 (the currently pinned clang) too, and might've been bad forever, and we just didn't notice 'cause that test didn't run until recently.

r289600 is bad.

I ran a sanity check on the revision we currently have as the stable toolchain, r289575. It's also bad.

https://build.chromium.org/p/chromium.fyi/builders/UBSanVptr Linux does not catch this, as it does not have edge coverage set. That makes this bug a non-blocker for the roll: we already have this bug in src/ and the roll does not make it any worse.

Just spotted #8 and #10 (sorry, I was on the meeting, and only made occasional writes). Yes, #12 confirms that the currently rolled Clang is already bad.

r288000 is bad.

r287000 is bad. Trying r285000.

r285000 is bad. Last attempt to claim it's a regression: r280000. After that I will be looking at the disassembly code.

r280000 is bad too. Turning into the investigation mode...

I have built Clang ToT (r290001) and spent some time digging. My current status is that this mmap with the same arguments succeeds for regular case and fails (return -1) when coverage=edge is enabled:
https://cs.chromium.org/chromium/src/base/allocator/partition_allocator/page_allocator.cc?sq=package:chromium&dr=CSs&rcl=1481905173&l=66

static void* systemAllocPages(
    void* hint,
    size_t len,
    PageAccessibilityConfiguration pageAccessibility) {
...
ret = mmap(hint, len, accessFlag, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
...

In both cases mmap leads to the tcmalloc hook:
https://cs.chromium.org/chromium/src/third_party/tcmalloc/chromium/src/malloc_hook_mmap_linux.h?q=third_party/tcmalloc/chromium/src/malloc_hook_mmap_linux.h:181&sq=package:chromium&l=181

Before I dive any deeper, I would like to take some time and reflect on my current findings. 

So, this is just rlimit. In case of coverage=edge, it reserves around 5GB of memory for bookkeeping. The real usage is much usually lower, but the test fails with OOM anyway, just because we're already above the limit when it's set.

https://cs.chromium.org/chromium/src/base/allocator/partition_allocator/partition_alloc_unittest.cc?sq=package:chromium&dr=CSs&l=70

The fix is sent for a review: https://codereview.chromium.org/2584123002/

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

commit 57d9a8022c40f1612774d7eb6a2554cf4a0cefe2
Author: krasin <krasin@chromium.org>
Date: Sun Dec 18 16:36:13 2016

PartitionAllocTest: increase address space limit to 6 GB.

In some cases, such as sanitizer_coverage_flags=edge,
more than 5 GB of address space is reserved at a startup.
Raising the address space limit to be higher than that.

Unfortunately, Linux has a broken implementation of getrusage,
and the proper way of fixing this (by setting the current usage + 4 GB)
is not trivial / impossible under a sandbox. This is the riskless
change I could make up: increase the address limit, while still
not increasing the amount of memory allocated to avoid issues on
Android.

BUG= 674665 

Review-Url: https://codereview.chromium.org/2584123002
Cr-Commit-Position: refs/heads/master@{#439372}

[modify] https://crrev.com/57d9a8022c40f1612774d7eb6a2554cf4a0cefe2/base/allocator/partition_allocator/partition_alloc_unittest.cc

The UBSanVptr ToT bot is now green:
https://build.chromium.org/p/chromium.fyi/builders/ClangToTLinuxUBSanVptr%20tester/builds/983