<html><body>
<p><font size="2" face="sans-serif">Alexey, Alexander,</font><br>
<br>
<font size="2" face="sans-serif">Thanks for the suggestions. I tried removing the flag </font><tt><font size="2">SA_NODEFER </font></tt><font size="2" face="sans-serif">but it didn't do any good...</font><font size="2" face="sans-serif"> 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 go away (!).</font><br>
<br>
<font size="2" face="sans-serif">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:</font><br>
<br>
<font size="2" face="sans-serif"> store i64 %0, i64* %9, align 8, !dbg !35, !nosanitize !2</font><br>
<font size="2" face="sans-serif"> call void @__asan_poison_cxx_array_cookie(i64* %9), !dbg !35</font><br>
<font size="2" face="sans-serif"> %10 = getelementptr inbounds i8* %call, i64 8, !dbg !35</font><br>
<font size="2" face="sans-serif"> %11 = bitcast i8* %10 to %struct.C*, !dbg !35</font><br>
<font size="2" face="sans-serif"> call void @llvm.dbg.value(metadata !{%struct.C* %11}, i64 0, metadata !23), !dbg !36</font><br>
<font size="2" face="sans-serif"> %x = bitcast i8* %call to i32*, !dbg !37</font><br>
<font size="2" face="sans-serif"> %12 = ptrtoint i32* %x to i64, !dbg !37</font><br>
<font size="2" face="sans-serif"> %13 = lshr i64 %12, 3, !dbg !37</font><br>
<font size="2" face="sans-serif"> %14 = add i64 %13, 2199023255552, !dbg !37</font><br>
<font size="2" face="sans-serif"> %15 = inttoptr i64 %14 to i8*, !dbg !37</font><br>
<font size="2" face="sans-serif"> %16 = load i8* %15, !dbg !37</font><br>
<font size="2" face="sans-serif"> %17 = icmp ne i8 %16, 0, !dbg !37</font><br>
<font size="2" face="sans-serif"> br i1 %17, label %18, label %24, !dbg !37, !prof !38</font><br>
<br>
<font size="2" face="sans-serif">; <label>:18 ; preds = %entry</font><br>
<font size="2" face="sans-serif"> %19 = and i64 %12, 7, !dbg !37</font><br>
<font size="2" face="sans-serif"> %20 = add i64 %19, 3, !dbg !37</font><br>
<font size="2" face="sans-serif"> %21 = trunc i64 %20 to i8, !dbg !37</font><br>
<font size="2" face="sans-serif"> %22 = icmp sge i8 %21, %16, !dbg !37</font><br>
<font size="2" face="sans-serif"> br i1 %22, label %23, label %24</font><br>
<br>
<font size="2" face="sans-serif">; <label>:23 ; preds = %18</font><br>
<font size="2" face="sans-serif"> call void @__asan_report_store4(i64 %12), !dbg !37</font><br>
<font size="2" face="sans-serif"> call void asm sideeffect "", ""()</font><br>
<font size="2" face="sans-serif"> unreachable</font><br>
<br>
<font size="2" face="sans-serif">; <label>:24 ; preds = %18, %entry</font><br>
<font size="2" face="sans-serif"> store i32 10, i32* %x, align 4, !dbg !37, !tbaa !39</font><br>
<font size="2" face="sans-serif"> %25 = call i64 @__asan_load_cxx_array_cookie(i64* %9), !dbg !44</font><br>
<br>
<font size="2" face="sans-serif">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. </font><br>
<br>
<font size="2" face="sans-serif">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?</font><br>
<br>
<font size="2" face="sans-serif">Thanks again!</font><br>
<font size="2" face="sans-serif">Samuel</font><br>
<br>
<img width="16" height="16" src="cid:1__=0ABBF7DDDF9B07C78f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for Alexander Potapenko ---09/05/2014 02:06:43 AM---Note that I've set the SA_NODEFER flag for the SEGV h"><font size="2" color="#424282" face="sans-serif">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</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">Alexander Potapenko <glider@google.com></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">Alexey Samsonov <vonosmas@gmail.com></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Cc: </font><font size="1" face="sans-serif">Samuel F Antao/Watson/IBM@IBMUS, Clang Developers List <cfe-dev@cs.uiuc.edu>, LLVM Dev <llvmdev@cs.uiuc.edu></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">09/05/2014 02:06 AM</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">Re: [cfe-dev] Address sanitizer regression test failures for PPC64 targets</font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<tt><font size="2">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 __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>
> (</font></tt><tt><font size="2"><a href="http://lab.llvm.org:8011/builders/sanitizer-ppc64-linux1">http://lab.llvm.org:8011/builders/sanitizer-ppc64-linux1</a></font></tt><tt><font size="2">).<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>
>> </font></tt><tt><font size="2"><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a></font></tt><tt><font size="2"><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>
> </font></tt><tt><font size="2"><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a></font></tt><tt><font size="2"><br>
><br>
<br>
<br>
<br>
-- <br>
Alexander Potapenko<br>
Software Engineer<br>
Google Moscow<br>
<br>
</font></tt><br>
</body></html>