[PATCH] D44623: [ASAN] Fix crash on i?86-linux (32-bit) against glibc 2.27 and later

[Peter Wu via Phabricator via llvm-commits]

Lekensteyn added a comment.

In https://reviews.llvm.org/D44623#1126624, @petarj wrote:

> I can see five failures after it is applied. Here they are:
>
> Failing Tests (5):
>
>     Builtins-i386-linux :: divsc3_test.c
>     LeakSanitizer-AddressSanitizer-x86_64 :: TestCases/Linux/use_tls_dynamic.cc
>     LeakSanitizer-Standalone-x86_64 :: TestCases/Linux/use_tls_dynamic.cc
>     MemorySanitizer-X86_64 :: dtls_test.c
>     MemorySanitizer-lld-X86_64 :: dtls_test.c
>   
>   Expected Passes    : 43861
>   Expected Failures  : 221
>   Unsupported Tests  : 1992
>   Unexpected Failures: 5


Are these tests passing with this patch reverted? What environment and what source revision is this?

I just ran `check-lsan` and can confirm the test failure (though I have not tested it with the patch reverted though):

  ******************** TEST 'LeakSanitizer-AddressSanitizer-x86_64 :: TestCases/Linux/use_tls_dynamic.cc' FAILED ********************
  Indirect leak of 1337 byte(s) in 1 object(s) allocated from:
      #0 0x4ec28f in __interceptor_malloc projects/compiler-rt/lib/asan/asan_malloc_linux.cc:121:3
      #1 0x52af83 in main projects/compiler-rt/test/lsan/TestCases/Linux/use_tls_dynamic.cc:27:13
      #2 0x7ffa49a4006a in __libc_start_main (/usr/lib/libc.so.6+0x2306a)
  
  Objects leaked above:
  0x61a000000680 (1337 bytes)
  
  -----------------------------------------------------
  Suppressions used:
    count      bytes template
        1    1048576 *tls_get_addr*
  -----------------------------------------------------

Perhaps the new implementation leaks pointers on the stack, causing false positives?

If I run the reproducer from the linked issue (`clang -g -fsanitize=address -m32 empty.c -o empty && ./empty`), it crashes without this patch and passes with this patch applied. Building the binary on Arch Linux x86_64 (glib 2.27-3) and running it on Ubuntu 16.04 (glibc 2.23-0ubuntu10) still crashes though. That is expected with this version of the patch as it assumes that libc used for compiling clang matches the runtime libc.

(https://reviews.llvm.org/D46638 was an alternative version that performs a runtime check, but it would need more changes so the current patch seems a good start.)


Repository:
  rL LLVM

https://reviews.llvm.org/D44623