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