On my machine, it points to the system library, because I happen to have the libc++-dev package installed.
$ ldd out/tsan/chrome_sandbox 
	...
	libc++.so => /usr/lib/x86_64-linux-gnu/libc++.so (0x00007f5ce3ac5000)
        ...

The file out/tsan/libc++.so exists, but it's just not getting picked up because chrome_sandbox removes the rpath config.
https://cs.chromium.org/chromium/src/sandbox/linux/BUILD.gn?rcl=024a9c036ef4f58d2cf1d5568245604bae67e1bf&l=326

According to the CL that added this (https://chromium.googlesource.com/chromium/src/+/3ea22b3a4855512be84da4bc186392434e14de7c%5E%21/#F1), this is for security reasons.  However, all configs that we actually ship don't set the rpath (they used to, but not any more).  I'm guessing this is just leftover from the days when release builds set the rpath, so we could probably remove it.

+dpranke (author of that cl) is it ok if we add the rpath config back in?

... or since chrome_sandbox only has C sources, we could also just set "no_default_deps = true" to prevent linking against libc++.so.

It's kind of crummy that we need to set the rpath for static builds that are instrumented with *san, just to get libc++.so.  IIRC, the reason it needs to be this way is so that the *san runtime can override certain symbols.  Perhaps what we really want is to just make those symbols visible in the instrumented case, and set the rpath iff is_component_build?

If there's no way to get the correct sanitized library w/o setting the rpath, I suppose we could do that, as long as we're clear that it's *only* allowed for that reason (and not in the component build generally).

I've added a check in the Linux packager code to ensure RPATH is explicitly not set, so it shouldn't regress. https://cs.chromium.org/chromium/src/chrome/installer/linux/common/installer.include?rcl=3f7cf703287b243de50dc5efd51cb942577e35f3&l=339

Note this is not a component build. Sounds like

  if (is_sanitizer)
    config += set_rpath

should be the right fix?

See c#2.  Unfortunately, we need to set the rpath when !libcpp_is_static (https://cs.chromium.org/chromium/src/build/config/c%2B%2B/c%2B%2B.gni?rcl=58c09bfdb7e6c9e17b14213f8525b1d20117e39f&l=33) because in that case we generate libc++.so.

We do this so *san can override malloc etc.  But this is just to workaround us hiding those symbols, and I'm wondering if we just didn't hide them if the *san runtime would still work.

Another point: build/update-linux-sandbox.sh doesn't copy libc++.so around either. So either we have to add that too, or disable asan for the target and link libc++.so statically (or, as you suggest, not at all). That might be simplest.

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

commit 43a48785f23a65d5b3f0cefac086d67c3dea4eb0
Author: Tom Anderson <thomasanderson@chromium.org>
Date: Mon Jun 11 19:23:04 2018

Stop removing rpath_for_built_shared_libraries from chrome_sandbox

For instrumented builds like tsan, this causes chrome_sandbox to reference the
wrong libc++.so due to a missing RPATH.

Since all configurations we ship don't set RPATH, we don't have to worry about
security vulnerabilities introduced by RPATH=$ORIGIN.  There's also a check to
enforce this in chrome/installer/linux/common/installer.include.

BUG= 850682 

Change-Id: I25307bd9de388009acffdbb8de6717210873655b
Reviewed-on: https://chromium-review.googlesource.com/1092077
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#566099}
[modify] https://crrev.com/43a48785f23a65d5b3f0cefac086d67c3dea4eb0/build/config/gcc/BUILD.gn
[modify] https://crrev.com/43a48785f23a65d5b3f0cefac086d67c3dea4eb0/sandbox/linux/BUILD.gn

c#7: Ah, thanks for pointing that out Nico.  Yes, I think "no_default_deps = true" is probably the best way to go for that.

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

commit f95d6e90225eb83eb39e2fdb1dd68abcbeb0ef34
Author: Tom Anderson <thomasanderson@chromium.org>
Date: Tue Jun 12 00:01:02 2018

Add no_default_deps to chrome_sandbox

This change is necessary to ensure that installing the sandbox with
update-linux-sandbox.sh works for component and instrumented builds.

BUG= 850682 
R=jorgelo

Change-Id: Id3ff96c13613e12e4cbe8df65d62919368766bb0
Reviewed-on: https://chromium-review.googlesource.com/1095563
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#566213}
[modify] https://crrev.com/f95d6e90225eb83eb39e2fdb1dd68abcbeb0ef34/sandbox/linux/BUILD.gn

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

commit 800f0b600cda4241af447f4594e9367f458aa339
Author: Findit <findit-for-me@appspot.gserviceaccount.com>
Date: Tue Jun 12 00:38:33 2018

Revert "Add no_default_deps to chrome_sandbox"

This reverts commit f95d6e90225eb83eb39e2fdb1dd68abcbeb0ef34.

Reason for revert:

Findit (https://goo.gl/kROfz5) identified CL at revision 566213 as the
culprit for failures in the build cycles as shown on:
https://findit-for-me.appspot.com/waterfall/culprit?key=ag9zfmZpbmRpdC1mb3ItbWVyRAsSDVdmU3VzcGVjdGVkQ0wiMWNocm9taXVtL2Y5NWQ2ZTkwMjI1ZWI4M2ViMzllMmZkYjFkZDY4YWJjYmViMGVmMzQM

Sample Failed Build: https://ci.chromium.org/buildbot/chromium.memory/Linux%20ChromiumOS%20MSan%20Builder/7687

Sample Failed Step: compile

Original change's description:
> Add no_default_deps to chrome_sandbox
> 
> This change is necessary to ensure that installing the sandbox with
> update-linux-sandbox.sh works for component and instrumented builds.
> 
> BUG= 850682 
> R=jorgelo
> 
> Change-Id: Id3ff96c13613e12e4cbe8df65d62919368766bb0
> Reviewed-on: https://chromium-review.googlesource.com/1095563
> Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
> Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#566213}

No-Presubmit: true
No-Tree-Checks: true
No-Try: true
BUG= 850682 

Change-Id: Iae4ce669520f317875e1ce8e3ac7eed39552e5c9
Reviewed-on: https://chromium-review.googlesource.com/1096494
Cr-Commit-Position: refs/heads/master@{#566224}
[modify] https://crrev.com/800f0b600cda4241af447f4594e9367f458aa339/sandbox/linux/BUILD.gn

Hm.. I guess libc++ is necessary for msan's static library that gets linked into every exectuable.  I suppose we could add another special case for msan to avoid linking in libclang_rt.msan_cxx-x86_64.a, but I think tomorrow I'm going to try the symbol visibility thing in c#2 and c#4 since it's The Right™ solution.

[15/19427] LINK ./chrome_sandbox
FAILED: chrome_sandbox 
python "../../build/toolchain/gcc_link_wrapper.py" --output="./chrome_sandbox" -- ../../third_party/llvm-build/Release+Asserts/bin/clang++ -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,now -Wl,-z,relro -fuse-ld=gold -B../../third_party/binutils/Linux_x64/Release/bin -Wl,--threads -Wl,--thread-count=4 -m64 -Werror -Wl,-O2 -Wl,--gc-sections -nostdlib++ --sysroot=../../build/linux/debian_sid_amd64-sysroot -L../../build/linux/debian_sid_amd64-sysroot/usr/local/lib/x86_64-linux-gnu -Wl,-rpath-link=../../build/linux/debian_sid_amd64-sysroot/usr/local/lib/x86_64-linux-gnu -L../../build/linux/debian_sid_amd64-sysroot/lib/x86_64-linux-gnu -Wl,-rpath-link=../../build/linux/debian_sid_amd64-sysroot/lib/x86_64-linux-gnu -L../../build/linux/debian_sid_amd64-sysroot/usr/lib/x86_64-linux-gnu -Wl,-rpath-link=../../build/linux/debian_sid_amd64-sysroot/usr/lib/x86_64-linux-gnu -fsanitize=memory -Wl,-rpath-link=. -Wl,--disable-new-dtags -Wl,-rpath=\$ORIGIN/. -Wl,-rpath-link=. -Wl,-R,\$ORIGIN/instrumented_libraries_prebuilt/msan/lib -Wl,-z,origin -Wl,-R,________________________________________________________________PADDING________________________________________________________________ -o "./chrome_sandbox" -Wl,--start-group @"./chrome_sandbox.rsp"  -Wl,--end-group   -ldl -lpthread -lrt 
/b/c/b/Linux_ChromiumOS_MSan_Builder/src/third_party/llvm-build/Release+Asserts/lib/clang/7.0.0/lib/linux/libclang_rt.msan_cxx-x86_64.a(ubsan_type_hash_itanium.cc.o):ubsan_type_hash_itanium.cc:function __ubsan::checkDynamicType(void*, void*, unsigned long): error: undefined reference to 'typeinfo for std::type_info'
/b/c/b/Linux_ChromiumOS_MSan_Builder/src/third_party/llvm-build/Release+Asserts/lib/clang/7.0.0/lib/linux/libclang_rt.msan_cxx-x86_64.a(ubsan_type_hash_itanium.cc.o):ubsan_type_hash_itanium.cc:function __ubsan::checkDynamicType(void*, void*, unsigned long): error: undefined reference to 'typeinfo for __cxxabiv1::__class_type_info'
/b/c/b/Linux_ChromiumOS_MSan_Builder/src/third_party/llvm-build/Release+Asserts/lib/clang/7.0.0/lib/linux/libclang_rt.msan_cxx-x86_64.a(ubsan_type_hash_itanium.cc.o):ubsan_type_hash_itanium.cc:function __ubsan::checkDynamicType(void*, void*, unsigned long): error: undefined reference to '__dynamic_cast'
/b/c/b/Linux_ChromiumOS_MSan_Builder/src/third_party/llvm-build/Release+Asserts/lib/clang/7.0.0/lib/linux/libclang_rt.msan_cxx-x86_64.a(ubsan_type_hash_itanium.cc.o):ubsan_type_hash_itanium.cc:function isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, __cxxabiv1::__class_type_info const*, long): error: undefined reference to 'typeinfo for __cxxabiv1::__class_type_info'
/b/c/b/Linux_ChromiumOS_MSan_Builder/src/third_party/llvm-build/Release+Asserts/lib/clang/7.0.0/lib/linux/libclang_rt.msan_cxx-x86_64.a(ubsan_type_hash_itanium.cc.o):ubsan_type_hash_itanium.cc:function isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, __cxxabiv1::__class_type_info const*, long): error: undefined reference to 'typeinfo for __cxxabiv1::__si_class_type_info'
/b/c/b/Linux_ChromiumOS_MSan_Builder/src/third_party/llvm-build/Release+Asserts/lib/clang/7.0.0/lib/linux/libclang_rt.msan_cxx-x86_64.a(ubsan_type_hash_itanium.cc.o):ubsan_type_hash_itanium.cc:function isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, __cxxabiv1::__class_type_info const*, long): error: undefined reference to '__dynamic_cast'
/b/c/b/Linux_ChromiumOS_MSan_Builder/src/third_party/llvm-build/Release+Asserts/lib/clang/7.0.0/lib/linux/libclang_rt.msan_cxx-x86_64.a(ubsan_type_hash_itanium.cc.o):ubsan_type_hash_itanium.cc:function isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, __cxxabiv1::__class_type_info const*, long): error: undefined reference to 'typeinfo for __cxxabiv1::__class_type_info'
/b/c/b/Linux_ChromiumOS_MSan_Builder/src/third_party/llvm-build/Release+Asserts/lib/clang/7.0.0/lib/linux/libclang_rt.msan_cxx-x86_64.a(ubsan_type_hash_itanium.cc.o):ubsan_type_hash_itanium.cc:function isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, __cxxabiv1::__class_type_info const*, long): error: undefined reference to 'typeinfo for __cxxabiv1::__vmi_class_type_info'
/b/c/b/Linux_ChromiumOS_MSan_Builder/src/third_party/llvm-build/Release+Asserts/lib/clang/7.0.0/lib/linux/libclang_rt.msan_cxx-x86_64.a(ubsan_type_hash_itanium.cc.o):ubsan_type_hash_itanium.cc:function isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, __cxxabiv1::__class_type_info const*, long): error: undefined reference to '__dynamic_cast'
/b/c/b/Linux_ChromiumOS_MSan_Builder/src/third_party/llvm-build/Release+Asserts/lib/clang/7.0.0/lib/linux/libclang_rt.msan_cxx-x86_64.a(ubsan_type_hash_itanium.cc.o):ubsan_type_hash_itanium.cc:function findBaseAtOffset(__cxxabiv1::__class_type_info const*, long): error: undefined reference to 'typeinfo for __cxxabiv1::__class_type_info'
/b/c/b/Linux_ChromiumOS_MSan_Builder/src/third_party/llvm-build/Release+Asserts/lib/clang/7.0.0/lib/linux/libclang_rt.msan_cxx-x86_64.a(ubsan_type_hash_itanium.cc.o):ubsan_type_hash_itanium.cc:function findBaseAtOffset(__cxxabiv1::__class_type_info const*, long): error: undefined reference to 'typeinfo for __cxxabiv1::__si_class_type_info'
/b/c/b/Linux_ChromiumOS_MSan_Builder/src/third_party/llvm-build/Release+Asserts/lib/clang/7.0.0/lib/linux/libclang_rt.msan_cxx-x86_64.a(ubsan_type_hash_itanium.cc.o):ubsan_type_hash_itanium.cc:function findBaseAtOffset(__cxxabiv1::__class_type_info const*, long): error: undefined reference to '__dynamic_cast'
/b/c/b/Linux_ChromiumOS_MSan_Builder/src/third_party/llvm-build/Release+Asserts/lib/clang/7.0.0/lib/linux/libclang_rt.msan_cxx-x86_64.a(ubsan_type_hash_itanium.cc.o):ubsan_type_hash_itanium.cc:function findBaseAtOffset(__cxxabiv1::__class_type_info const*, long): error: undefined reference to 'typeinfo for __cxxabiv1::__vmi_class_type_info'
clang: error: linker command failed with exit code 1 (use -v to see invocation)

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

