<html><body>
<p><font size="2" face="sans-serif">Kostya,</font><br>
<br>
<font size="2" face="sans-serif">Thanks! The patch seems to have fixed the problem with poison array test! :)</font><br>
<br>
<font size="2" face="sans-serif">I still have some issues with some other testcases. E.g. stress_dtls is getting trapped into some infinite loop, although it seems not to be related with the previous issue. I'll have to investigate a little bit more and will post my conclusions...</font><br>
<br>
<font size="2" face="sans-serif">Thanks again,</font><br>
<font size="2" face="sans-serif">Samuel</font><br>
<br>
<br>
<tt><font size="2">Kostya Serebryany <kcc@google.com> wrote on 10/01/2014 07:35:37 PM:<br>
<br>
> From: Kostya Serebryany <kcc@google.com></font></tt><br>
<tt><font size="2">> To: Samuel F Antao/Watson/IBM@IBMUS</font></tt><br>
<tt><font size="2">> Cc: Clang Developers List <cfe-dev@cs.uiuc.edu>, LLVM Dev <br>
> <llvmdev@cs.uiuc.edu></font></tt><br>
<tt><font size="2">> Date: 10/01/2014 07:35 PM</font></tt><br>
<tt><font size="2">> Subject: Re: [LLVMdev] [cfe-dev] Address sanitizer regression test <br>
> failures for PPC64 targets</font></tt><br>
<tt><font size="2">> <br>
> On Wed, Oct 1, 2014 at 4:13 PM, Samuel F Antao <sfantao@us.ibm.com> wrote:</font></tt><br>
<tt><font size="2">> Hi Kostya,</font></tt><br>
<tt><font size="2">> <br>
> Thanks for looking into this! Currently the test starts calling the <br>
> destructor ~C() several times as it were in a infinite loop and it <br>
> does not return. </font></tt><br>
<tt><font size="2">> <br>
> Aha, I see the problem! </font></tt><br>
<tt><font size="2">> <br>
> The test has an intentional bug that asan is supposed to find. </font></tt><br>
<tt><font size="2">> So, by default and with ASAN_OPTIONS=poison_array_cookie=1 the test <br>
> should never reach the point where it calls ~C. </font></tt><br>
<tt><font size="2">> Is this true for you on PPC? </font></tt><br>
<tt><font size="2">> <br>
> But then, the test is also executed <br>
> with ASAN_OPTIONS=poison_array_cookie=0, i.e. the bug is not <br>
> detected and the execution goes further and tries to execute the DTOR. </font></tt><br>
<tt><font size="2">> And then yes, on a little-endian machine the DTOR will get executed <br>
> 10 times, while on a big-endian one it will get executed near-<br>
> infinite amount of times. </font></tt><br>
<tt><font size="2">> <br>
> Does r218841 help? </font></tt><br>
<tt><font size="2">> <br>
> --kcc </font></tt><br>
<tt><font size="2">> <br>
> </font></tt><br>
<tt><font size="2">> <br>
> I'll try to explain how do I understand the problem. Just to make <br>
> sure we are on the same page, I am attaching the instrumented IR <br>
> that I obtain by running:</font></tt><br>
<tt><font size="2">> <br>
> clang --driver-mode=g++ -fsanitize=address -mno-omit-leaf-frame-<br>
> pointer -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -m64 <br>
> -O3 /home/sfantao/llvm-trunk/llvm-svn.src/projects/compiler-rt/test/<br>
> asan/TestCases/Linux/new_array_cookie_test.cc -o debug.ir -S -emit-llvm</font></tt><br>
<tt><font size="2">> <br>
> In this code %x (i32*) and %9 (*i64) alias to %call. When 10 is <br>
> stored to %x, the way this is reflected in a load from %9 (the ASAN <br>
> calls use this pointer instead of %x) differs depending on the <br>
> endianess. Assuming that %9 and %x are 0x00, the memory layout <br>
> before and after the store in big-endian will be</font></tt><br>
<tt><font size="2">> </font></tt><br>
<tt><font size="2">> Addr - Before - After</font></tt><br>
<tt><font size="2">> 0x00 0xZZ 0xZZ</font></tt><br>
<tt><font size="2">> 0x01 0xZZ 0xZZ</font></tt><br>
<tt><font size="2">> 0x02 0xZZ 0xZZ</font></tt><br>
<tt><font size="2">> 0x03 0xZZ 0x0A</font></tt><br>
<tt><font size="2">> 0x04 0xZZ 0xZZ</font></tt><br>
<tt><font size="2">> 0x05 0xZZ 0xZZ</font></tt><br>
<tt><font size="2">> 0x06 0xZZ 0xZZ</font></tt><br>
<tt><font size="2">> 0x07 0xZZ 0xZZ</font></tt><br>
<tt><font size="2">> <br>
> When a load using %9 is done, I get 0xZZZZZZ0AZZZZZZZZ. In a little-<br>
> endian machine I would get 0xZZZZZZZZZZZZZZ0A instead, what is <br>
> probably what you would expect. Then, when the destructor is called,<br>
> whatever is decoding the size of 'buffer' loads the wrong <br>
> information (possible zero or a very large number, causing the infinite loop).</font></tt><br>
<tt><font size="2">> <br>
> Any hint on how to fix this? I understand some other information is <br>
> being encoded in the pointers, so it is hard for me to understand <br>
> whether fixing this for %x would have bad implications in other <br>
> components of the sanitizer.</font></tt><br>
<tt><font size="2">> <br>
> Let me know if you'd like me to provide more information. </font></tt><br>
<tt><font size="2">> <br>
> Thanks again!</font></tt><br>
<tt><font size="2">> Samuel</font></tt><br>
<tt><font size="2">> <br>
> 2014-10-01 14:28 GMT-04:00 Kostya Serebryany <kcc@google.com>:</font></tt><br>
<tt><font size="2">> <br>
> On Mon, Sep 8, 2014 at 7:00 PM, Samuel F Antao <sfantao@us.ibm.com> wrote:</font></tt><br>
<tt><font size="2">> Alexey, Alexander,<br>
> <br>
> Thanks for the suggestions. I tried removing the flag SA_NODEFER but<br>
> it didn't do any good... I have been digging into the problem with <br>
> the null_deref test today but I was unable to clearly identify the <br>
> problem. I suspect that it was either a bug with the calling <br>
> convention/unwinding that lead to the flags() pointer to get <br>
> corrupted. It is also possible that it was related with endianess <br>
> issues caused by some bug in the pointer arithmetic inserted by the <br>
> sanitizer code (there are many type and bit casts which makes hard <br>
> to follow the references). I decided to upgrade the compiler I was <br>
> using to build clang which made the problem with this testcase to goaway (!).<br>
> <br>
> Nevertheless, I still got problems in other testcases that may be <br>
> potentially related with the problem I was getting before. E.g., in <br>
> the new_array_cookie_test I am getting an infinite loop in the <br>
> destructor of the array (delete [] operator). I noticed that the <br>
> references passed to __asan_poison_cxx_array_cookie and <br>
> __asan_load_cxx_array_cookie were pointing to values differing in <br>
> the 4 most significant bytes, which made me suspect that the problem<br>
> is related with endianess. I am reproducing part of the IR generated<br>
> for this test:</font></tt><br>
<tt><font size="2">> [I am sorry, I've missed this thread. Don't hesitate to ping me if I<br>
> don't respond in 1-2 days. ]</font></tt><br>
<tt><font size="2">> </font></tt><br>
<tt><font size="2">> This is a new test for new functionality, currently present in <br>
> clang's asan, not in GCC. </font></tt><br>
<tt><font size="2">> We never tried it on big-endian machines. </font></tt><br>
<tt><font size="2">> <br>
> <br>
> <br>
> store i64 %0, i64* %9, align 8, !dbg !35, !nosanitize !2<br>
> call void @__asan_poison_cxx_array_cookie(i64* %9), !dbg !35<br>
> %10 = getelementptr inbounds i8* %call, i64 8, !dbg !35<br>
> %11 = bitcast i8* %10 to %struct.C*, !dbg !35<br>
> call void @llvm.dbg.value(metadata !{%struct.C* %11}, i64 0, <br>
> metadata !23), !dbg !36<br>
> %x = bitcast i8* %call to i32*, !dbg !37<br>
> %12 = ptrtoint i32* %x to i64, !dbg !37<br>
> %13 = lshr i64 %12, 3, !dbg !37<br>
> %14 = add i64 %13, 2199023255552, !dbg !37<br>
> %15 = inttoptr i64 %14 to i8*, !dbg !37<br>
> %16 = load i8* %15, !dbg !37<br>
> %17 = icmp ne i8 %16, 0, !dbg !37<br>
> br i1 %17, label %18, label %24, !dbg !37, !prof !38<br>
> <br>
> ; <label>:18 ; preds = %entry<br>
> %19 = and i64 %12, 7, !dbg !37<br>
> %20 = add i64 %19, 3, !dbg !37<br>
> %21 = trunc i64 %20 to i8, !dbg !37<br>
> %22 = icmp sge i8 %21, %16, !dbg !37<br>
> br i1 %22, label %23, label %24<br>
> <br>
> ; <label>:23 ; preds = %18<br>
> call void @__asan_report_store4(i64 %12), !dbg !37<br>
> call void asm sideeffect "", ""()<br>
> unreachable<br>
> <br>
> ; <label>:24 ; preds = %18, %entry<br>
> store i32 10, i32* %x, align 4, !dbg !37, !tbaa !39<br>
> %25 = call i64 @__asan_load_cxx_array_cookie(i64* %9), !dbg !44<br>
> <br>
> In this code, %9 and %x alias but have different types (i64* and <br>
> i32*), which makes the code in 'store i32 10, i32* %x, align 4, !dbg<br>
> !37, !tbaa !39' to produce different results in machines with <br>
> different endianess. In a big-endian machine the value 10 is written<br>
> to the 4 most-significant bytes of the memory referenced by %9. </font></tt><br>
<tt><font size="2">> <br>
> How does the test behave on PPC? </font></tt><br>
<tt><font size="2">> <br>
> --kcc </font></tt><br>
<tt><font size="2">> <br>
> <br>
> As I mentioned before, I don't know the sanitizer implementation <br>
> well so it is possible I may be missing something. Can anyone shed <br>
> some light on this?<br>
> <br>
> Thanks again!<br>
> Samuel<br>
> <br>
> [image removed] Alexander Potapenko ---09/05/2014 02:06:43 AM---Note<br>
> that I've set the SA_NODEFER flag for the SEGV handler in the ASan <br>
> runtime only a couple of day<br>
> <br>
> From: Alexander Potapenko <glider@google.com><br>
> To: Alexey Samsonov <vonosmas@gmail.com><br>
> Cc: Samuel F Antao/Watson/IBM@IBMUS, Clang Developers List <cfe-<br>
> dev@cs.uiuc.edu>, LLVM Dev <llvmdev@cs.uiuc.edu><br>
> Date: 09/05/2014 02:06 AM<br>
> Subject: Re: [cfe-dev] Address sanitizer regression test failures <br>
> for PPC64 targets</font></tt><br>
<tt><font size="2">> <br>
> <br>
> <br>
> <br>
> Note that I've set the SA_NODEFER flag for the SEGV handler in the<br>
> ASan runtime only a couple of days ago.<br>
> Not sure that could've affected this test though; without that flag<br>
> the second SEGV would've simply crashed the program. But you can try<br>
> removing the flag from<br>
> compiler-rt/trunk/lib/sanitizer_common/sanitizer_posix_libcdep.cc and<br>
> see if that makes any difference.<br>
> <br>
> HTH,<br>
> Alex<br>
> <br>
> On Fri, Sep 5, 2014 at 5:26 AM, Alexey Samsonov <vonosmas@gmail.com> wrote:<br>
> > +Bill Schmidt<br>
> ><br>
> > On Thu, Sep 4, 2014 at 5:39 PM, Samuel F Antao <sfantao@us.ibm.com> wrote:<br>
> >><br>
> >> Hi all,<br>
> >><br>
> >> I have been experiencing the failure of the address sanitizer regression<br>
> >> tests for a PPC64 target (Power7 machine). My understanding is that most of<br>
> >> the failures are related with the fact the stack is not being dumped.<br>
> >><br>
> >> I tried to understand what might be wrong and started by looking into the<br>
> >> null_deref.cc test as it hangs during the test run. I observe that after<br>
> >> the detection of the faulty memory access it receives a SEGV after entering<br>
> >> ReportSIGSEGV() more precisely when it gets to the __intercept_strlen() and<br>
> >> tries to access flags()->replace_str. The caller of <br>
> __intercept_strlen() is<br>
> >> get_cie_encoding() from libgcc (version 4.8.2 in my system).<br>
> >><br>
> >> As I am not familiar with the sanitizer implementation, I was wondering if<br>
> >> this is an expected failure for PPC targets due to some incomplete<br>
> >> implementation, an unexpected bug, or due to some misconfiguration in the<br>
> >> Clang/LLVM build for PPC targets.<br>
> >><br>
> >> Has anyone experienced a similar issue?<br>
> ><br>
> ><br>
> > Sanitizer used to work on PPC at some point, but currently it fails on most<br>
> > of the tests from "check-asan" test suite on the PowerPC buildbot<br>
> > (<a href="http://lab.llvm.org:8011/builders/sanitizer-ppc64-linux1">http://lab.llvm.org:8011/builders/sanitizer-ppc64-linux1</a>).<br>
> > I can't really diagnose the issue from your description. flags() is just a<br>
> > pointer to a global variable, so I don't see why access to<br>
> > flags()->replace_str will segfault.<br>
> ><br>
> >><br>
> >><br>
> >><br>
> >> Thanks in advance!<br>
> >> Samuel<br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> cfe-dev mailing list<br>
> >> cfe-dev@cs.uiuc.edu<br>
> >> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
> >><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Alexey Samsonov<br>
> > vonosmas@gmail.com<br>
> ><br>
> > _______________________________________________<br>
> > cfe-dev mailing list<br>
> > cfe-dev@cs.uiuc.edu<br>
> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
> ><br>
> <br>
> <br>
> <br>
> -- <br>
> Alexander Potapenko<br>
> Software Engineer<br>
> Google Moscow<br>
> <br>
</font></tt><br>
<tt><font size="2">> <br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> LLVMdev@cs.uiuc.edu <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</font></tt><br>
<tt><font size="2">> <br>
> <br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> LLVMdev@cs.uiuc.edu <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</font></tt></body></html>