Re: ASAN - How to suppress strlen Error ?

You can run Asan in error recovery mode (it's not generally recommended as errors after the first one can not be reported reliably but normally it works fine). You can see details e.g. in this answer: https://github.com/google/sanitizers/issues/649#issuecomment-176304136 On 2/19/19, Hiren Shah

Re: Leak sanitizer not working with optimisations enabled

Hi Ankur, If pointer to allocated buffer manages to survive in one of the registers or on stack (after program returns from main), LSan would consider buffer to be reachable and won't report it. This behavior is very sensitive to compiler/Glibc version and compilation flags. On 2/15/19, Ankur

Re: How to use address sanitizer on a sub process

On Mon, May 21, 2018 at 5:24 PM, Konstantin Serebryany wrote: > > > On Mon, May 21, 2018 at 9:01 AM Seshadri R wrote: >> >> Hi, >> >> I want to use address sanitizer to profile a program (say A). However, >> this program is launched as

Re: Address Sanitizer with Ruby Nokogiri module/Gem

On Fri, May 18, 2018 at 11:05 PM, Konstantin Serebryany wrote: > > > On Fri, May 18, 2018 at 2:30 PM MK wrote: >> >> Hi kcc, >> >> Thanks for your hint. It did get me further to some point. >> >> I successfully compiled Ruby, libxml2,

Re: RFC: Enable core dumps even on 64-bit platforms

; useful with asan reports and because they will cause more trouble then is > worth it (atexit timeout, disk full, etc) Well, maybe this isn't an issue with madv_dont_dump being default? > On Wed, Jul 26, 2017 at 11:57 PM, Yuri Gribov <tetra2...@gmail.com> wrote: >> &

RFC: Enable core dumps even on 64-bit platforms

Hi all, Currently core dumps are disabled on 64-bit platforms. This decisions come from old times when 16 TB shadow memory was included in coredump. Nowadays we have use_madv_dontdump (enabled by default) which keeps size of core file reasonable. Perhaps we can disable disable_coredump on all

Re: Making adaptive redzones less aggressive

On Mon, Jul 17, 2017 at 10:25 AM, 'Alexander Potapenko' via address-sanitizer <address-sanitizer@googlegroups.com> wrote: > On Sat, Jul 15, 2017 at 4:39 PM, Yuri Gribov <tetra2...@gmail.com> wrote: >> Hi all, >> >> From reading the original feature reques

Making adaptive redzones less aggressive

Hi all, >From reading the original feature request in https://github.com/google/sanitizers/issues/8 it seems that adaptive redzones were mainly meant for catching overflows in arrays of large objects e.g. struct { int a[10]; int x; } a[100]; a[101].x = 0; // Skips redzone Current

Re: c1plus: error: unrecognized command line option "-fsanitize=address"

e=address' To understand what's going on, you probly need to inspect config.log and see which command is failing and why. > On Fri, Jul 7, 2017 at 4:25 PM, Yuri Gribov <tetra2...@gmail.com> wrote: >> >> On Fri, Jul 7, 2017 at 10:48 AM, Ramin Farajpour Cami >> <ramin.black...@gmai

Re: c1plus: error: unrecognized command line option "-fsanitize=address"

S FOR A PARTICULAR PURPOSE. > > > > On Friday, July 7, 2017 at 2:00:50 PM UTC+4:30, Yuri Gribov wrote: >> >> On Fri, Jul 7, 2017 at 10:22 AM, Ramin Farajpour Cami >> <ramin.b...@gmail.com> wrote: >> > i don't know, i spend many time for r

Re: c1plus: error: unrecognized command line option "-fsanitize=address"

se try to execute gcc --version g++ --version c++ --version and report your findings. > On Friday, July 7, 2017 at 11:18:33 AM UTC+4:30, Yuri Gribov wrote: >> >> On Fri, Jul 7, 2017 at 7:32 AM, Ramin Farajpour Cami >> <ramin.b...@gmail.com> wrote: >> >

Re: c1plus: error: unrecognized command line option "-fsanitize=address"

On Fri, Jul 7, 2017 at 7:32 AM, Ramin Farajpour Cami wrote: > Yuri, > > again i have error: > > [root@localhost usb]# ./configure CXXFLAGS="-fsanitize=address -ggdb" > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is

Re: c1plus: error: unrecognized command line option "-fsanitize=address"

On Fri, Jul 7, 2017 at 6:41 AM, Ramin Farajpour Cami wrote: > Hi, > > I going to enable ASAN for my C++ program,i install libasan package, i get > this error message, i don't know how to resolve it? You need a newer compiler (gcc 4.7 at least, newer versions are

Re: How to enable GCC Asan dynamic shadow address?

On Mon, Jun 12, 2017 at 9:23 AM, steven shi wrote: > Hi Yuri, >> >> >> > Note that this flag only allows you to set fixed offset (in contrast, >> > dynamic offset allows the selection to be done at runtime). This may >> > or may not be enough for your case. > > > It is not

Re: How to enable GCC Asan dynamic shadow address?

On Fri, Jun 9, 2017 at 5:51 AM, steven shi wrote: > Hi Yuri, > I'm trying to use the Kasan -fasan-shadow-offset option to work around the > Asan fixed shadow offset issue in gcc. I see you enabled it with this patch > https://patchwork.ozlabs.org/patch/402873/. If it works,

Re: GetPreviousInstructionPc question

On Thu, Apr 20, 2017 at 10:53 AM, 'Dmitry Vyukov' via address-sanitizer <address-sanitizer@googlegroups.com> wrote: > On Thu, Apr 20, 2017 at 11:50 AM, Yuri Gribov <tetra2...@gmail.com> wrote: >> On Thu, Apr 20, 2017 at 10:20 AM, 'Dmitry Vyukov' via >> address-s

Re: ASN for MIPS with either clang or gcc

On Wed, Dec 14, 2016 at 12:15 PM, Maxim Ostapenko wrote: > Hi, > > 2016-12-14 10:23 GMT+03:00 Park Kit : >> >> Hi Maxim, >> >> Sorry for a slow response since I took some time to check ASAN's working >> on a target platform. Thanks to your help, have

Re: Proposal to add support for structure inner elements in Asan

o C at all) > > And I totally agree that this is a large missing piece in asan. > > --kcc > > On Thu, Dec 1, 2016 at 9:31 PM, Yuri Gribov <tetra2...@gmail.com> wrote: >> >> On Fri, Dec 2, 2016 at 7:22 AM, Yuri Gribov <tetra2...@gmail.com> wrote: >>

