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

[Alexander Potapenko]

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