commit d2a6d6bcbeccd540b8a27b4fbb3ed84d5113ea7c
Author: Thomas Anderson <thomasanderson@chromium.org>
Date: Wed Jun 20 01:07:17 2018

Revert "Stop removing rpath_for_built_shared_libraries from chrome_sandbox"

This reverts commit 43a48785f23a65d5b3f0cefac086d67c3dea4eb0.

Reason for revert: This CL made the assumption that we didn't ship in any configurations that are instrumented or that are component builds.  However  bug 853266  points out that CrOs ships in an asan configuration, so the rpath removal will still be necessary until the change in [1] is made.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=850682#c14

Original change's description:
> Stop removing rpath_for_built_shared_libraries from chrome_sandbox
>
> For instrumented builds like tsan, this causes chrome_sandbox to reference the
> wrong libc++.so due to a missing RPATH.
>
> Since all configurations we ship don't set RPATH, we don't have to worry about
> security vulnerabilities introduced by RPATH=$ORIGIN.  There's also a check to
> enforce this in chrome/installer/linux/common/installer.include.
>
> BUG= 850682 
>
> Change-Id: I25307bd9de388009acffdbb8de6717210873655b
> Reviewed-on: https://chromium-review.googlesource.com/1092077
> Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
> Reviewed-by: Dirk Pranke <dpranke@chromium.org>
> Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#566099}

