<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt">+glider<div>The compiler hardly matters here, I would expect the same failures with clang. </div><div>Alex, could you please take a look? </div><div><br>
</div><div>--kcc <br><br><div class="gmail_quote">On Thu, Nov 29, 2012 at 9:55 PM, Jack Howarth <span dir="ltr"><<a href="mailto:howarth@bromo.med.uc.edu" target="_blank">howarth@bromo.med.uc.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Nick,<br>
   Can you take a quick look at the <a href="http://asan_eh_bug.tar.bz" target="_blank">asan_eh_bug.tar.bz</a> testcase<br>
I uploaded into the newly opened radr://12777299, "potential<br>
pthread/eh bug exposed by libsanitizer". The FSF gcc developers<br>
have ported <a href="http://llvm.org" target="_blank">llvm.org</a>'s asan code into FSF gcc (and are keeping<br>
it synced to the upstream <a href="http://llvm.org" target="_blank">llvm.org</a> code). I have been helping<br>
with the darwin build and testing -fsanitize=address against the<br>
complete FSF gcc testsuite. This seems to have exposed a potential<br>
bug in pthread or eh on darwin under libasan. Hundreds of test cases<br>
in the g++ and libstdc++ testsuites fail under -fsanitize=address<br>
in the following manner...<br>
<br>
ASAN:SIGSEGV<br>
=================================================================<br>
==2738== ERROR: AddressSanitizer: SEGV on unknown address 0x0000ffd27000 (pc 0x0000ffd27000 sp 0x7fff55e40828 bp 0x7fff55e408f0 T0)<br>
AddressSanitizer can not provide additional info.<br>
    #0 0xffd26fff (/Users/howarth/asan_eh_bug/./cond1_asan.exe+0xf5f67fff)<br>
    #1 0x7fff8bd827e0 (/usr/lib/system/libdyld.dylib+0x27e0)<br>
    #2 0x0<br>
Stats: 0M malloced (0M for red zones) by 3 calls<br>
Stats: 0M realloced by 0 calls<br>
Stats: 0M freed by 0 calls<br>
Stats: 0M really freed by 0 calls<br>
Stats: 1M (384 full pages) mmaped in 3 calls<br>
  mmaps   by size class: 7:4095; 8:2047; 9:1023;<br>
  mallocs by size class: 7:1; 8:1; 9:1;<br>
  frees   by size class:<br>
  rfrees  by size class:<br>
Stats: malloc large: 0 small slow: 3<br>
==2738== ABORTING<br>
<br>
The failure of...<br>
<br>
FAIL: g++.dg/eh/cond1.C -std=c++98 execution test<br>
<br>
was used as the test case for the radar report and compiled with...<br>
<br>
g++-fsf-4.8 -static-libasan -fsanitize=address -std=c++98 cond1.C -g -O0 -o cond1_asan.exe<br>
<br>
to produce the above failure. When compiled without libasan as...<br>
<br>
g++-fsf-4.8 -std=c++98 cond1.C -g -O0 -o cond1_no_asan.exe<br>
<br>
the resulting executable runs fine. Debugging this in gdb seems to show that the failure<br>
is occuring in the final call to dyld_stub_pthread_once (). The same test case<br>
compiles fine with -fsanitize=address under llvm 3.2 clang++ and produces no runtime errors<br>
but the code execution path is very different in that case (because of the different<br>
libstdc++).<br>
    Can you take a quick peek at this and determine if this is a darwin pthread or unwinder<br>
bug or an issue with libasan that FSF gcc's compiler is exposing? Thanks in advance for<br>
any help on this.<br>
         Jack<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br></div></div>