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

Kostya Serebryany kcc at google.com
Thu Jan 9 20:02:33 PST 2014


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/07be8827/attachment.html>


More information about the cfe-dev mailing list