Marshall Clow
2014-Jan-09 20:53 UTC
[LLVMdev] [cfe-dev] lsan for LLVM bootstrap; leaks in TableGen
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? 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/llvm-dev/attachments/20140109/48497f0d/attachment.html>
Kostya Serebryany
2014-Jan-10 04:02 UTC
[LLVMdev] [cfe-dev] lsan for LLVM bootstrap; leaks in TableGen
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/llvm-dev/attachments/20140110/07be8827/attachment.html>
Kostya Serebryany
2014-Jan-10 13:04 UTC
[LLVMdev] [cfe-dev] lsan for LLVM bootstrap; leaks in TableGen
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/llvm-dev/attachments/20140110/cf6d2aa8/attachment.html>