Re: Proposal to add support for structure inner elements in Asan

On Fri, Dec 2, 2016 at 7:22 AM, Yuri Gribov <tetra2...@gmail.com> wrote: > On Fri, Dec 2, 2016 at 6:35 AM, Maxim Ostapenko <chefm...@gmail.com> wrote: >> Hi, >> >> 02 Дек 2016 г. 7:30 пользователь "steven shi" <shijunj...@gmail.com> >

Re: Proposal to add support for structure inner elements in Asan

On Fri, Dec 2, 2016 at 6:35 AM, Maxim Ostapenko wrote: > Hi, > > 02 Дек 2016 г. 7:30 пользователь "steven shi" > написал: >> >> Hello, >> With the experts' help in this community, I've enabled the Asan for global >> and stack buffer in my bare-mental

Re: ASAN without pthread support

FYI there have been many attempts in applying ASan to bare-metal and at least some were successful. E.g. http://events.linuxfoundation.org/sites/events/files/slides/Alexander_Popov-KASan_in_a_Bare-Metal_Hypervisor_0.pdf and also grep for "bare-metal" and similar stuff in this group. Given that

Re: Any way to make ASAN/UBSAN continue after the first error?

UBSan should behave like this by default and for ASan you'll need -fsanitize-recover=address (see the very first question in FAQ at https://github.com/google/sanitizers/wiki/AddressSanitizer for details). Note that you'll need recent GCC and Clang as the feature is quite new. On Mon, Sep 12,

Re: UBSan suppressions on embedded system

