similar to: [LLVMdev] PATCH: AddressSanitizer: Fix errors about mis-matched exception specifiers for intercepted libc functions on Linux

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

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

done: r159132. On Mon, Jun 25, 2012 at 1:47 PM, 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,

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: >

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

Hi, I triggered a build failure on a Windows-sanitizer by making the sanity checking in `ASAN_INTERCEPT_FUNC` a bit stricter. My best guess is that the type of the defined interceptor is not compatible (in C++ typing terms) with the “real” function. This seems to be the case for the following 2 functions: CreateThread “no conversion”: From: 'DWORD (__cdecl *)(void * ,

I am guessing that sanitizers are not supported with static linking. The AddressSanitizer document says so explicitly but the others do not. Yet the interceptors use dlsym to set up certain system calls, so by definition they can't support static linking. Given that sanitizers won't work with static linking, why are static libraries created for them? Should there be an error check in the

On Mon, Jun 25, 2012 at 4:00 PM, Chandler Carruth <chandlerc at google.com>wrote: > Context: I'm trying to implement support for ASan's unittest suite in > CMake. This is ... quite challenging. > > I think I can get it to work with one significant caveat: it will require > manual dependency management. None of the automatic header tracking. I > think this is fine

Context: I'm trying to implement support for ASan's unittest suite in CMake. This is ... quite challenging. I think I can get it to work with one significant caveat: it will require manual dependency management. None of the automatic header tracking. I think this is fine in some cases, and not so fine in other cases. Let me explain. It feels like these tests are really comprised of two

Hello, I have been working on porting ASan to AArch64. I am building compiler-rt in "standalone mode" targeting aarch64. My build is successful, but I get the following runtime error when I run an ASan enabled executable through qemu-aarch64: ==29184==Parsed ASAN_OPTIONS: verbosity=1 ==29184==AddressSanitizer: failed to intercept '__isoc99_printf' ==29184==AddressSanitizer:

Hi Evgeniy, Now that I can run check-asan without the AArch64 tests, there are a number of ARM tests that fail with the wrong line number on the CHECK line... use-after-delete.cc:20:18: error: expected string not found in input // CHECK-Linux: {{ #1 0x.* in main .*use-after-delete.cc:}}[[@LINE-10]] <stdin>:9:33: note: with expression "@LINE-10" equal to "10" #0

Hello, I am building sanitizers for our different platforms and trying to use it in an example program, but while it seems like ASAN is running it's init functions (see stdout below with ASAN_OPTIONS=verbosity=1) it never catches anything in the program. This is LLVM 8.0.1 btw. I was using this small test case: int main(int argc, char** argv) { int *array = new int[100]; delete []

> On 2 Sep 2016, at 11:18, Dmitry Vyukov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, Sep 1, 2016 at 2:30 PM, Kuba Brecka <kuba.brecka at gmail.com> wrote: >> Hi, >> >> I'm trying to write a TSan interceptor for the C++11 call_once function. There are currently false positive reports, because the inner __call_once function is located in

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 2 Sep 2016, at 12:11, Dmitry Vyukov <dvyukov at google.com> wrote: > > On Fri, Sep 2, 2016 at 12:09 PM, Kuba Brecka <kuba.brecka at gmail.com> wrote: >> >>> On 2 Sep 2016, at 11:18, Dmitry Vyukov via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> On Thu, Sep 1, 2016 at 2:30 PM, Kuba Brecka <kuba.brecka at gmail.com>

Hi, I'm trying to write a TSan interceptor for the C++11 call_once function. There are currently false positive reports, because the inner __call_once function is located in the (non-instrumented) libcxx library, and on macOS we can't expect the users to build their own instrumented libcxx. TSan already supports pthread_once and dispatch_once by having interceptors that re-implement the

I have simple standalone ASan examples working on Android, and now I'd like to try using ASan with the Android build system. I'm building the release_33 branch of llvm+clang+compiler-rt with CMake. To test, I'm looking at libjpg, because with just a small change its Android.mk it compiles in a few seconds and without needing any additional dependencies. When I run 'djpeg' on

Hello Alex, Thanks for the hint. It was actually not the -O flag that created the problem. But it pointed me in the right direction, when I passed -fno-experimental-new-pass-manager it started to show the error. My guess is that the new pass manager is more aggressive in removing UB? Thanks, Tobias On Mon, Feb 3, 2020 at 5:29 PM Alex Brachet-Mialot <alexbrachetmialot at gmail.com> wrote:

On Tue, Jun 19, 2012 at 10:59 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Tue, Jun 19, 2012 at 10:46 PM, Kostya Serebryany <kcc at google.com>wrote: > >> >> >> On Wed, Jun 20, 2012 at 9:39 AM, Chandler Carruth <chandlerc at google.com>wrote: >> >>> On Tue, Jun 19, 2012 at 9:07 PM, Kostya Serebryany <kcc at

On Mon, Jun 25, 2012 at 5:43 PM, Kostya Serebryany <kcc at google.com> wrote: > > > On Mon, Jun 25, 2012 at 4:00 PM, Chandler Carruth <chandlerc at google.com>wrote: > >> Context: I'm trying to implement support for ASan's unittest suite in >> CMake. This is ... quite challenging. >> >> I think I can get it to work with one significant