Huh, failed to repro with local clang at 291446 (from Jan). But I did a component build, maybe it only repros in static builds. Trying again.

I can repro with

target_os = "android"
is_debug = false
is_clang = true
clang_use_chrome_plugins = false
clang_base_path = getenv("HOME") + "/src/llvm-build-nolibcxx"

with clang at 291446

`ninja -C out/gn lib_android_webview_unittests__library.so`

(current pinned clang is 289944)

290700 bad

209300 bad -- let me build with pinned clang and make sure that works

Pinned clang fails the same way :-/

So I guess this is due to some chromium-side change and nobody noticed cause nothing else builds that target?

(my chromium checkout was at #448417, now going back in time there. at least i can use goma for bisecting there.)

things are happy at #430287

#438188 good

#440760 bad

at #439144 clang crashes while building :-/

clang: /b/build/slave/linux_upload_clang/build/src/third_party/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:6973: llvm::MemSDNode::MemSDNode(unsigned int, unsigned int, const llvm::DebugLoc &, llvm::SDVTList, llvm::EVT, llvm::MachineMemOperand *): Assertion `memvt.getStoreSize() <= MMO->getSize() && "Size mismatch!"' failed.
#0 0x00000000019ef2b5 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/google/home/thakis/src/chrome/src/third_party/llvm-build/Release+Asserts/bin/clang+0x19ef2b5)
#1 0x00000000019ef966 (/usr/local/google/home/thakis/src/chrome/src/third_party/llvm-build/Release+Asserts/bin/clang+0x19ef966)
#2 0x00007f6f7ac54330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
#3 0x00007f6f79848c37 gsignal /build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
#4 0x00007f6f7984c028 abort /build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0
#5 0x00007f6f79841bf6 __assert_fail_base /build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0
#6 0x00007f6f79841ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2)
#7 0x000000000212ca1f (/usr/local/google/home/thakis/src/chrome/src/third_party/llvm-build/Release+Asserts/bin/clang+0x212ca1f)
#8 0x0000000002124052 llvm::SelectionDAG::getMemIntrinsicNode(unsigned int, llvm::SDLoc const&, llvm::SDVTList, llvm::ArrayRef<llvm::SDValue>, llvm::EVT, llvm::MachineMemOperand*) (/usr/local/google/home/thakis/src/chrome/src/third_party/llvm-build/Release+Asserts/bin/clang+0x2124052)

(at clang 289864 at that point)

(that was https://llvm.org/bugs/show_bug.cgi?id=31404)

#438558 good -- maybe this broke during the https://docs.google.com/document/d/1iWP1Ypv-sHWqm2P1cf6drOiSsaPosyGYPpS1KQaml68/edit?pli=1# saga? :-/

#439325 bad :-/

If it broke in that interval, clang 289575:289944 is potential regression range (at least fairly small i suppose)

bad with clang r289775 (with 289703 reverted to work around that crash)

clang r289675 bad

289625 bad

289600 bad (huh...)

issue 648948 looks pretty related

clang 289575 locally built with chrome #439325 too. So not due to the clang rolls in december.

clang 289575 locally built with chrome #439325 *is bad* too.

(also related: https://chromium.googlesource.com/chromium/src/+/c4ffc5d95c07e6777d4c57dc086d1b681a830a34%5E%21/#F0)

#439000 good

#439150 with pinned clang changed to 289575 to work around the clang crash is bad

#439080 bad

#439040 bad

#439020 bad

#439010 bad

#439005 bad ... suspicious, trying 439000 again now. I did incremental builds for the latest string of rebuilds, maybe that mattered somehow?

Do you think this still blocks the roll?

#439000 bad this time :-/

No, it's not blocking the roll. Removing that.

clean build at #439000 now bad too. maybe comment 25 is just wrong

#438558 still good.

At that revision,

$ ls -l out/gn/lib.unstripped/lib_android_webview_unittests__library.so
-rwxr-x--- 1 thakis eng 4291227964 Feb  8 13:06 out/gn/lib.unstripped/lib_android_webview_unittests__library.so


which is pretty close to UINT_MAX (4294967295), only 3739331 / 3.7MB away from it. Since we're building with full symbols, it might just be organic growth.

I'll just do https://chromium.googlesource.com/chromium/src/+/c4ffc5d95c07e6777d4c57dc086d1b681a830a34%5E%21/#F0 for clang and call it a day.

https://codereview.chromium.org/2685033002/

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

commit 7be003ae95486a55fc2a9ef5fb34e26f702fc241
Author: thakis <thakis@chromium.org>
Date: Thu Feb 09 16:43:41 2017

android: Default symbol_level to 1 in 32-bit builds for clang too

clang finally hit the same file size wall that gcc hit a while ago.

(Locally, building lib_android_webview_unittests__library.so goes
from 6.5min to 3.8min on my linux box and file size of the .so goes
from over 4.1GB to 320MB -- at the cost of no detailed debug info
of coarse. Feels like investigating fission or similar would probably
be beneficial for the android build.)

BUG=648948, 685259 

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

[modify] https://crrev.com/7be003ae95486a55fc2a9ef5fb34e26f702fc241/build/config/compiler/compiler.gni

bot's green again, but now we don't have any bots testing debug info on android with clang tot. Probably should make a release component bot or something.