[cfe-dev] Sanitizer test failures when switching to libc++ by default

Wed Feb 10 16:07:26 PST 2016

On Wed, Feb 10, 2016 at 7:30 AM, Hahnfeld, Jonas <
Hahnfeld at itc.rwth-aachen.de> wrote:

>
>
>
>
> *From:* cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] *On Behalf Of *Hahnfeld,
> Jonas via cfe-dev
> *Sent:* Wednesday, February 10, 2016 7:43 AM
> *To:* Alexey Samsonov
> *Cc:* cfe-dev at lists.llvm.org
>
> *Subject:* Re: [cfe-dev] Sanitizer test failures when switching to libc++
> by default
>
>
>
>
>
>
>
> *From:* Alexey Samsonov [mailto:vonosmas at gmail.com <vonosmas at gmail.com>]
> *Sent:* Wednesday, February 10, 2016 1:54 AM
> *To:* Hahnfeld, Jonas
> *Cc:* Kostya Serebryany; cfe-dev at lists.llvm.org
> *Subject:* Re: [cfe-dev] Sanitizer test failures when switching to libc++
> by default
>
>
>
>
>
> On Sat, Feb 6, 2016 at 1:33 AM, Hahnfeld, Jonas <
> Hahnfeld at itc.rwth-aachen.de> wrote:
>
>
>
> *From:* Alexey Samsonov [mailto:vonosmas at gmail.com]
> *Sent:* Friday, February 05, 2016 11:05 PM
> *To:* Kostya Serebryany
> *Cc:* Hahnfeld, Jonas; cfe-dev at lists.llvm.org
> *Subject:* Re: [cfe-dev] Sanitizer test failures when switching to libc++
> by default
>
>
>
> On Fri, Feb 5, 2016 at 11:11 AM, Kostya Serebryany via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>
>
>
>
> On Fri, Feb 5, 2016 at 6:21 AM, Hahnfeld, Jonas via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> Hi all,
>
> I'm currently looking into (optionally) switching the default C++ stdlib to
> libc++ (see http://reviews.llvm.org/D15920 which hasn't received a review
> so
> far)
> I've resolved all regression test failures in clang which are now passing
> cleanly.
>
> I'm now investigating the failing sanitizer tests in compiler-rt, here's
> what I got so far:
>  - two tests use -static-libstdc++ which obviously needs a
> -stdlib=libstdc++
> (asan/TestCases/throw_invoke_test.cc and tsan/static_init6.cc)
>
>
>
> Makes sense.
>
> I wonder if we can also use -static-libc++ for these tests
>
>
>
> At least in my build there is not static version of libc++… I think this
> isn’t built by default but I haven’t yet searched for an opt-in.
>
>
>
>  - tsan builds an instrumented version of libc++ and adds their headers.
> This leads to errors with default C headers which are #include_next'd in
> libc++. These #include_next then find the headers of the "normal" libc++
> which in turn instantly return because of the header guards. Therefore
> basic
> functions like printf aren't defined.
> Solution: Pass -nostdinc++ to disable the headers of the "normal" libc++
>
>
>
> emm, probably.
>
>
>
> Just to clarify: do you want to pass it to TSan lit tests? How would you
> ensure that
>
> we'll still pick up C++ standard library headers when tests are run with
> Clang configured
>
> to use libstdc++?
>
>
>
> I’m planning on passing it in test/tsan/lit.cfg around line 57. Those
> flags are only applied if an instrumented version of libcxx is available
> and there is an explicit definition of the header include path, so this
> should work.
>
>
>
> I see. Yes, probably -nostdinc++ would work in this case.
>
>
>
>
>
>
>
>  - lsan completely fails with libc++, I had to generally pass
> -stdlib=libstdc++ - is this known and possibly still work in progress?
>
>
>
> This is not known to me. What are the symptoms?
>
>
>
> “LeakSanitizer has encountered a fatal error” on all C++ tests. This is
> fixed when building the tests with “-stdlib=libstdc++”, everything else
> still built with libc++…
>
> I also can’t debug with gdb because the errors seems to not occur inside a
> debugger :-( is there any special trick with the sanitizers inside a
> debugger that I have not found yet?
>
>
>
> LSan uses ptrace to stop the program and list all its threads, the same as
> GDB. So, LSan is sadly special in this case. You can try to gain more
> insight into what's happening by running the binary
>
> with smth. like LSAN_OPTIONS=verbosity=1:log_pointers=1:log_threads=1
> (apart from LSAN_OPTIONS specified in each lit test case).
>
>
>
> Thanks for the hint, I will try and see whether I can get some reliable
> information…
>
>
>
> --
>
> Ok, so here are my findings so far:
>
> verbosity=1 revealed the output “Tracer caught signal 11: […]”
>
> So I disabled the signal handler and the core-file told me that it died
> when dereferencing the first TLS address in “ScanRangeForPointers()” in
> lib/lsan/lsan_common.cc.
>
> (this also explains the behavior within gdb: It then can’t attach to the
> thread and therefore doesn’t  crash on scanning TLS)
>
>
>
> For me it looks like “ThreadSelf()” in
> lib/sanitizer_common/sanitizer_linux_libcdep.cc reports a wrong address…
>
> I can reproduce this with a small C++ program that only contains an empty
> main: It crashes with –fsanitize=leak –stdlib=libc++ and works fine with
> –stdlib=libstdc++.
>

... but if there's only main() then you don't have threads except for the
main thread. Or does LSan crash when trying to access TLS of a main thread?
That's weird anyway. It may be the case that libc++ initializers use TLS
differently than libstdc++ ones.

>
>
> Information on my system: x86-64, Scientific Linux 6.6 -> glibc 2.12
>
> It seems to work with libc++ on CentOS 7, but then why is libstdc++ also
> working on SL6?
>

I don't know. Is there a difference in what ThreadSelf() and (in
particular) ThreadDescriptorSize() report on these platforms? This code is
really fragile, and it can easily fail for certain versions or forks of
glibc.

>
>
>
>
>
> Greetings,
> Jonas
>
> --
> Jonas Hahnfeld, MATSE-Auszubildender
>
> IT Center
> Group: High Performance Computing
> Division: Computational Science and Engineering
> RWTH Aachen University
> Seffenter Weg 23
> D 52074  Aachen (Germany)
> Hahnfeld at itc.rwth-aachen.de
> www.itc.rwth-aachen.de
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
>
>
> --
>
> Alexey Samsonov
> vonosmas at gmail.com
>
>
>
>
>
> --
>
> Alexey Samsonov
> vonosmas at gmail.com
>

-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160210/9704380c/attachment.html>