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 wr
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 Raj
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 a child of another process (B). I have built the
>> executabl
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, libxst and Nokogiri with ASan, but
>> when I run it I still g
se 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 wrote:
>>
>> Hi all,
>>
>> Currently core dumps are disabled on 64
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 plat
On Mon, Jul 17, 2017 at 10:25 AM, 'Alexander Potapenko' via
address-sanitizer wrote:
> On Sat, Jul 15, 2017 at 4:39 PM, Yuri Gribov wrote:
>> Hi all,
>>
>> From reading the original feature request in
>> https://github.com/google/sanitizers/issues/8 it seems
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
On Wed, Jul 12, 2017 at 4:55 PM, sothy shan wrote:
>
>
> On Wednesday, July 12, 2017 at 2:52:12 PM UTC+2, Maxim Ostapenko wrote:
>>
>> Hm, looks pretty the same to
>> https://github.com/google/sanitizers/issues/830. Could you provide more
>> details how to reproduce the issue?
>
>
> This error is
27;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 wrote:
>>
>> On Fri, Jul 7, 2017 at 10:48 AM, Ramin Farajpour Cami
>> wrote:
>> > Ok Thanks a lot Yuri,
>> >
>>
gt;
>
> 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
>> wrote:
>> > i don't know, i spend many time for resolve it, but nothing,
>> >
>> > please look : https://
ute
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
>> wrote:
>> > Yuri,
>> >
>> > again i
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 sane... yes
> checking for a
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 better).
-Y
--
You received thi
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 perfect but really works
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, I will replace the
> As
On Thu, Jun 1, 2017 at 11:51 AM, steven shi wrote:
> Clang does works, at least for X64, and I have depended on it to enable the
> LLVM Asan in my Uefi firmware. I can see the related patch is here:
> https://reviews.llvm.org/D23354. Although this patch say it is for Windows
> 64bits, but I think
On Thu, Jun 1, 2017 at 9:40 AM, steven shi wrote:
> Hello,
> I'm trying to enable the gcc asan on my bare-mental firmware after llvm. I
> need to set the GCC Asan shadow memory value dynamically, but I cannot find
> proper gcc build option to do it. With Clang, I can use "-mllvm
> -asan-force-dyna
On Thu, Apr 20, 2017 at 10:53 AM, 'Dmitry Vyukov' via
address-sanitizer wrote:
> On Thu, Apr 20, 2017 at 11:50 AM, Yuri Gribov wrote:
>> On Thu, Apr 20, 2017 at 10:20 AM, 'Dmitry Vyukov' via
>> address-sanitizer wrote:
>>> On Thu, Apr 20, 2017 at 11:1
On Thu, Apr 20, 2017 at 10:20 AM, 'Dmitry Vyukov' via
address-sanitizer wrote:
> On Thu, Apr 20, 2017 at 11:11 AM, evgeny777 wrote:
>> Thanks for clarifying it, Dmitry.
>>
>> Here is piece of report I get:
>>
>> ==18244==ERROR: AddressSanitizer: heap-buffer-overflow on address
>> 0x6020001a a
On Thu, Apr 20, 2017 at 9:44 AM, evgeny777 wrote:
> I noticed that GetPreviousInstructionPc() function returns 'pc - 1' for both
> arm32 and arm64.
> This causes odd addresses to appear in stack traces, which is nonsense, as
> both arm32/64 instructions
> have 4 byte size and alignment.
Thumb ins
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 managed to build ASAN with
>> uclibc and builds
ally agree that this is a large missing piece in asan.
>
> --kcc
>
> On Thu, Dec 1, 2016 at 9:31 PM, Yuri Gribov wrote:
>>
>> On Fri, Dec 2, 2016 at 7:22 AM, Yuri Gribov wrote:
>> > On Fri, Dec 2, 2016 at 6:35 AM, Maxim Ostapenko
>> > wrote:
>>
On Fri, Dec 2, 2016 at 7:22 AM, Yuri Gribov wrote:
> 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
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 platform firmware, thanks a lot.
>> But I find
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 thi
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, 2016
Pierre,
In this case it seems that you need to do some additional actions to
export your new symbol from runtime library. I remember that it hides
(i.e. does not export) most of it's symbols by default so you need to
whitelist your new function somewhere.
On Fri, May 27, 2016 at 3:51 PM, Pierre G
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 like to avoid that if possible :)
Yeah.
On Tue, May 3, 2016 at 8:49 PM, Konstantin Serebryany
wrote:
>
>
> On Tue, May 3, 2016 at 1:03 AM, 'Ilya' via address-sanitizer
> wrote:
>>
>> Hello everybody,
>> first of all: thanks for reading. I have questions regarding the
>> UndefinedBehaviourSanitizer and didn't know where else to post the
On Wed, Feb 17, 2016 at 10:52 PM, Konstantin Serebryany
wrote:
>
>
> On Wed, Feb 17, 2016 at 11:50 AM, Yuri Gribov wrote:
>>
>> On Wed, Feb 17, 2016 at 5:45 PM, Konstantin Serebryany
>> wrote:
>> > +Roland
>> >
>> > The only good solution i
On Wed, Feb 17, 2016 at 5:45 PM, Konstantin Serebryany
wrote:
> +Roland
>
> The only good solution is to have the upstream glibc fixed and maintained in
> this state.
> (We need to make it build with clang+asan and have the bots that verify it
> still works on every commit).
Why not sanitize it w
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 talking about gcc or clang?
>>
>> gcc in this case.
>>
>> > In gcc looks like this does
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 but
> performance is still
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* examples.
> It's unclear how many bugs w
On Thu, Jan 14, 2016 at 11:45 PM, Konstantin Serebryany
wrote:
>
>
> On Thu, Jan 14, 2016 at 12:17 PM, Yuri Gribov wrote:
>>
>> Hi Martin,
>>
>> On Thu, Jan 14, 2016 at 3:17 PM, Martin Liška
>> wrote:
>> > Hello.
>> >
>>
Hi Martin,
On Thu, Jan 14, 2016 at 3:17 PM, Martin Liška wrote:
> Hello.
>
> Let me firstly give you big compliment for address sanitizer infrastructure!
> I've been currently working as GCC developer and I find two potential
> interesting use-cases for the sanitizer:
>
> 1) use of uninitialized
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 somewhere in the
>> >
BTW could someone mention __asan_default_options in
https://github.com/google/sanitizers/wiki/AddressSanitizerFlags ?
Can't do this from my home email.
On Tue, Jan 12, 2016 at 8:01 PM, Yuri Gribov wrote:
> On Tue, Jan 12, 2016 at 7:57 PM, wrote:
>>
>>
>> On Monday, J
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 ensure the option is in ef
On Fri, Oct 30, 2015 at 10:02 PM, Hanno Böck wrote:
> Hi,
>
> With the shutdown of google code it seems several docs for asan have
> disappeared.
> E.g. there was a doc about the various ASAN_OPTIONS variants here:
> https://code.google.com/p/address-sanitizer/wiki/Flags
What about https://gith
On Fri, Jun 5, 2015 at 9:32 PM, Yuri Gribov 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
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 layout in projects/compiler-rt/lib/asan/asan_mapping.h.
>
> __asan_re
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 runt
On Wed, May 27, 2015 at 1:52 PM, Dmitriy - 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
> LD_LIBRARY_PATH=./dist/jdk_7/debug/open/jdk/jre/lib/amd64/drlvm/
On Wed, May 6, 2015 at 10:57 PM, 'Evgeniy Stepanov' via
address-sanitizer 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
> ARM, and it still is, but we pl
On Thu, Dec 4, 2014 at 8:06 PM, 'Dmitry Vyukov' via address-sanitizer
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 Groups
"address-sanitizer" group.
T
On Sat, Nov 1, 2014 at 8:39 AM, 'Evgeniy Stepanov' via
address-sanitizer wrote:
> Maybe we could go back to the idea of late initialization?
You mean making all interceptors respect asan_inited flag?
> Late shadow mapping seems to work OK in most cases, you could hack the loader
> to reserve th
Cool! Could someone apply this then?
On Wed, Oct 1, 2014 at 2:18 PM, 'Evgeniy Stepanov' via
address-sanitizer wrote:
> Sorry, my bad, missed the "$" sign.
>
>
> On Wed, Oct 1, 2014 at 2:03 PM, Yuri Gribov wrote:
>> On Wed, Oct 1, 2014 at 1:56 PM, '
On Wed, Oct 1, 2014 at 1:56 PM, 'Evgeniy Stepanov' via
address-sanitizer wrote:
>> CLANGXX=${CLANGXX:-$(echo $CLANG | sed -e 's/gcc$/g++/')}
> What if there is more than one "gcc" in the compiler path?
Sorry, don't understand... I'm just replacing trailing gcc with g++ so
e.g. path/to/my/cross-gc
On Fri, Sep 19, 2014 at 11:13 PM, Yuri Gribov wrote:
> Will test and resend on Monday.
Ok, I've fallen ill and then completely forgot about this. Here's an
updated version.
>> CLANG=${CLANG:-clang}
> You probably need the same for CLANGXX
I'm doing this below de
On Fri, Sep 26, 2014 at 4:08 PM, Jonas Wagner 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
> debugging tool more t
On Fri, Sep 19, 2014 at 9:02 PM, Yuri Gribov 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
> opti
On Fri, Sep 19, 2014 at 4:13 PM, 'Evgeniy Stepanov' via
address-sanitizer 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 detection? It is on by default, wh
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 you
On Wed, Aug 13, 2014 at 6:06 AM, ji wang wrote:
> Hi, Yuri
> After I used LD_PRELOAD=libasan.so.1 before the process started, those
> errors at the top post I mentioned gone. A little confused, do we have to
> use LD_PRELOAD to preload libasan.so before the process start even I've used
> Gcc A
> libasan.so.1 is ahead of libc.so,
> And I think the other libs couldn't link the libasan.so.1 except this
> recompiled one,
> so the interceptors not work for them. Am I right?
No, that's not how symbol resolution works on Linux systems. As I
mentioned, interception is done globally. You'll pro
> 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 libas
> 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 su
Ji,
This happens when uninstrumented code calls glibc functions that are
intercepted by Asan (e.g. memset).
On Thu, Aug 7, 2014 at 2:39 PM, ji wang wrote:
> There is one more question, kcc
> Accroding to my test result, Asan report some error at non-instrumented
> code, which means the stacks as
On Wed, Jul 30, 2014 at 12:30 PM, ji wang wrote:
>>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).
> Yuri, Do you know where your GCC4.10 organize this link order? Or how to
> insert the -lasan
On Wed, Jul 30, 2014 at 5:49 AM, ji wang 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 options look rather unexp
Ji,
I think Evgeny needs output for final gcc link invocation with -v
appended to CFLAGS.
On Tue, Jul 29, 2014 at 3:05 PM, ji wang wrote:
> Here is the detail below, and I can't find the -l flags to the linker, where
> is it?
> And is there any way to put libasan.so.1 ahead of libc.so in this gc
On Tue, Jul 29, 2014 at 10:34 AM, ji wang 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 Android. And GCC Asan is n
On Tue, Jul 29, 2014 at 4:58 AM, ji wang wrote:
> Why the asan runtime lib libasan.so.0 is needed before libc.so.6, does linux
> have any special env settings?
Like Evgeny mentioned above, you want libasan _before_ libc to be sure
that public symbols (malloc, memset, etc.) are properly intercepte
Compiler might have inlined call to memcmp.
On Mon, Jul 28, 2014 at 4:30 PM, ji wang wrote:
>
>> >You lose detection of libc usage errors (like strchr() on an
>> >unaddressable buffer, etc).
>
>
> This explain seems reasonable, but I tested libsqlite.so with asan just now,
> got an Asan error tha
On Wed, Jul 23, 2014 at 3:55 PM, 'Evgeniy Stepanov' via
address-sanitizer 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 you are subscribed to the Google Gro
On Wed, Jul 23, 2014 at 3:23 PM, 'Evgeniy Stepanov' via
address-sanitizer 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 list). In that case ASan would a
> 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 fro
> This is somewhat harder to do in user-space, because we don't
> necessary know when a stack is mapped, when it's unmapped and what's
> its size (on linux, windows and mac).
We could re-use fake stack for this but make it slimmer e.g. have just
one ring buffer for all frame sizes.
-Y
--
You re
On Wed, Jul 16, 2014 at 7:59 PM, 'Dmitry Vyukov' via address-sanitizer
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. This can become a constant
> pain
Dmitry,
> Yes, -fsanitize=kernel-address is highly desirable asap. Because
> current scheme is incompatible with inline instrumentation for kernel.
> So we need to start telling people to use -fsanitize=kernel-address as
> early as possible.
Could you check the attached patch which implements
-fs
On Tue, Jul 8, 2014 at 5:16 PM, Alexey Preobrazhensky 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
>> wrote:
>> > --param asan-memintrin=0 --param asan-fixed-shadow-offse
> Most of the fake frames are less than page size
> so madvise can only
> be applied to large fake frames and there are just a few of them.
I may be missing something but I thought that sum of small frames may
grow large in e.g. message-driven apps.
> Also, madvise is a syscall so we will trade R
All,
Has anyone considered doing madvise(DONTNEED) on dead fake frames to save
RAM?
-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 it, send an email
to address-sanitizer+
On Fri, Jun 20, 2014 at 4:50 PM, Andrey Ryabinin 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 because you are subscr
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
asan-instr
> 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.
>>
>> Agree
> 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
All,
Are there plans to extend -fsanitize-recover beyond UBSan? It seems
that adding this functionality to e.g. ASan would be trivial.
-Y
--
You received this message because you are subscribed to the Google Groups
"address-sanitizer" group.
To unsubscribe from this group and stop receiving em
>>> 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.
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.
> alternative to __kasan_instrument_stack is to implement
> __asan_get_shadow_ptr(addr) and then reuse the existing inline stack
> instrumentation.
This would be even easier.
-Y
--
You received this message because you are subscribed to the Google Groups
"address-sanitizer" group.
To unsubscri
On Mon, May 26, 2014 at 7:57 PM, 'Dmitry Vyukov' via address-sanitizer
wrote:
> What exactly do you want to write? We need to coordinate.
>From compiler's side we'll probably start experimenting with stack
instrumentation. Provided that we stick with function calls, I like
the frame metadata appr
> 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).
>
>>> So, I think we should either fix the check or remove it.
>>
>> After spending too much time debugging symbol resolution conflicts,
>> I'd try my best to have _some_ checking in runtime.
>>
>> One option (proposed by Jakub) would be to check that libasan precedes
>> libc.so, libpthread.so, etc.
>> The easiest solution is probably to hide current warning under verbosity > 0
>
> A check under verbosity > 0 is almost ("but not quite entirely")
> useless because verbosity > 0
> is not a normal mode of operation.
Well, Asan team typically asks users to provide verbose reports in
case of error
Kostya,
>> I'm wondering, have you thought about implementing stack instrumentation for
>> linux kernel?
> Of course we did! This is in our near term plans.
When do you think we can expect this feature?
> We first need to prepare a reasonable patch to GCC that implements
> kasan instrumentation
> asan may still emit inlined checks for things like 'long double'
Is this intentional? How about replacing these with a call to
__asan_{load,store}N?
-Y
--
You received this message because you are subscribed to the Google Groups
"address-sanitizer" group.
To unsubscribe from this group and s
>> GCC with it's default dynamic runtime would suffer quite a bit...
>
> Only if the out-line calls will be used (in clang, this is a
> workaround for a bad compile-time, we'll use out-line functions only
> when there are more than 1 checks in a function).
Right, this may be enough for Clang's
>> Solution here is obvious - throw in another static lib that would get
>> linked into DSOs. But this would complicate driver of course.
>
> immensely
GCC with it's default dynamic runtime would suffer quite a bit...
-Y
--
You received this message because you are subscribed to the Google Grou
>> 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
--
Yo
> You call __asan_report_load8 directly.
> This will only work if __asan_load8 does not have its own frame.
You mean you don't want asan callbacks to be present in stacktraces?
> My version lacked the UNLIKELY trick. fixed.
Cool, upstream code seems to run really fast now: 16 sec. (vs my 17.8
se
Re-attaching updated implementation just in case.
On Mon, Apr 21, 2014 at 10:33 AM, Yuri Gribov wrote:
>>> So even though my implementation is slightly faster we're still
>>> getting a 70% perf hit.
>> interesting.
>>
>> can you show the assembly (objd
>> 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 variants?
My disas:
004cf6a0 <__asan_load8>:
4cf6a0: 48 89 f8mov%rdi,%rax
4cf6a3:
>> 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
>> > 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 b
>> 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
> And unless the savings are really big I'd probably not want the change in
> trunk
Sure, I was just letting you guys know. This is a rather drastic and
incompatible change.
-Y
--
You received this message because you are subscribed to the Google Groups
"address-sanitizer" group.
To unsubscrib
> 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
1 - 100 of 129 matches
Mail list logo
