similar to: [LLVMdev] [PATCH] AddressSanitizer: force the __asan_unregister_globals to reside in the runtime library

+llvmdev Question to MacOS gurus: is there a way to disable ASLR (address space layout randomization) on Darwin at link time instead of doing setenv("DYLD_NO_PIE", "1", 1); and reexec? Thanks, --kcc On Fri, Dec 9, 2011 at 4:28 AM, Alexander Potapenko <glider at google.com>wrote: > The attached patch introduces the disable_aslr option (off by default) > and the

(see http://code.google.com/p/address-sanitizer/issues/detail?id=23) In order for exceptions to work correctly, it should be possible to unwind through the functions wrapped by ASan RTL (in particular, __cxa_throw()) Because we intentionally build the runtime with -fno-exceptions, we need at least the unwind tables to support _Unwind_Backtrace(). -- Alexander Potapenko Software Engineer Google

Options when creating a main executable -pie This makes a special kind of main executable that is position independent (PIE). On Mac OS X 10.5 and later, the OS the OS will load a PIE at a random address each time it is executed. You cannot create a PIE from .o files compiled with -mdy- namic-no-pic. That means the

Hi Alex Thanks for your email. But it seems not work. I removed the -fsanitize=address flag. The global buffer overflow message doesn't show. However, no *.sancov file is created after I run perlbench. Thus, I could not get the BB coverage. Do you have any ideas? Many Thanks Regards Muhui Alexander Potapenko <glider at google.com> 于2018年9月5日周三 下午7:14写道： > Hi Muhui, > > If

If this is the same test: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/eh/cond1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1, then it doesn't fail for me on Mac OS 10.8 with ASan (Clang r168632) Have you tried symbolizing the report? On Thu, Nov 29, 2012 at 11:07 AM, Alexander Potapenko <glider at google.com> wrote: > Jack, can you please upload this test somewhere?

On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > Just want to remind everyone that we plan to stop using mach_override in > asanin favor of OSX's native function interposition. > So, we probably don't want to spend too much effort fixing mach_override. > > --kcc Kostya, Is the native function interposition that is being adopted based on...

.. 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, can you please check the problem is fixed by r195125? On Tue, Nov 19, 2013 at 2:35 PM, Alexander Potapenko <glider at google.com> wrote: > Hi Cameron, > > I'm planning to address this issue today. > > HTH, > Alex > > On Mon, Nov 18, 2013 at 9:45 PM, Cameron McInally > <cameron.mcinally at nyu.edu> wrote: >> Hey guys, >> >> My local

Hi If so, is it able to disable this check. All I need is just to get the BB coverage information Regards Muhui Alexander Potapenko <glider at google.com>于2018年9月5日 周三下午6:57写道： > This is a known problem in SPECCPU2006, see > https://github.com/google/sanitizers/wiki/AddressSanitizerFoundBugs > On Wed, Sep 5, 2018 at 7:36 AM Muhui Jiang via llvm-dev > <llvm-dev at

Looks like this happens on x86_64 because the position of __cxa_throw is too far from the allocated branch island (should be <2G). This can be solved by allocating the branch islands somewhere near the text segment (look for kIslandEnd in asan_mac.cc, this is currently 0x7fffffdf0000) or by patching the function with a longer instruction sequence that stores the jump target in a register and

Just want to remind everyone that we plan to stop using mach_override in asanin favor of OSX's native function interposition. So, we probably don't want to spend too much effort fixing mach_override. --kcc On Fri, Nov 30, 2012 at 4:46 AM, Alexander Potapenko <glider at google.com>wrote: > Looks like this happens on x86_64 because the position of __cxa_throw > is too far from

No, we are not going to use mach_inject. This isn't portable and may be even harder to set up than mach_override. The new ASan runtime will use the dylib interposition and will in fact require DYLD_INSERT_LIBRARIES to work. However ASan already handles it correctly itself: if the corresponding env var is missing the app is just re-execed. Dylib interposition is supported by Apple and should

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,

Jack, can you please upload this test somewhere? On Thu, Nov 29, 2012 at 10:09 AM, Kostya Serebryany <kcc at google.com> wrote: > +glider > The compiler hardly matters here, I would expect the same failures with > clang. > Alex, could you please take a look? > > --kcc > > > On Thu, Nov 29, 2012 at 9:55 PM, Jack Howarth <howarth at bromo.med.uc.edu> >

+kledzik at apple.com The dynamic runtime is using dylib interposition (google for "__DATA,__interpose). If I'm understanding correctly (Nick, can you please confirm this?) this allows to interpose the function regardless of the two-level namespace. The support for dynamic runtime in ASan is almost there. But the new interposition method has revealed some issues with the allocator which

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

Currently the replacement of allocation routines is based on creating a new malloc zone and a new CFAllocator (because the allocator replacement is done later than it could be, we must have both). This makes us depend on CoreFoundation to call CFAllocatorSetDefault. Because of some bugs in CF which start firing after CFAllocatorSetDefault, we have to add several hacks to circumvent the effects of

On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > Just want to remind everyone that we plan to stop using mach_override in > asanin favor of OSX's native function interposition. > So, we probably don't want to spend too much effort fixing mach_override. > > --kcc Kostya, Unless I am misunderstanding the code in asan/asan_intercepted_functions.h,

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

+kremenek, ganna On Sat, Dec 1, 2012 at 4:33 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > > Just want to remind everyone that we plan to stop using mach_override in > > asanin favor of OSX's native function interposition. > > So, we probably don't want to spend too much effort fixing