TBR=jorgelo@chromium.org,palmer@chromium.org,dpranke@chromium.org,thomasanderson@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  850682 , 853266 
Change-Id: I4b094a512b29b76e12659cba905536118a49208c
Reviewed-on: https://chromium-review.googlesource.com/1107137
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Thomas Anderson <thomasanderson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568675}
[modify] https://crrev.com/d2a6d6bcbeccd540b8a27b4fbb3ed84d5113ea7c/build/config/gcc/BUILD.gn
[modify] https://crrev.com/d2a6d6bcbeccd540b8a27b4fbb3ed84d5113ea7c/sandbox/linux/BUILD.gn

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/buildtools/+/49b054d87c536f8a07aba08e9fd0ad2ea8a2382f

commit 49b054d87c536f8a07aba08e9fd0ad2ea8a2382f
Author: Tom Anderson <thomasanderson@chromium.org>
Date: Thu Jun 28 23:50:13 2018

Remove libcpp_is_static

This change makes libc++ a shared_library iff is_component_build=true, just like
all other components.  This has the advantage that the RPATH doesn't need to be
set in sanitizer (non-component) builds just so binaries can find libc++.so.

Needed for src CL:
https://chromium-review.googlesource.com/c/chromium/src/+/1119098

R=thakis
BUG= 850682 
Change-Id: Ic59cb002f33f3d6b030b27000ff8a7e34228a6ee

