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

[Vitaly Buka via Phabricator via llvm-commits]

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,
----------------
vitalybuka wrote:
> 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.
> 
> 
> 
D48265 works for me


Repository:
  rL LLVM

https://reviews.llvm.org/D44623