On Mon, May 9, 2016 at 10:35 AM, 'Ilya' via address-sanitizer wrote: > >> Worst case you could wrap problematic code in #ifdef >> __SANITIZE_UNDEFINED__ and provide dedicated implementation. What's >> the problem with packed stuff though? > > > Yep, but I'd

Re: configure scripts, pthread detection and asan

On Wed, Jan 20, 2016 at 8:44 PM, Konstantin Serebryany wrote: > > > On Wed, Jan 20, 2016 at 9:40 AM, Hanno Böck wrote: >> >> On Wed, 20 Jan 2016 09:14:53 -0800 >> Konstantin Serebryany wrote: >> >> > Are you

Re: Stack oob not detected with -O2

On Sun, Jan 17, 2016 at 11:56 AM, John Regehr wrote: > Would it be possible to add an option specifying that the asan > instrumentation is done before running any optimizers? Presumably this would > offer an interesting tradeoff where there transparent bugs aren't missed

Re: Stack oob not detected with -O2

It's in ASan FAQ btw. On Fri, Jan 15, 2016 at 7:58 PM, Konstantin Serebryany wrote: > +john > > Yea, if optimizations get rid of the buggy code before asan gets a chance to > instrument it -- the bug will be missed. > We've seen it before in many *trivial*

Re: Experimental detection of usage on an uninitialized memory

On Thu, Jan 14, 2016 at 11:45 PM, Konstantin Serebryany <konstantin.s.serebry...@gmail.com> wrote: > > > On Thu, Jan 14, 2016 at 12:17 PM, Yuri Gribov <tetra2...@gmail.com> wrote: >> >> Hi Martin, >> >> On Thu, Jan 14, 2016 at 3:17 PM, Martin Liška

Re: "check_initialization_order=true" command line option?

On Thu, Jan 14, 2016 at 6:59 AM, wrote: > >> >> If you want to bake in some options at compile time, there are a few >> >> ways >> >> to do it. -DASAN_DEFAULT_OPTIONS=check_initialization_order=true will >> >> work, >> >> or you can define the __asan_default_options function

Re: "check_initialization_order=true" command line option?

On Tue, Jan 12, 2016 at 7:57 PM, wrote: > > > On Monday, January 11, 2016 at 1:51:58 PM UTC-5, Reid Kleckner wrote: >> >> Which command line are you referring to, the compiler command line or the >> application command line? > > > When we invoke the compiler, we want to

Re: Failure on large allocation

On Fri, Jun 5, 2015 at 9:21 PM, 'Alexey Samsonov' via address-sanitizer address-sanitizer@googlegroups.com wrote: Wow, the world of 1Tb RAM machines is here. 1) You can try to allocate 156Gb of memory with mmap() instead of malloc(). 2) 64Gb is a hard limit on allocation size in ASan runtime.

Re: unknown-crash with __asan_memset

On Fri, Jun 5, 2015 at 9:32 PM, Yuri Gribov tetra2...@gmail.com wrote: On Fri, Jun 5, 2015 at 9:12 PM, 'Alexey Samsonov' via address-sanitizer address-sanitizer@googlegroups.com wrote: Looks like the position of Java heap (0xdfff8000) interferes with ASan shadow memory mappings. See memory

Re: unknown-crash with __asan_memset

On Wed, May 27, 2015 at 1:52 PM, Dmitriy - dima00...@gmail.com wrote: Hello all. I try using ASan for debug jvm. All .so library in jvm instrumented with ASan. But, I have some error here: LD_PRELOAD=/usr/lib/libclang_rt.asan-x86_64.so

Re: Android L arm address sanitizer problem

On Wed, May 6, 2015 at 10:57 PM, 'Evgeniy Stepanov' via address-sanitizer address-sanitizer@googlegroups.com wrote: Again, sorry for the delayed response. There were lots of ASan-related changes both in LLVM repo and in AOSP in the last two weeks. You were right, ASan in AOSP was limited to

Re: [PINGv2][PATCH] Ignore alignment by option

On Thu, Dec 4, 2014 at 8:06 PM, 'Dmitry Vyukov' via address-sanitizer address-sanitizer@googlegroups.com wrote: You answered your own question about user space :) Yeah, I hoped someone would rush to overpersuade me... -Y -- You received this message because you are subscribed to the Google