[modify] https://crrev.com/49b054d87c536f8a07aba08e9fd0ad2ea8a2382f/third_party/libc++/BUILD.gn
[modify] https://crrev.com/49b054d87c536f8a07aba08e9fd0ad2ea8a2382f/third_party/libc++abi/BUILD.gn

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/buildtools/+/637716e67c05e9700988a7dd937e1d9d3f2c7353

commit 637716e67c05e9700988a7dd937e1d9d3f2c7353
Author: Tom Anderson <thomasanderson@chromium.org>
Date: Wed Jul 25 00:43:13 2018

Remove libcpp_is_static

This change makes libc++ a shared_library iff is_component_build=true, just like
all other components.  This has the advantage that the RPATH doesn't need to be
set in sanitizer (non-component) builds just so binaries can find libc++.so.

Needed for src CL:
https://chromium-review.googlesource.com/c/chromium/src/+/1119098

R=thakis
BUG= 850682 

Change-Id: Iaaa5a0426bac852e5ffd6768ece813f31b8f299f
[modify] https://crrev.com/637716e67c05e9700988a7dd937e1d9d3f2c7353/third_party/libunwind/BUILD.gn
[modify] https://crrev.com/637716e67c05e9700988a7dd937e1d9d3f2c7353/third_party/libc++/BUILD.gn
[modify] https://crrev.com/637716e67c05e9700988a7dd937e1d9d3f2c7353/third_party/libc++abi/BUILD.gn

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

commit f002a96e9b788fe71fd1c773a4bc891940c409d8
Author: Tom Anderson <thomasanderson@chromium.org>
Date: Wed Jul 25 21:56:41 2018

Remove libcpp_is_static

This change makes libc++ a shared_library iff is_component_build=true, just like
all other components.  This has the advantage that the RPATH doesn't need to be
set in sanitizer (non-component) builds just so binaries can find libc++.so.
This CL also changes RPATH to be set iff is_component_build=true.

Needs buildtools CL:
https://chromium-review.googlesource.com/c/chromium/buildtools/+/1142370

TBR=dpranke,jochen
R=thakis
BUG= 850682 
CQ_INCLUDE_TRYBOTS=luci.chromium.try:linux_chromium_msan_rel_ng;master.tryserver.chromium.linux:linux_chromium_ubsan_rel_ng;luci.chromium.try:linux_chromium_asan_rel_ng;luci.chromium.try:linux_chromium_tsan_rel_ng

Change-Id: I96e74da6d907659b939a0f229693bbd2a6d9140a
Reviewed-on: https://chromium-review.googlesource.com/1119098
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Reviewed-by: Peter Collingbourne <pcc@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#578085}
[modify] https://crrev.com/f002a96e9b788fe71fd1c773a4bc891940c409d8/DEPS
[modify] https://crrev.com/f002a96e9b788fe71fd1c773a4bc891940c409d8/build/config/BUILD.gn
[modify] https://crrev.com/f002a96e9b788fe71fd1c773a4bc891940c409d8/build/config/BUILDCONFIG.gn
[modify] https://crrev.com/f002a96e9b788fe71fd1c773a4bc891940c409d8/build/config/c++/c++.gni
[modify] https://crrev.com/f002a96e9b788fe71fd1c773a4bc891940c409d8/build/config/gcc/BUILD.gn
[modify] https://crrev.com/f002a96e9b788fe71fd1c773a4bc891940c409d8/build/config/posix/BUILD.gn
[modify] https://crrev.com/f002a96e9b788fe71fd1c773a4bc891940c409d8/build/config/win/BUILD.gn
[modify] https://crrev.com/f002a96e9b788fe71fd1c773a4bc891940c409d8/chrome/installer/linux/BUILD.gn
[modify] https://crrev.com/f002a96e9b788fe71fd1c773a4bc891940c409d8/extensions/shell/installer/linux/BUILD.gn
[modify] https://crrev.com/f002a96e9b788fe71fd1c773a4bc891940c409d8/remoting/host/linux/BUILD.gn

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

commit c7b993b3e84a3d35b51f959f21b1418d3cdfed41
Author: Tom Anderson <thomasanderson@chromium.org>
Date: Thu Jul 26 17:15:04 2018

Reland "Stop removing rpath_for_built_shared_libraries from chrome_sandbox"

This is a reland of 43a48785f23a65d5b3f0cefac086d67c3dea4eb0

After [1], the RPATH is no longer set for sanitizer builds.  Also, after [2],
the setuid bit is no longer set on chrome_sandbox anyway.

[1] https://chromium.googlesource.com/chromium/src.git/+/f002a96e9b788fe71fd1c773a4bc891940c409d8
[2] https://chromium.googlesource.com/chromiumos/chromite.git/+/de3a6f421ec7e32c45fd4131f50d2c0a98fcdd56

Original change's description:
> Stop removing rpath_for_built_shared_libraries from chrome_sandbox
>
> For instrumented builds like tsan, this causes chrome_sandbox to reference the
> wrong libc++.so due to a missing RPATH.
>
> Since all configurations we ship don't set RPATH, we don't have to worry about
> security vulnerabilities introduced by RPATH=$ORIGIN.  There's also a check to
> enforce this in chrome/installer/linux/common/installer.include.
>
> BUG= 850682 
>
> Change-Id: I25307bd9de388009acffdbb8de6717210873655b
> Reviewed-on: https://chromium-review.googlesource.com/1092077
> Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
> Reviewed-by: Dirk Pranke <dpranke@chromium.org>
> Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#566099}

