[LLVMdev] radr://12777299, "potential pthread/eh bug exposed by libsanitizer"

[Jack Howarth]

On Thu, Nov 29, 2012 at 11:15:37AM -0800, Alexander Potapenko wrote:
> If this is the same test:
> http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/eh/cond1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1,
> then it doesn't fail for me on Mac OS 10.8 with ASan (Clang r168632)
> Have you tried symbolizing the report?

Alexander,
    Which c++ compiler are you testing with? You won't reproduce the problem on clang++
because it is using a wildly different libstdc++ than FSF g++ 4.8 (see the gdb traces
I posted earlier in reply to Kostya). I have reproduced this failure with...

g++-fsf-4.8 -fsanitize=address -std=c++98 cond1.C -o cond1_asan.exe 

on darwin10, darwin11 and darwin12 against current FSF gcc trunk's libasan. I also
verified that switching the FSF gcc X86_64 Fedora 15 to use emutls (like darwin)
via --disable-tls doesn't trigger the bug on linux. I would also note that the
gdb trace for the FSF gcc build of cond1.C seems to execute exactly the same
compared the -fsanitize=address build with FSF gcc except latter crashes at the
final call to dyld_stub_pthread_once()...

0x00000001023f842a in dyld_stub_pthread_once ()
(gdb) 
Single stepping until exit from function dyld_stub_pthread_once, 
which has no line number information.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000000ffd27000
0x00000000ffd27000 in ?? ()

                     Jack

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