Re: Small improvements to run_spec_clang_asan.sh

Cool! Could someone apply this then? On Wed, Oct 1, 2014 at 2:18 PM, 'Evgeniy Stepanov' via address-sanitizer address-sanitizer@googlegroups.com wrote: Sorry, my bad, missed the $ sign. On Wed, Oct 1, 2014 at 2:03 PM, Yuri Gribov tetra2...@gmail.com wrote: On Wed, Oct 1, 2014 at 1:56 PM

Re: AddressSanitizer's allocator

On Fri, Sep 26, 2014 at 4:08 PM, Jonas Wagner jonas.wag...@epfl.ch wrote: Also, this might be very interesting for the stack, too. I think even a slightly randomized stack layout (through random redzone sizes or variable reordering) could make it harder to write exploits. I know ASan is a

Re: Small improvements to run_spec_clang_asan.sh

On Fri, Sep 19, 2014 at 4:13 PM, 'Evgeniy Stepanov' via address-sanitizer address-sanitizer@googlegroups.com wrote: CLANG=${CLANG:-clang} You probably need the same for CLANGXX I do this in the next block (autodetection is different clang and gcc are different). Why are you disabling leak

Re: Small improvements to run_spec_clang_asan.sh

On Fri, Sep 19, 2014 at 9:02 PM, Yuri Gribov tetra2...@gmail.com wrote: I don't understand this LD_LIBRARY_PATH magic, what's its for? Snap, believe it or not but that's a typo. It should be ASAN_OPTIONS and the weird expression optionally inserts : in front of added options (so that user can

Small improvements to run_spec_clang_asan.sh

Hi all, Here is a small patch for https://code.google.com/p/address-sanitizer/source/browse/trunk/spec/run_spec_clang_asan.sh which * updates docs * adds some option verification * adds GCC support * disables leak detection Does the change look sane? -Y -- You received this message because

Re: GCC Asan report some unexpected log when an error detected, anyone explain me why?

I used Gcc Asan recomplied only one shared lib, and I think the interceptors only works for this lib, why the other could call those asan interceptors? No-no, that's not how interceptors work on Linux. They shadow libc definitions globally. -Y -- You received this message because you are

Re: GCC Asan report some unexpected log when an error detected, anyone explain me why?

I think those interceptors means that we define the same name functions as libc, like memset, and preload it before libc, so the instrumented code call the asan memset not the libc memset. Right. So the preload decides whether call asan memset or not, and Gcc Asan only preload the

Re: Does anyone can post a Manual of the usage of Asan in GCC4.9(arm, x86, etc) here? For testing excutable and shared liberary,thanks.

On Wed, Jul 30, 2014 at 5:49 AM, ji wang mason.wan...@gmail.com wrote: And Here is an output of GCC on X86 to compare with FYI I'm getting the same link sequence if I link hello-world with GCC 4.10 x86 and ARM Linux toolchains (and they both match your results for x86). As for Android, link

Re: Does anyone can post a Manual of the usage of Asan in GCC4.9(arm, x86, etc) here? For testing excutable and shared liberary,thanks.

On Tue, Jul 29, 2014 at 10:34 AM, ji wang mason.wan...@gmail.com wrote: Do you mean Android? ARM Linux should be 100% similar to x86 Linux. Yes, I mean Android. I am using Asan enabled GCC android toolchain now. From Evgeny's words it seems that GCC Asan and LLVM Asan work differently on

Re: Problem about using LLVM Asan for checking android shared lib like libhwui.so...

