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

Vitaly Buka via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Jun 16 15:29:50 PDT 2018


vitalybuka added inline comments.


================
Comment at: compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc:208
+  if (CHECK_GET_TLS_STATIC_INFO_VERSION &&
+      !dlvsym(RTLD_NEXT, "glob", "GLIBC_2.27"))
+    CallGetTls<GetTlsStaticInfoRegparmCall>(get_tls_static_info_ptr,
----------------
Lekensteyn wrote:
> vitalybuka wrote:
> > This breaks lsan:
> > 
> > ```
> > ==211269==Sanitizer CHECK failed: compiler-rt/lib/lsan/lsan_interceptors.cc:54 ((!lsan_init_is_running)) != (0) (0, 0)
> > ```
> > 
> > dlvsym calls malloc when lsan is not initialized
> > 
> > 
> > 
> Ok, I can reproduce this with `-fsanitize=leak` (but not `-fsanitize=address`), but only in this setting:
> - `#define CHECK_GET_TLS_STATIC_INFO_VERSION 1`
> - `dlvsym(RTLD_NEXT, "globsomethingnonexisting", ...)`
> This presumably affects only 32-bit libraries with glibc before 2.27.
> 
> I did not see any buildbot complain on this though, how did you catch this issue? It seems a lack of test coverage.
> 
> If it does not need an immediate fix (buildbots are not blocked), I could try to work on using the `confstr` patch again to dynamically query the glibc version which should avoid malloc. Otherwise the patch needs to be reverted.
>> -fsanitize=leak (but not -fsanitize=address), but only in this setting:
Asan malloc interceptor will use internal buffer for allocations which happen before asan is initialized.

>> I did not see any buildbot complain on this though, how did you catch this issue? It seems a lack of test coverage
Looks like bots have no i386 libs installed. I will try to fix that.





Repository:
  rL LLVM

https://reviews.llvm.org/D44623





More information about the llvm-commits mailing list