Bug:  850682 
Change-Id: I82fda0bd5b8f0222d64dcf6c4b7d1199c7e5e585
Reviewed-on: https://chromium-review.googlesource.com/1150254
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#578346}
[modify] https://crrev.com/c7b993b3e84a3d35b51f959f21b1418d3cdfed41/build/config/gcc/BUILD.gn
[modify] https://crrev.com/c7b993b3e84a3d35b51f959f21b1418d3cdfed41/sandbox/linux/BUILD.gn

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

commit c2b25737b2f878e0917d8cd0553d11c557b5cb92
Author: Scott Violet <sky@chromium.org>
Date: Thu Jul 26 21:00:10 2018

Revert "Remove libcpp_is_static"

This reverts commit f002a96e9b788fe71fd1c773a4bc891940c409d8.

Reason for revert: Dirk bisected the chromeos asan failures and it appears this is the culprit. The output from the failing bots isn't particularly helpful as it doesn't have symbols. Here's a recent failure: https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Linux%20Chromium%20OS%20ASan%20LSan%20Tests%20%281%29/28402

BUG= 867826 

Original change's description:
> Remove libcpp_is_static
> 
> This change makes libc++ a shared_library iff is_component_build=true, just like
> all other components.  This has the advantage that the RPATH doesn't need to be
> set in sanitizer (non-component) builds just so binaries can find libc++.so.
> This CL also changes RPATH to be set iff is_component_build=true.
> 
> Needs buildtools CL:
> https://chromium-review.googlesource.com/c/chromium/buildtools/+/1142370
> 
> TBR=dpranke,jochen
> R=​thakis
> BUG= 850682 
> CQ_INCLUDE_TRYBOTS=luci.chromium.try:linux_chromium_msan_rel_ng;master.tryserver.chromium.linux:linux_chromium_ubsan_rel_ng;luci.chromium.try:linux_chromium_asan_rel_ng;luci.chromium.try:linux_chromium_tsan_rel_ng
> 
> Change-Id: I96e74da6d907659b939a0f229693bbd2a6d9140a
> Reviewed-on: https://chromium-review.googlesource.com/1119098
> Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
> Reviewed-by: Peter Collingbourne <pcc@chromium.org>
> Reviewed-by: Nico Weber <thakis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#578085}

TBR=thakis@chromium.org,pcc@chromium.org,thomasanderson@chromium.org

Change-Id: Ieec9ae83b7c12004521358cf71eb2d09fdfc7a09
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  850682 
Cq-Include-Trybots: luci.chromium.try:linux_chromium_msan_rel_ng;master.tryserver.chromium.linux:linux_chromium_ubsan_rel_ng;luci.chromium.try:linux_chromium_asan_rel_ng;luci.chromium.try:linux_chromium_tsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1151917
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#578435}
[modify] https://crrev.com/c2b25737b2f878e0917d8cd0553d11c557b5cb92/DEPS
[modify] https://crrev.com/c2b25737b2f878e0917d8cd0553d11c557b5cb92/build/config/BUILD.gn
[modify] https://crrev.com/c2b25737b2f878e0917d8cd0553d11c557b5cb92/build/config/BUILDCONFIG.gn
[modify] https://crrev.com/c2b25737b2f878e0917d8cd0553d11c557b5cb92/build/config/c++/c++.gni
[modify] https://crrev.com/c2b25737b2f878e0917d8cd0553d11c557b5cb92/build/config/gcc/BUILD.gn
[modify] https://crrev.com/c2b25737b2f878e0917d8cd0553d11c557b5cb92/build/config/posix/BUILD.gn
[modify] https://crrev.com/c2b25737b2f878e0917d8cd0553d11c557b5cb92/build/config/win/BUILD.gn
[modify] https://crrev.com/c2b25737b2f878e0917d8cd0553d11c557b5cb92/chrome/installer/linux/BUILD.gn
[modify] https://crrev.com/c2b25737b2f878e0917d8cd0553d11c557b5cb92/extensions/shell/installer/linux/BUILD.gn
[modify] https://crrev.com/c2b25737b2f878e0917d8cd0553d11c557b5cb92/remoting/host/linux/BUILD.gn

+pcc It looks like there's some conflict between libstdc++ and libc++abi.  The crash below occurs on libstdc++ 4.8 (but not 7.3).  Do you think we should export libc++ from executables like we did with libc++abi?

tom@tom-VirtualBox:/mnt/hgfs/dev/chromium_1/src/out/linux-cros-asan-lsan$ gdb --args ./aura_unittests --gtest_filter=GestureRecognizerTest.FlushAllOnHide
(gdb) r
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe6bfd700 (LWP 8586)]
0x00000000068383a5 in __cxxabiv1::__vmi_class_type_info::has_unambiguous_public_base(__cxxabiv1::__dynamic_cast_info*, void*, int) const ()
    at ../../buildtools/third_party/libc++abi/trunk/src/private_typeinfo.cpp:321
321	    if (is_equal(this, info->static_type, false))
(gdb) bt
#0  0x00000000068383a5 in __cxxabiv1::__vmi_class_type_info::has_unambiguous_public_base(__cxxabiv1::__dynamic_cast_info*, void*, int) const
    () at ../../buildtools/third_party/libc++abi/trunk/src/private_typeinfo.cpp:321
#1  0x00007fffe53981c8 in __cxxabiv1::__dynamic_cast (src_ptr=0x7fffe563d940 <(anonymous namespace)::ctype_c>, 
    src_type=0x7fffe5622fb0 <typeinfo for std::locale::facet>, dst_type=0x7fffe5622d40 <typeinfo for std::ctype<char>>, src2dst=0)
    at ../../../../src/libstdc++-v3/libsupc++/dyncast.cc:72