On Wed, Jul 23, 2014 at 3:23 PM, 'Evgeniy Stepanov' via address-sanitizer address-sanitizer@googlegroups.com wrote: There is an idea that I always wanted to implement for ASan applications to re-exec themselves if they are run with asanwrapper (i.e. without ASan runtime library in LD_PRELOAD

Re: Problem about using LLVM Asan for checking android shared lib like libhwui.so...

On Wed, Jul 23, 2014 at 3:55 PM, 'Evgeniy Stepanov' via address-sanitizer address-sanitizer@googlegroups.com wrote: Yes. In fact, to all platforms that need LD_PRELOAD-style hacks. Yeah, this would be a useful feature. I see if we can implement this. -Y -- You received this message because

Re: Reverse poisoning

On Wed, Jul 16, 2014 at 7:59 PM, 'Dmitry Vyukov' via address-sanitizer address-sanitizer@googlegroups.com wrote: Also I am not sure what it will give us. For malloc it already works in the best possible way. For other memory it will only verify asan's guessing of what memory is OK to access.

Re: Reverse poisoning

one ring buffer for all frame sizes Ok, this was nonsense. I actually had in mind a per-thread buffer for fake stack frames. -Y -- You received this message because you are subscribed to the Google Groups address-sanitizer group. To unsubscribe from this group and stop receiving emails from

Re: Stack instrumentation for kernel.

On Tue, Jul 8, 2014 at 5:16 PM, Alexey Preobrazhensky pre...@google.com wrote: On Friday, June 20, 2014 6:26:37 PM UTC+4, Yuri Gribov wrote: On Fri, Jun 20, 2014 at 4:50 PM, Andrey Ryabinin ryabin...@gmail.com wrote: --param asan-memintrin=0 --param asan-fixed-shadow-offset=0 This wasn't

Re: Stack instrumentation for kernel.

All, FYI it should now be possible to replace existing Kasan implementation (which abuses TSan) with stock userspace Asan. We (well, Andrew) have successfully sanitized kernel with CFLAGS = -fsanitize=address --param asan-stack=0 --param asan-globals=0 --param use-after-return=0 --param

Re: Stack instrumentation for kernel.

On Fri, Jun 20, 2014 at 4:50 PM, Andrey Ryabinin ryabinin@gmail.com wrote: --param asan-memintrin=0 --param asan-fixed-shadow-offset=0 This wasn't yet upstreamed. And with --param asan-stack=1 it also works now. This requires asan-fixed-shaw-offset=0. -Y -- You received this message

Re: Future of -fsanitize-recover

What are your reasons? Collect more memory errors from a single run. E.g. I have an embedded system at hand which requires at least 20m for typical fix-compile-run cycle (and some steps like reflashing the device are manual). Being able to fix more than one error at once would significantly

Re: Future of -fsanitize-recover

there are downsides: one bug may trigger another report Doesn't UBSan have the same problem? the user will spend time investigating more reports than needed. True but that would be a concious trade-off. It will create more problems to users and developers than it will solve. Agreed, it

Re: Stack instrumentation for kernel.

Dmitry, I propose to add -fsanitize=kernel-address when the first patch is committed. Now it will just enable -fsanitize=address -asan-instrumentation-with-call-threshold=-1 internally. But later we will be able to change instrumentation for kernel under the hood w/o disturbing users. Yup,

Re: Stack instrumentation for kernel.

Actually I advanced much further than just building and booting. I did some work on the basis of existing implementation from https://github.com/xairy/linux. First of all I removed all x86 specific hacks, so it's cross-platform now (currently I'm running sanitized kernel on ARM board). Also

Re: Out-of-line memory checks

Re-attaching updated implementation just in case. On Mon, Apr 21, 2014 at 10:33 AM, Yuri Gribov tetra2...@gmail.com wrote: So even though my implementation is slightly faster we're still getting a 70% perf hit. interesting. can you show the assembly (objdump -d) for __asan_load8 in both

Re: Out-of-line memory checks

BTW note that we will suffer significant PLT penalty in sanitized shared libs. Don't use shared libs :) I don't ;) - it's all about the users. Solution here is obvious - throw in another static lib that would get linked into DSOs. But this would complicate driver of course. -Y -- You

Re: Out-of-line memory checks

I wonder where such big difference is coming from. I'll examine perf when I finally get my hands on SPEC2006. You don't need SPEC, just run something small like bzip2. Ok, good to know. Here are my results for bunzipping a vmtouched 100M file: gcc: 0m6.315s clang: 0m5.570s clang

Re: Out-of-line memory checks

Meanwhile we've made the first step for Out-of-line memory checks. Looks like an effort duplication, I've been working on this for the last couple of days. btw, I've run SPEC (test data, C only) and it shows that out-of-line instrumentation is 2x slower. I wonder whether this is due to PLT

