$ clang --version
clang version 6.0.0 (trunk 312679)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /d/code/chrome/src/third_party/llvm-build/Release+Asserts/bin

Sorry Hans, looks your still busy debugging taskqueue flakiness :-( maybe someone else in the team can take a look...

I'll take a look tomorrow.

Dale, is this a build config that's used on a bot somewhere, or where does it come from?

I've tried all the way back to August 1 (1a159a003ca82e0b0bd653078dbde80757bf9e2c), but the compile of that file sits there forever (five minutes or so).

Are you saying this is a regression and used to work recently? How long did the compile usually take?

The time is spent in the PBQP register allocator:


#1  0x00000000019eef55 in count (Val=..., this=0x7fffffff9b90) at ../include/llvm/ADT/DenseMap.h:143
#2  count (V=..., this=0x7fffffff9b90) at ../include/llvm/ADT/DenseSet.h:92
#3  (anonymous namespace)::Interference::apply (this=<optimized out>, G=...) at ../lib/CodeGen/RegAllocPBQP.cpp:376
#4  0x00000000019e6468 in llvm::PBQPRAConstraintList::apply (this=<optimized out>, G=...) at ../include/llvm/CodeGen/PBQPRAConstraint.h:55
#5  0x00000000019f1f52 in (anonymous namespace)::RegAllocPBQP::runOnMachineFunction (this=0x7c96480, MF=...) at ../lib/CodeGen/RegAllocPBQP.cpp:826

I didn't even know Clang used that by default; and it doesn't, it's because we pass in these flags when building:


-mllvm -regalloc=pbqp -mllvm -pbqp-coalescing

Those flags are added here:

https://cs.chromium.org/chromium/src/build/config/sanitizers/BUILD.gn?rcl=cefe5557b34e3cb4723508c9856d8fd964de9f26&l=467

    # Chromecast ubsan builds fail to compile with these
    # experimental flags, so only add them to non-chromecast ubsan builds.
    if (!is_chromecast) {
      cflags += [
        # Employ the experimental PBQP register allocator to avoid slow
        # compilation on files with too many basic blocks.
        # See  http://crbug.com/426271 .
        "-mllvm",
        "-regalloc=pbqp",


And it's been that way a long time. I'm still not sure what changed here.

I'm suspecting this is essentially a dupe of https://bugs.llvm.org/show_bug.cgi?id=17409 i.e. register allocation takes forever on certain large pieces of code.

Ah, hmm, I got these flags from ClusterFuzz... It did succeed once yesterday with these flags and I thought I had built it this way before too. I did recently add these to my config, so I may have messed something up. +mmoroz because presumably the libfuzzer builds are hanging or taking forever to build somewhere with these ubsan flags...

Thanks for the heads up, libFuzzer buildbots look fine:
-
 https://build.chromium.org/p/chromium.fyi/builders/Libfuzzer%20Upload%20Linux%20ASan
- https://build.chromium.org/p/chromium.fyi/builders/Libfuzzer%20Upload%20Linux%20UBSan
- https://build.chromium.org/p/chromium.fyi/builders/Libfuzzer%20Upload%20Linux%20MSan
- https://build.chromium.org/p/chromium.fyi/builders/Libfuzzer%20Upload%20Linux%20ASan%20Debug

Hmm, I guess what's unique about my config is it's setting is_asan + is_ubsan, vs the bots which are just setting is_ubsan_for_security, which is a flag code search doesn't seem to find... How is that one different then is_ubsan + is_asan mmoroz?

enable_nacl = false
ffmpeg_branding = "ChromeOS"
goma_dir = "/b/build/slave/cache/goma_client"
is_debug = false
is_ubsan_security = true
optimize_for_fuzzing = true
pdf_enable_xfa = true
proprietary_codecs = true
use_libfuzzer = true

1) is_ubsan is  a general purpose UBSan config, there are many different flags enabled:  
https://cs.chromium.org/chromium/src/build/config/sanitizers/BUILD.gn?l=442

I think it's being used for fuzzing, but not with libFuzzer-based stuff (https://bugs.chromium.org/p/chromium/issues/list?can=1&q=Description%3Alinux_ubsan_chrome%2Clinux_ubsan_pdfium&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids)


2) is_ubsan_security purpose is to detect bugs that MAY BE security issues. It has been created because general "ubsan" config (#1 described above) has too many different flags enabled:
https://cs.chromium.org/chromium/src/build/config/sanitizers/BUILD.gn?q=is_ubsan_security&sq=package:chromium&dr=C&l=491


I'm not sure if I got your point about is_asan + is_ubsan. Do you want to enable both sanitizers at the same time?

There is a 3rd configuration, by the way, is_ubsan_vptr: https://cs.chromium.org/chromium/src/build/config/sanitizers/BUILD.gn?l=510

This is a separate build with -fsanitize=vptr flag only. The main goal here is to detect type confusion bugs, which are valid security issues in most of the cases.

Thanks, not sure why code search didn't find those earlier...

That was the idea and what I thought ClusterFuzz did :) I was hoping to avoid rebuilding every time I got a ubsan vs an asan test case, but seems like that dream may not be possible currently.

I see.. Yeah, in general ASan + UBSan should work together, but there might be some edge cases where instrumentation becomes too complicated or even incompatible, as those tools were implemented by different groups of people :/