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

[Alexander Potapenko]

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?

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