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

[Alexey Samsonov via cfe-dev]

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).


>
>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160209/e34c806f/attachment.html>