#2  0x00007fffe53c2300 in std::has_facet<std::ctype<char> > (__loc=...)
    at /build/gcc-4.8-zbxcSF/gcc-4.8-4.8.4/build/x86_64-linux-gnu/libstdc++-v3/include/bits/locale_classes.tcc:110
#3  0x00007fffe53b76c4 in std::basic_ios<char, std::char_traits<char> >::_M_cache_locale (this=this@entry=0x7fffe563c6e8 <std::cout+8>, 
    __loc=...) at /build/gcc-4.8-zbxcSF/gcc-4.8-4.8.4/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_ios.tcc:159
#4  0x00007fffe53b7810 in std::basic_ios<char, std::char_traits<char> >::init (this=this@entry=0x7fffe563c6e8 <std::cout+8>, __sb=
    0x7fffe563bfc0 <__gnu_internal::buf_cout_sync>)
    at /build/gcc-4.8-zbxcSF/gcc-4.8-4.8.4/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_ios.tcc:132
#5  0x00007fffe53a8e19 in basic_ostream (__sb=<optimized out>, this=<optimized out>, __in_chrg=<optimized out>, __vtt_parm=<optimized out>)
    at /build/gcc-4.8-zbxcSF/gcc-4.8-4.8.4/build/x86_64-linux-gnu/libstdc++-v3/include/ostream:85
#6  std::ios_base::Init::Init (this=<optimized out>) at ../../../../../src/libstdc++-v3/src/c++98/ios_init.cc:91
#7  0x00007fffe563fc00 in ?? () from /usr/lib/x86_64-linux-gnu/libtxc_dxtn.so
#8  0x00007ffff7dea1da in call_init (l=<optimized out>, argc=argc@entry=2, argv=argv@entry=0x7fffffffdf18, env=env@entry=0x615000001c00)
    at dl-init.c:78
#9  0x00007ffff7dea2c3 in call_init (env=<optimized out>, argv=<optimized out>, argc=<optimized out>, l=<optimized out>) at dl-init.c:36
#10 _dl_init (main_map=main_map@entry=0x61a00000fc80, argc=2, argv=0x7fffffffdf18, env=0x615000001c00) at dl-init.c:126
#11 0x00007ffff7deed00 in dl_open_worker (a=a@entry=0x7fffe6bf88b8) at dl-open.c:577
#12 0x00007ffff7dea094 in _dl_catch_error (objname=objname@entry=0x7fffe6bf88a8, errstring=errstring@entry=0x7fffe6bf88b0, 
    mallocedp=mallocedp@entry=0x7fffe6bf88a0, operate=operate@entry=0x7ffff7deea30 <dl_open_worker>, args=args@entry=0x7fffe6bf88b8)
    at dl-error.c:187
#13 0x00007ffff7dee44b in _dl_open (file=0x7fffeddb5800 <.str> "libtxc_dxtn.so", mode=-2147483391, caller_dlopen=<optimized out>, nsid=-2, 
    argc=2, argv=0x7fffffffdf18, env=0x615000001c00) at dl-open.c:661
#14 0x00007ffff77da02b in dlopen_doit (a=a@entry=0x7fffe6bf8ad0) at dlopen.c:66
#15 0x00007ffff7dea094 in _dl_catch_error (objname=0x60300003c5f0, errstring=0x60300003c5f8, mallocedp=0x60300003c5e8, 
    operate=0x7ffff77d9fd0 <dlopen_doit>, args=0x7fffe6bf8ad0) at dl-error.c:187
#16 0x00007ffff77da62d in _dlerror_run (operate=operate@entry=0x7ffff77d9fd0 <dlopen_doit>, args=args@entry=0x7fffe6bf8ad0) at dlerror.c:163
#17 0x00007ffff77da0c1 in __dlopen (file=<optimized out>, mode=<optimized out>) at dlopen.c:87
#18 0x00000000004e2df8 in __interceptor_dlopen ()
    at /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5918
#19 0x00007fffed5364c2 in _mesa_dlopen () at ../../third_party/mesa/src/src/mesa/main/dlopen.h:53
#20 0x00007fffed5362d5 in _mesa_init_texture_s3tc () at ../../third_party/mesa/src/src/mesa/main/texcompress_s3tc.c:116
#21 0x00007fffed1eb34e in init_attrib_groups () at ../../third_party/mesa/src/src/mesa/main/context.c:805
#22 0x00007fffed1ea553 in _mesa_initialize_context () at ../../third_party/mesa/src/src/mesa/main/context.c:958
#23 0x00007fffecd67da4 in OSMesaCreateContextExt () at ../../third_party/mesa/src/src/mesa/drivers/osmesa/osmesa.c:712
#24 0x000000000c38929c in gl::OSMESAApiBase::OSMesaCreateContextExtFn(unsigned int, int, int, int, osmesa_context*) ()
    at ../../ui/gl/gl_bindings_autogen_osmesa.cc:79
#25 0x000000000c18b17c in gl::GLContextOSMesa::Initialize(gl::GLSurface*, gl::GLContextAttribs const&) ()
    at ../../ui/gl/gl_context_osmesa.cc:46
#26 0x000000000c186ab9 in gl::InitializeGLContext(scoped_refptr<gl::GLContext>, gl::GLSurface*, gl::GLContextAttribs const&) ()
    at ../../ui/gl/gl_context.cc:401
