[compiler-rt] r269917 - [sanitizer] Fix a crash when demangling Swift symbols, take 3

[Kuba Brecka via llvm-commits]

http://reviews.llvm.org/D20911

> On 19 May 2016, at 19:29, Kuba Brecka via llvm-commits <llvm-commits at lists.llvm.org> wrote:
> 
> There was a failure on the Windows bot.
> 
> I’ll try to commit this again and add empty function.
> 
> Kuba
> 
>> On 19 May 2016, at 19:09, Kostya Serebryany <kcc at google.com <mailto:kcc at google.com>> wrote:
>> 
>> But you've reverted it right? 
>> Please, do find another fix. 
>> Otherwise the whole project will drown in #ifdefs
>> 
>> On Thu, May 19, 2016 at 10:07 AM, Kostya Serebryany <kcc at google.com <mailto:kcc at google.com>> wrote:
>> 
>> 
>> On Thu, May 19, 2016 at 4:02 AM, Kuba Brecka <jbrecka at apple.com <mailto:jbrecka at apple.com>> wrote:
>> 
>>> On 18 May 2016, at 20:00, Kostya Serebryany <kcc at google.com <mailto:kcc at google.com>> wrote:
>>> 
>>> 
>>> 
>>> On Wed, May 18, 2016 at 6:00 AM, Kuba Brecka via llvm-commits <llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>> wrote:
>>> Author: kuba.brecka
>>> Date: Wed May 18 08:00:20 2016
>>> New Revision: 269917
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=269917&view=rev <http://llvm.org/viewvc/llvm-project?rev=269917&view=rev>
>>> Log:
>>> [sanitizer] Fix a crash when demangling Swift symbols, take 3
>>> 
>>> The previous patch (r269291) was reverted (commented out) because the patch caused leaks that
>>> were detected by LSan and they broke some lit tests.  The actual reason was that dlsym allocates
>>> an error string buffer in TLS, and some LSan lit tests are intentionally not scanning TLS for
>>> root pointers.  This patch simply makes LSan ignore the allocation from dlsym, because it's
>>> not interesting anyway.
>>> 
>>> 
>>> Modified:
>>>     compiler-rt/trunk/lib/asan/asan_rtl.cc
>>>     compiler-rt/trunk/lib/tsan/rtl/tsan_rtl.cc
>>> 
>>> Modified: compiler-rt/trunk/lib/asan/asan_rtl.cc
>>> URL: http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/asan/asan_rtl.cc?rev=269917&r1=269916&r2=269917&view=diff <http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/asan/asan_rtl.cc?rev=269917&r1=269916&r2=269917&view=diff>
>>> ==============================================================================
>>> --- compiler-rt/trunk/lib/asan/asan_rtl.cc (original)
>>> +++ compiler-rt/trunk/lib/asan/asan_rtl.cc Wed May 18 08:00:20 2016
>>> @@ -553,8 +553,14 @@ static void AsanInitInternal() {
>>> 
>>>    InitializeSuppressions();
>>> 
>>> -  // TODO(kuba) Fix Me.
>>> -  // Symbolizer::LateInitialize();
>>> +  {
>>> +#if CAN_SANITIZE_LEAKS
>>> 
>>> This adds one more #ifdef. 
>>> Please, can we have fewer of those? 
>>> 
>>> if(CAN_SANITIZE_LEAKS) or similar would be much better! 
>> 
>> Again, I’d love to use regular ifs, but I thought doing so causes linker errors.  But, to my surprise, it seems that all my local builds work fine -- it seems that Clang just removes if(0) blocks even in debug builds.  Is that guaranteed?  
>> 
>> I don't think this is really 100% guaranteed, but "if (0) code() " will usually be deleted even at -O0. 
>> If we see linker errors we should fix them by providing the stubs for functions where they are missing.
>>  
>> I committed r270038 to see how the other bots like this.
>> 
>> Thanks! 
>>  
>> 
>> Kuba
>> 
>> 
>> 
>> 
>> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160602/9c8dd364/attachment.html>