Re: Out-of-line memory checks

btw, I've run SPEC (test data, C only) and it shows that out-of-line instrumentation is 2x slower. I wonder whether this is due to PLT redirection. clang uses static asan-rt by default, no PLT. Agreed, this will only matter for sanitized shared libraries. I wonder where such big

/dev/byte8

All, FYI one of my colleagues has recently proposed a kernel patch which implements a family of /dev/byteN virtual devices. These could be used as a source of arbitrary byte values (see https://lkml.org/lkml/2014/3/31/466 for more details). /dev/bytes work more or less similiar to /dev/zero and

Re: /dev/byte8

More details? Ok. So currently we initialize shadow memory via anonymous mmap which effectively fills it with zeros. If we filled it with eights instead (by mmapping /dev/byte8), we could simplify Asan check to a single comparison: byte *shadow_address = MemToShadow(address); byte shadow_value

Re: Out-of-line memory checks

That will add some more complexity to the build system. E.g. __asan_read1co will have to reside in a separate library. Yup. You probably want to implement them in hand-written assembly, because otherwise we'll get the same bad code generated by the same compiler. Sure, that goes w/o saying.

Underusage of LIKELY macro in ASan sources

All, I got curious about lack of LIKELY/UNLIKELY annotations in implementation of CHECK* macro and asan_init checks in e.g. asan_malloc.cc. Is this intentional? -Y -- You received this message because you are subscribed to the Google Groups address-sanitizer group. To unsubscribe from this

Out-of-line memory checks

All, I was wondering whether there are plans to add (optional) out-of-line instrumentation of memory accesses i.e. use function calls like __asan_read1 instead of explicit instruction sequence to access shadow memory? AFAIK KernelSanitizer is already using this approach. Memory savings would be

Avoid reserving shadow for kernel area

All, It looks like currently Asan reserves shadow even for kernel area (upper 2G for Windows and 1G for Linux). Is this really necessary? 256M of address space may be important on 32-bit platforms. -Y -- You received this message because you are subscribed to the Google Groups

Re: Avoid reserving shadow for kernel area

On Tue, Mar 18, 2014 at 1:20 PM, Alexander Potapenko gli...@google.com wrote: This sounds feasible. In order to do this we must also shrink the shadow gap so that those 256M can be actually used. Cool. I see if I can prepare something this week. -Y -- You received this message because you

Re: AddressSanitizer: SEGV on unknown address 0x000000000000...

On Sat, Mar 15, 2014 at 12:32 PM, Konstantin Serebryany konstantin.s.serebry...@gmail.com wrote: We see the stack trace from asan's SEGV handler, so __asan_init was already called. True, I wonder what could go wrong then? -Y -- You received this message because you are subscribed to the

Re: Faster unwind when malloc_context_size=1

Is there are a reason why you can't compile your code/libraries with -fno-omit-frame-pointer and use a fast unwinder? Fast unwinder is nice but * some legacy libs can't be recompiled * people may not want to rebuild standard libraries with -fno-omit-frame-pointer (glibc, etc.) * I'd prefer not

Re: Faster unwind when malloc_context_size=1

In my experience, slow unwinder is so slow on ARM that it's completely unusable. I've seen ~90% CPU time spent in the unwinder (things are slightly better with malloc_context_size=3 or so, but what's the point of the real unwinder then?). Does this mean that you support fast

Re: Issue 271 in address-sanitizer: cannot use ASAN w/shared-library code (JVM, JNI)

Would like to know how to inject ASAN code at runtime. Rebuilding the JVM is not really feasible. AFAIK this is a feature of LLVM ASan. Here an excerpt from Clang docs: The AddressSanitizer run-time library should be linked to the final executable, so make sure to use clang (not ld) for the

Re: AddressSanitizer enabled shared object dlopen'd in non-AddressSanitizer executable

but I don't want to do this unless we know that someone really needs it and this is the right way to solve some problem. Some benefits of dynamic runtime: 1) reduced memory overhead (important for embedded world) 2) it's also rather handy when you have a bunch of apps and libs some of which are