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

[Jack Howarth]

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