#27 0x00000000034339d7 in ui::GLOzoneOSMesa::CreateGLContext(gl::GLShareGroup*, gl::GLSurface*, gl::GLContextAttribs const&) ()
    at ../../ui/ozone/common/gl_ozone_osmesa.cc:60
#28 0x000000000ca92f56 in gl::init::CreateGLContext(gl::GLShareGroup*, gl::GLSurface*, gl::GLContextAttribs const&) ()
    at ../../ui/gl/init/gl_factory_ozone.cc:39
#29 0x000000000cfd5a1d in InitializeOnGpuThread () at ../../gpu/ipc/in_process_command_buffer.cc:400
#30 0x000000000cff5acb in Invoke<gpu::ContextResult (gpu::InProcessCommandBuffer::*)(gpu::InProcessCommandBuffer::InitializeOnGpuThreadParams const&), gpu::InProcessCommandBuffer*, gpu::InProcessCommandBuffer::InitializeOnGpuThreadParams> () at ../../base/bind_internal.h:516
#31 0x000000000cff579e in MakeItSo<gpu::ContextResult (gpu::InProcessCommandBuffer::*)(gpu::InProcessCommandBuffer::InitializeOnGpuThreadParams const&), gpu::InProcessCommandBuffer*, gpu::InProcessCommandBuffer::InitializeOnGpuThreadParams> () at ../../base/bind_internal.h:616
#32 0x000000000cff5525 in RunImpl<gpu::ContextResult (gpu::InProcessCommandBuffer::*)(gpu::InProcessCommandBuffer::InitializeOnGpuThreadParams const&), std::__1::tuple<base::internal::UnretainedWrapper<gpu::InProcessCommandBuffer>, gpu::InProcessCommandBuffer::InitializeOnGpuThreadParams>, 0, 1> () at ../../base/bind_internal.h:689
#33 0x000000000cff52e9 in RunOnce () at ../../base/bind_internal.h:658
#34 0x000000000cff62e1 in Run () at ../../base/callback.h:99
#35 0x000000000cfeb221 in operator() () at ../../gpu/ipc/in_process_command_buffer.cc:92
#36 0x000000000cfeb1a9 in Invoke<(lambda at ../../gpu/ipc/in_process_command_buffer.cc:90:18), base::OnceCallback<gpu::ContextResult ()>, gpu::ContextResult *, base::WaitableEvent *>(void) () at ../../base/bind_internal.h:403
#37 0x000000000cfeafcd in MakeItSo<(lambda at ../../gpu/ipc/in_process_command_buffer.cc:90:18), base::OnceCallback<gpu::ContextResult ()>, gpu::ContextResult *, base::WaitableEvent *>(void) () at ../../base/bind_internal.h:616
#38 0x000000000cfeaf6d in RunImpl<(lambda at ../../gpu/ipc/in_process_command_buffer.cc:90:18), std::__1::tuple<base::OnceCallback<gpu::ContextResult ()>, gpu::ContextResult *, base::WaitableEvent *>, 0, 1, 2>(void) () at ../../base/bind_internal.h:689
#39 0x000000000cfeae49 in RunOnce () at ../../base/bind_internal.h:658
#40 0x0000000002588af1 in Run () at ../../base/callback.h:99
#41 0x000000000aa3e434 in RunTask () at ../../base/debug/task_annotator.cc:101
#42 0x000000000a3c74a7 in base::MessageLoop::RunTask(base::PendingTask*) () at ../../base/message_loop/message_loop.cc:424
#43 0x000000000a3c7d27 in DeferOrRunPendingTask () at ../../base/message_loop/message_loop.cc:435
#44 0x000000000a3c890f in DoWork () at ../../base/message_loop/message_loop.cc:483
#45 0x000000000a3eba46 in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) ()
    at ../../base/message_loop/message_pump_default.cc:37
#46 0x000000000a3c5e9b in Run () at ../../base/message_loop/message_loop.cc:376
#47 0x000000000a56708b in Run () at ../../base/run_loop.cc:102
#48 0x000000000a7054a0 in base::Thread::Run(base::RunLoop*) () at ../../base/threading/thread.cc:262
#49 0x000000000a70758a in ThreadMain () at ../../base/threading/thread.cc:357
#50 0x000000000a9c6afb in ThreadFunc () at ../../base/threading/platform_thread_posix.cc:76
#51 0x00007ffff75c3184 in start_thread (arg=0x7fffe6bfd700) at pthread_create.c:312
#52 0x00007ffff309603d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Also it looks like this isn't the first time someone's ran into this issue:
https://stackoverflow.com/questions/34583871/crash-in-boostpython-when-returning-a-pointer-to-llvmvalue

I'm not sure how much that would help. The issue appears to be that there are two ABI libraries loaded with default visibility, which is a good way for bad things to happen. Assuming that this started happening with your change I don't know how it didn't cause an issue before but maybe we were getting lucky.

In https://codereview.chromium.org/2876693003/ I stopped mesa from loading libtxc_dxtn.so when msan is enabled (contrary to one of the comments it was not reverted, I created the revert by mistake), maybe we should do the same thing with asan/ubsan-vptr as well?

Ok I think I figured it out.  The issue is -rdynamic is only passed on desktop Linux, not CrOs:
https://cs.chromium.org/chromium/src/build/config/BUILDCONFIG.gn?rcl=0fba4dc907589bf2425c43d7e036fc9088a12d8c&l=580

If I add that config when (is_asan || is_ubsan_vptr), then the test passes.

Okay, adding that config when (is_asan || is_ubsan_vptr) seems like the right thing to do. We might want to do something about the dueling ABI libraries but maybe not if it isn't causing an actual problem in practice.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/buildtools/+/9a90d9aaadeb5e04327ed05775f45132e4b3523f

