[cfe-dev] [LLVMdev] lsan for LLVM bootstrap; leaks in TableGen

[Kostya Serebryany]

FTR: LLVM is now LeakSanitizer-clean, lsan is enabled on the sanitizer
bootstrap bot, which is green:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap

--kcc


On Fri, Jan 10, 2014 at 8:02 AM, Kostya Serebryany <kcc at google.com> wrote:

>
>
>
> On Fri, Jan 10, 2014 at 12:53 AM, Marshall Clow <mclow.lists at gmail.com>wrote:
>
>> On Dec 25, 2013, at 11:55 PM, Kostya Serebryany <kcc at google.com> wrote:
>>
>> On Thu, Dec 26, 2013 at 11:49 AM, Chandler Carruth <chandlerc at google.com>
>>  wrote:
>>
>>>
>>> On Thu, Dec 26, 2013 at 2:40 AM, Kostya Serebryany <kcc at google.com>
>>>  wrote:
>>>
>>>> Like this?
>>>>
>>>> +extern "C" {
>>>> +// Disable LeakSanitizer, see
>>>> http://llvm.org/bugs/show_bug.cgi?id=18325.
>>>>
>>>
>>> We don't often reference bugs in comments. I would give a brief summary
>>> in the text of the comment, and mention the bug in the commit log.
>>>
>>
>>> This?
>>
>> +extern "C" {
>> +// Disable LeakSanitizer for this binary as it has too many leaks that
>> are not
>> +// very interesting to fix. __lsan_is_turned_off is explained in
>> +// compiler-rt/include/sanitizer/lsan_interface.h
>> +int __lsan_is_turned_off() { return 1; }
>> +}  // extern “C"
>>
>>
>> [ Sorry to be joining the conversation late ]
>>
>> What is the reasoning behind having them define a function to disable
>> lsan, rather than calling __lsan_disable?
>> Is it so that lsan can be turned off before main() is entered?
>>
>
> Yes. Also, this allows us to disable lsan w/o modifying the source file
> where main() is defined
>
> --kcc
>
>
>
>> I’m not really happy with the idea of the user having to define a
>> function with a reserved name in their code.
>>
>> — Marshall
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140110/cf6d2aa8/attachment.html>