Disable intercept_tls_get_addr for LSan tests on linux.

google/sanitizers#1322

According to that github issue, lsan will mistakenly detect "2.19 for
the real glibc of version 2.25 or higher."

On our xenial test bots, /lib/x86_64-linux-gnu/libc.so.6 is 2.23. On
our bionic test bots, libc is 2.27. So when we switched our asan/lsan
tests to bionic, we started hitting strange lsan errors:

Tracer caught signal 11: addr=0x330004f3 pc=0x55af5266644a sp=0x7f405e956d40
==28674==LeakSanitizer has encountered a fatal error.
eg: https://chromium-swarm.appspot.com/task?id=53745e69a9525810

It appears that error is the same reported in the github issue, as
disabling the DTLS check prevents those same LSan errors.

Though this doesn't entirely explain why the failures are transient
when nothing about the bots seemingly changes. eg:
https://ci.chromium.org/p/chromium/builders/ci/Linux%20ASan%20LSan%20Tests%20%281%29
Why does components_unittests fail in builds 89913 - 89916, but is
fine before and after?

Bug: 1200574
Change-Id: Id8ffed3bd50d648a1147de50bb4fd2f001c01d12
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2888418
Reviewed-by: Thomas Anderson <[email protected]>
Reviewed-by: Garrett Beaty <[email protected]>
Reviewed-by: Dirk Pranke <[email protected]>
Owners-Override: Garrett Beaty <[email protected]>
Commit-Queue: Ben Pastene <[email protected]>
Cr-Commit-Position: refs/heads/master@{#883698}

Author: bpastene

testing/test_env.py

@@ -94,6 +94,10 @@ def get_sanitizer_env(cmd, asan, lsan, msan, tsan, cfi_diag):
     asan_options = symbolization_options[:]
     if lsan:
       asan_options.append('detect_leaks=1')
+      # LSan appears to have trouble with later versions of glibc.
+      # See https://github.com/google/sanitizers/issues/1322
+      if 'linux' in sys.platform:
+        asan_options.append('intercept_tls_get_addr=0')
 
     if asan_options:
       extra_env['ASAN_OPTIONS'] = ' '.join(asan_options)