commit 9a90d9aaadeb5e04327ed05775f45132e4b3523f
Author: Tom Anderson <thomasanderson@chromium.org>
Date: Fri Jul 27 23:14:29 2018

Use new export_libcxxabi_from_executables variable

The variable is added in src CL [1] to simplify some complex logic.

[1] https://chromium-review.googlesource.com/c/chromium/src/+/1153978

BUG= 850682 
R=pcc

Change-Id: I7d026d0400de2e7f990faa6a08a457ae22dff0b4

[modify] https://crrev.com/9a90d9aaadeb5e04327ed05775f45132e4b3523f/third_party/libc++/BUILD.gn
[modify] https://crrev.com/9a90d9aaadeb5e04327ed05775f45132e4b3523f/third_party/libc++abi/BUILD.gn

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

commit 8a1a7293f365fb2685ae57fa24d34b7ee72ad8dd
Author: Tom Anderson <thomasanderson@chromium.org>
Date: Mon Jul 30 20:05:37 2018

Remove libcpp_is_static and add export_libcxxabi_from_executables

This includes a reland of [1].  The original CL was broken on certain ChromeOS
configs because -rdynamic wasn't getting set on executables.  This CL fixes the
issue by adding //build/config/compiler:export_dynamic.

This change makes libc++ a shared_library iff is_component_build=true, just like
all other components.  This has the advantage that the RPATH doesn't need to be
set in sanitizer (non-component) builds just so binaries can find libc++.so.
This CL also changes RPATH to be set iff is_component_build=true.

Needs buildtools CL [2].

[1] https://chromium.googlesource.com/chromium/src/+/f002a96e9b788fe71fd1c773a4bc891940c409d8
[2] https://chromium-review.googlesource.com/c/chromium/buildtools/+/1153974

R=thakis,pcc,dpranke
TBR=jochen,michaelpg,sergeyu
BUG= 850682 
CQ_INCLUDE_TRYBOTS=luci.chromium.try:linux_chromium_msan_rel_ng;master.tryserver.chromium.linux:linux_chromium_ubsan_rel_ng;luci.chromium.try:linux_chromium_asan_rel_ng;luci.chromium.try:linux_chromium_tsan_rel_ng

Change-Id: I0067041dab85e16595bdeb2f790a68443208117f
Reviewed-on: https://chromium-review.googlesource.com/1153978
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Reviewed-by: Peter Collingbourne <pcc@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#579138}
[modify] https://crrev.com/8a1a7293f365fb2685ae57fa24d34b7ee72ad8dd/DEPS
[modify] https://crrev.com/8a1a7293f365fb2685ae57fa24d34b7ee72ad8dd/build/config/BUILD.gn
[modify] https://crrev.com/8a1a7293f365fb2685ae57fa24d34b7ee72ad8dd/build/config/BUILDCONFIG.gn
[modify] https://crrev.com/8a1a7293f365fb2685ae57fa24d34b7ee72ad8dd/build/config/c++/c++.gni
[modify] https://crrev.com/8a1a7293f365fb2685ae57fa24d34b7ee72ad8dd/build/config/compiler/BUILD.gn
[modify] https://crrev.com/8a1a7293f365fb2685ae57fa24d34b7ee72ad8dd/build/config/gcc/BUILD.gn
[modify] https://crrev.com/8a1a7293f365fb2685ae57fa24d34b7ee72ad8dd/build/config/posix/BUILD.gn
[modify] https://crrev.com/8a1a7293f365fb2685ae57fa24d34b7ee72ad8dd/build/config/win/BUILD.gn
[modify] https://crrev.com/8a1a7293f365fb2685ae57fa24d34b7ee72ad8dd/chrome/installer/linux/BUILD.gn
[modify] https://crrev.com/8a1a7293f365fb2685ae57fa24d34b7ee72ad8dd/components/nacl/loader/BUILD.gn
[modify] https://crrev.com/8a1a7293f365fb2685ae57fa24d34b7ee72ad8dd/extensions/shell/installer/linux/BUILD.gn
[modify] https://crrev.com/8a1a7293f365fb2685ae57fa24d34b7ee72ad8dd/remoting/host/linux/BUILD.gn

The resolution is that libc++ now gets linked statically into the (C-only) sandbox binary in sanitizer builds, and component builds still have this issue, correct? (Which is fine.)

That's correct.  Actually, now that you mention it, I think update-linux-sandbox.sh should probably give an error if it detects a component build.

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

commit 2b8a836630dcf0d5c5eba4ecdcc71a5f1ebfb914
Author: Tom Anderson <thomasanderson@chromium.org>
Date: Wed Aug 01 17:41:34 2018

Require CHROME_DEVEL_SANDBOX to be built with a non-component config

Also:
* Remove an out-of-date comment.
* Add binutils to install-build-deps.sh for readelf and grep.  We already use
  binutils in many places, and it's likely already installed everywhere, but
  it's good to list out direct dependencies.

BUG= 850682 
R=thakis

Change-Id: I80830ad42fe37f1b93f393f5a6ca5af68ef92998
Reviewed-on: https://chromium-review.googlesource.com/1157436
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#579853}
[modify] https://crrev.com/2b8a836630dcf0d5c5eba4ecdcc71a5f1ebfb914/build/config/gcc/BUILD.gn
[modify] https://crrev.com/2b8a836630dcf0d5c5eba4ecdcc71a5f1ebfb914/build/install-build-deps.sh
[modify] https://crrev.com/2b8a836630dcf0d5c5eba4ecdcc71a5f1ebfb914/build/update-linux-sandbox.sh