similar to: [LLVMdev] How do I add suppressions to LSan when testing LLVM with ASan enabled?

On 7 October 2014 20:55, Evgeniy Stepanov <eugenis at google.com> wrote: > Can you elaborate on this? Does it ever clean those lines? These > numbers are correct on multiple other platforms. I wonder if it's some > codegen peculiarity that leads to this off-by-one mistake? Can you go > down to the individual compile/run invocation and verify that line > numbers match (or

On 8 October 2014 11:18, Evgeniy Stepanov <eugenis at google.com> wrote: > Something you could try: ASAN_OPTIONS=fast_unwind_on_malloc=0 should > switch to cfi unwinder and fix the stack trace, but that's not a > solution to the problem. Is this when compiling Clang? The file? or running the final binary? --renato

First off, thanks -- this is a pretty great library and it feels like I'm learning a lot. I'm getting some more experience with libfuzzer and finding that I have a couple of questions: - How does libfuzzer decide to write a new test file? What distinguishes this one from all the other cases for which new test inputs were not written? Must be something about the path taken through the

On Mon, Aug 10, 2015 at 8:08 PM, Kostya Serebryany <kcc at google.com> wrote: > > > On Mon, Aug 10, 2015 at 5:53 PM, Brian Cain via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> First off, thanks -- this is a pretty great library and it feels like I'm >> learning a lot. >> > > Thanks! > > >> I'm getting some

On Thu, Nov 12, 2015 at 8:42 PM, Kostya Serebryany <kcc at google.com> wrote: > 2 questions: > - Do you see this with the fresh llvm trunk? > - Can you prepare a minimized example? Pretty recent, I updated a couple days ago. I tried to minimize the attached but at the same time I didn't want to lose too many unions and casts in case it didn't trigger any more. $ clang

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. -------------- next part

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

Hi, Currently the first stage ("run sanitizer tests in gcc build") of the sanitizer-ppc64-linux1 buildbot is only failing because of: + cd clang_build + make -j16 check-lsan make: *** No rule to make target `check-lsan'. Stop. + echo @@@STEP_FAILURE@@@ @@@STEP_FAILURE@@@ + cd clang_build + make -j16 check-msan make: *** No rule to make target `check-msan'. Stop. + echo

LGTM. I think it is totally reasonable to just disable LSan directly in tablegen at least for now. I would leave some comments on the disabling to clarify: 1) What it does, the reader may not have heard about LSan. 2) Some of the high-level information from this thread as pointers for anyone who wants to go and fix this some day. -Chandler On Wed, Dec 25, 2013 at 2:26 PM, Kostya Serebryany

How about tweaking the compiler-rt cmakefiles so that if lsan is not supported, the target check-lsan still exists but does nothing? I've attached a patch that does this. (I don't know much about cmake so there might be a better way of doing it.) Alternatively, can I change the zorg build script so that "run sanitizer tests in gcc build" doesn't try to run check-lsan etc

On Wed, Dec 25, 2013 at 9:38 PM, dblaikie at gmail.com <dblaikie at gmail.com> wrote: > Its generally been by design that tblgen leaks. Might be nice to fix one day > but it's been that way for a while now so don't expect it to be fixed soon. > > If thats the suppression mechanism of choice (I would've expected a build > flag option) for lsan, I'd say go for

Hi, We are trying to enable LeakSanitizer on our asan/msan llvm bootstrap bot (http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/). In clang itself there are two leaks (http://llvm.org/bugs/show_bug.cgi?id=18318, http://llvm-reviews.chandlerc.com/D2472) and one lsan-hostile feature (http://llvm.org/bugs/show_bug.cgi?id=18320), all of which are easy to fix. And there are also

Hello, On modern Linux installs, glibc has a very annoying practice: it adds an empty exception specifier to lots of libc functions as an optimization. It only does this if the compiler is modern and GCC-like, and we are compiling in C++ mode. This, however, causes GCC to complain about signature mismatches between the glibc functions declared in malloc.h and those defined as an alias in the

http://bugs.freedesktop.org/show_bug.cgi?id=15777 Summary: nouveau driver crash with Xen kernel Product: xorg Version: 7.3 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy: hub at

On Mon, Jun 25, 2012 at 1:10 PM, Chandler Carruth <chandlerc at google.com> wrote: > Hello, > > On modern Linux installs, glibc has a very annoying practice: it adds an > empty exception specifier to lots of libc functions as an optimization. It > only does this if the compiler is modern and GCC-like, and we are compiling > in C++ mode. > > This, however, causes GCC

On Mon, Dec 8, 2014 at 2:00 AM, Alexander Potapenko <glider at google.com> wrote: > Hope you're assuming there's always a single copy of common_flags in > the process. > This isn't the case for e.g. ASan+UBSan on Mac, but that's a broken setup. > > What if we let the tools protect specific flags (by adding a bool to > each flag) once they set their values

I really don't see why this is the correct fix. 1) I like including the system's headers. It ensures that the interceptor DTRT. 2) It's hardly the only system header you pull in here 3) I think we should probably match what glibc does when declaring these routines. any reason to avoid this? On Mon, Jun 25, 2012 at 3:00 AM, Kostya Serebryany <kcc at google.com> wrote: >

.. And the right fix would be to completely get rid of "#include <malloc.h>" in this file. I'll do that change. --kcc On Mon, Jun 25, 2012 at 1:42 PM, Alexander Potapenko <glider at google.com>wrote: > On Mon, Jun 25, 2012 at 1:10 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > Hello, > > > > On modern Linux installs, glibc has

Hi all, TL;DR 1) We should change the way we parse common runtime flags in sanitizers. 2) We should make ASan aware of the tools it can be combined with (LSan and UBSan). 3) We may have to restrict the tools UBSan can be combined with (currently to ASan) (see [1]) Currently we have two kinds of sanitizer runtime flags: tool-specific flags and "common flags", defined in sanitizer_common

I have ported ASan in LLVM to Myriad RTEMS, and I would like to upstream the port. Below is the design doc. Feedback welcome. https://docs.google.com/document/d/1oxmk0xUojybDaQDAuTEVpHVMi5xQX74cJPyMJbaSaRM The port is expected to work with modified versions of RTEMS and newlib. I have a git repo with changes to those projects, that I can make available if there is interest. Here is the patch