Re: MTE enabled hardware

[Konstantin Serebryany]

Hi Jakob!

Thanks for your interest.
Unfortunately, we are not aware of any publicly available device with
usable MTE.
Please pester your hardware suppliers directly, or wait :)

--kcc



On Thu, Sep 29, 2022 at 3:08 PM 'Jakob K.' via address-sanitizer <
address-sanitizer@googlegroups.com> wrote:

> Hi all,
>
> I'm currently looking into MTE and therefore inevitably also at the great
> work on MemTagSanitizer & KASAN_HW_TAGS.
>
> Since you guys are working on this: do you happen to know if there is any
> hardware out on the market you are using for testing MTE?
>
> I've been looking at the Samsung S22 with the exynos2200 which does
> support MTE. Unfortunately it looks like the bootloader (in connection with
> "Exynos Secure Monitor") is responsible to setup the DRAM locations to
> store the tags & this doesn't seem to be enabled. This results in MTE
> working *until* the tagged memory is evicted from the cache. Once the
> memory is brought back into the cache it forgot that it was tagged :/
>
> If you know of any hardware out there that you might have tested with MTE,
> I'd appreciated some pointers!
>
> Thank you!
> Jakob
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/address-sanitizer/01cba890-7360-4dc5-a45b-7265d14c4195n%40googlegroups.com
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/address-sanitizer/CAGQ9bdxJM_eXgFQm_Wq%2BNyF-_p0XXVQChOGN08J6%3D%3Dok_8SPGw%40mail.gmail.com.

Re: What does CHUNK_QUARANTINED mean?

[Konstantin Serebryany]

Hi Will,

CHUNK_QUARANTINED is an implementation detail.
Normally, users are not expected to see any such reports.
A CHECK failure like this are likely to happen when there is a memory
corruption
that ASAN doesn't detect and which corrupts ASAN's own internal state.

Your report has */usr/local*/lib/libopencv_core.so in it.
Does it mean that you run uninstrumented libopencv? (or, you've
installed an asan-instrumented lib into /usr/local?)
That may well explain the situation.
You either hit a memory corruption bug in libopencv or you misuse libopencv
causing it to corrupt memory on your behalf.
The solution would be to use asan-instrumented variants for all important
libraries in your process.

hth,
--kcc





On Wed, Jul 22, 2020 at 2:35 PM Will Lucas  wrote:

> I'm new to using address sanitizer, and I've been trying to deal with what
> I think is a heap corruption issue. I keep getting ASan reports like below:
>
> ==43795==AddressSanitizer CHECK failed: ../../../../src/libsanitizer/asan/
> asan_allocator.cc:135 "((m->chunk_state)) == ((CHUNK_QUARANTINE))" (0x13,
> 0x3)
>
>#0 0x7f2961ca8bf2  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe9bf2)
>
>#1 0x7f2961cc7575 in __sanitizer::CheckFailed(char const*, int, char
> const*, unsigned long long, unsigned long long) (/usr/lib/x86_64-linux-gnu/
> libasan.so.4+0x108575)
>
>#2 0x7f2961be9ab1  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x2aab1)
>
>#3 0x7f2961bea443  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x2b443)
>
>#4 0x7f2961c9d772 in __interceptor_free (/usr/lib/x86_64-linux-gnu/
> libasan.so.4+0xde772)
>
>#5 0x7f295d76a718 in cv::Mat::deallocate() (/usr/local/lib/libopencv_
> core.so.3.4+0x18a718)
>
>#6 0x558a2adc8db7 in cv::Mat::release() /usr/local/include/opencv2/
> core/mat.inl.hpp:901
>
>#7 0x558a2adc8db7 in cv::Mat::~Mat() /usr/local/include/opencv2/
> core/mat.inl.hpp:787
>
> I'm trying to understand what CHUNK_QUARANTINED means in order to
> determine next steps for debugging. Is there documentation on this type of
> failure, or has anyone dealt with these types of errors?
>
> Thanks for your time!
> Will
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/address-sanitizer/780fe7cd-6e95-40c3-9cce-63bd91c87109o%40googlegroups.com
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/address-sanitizer/CAGQ9bdy8nj7RSyOD7%2BA1TdDNscsx0EAB25ftZkFaa4RPE3QFqQ%40mail.gmail.com.

Re: Which comes first, and does one override the other?

[Konstantin Serebryany]

The env overrides __asan_default_options.

--kcc

On Fri, May 31, 2019 at 1:03 PM 'David Barto' via address-sanitizer <
address-sanitizer@googlegroups.com> wrote:

> ASAN_OPTIONS from the environment
> __asan_default_options from the program it self?
>
> Does one override the other, or can __asan_default_options enhance/extend
> the environment variable?
>
> David
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/address-sanitizer/CF111C13-C13B-4780-8781-796ABC2FE8D4%40cambridgesemantics.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/address-sanitizer/CAGQ9bdzyRh1N2f4WfV_HKXU17CpcdtZ%3DhirhPxndV-gNPdF9Vw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suppression file appears to not be working

[Konstantin Serebryany]

please check this page for the exact syntax of leak suppressions:
https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer#suppressions

On Wed, May 29, 2019 at 11:37 AM 'David Barto' via address-sanitizer <
address-sanitizer@googlegroups.com> wrote:

> I’d prefer to suppress based on libcrypto, and it doesn’t take.
>
> This is using gcc-7.2.0. This may be a too-old version of the compiler, if
> so, please let me know.
>
> David
>
> 1041_ cat asan.suppression
> interceptor_via_lib:libcrypto
> interceptor_via_fun:CRYPTO_malloc
> interceptor_via_fun:CRYPTO_realloc
> 1042_ export ASAN_OPTIONS=suppressions=$(pwd)/asan.suppression
> 1043_ azgctl -stop
> Stopping database...
>
> =
> ==5242==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 400 byte(s) in 2 object(s) allocated from:
> #0 0x7fc7be8a98e0 in __interceptor_malloc
> ../../../../libsanitizer/asan/asan_malloc_linux.cc:62
> #1 0x7fc7bd5f93b7 in CRYPTO_malloc (/usr/lib64/libcrypto.so.10+0x6e3b7)
>
> Indirect leak of 7670 byte(s) in 141 object(s) allocated from:
> #0 0x7fc7be8a98e0 in __interceptor_malloc
> ../../../../libsanitizer/asan/asan_malloc_linux.cc:62
> #1 0x7fc7bd5f93b7 in CRYPTO_malloc (/usr/lib64/libcrypto.so.10+0x6e3b7)
>
> Indirect leak of 64 byte(s) in 1 object(s) allocated from:
> #0 0x7fc7be8a9c90 in __interceptor_realloc
> ../../../../libsanitizer/asan/asan_malloc_linux.cc:75
> #1 0x7fc7bd5f94a8 in CRYPTO_realloc
> (/usr/lib64/libcrypto.so.10+0x6e4a8)
>
> SUMMARY: AddressSanitizer: 8134 byte(s) leaked in 144 allocation(s).
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/address-sanitizer/26BE0E98-7B93-4569-BA9C-74B7C5E8E2A4%40cambridgesemantics.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/address-sanitizer/CAGQ9bdyWLkOEv%2Bi1oo-_OogPYgbHumkitgHOKs9oAQoQs0Rjzw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is building in Debug or Release preferred with address sanitizer?

[Konstantin Serebryany]

One thing to avoid is -O0 (fully disabled optimizations) where asan will be
too slow.
If I had to choose one configuration I would go with "-fsanitize=address -g
-fno-omit-frame-pointers"
and -O1 or -O2 w/o any other flags, especially without -D_NDEBUG which
disables assertions.
The choice between -O1 and -O2 should be based on performance -- use -O1 if
it's fast enough for you, otherwise use -O2

hth,

--kcc

On Wed, Apr 10, 2019 at 4:08 PM  wrote:

> Is it better to have all the optimization in place that a release build
> does vs. a debug build?
>
> We ship release builds however our ASAN and production builds use
> different compilers so we already have optimization differences between the
> two builds.
>
> I saw in the FAQ (
> https://github.com/google/sanitizers/wiki/AddressSanitizer) somebody had
> a known problem that wasn't detected and the statement was maybe it was
> optimized out.
>
>-
>
>Q: Why didn't ASan report an obviously invalid memory access in my
>code?
>-
>
>A1: If your errors is too obvious, compiler might have already
>optimized it out by the time Asan runs.
>
> If that is really the case I would prefer a debug build so issues are
> fixed in both release and debug.
>
> If you had to pick one build type which would you use to find the most
> issues?
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Analyis Address Sanitizer report

[Konstantin Serebryany]

"AddressSanitizer: SEGV on unknown address 0x60305beb6ba5"
means that the program has accessed some unmapped memory,
and the stack trace tells you where.
There is not much else to see in this report.

Since this is happening inside std::string::append, it is more likely to be
a use-after-free than a buffer-overflow,
and one that ASAN is not able to report properly.

Maybe try rerunning the test with ASAN_OPTIONS=quarantine_size_mb=100
(infinite quarantine).
If it's a use-after free it should report it as such.

Hard to imagine how, but it could also be a stack-use-after-return
(see
https://github.com/google/sanitizers/wiki/AddressSanitizerUseAfterReturn)
so try ASAN_OPTIONS=detect_stack_use_after_return=1

Maybe some other kind of undefined behavior is at play. Try UBSAN, TSAN,
and MSAN.

hth,

--kcc






On Thu, Apr 4, 2019 at 4:34 AM Diapnshu  wrote:

> Hi ,
> Guys , I am using address sanitizer in my project .
>
> But it is difficult to analysis the report . Could you please help to
> understand .
>
> Thanks in Advance .
>
>
> SUMMARY: AddressSanitizer: heap-use-after-free
> (/home/dkundu/develop/bin/Linux/Container+0x78350e) in memcpy
> Shadow bytes around the buggy address:
>   0x0c0680ccebc0: fa fa fd fd fd fd fa fa fd fd fd fd fa fa fd fd
>   0x0c0680ccebd0: fd fd fa fa fd fd fd fd fa fa fa fa fa fa fa fa
>   0x0c0680ccebe0: fd fd fd fd fa fa fd fd fd fd fa fa fd fd fd fd
>   0x0c0680ccebf0: fa fa fa fa fa fa fa fa fd fd fd fd fa fa fa fa
>   0x0c0680ccec00: fa fa fa fa fa fa fa fa fa fa fd fd fd fd fa fa
> =>0x0c0680ccec10: fd fd fd[fd]fa fa fd fd fd fd fa fa fa fa fa fa
>   0x0c0680ccec20: fa fa fa fa fa fa fa fa fd fd fd fd fa fa fd fd
>   0x0c0680ccec30: fd fd fa fa fd fd fd fd fa fa fd fd fd fd fa fa
>   0x0c0680ccec40: fd fd fd fd fa fa fd fd fd fd fa fa fd fd fd fd
>   0x0c0680ccec50: fa fa fd fd fd fd fa fa fd fd fd fd fa fa fd fd
>   0x0c0680ccec60: fd fd fa fa fd fd fd fd fa fa fd fd fd fd fa fa
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:   00
>   Partially addressable: 01 02 03 04 05 06 07
>   Heap left redzone:   fa
>   Freed heap region:   fd
>   Stack left redzone:  f1
>   Stack mid redzone:   f2
>   Stack right redzone: f3
>   Stack after return:  f5
>   Stack use after scope:   f8
>   Global redzone:  f9
>   Global init order:   f6
>   Poisoned by user:f7
>   Container overflow:  fc
>   Array cookie:ac
>   Intra object redzone:bb
>   ASan internal:   fe
>   Left alloca redzone: ca
>   Right alloca redzone:cb
> =
> ==6613==ERROR: AddressSanitizer: SEGV on unknown address 0x60305beb6ba5
> (pc 0x7f589e725226 bp 0x7f5891c84070 sp 0x7f5891c837d8 T13)
> ==6613==The signal is caused by a READ memory access.
> #0 0x7f589e725225 in __memmove_ssse3_back (/lib64/libc.so.6+0x150225)
> #1 0x782e6e in memcpy
> (/home/dkundu/develop/bin/Linux/Container+0x782e6e)
> #2 0x7f589f174a43 in std::string::append(std::string const&)
> (/lib64/libstdc++.so.6+0xbea43)
> #3 0x8b6fb4 in std::basic_string,
> std::allocator > std::operator+,
> std::allocator >(std::basic_string,
> std::allocator > const&, std::basic_string std::char_traits, std::allocator > const&)
> /opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/bits/basic_string.h:5880:13
> #4 0x98bdd6 in TITMMessage::mySetValue(AnsiString const&, AnsiString
> const&, AnsiString const&)
> /home/dkundu/develop/Container/../pluginutils_new/unit_itmmessage.cpp:274:33
> #5 0x98d93c in TITMMessage::GeneralSetValue(AnsiString const&,
> AnsiString const&)
> /home/dkundu/develop/Container/../pluginutils_new/unit_itmmessage.cpp:323:2
> #6 0x98e0cb in TITMMessage::SetSource(AnsiString const&)
> /home/dkundu/develop/Container/../pluginutils_new/unit_itmmessage.cpp:343:2
> #7 0x9bfde4 in TITMPluginHelper::log(AnsiString const&, AnsiString,
> TITMLOGLEVEL, int) const
> /home/dkundu/develop/Container/../pluginutils_new/unit_pluginhelper.cpp:917:4
> #8 0x9a2c6b in TITMPluginHelper::log(TITMMessage const*, AnsiString
> const&, TITMLOGLEVEL, bool, int) const
> /home/dkundu/develop/Container/../pluginutils_new/unit_pluginhelper.cpp:895:2
> #9 0x7f5889bc6888 in ProcessSendOnlineTransactions(TITMPluginHelper&,
> int, int, int, TMyCollection const&, std::map std::unique_ptr >, std::less,
> std::allocator std::default_delete > > > >&)
> /home/dkundu/develop/Plugins/RenEndPointDataProcessor/unit_endpointdataclient.cpp:231:9
> #10 0x7f5889bc183d in comhandler
> /home/dkundu/develop/Plugins/RenEndPointDataProcessor/unit_endpointdataclient.cpp:106:16
> #11 0x94504d in TITMPlugin::ExecuteComHandler(int)
> /home/dkundu/develop/Container/unit_itmplugin.cpp:319:4
> #12 0x965c5f in TPluginThread::Execute()
> /home/dkundu/develop/Container/unit_pluginthread.cpp:203:9
> #13 0xb98897 in 

Re: ASAN on embedded platform (Cortex-M) ?

[Konstantin Serebryany]

IIUC, Cortex-M is a 32-bit system, right?
asan's memory consumption is typically around 2x: you have redzones,
quarantine, 1/8 for the shadow, and some bookkeeping overhead.
You can reduce most of it at the expense of bug report quality and bug
detection probability, but probably it will remain at least 50%.

please also take a look at hwasan:
https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
It's another flavor of asan, with a much smaller RAM overhead, typically <
10%.
The current implementation is 64-bit only, but if you fully control all of
your source code, don't have too many assembly blobs,
 and if you can squeeze your address space into ~ 28 bits, this scheme may
work for you too.




On Tue, Mar 19, 2019 at 9:55 AM 'Alexander Potapenko' via address-sanitizer
 wrote:

> On Tue, Mar 19, 2019 at 5:46 PM Thomas Legrand  wrote:
> >
> > Hello,
> >
> > Thanks a lot for the reply.
> >
> > I have total control over the loaded program:
> > - running code before startup is no problem
> > - reserving 1/8th the memory seems doable (I can change the linker
> script to split the memory regions)
> > - I do not use any malloc / free in my applications (new keyword only
> with specified custom allocators, or placement new)
> > - for error reporting, triggering a hardware breakpoint seems ok to me
> (I already do that for e.g. failing assert), so that I have full stack
> trace, etc. and I wouldn't use ASAN "unattended" (without debug probe
> attached)
> > - flash size should be ok, I see that more as a debug tool so I can
> remove parts of the application if needed to fit in flash (but on some
> project I wouldn't be able to test the full application, that's right)
> >
> > I just checked asan.c and it's probably much much overkill to try to
> implement everything (and probably not possible with embedded contraints).
> >
> > But looking at the ARM GCC compiler errors when I add the
> -fsanitize=address switch, it doesn't seem to call that much different
> methods:
> > - __asan_report_storeN
> > - __asan_report_loadN
> > - __asan_handle_no_return
> > - __asan_report_store_n
> > - __asan_report_load_n
> > - __asan_stack_malloc_N
> > - __asan_stack_free_N
> > - __asan_option_detect_stack_use_after_return
> > - __asan_after_dynamic_init
> > - __asan_before_dynamic_init
> >
> > Maybe I could make good use of this automatic instrumentation to catch
> at least some bugs.
> > Do you know where I could find the use and signature of these ?
> You can take a look here:
> https://github.com/llvm-mirror/compiler-rt/tree/master/lib/asan (it
> should be somewhere in GCC as well, but LLVM repo is the source of
> truth)
> Guess you won't be able to compile ASan runtime for your arch
> directly, but it can give you an idea of what's going on.
> Most certainly you won't need complicated stuff like thread support,
> env-based options, even the fancy malloc.
> You can also start with disabling most of ASan instrumentation
> (https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html, more
> in asan.c in GCC), so that less of those functions are emitted.
> > Thomas.
> >
> >
> > On Tuesday, March 19, 2019 at 2:06:43 PM UTC+1, Thomas Legrand wrote:
> >>
> >> Hello,
> >>
> >>
> >>
> >> I’m totally new to ASAN, I’m using latest GCC ARM compiler for embedded
> projects.
> >>
> >> I was wondering if someone already tried to use ASAN on embedded
> platforms like Cortex-M ?
> >>
> >> I tried adding “-fsanitize=address” to my compile/link command line and
> it compiled fine but failed at linking because of missing functions
> (__asan_*).
> >>
> >>
> >>
> >> Is it “doable” to implement these ?
> >>
> >> I guess there are 2 options, do checks on the target itself (but what
> is the required RAM/FLASH/CPU footprint ?) and trigger e.g. a breakpoint on
> error, or transfer data to a PC for calculations (but what would be the
> required bandwidth ?) but that would require developing a dedicated GUI/app.
> >>
> >>
> >>
> >> Any advice ?
> >>
> >>
> >>
> >> Thomas.
> >
> > --
> > 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+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Alexander Potapenko
> Software Engineer
>
> Google Germany GmbH
> Erika-Mann-Straße, 33
> 80636 München
>
> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 

Re: Using asan on x86_64 with a large chunk of memory mapped

[Konstantin Serebryany]

What is the fixed address range you are using?

There are two fixed address ranges that asan is using: one for the shadow,
one for the allocator.

If you are using the latest clang, you may try -mllvm
-asan-force-dynamic-shadow=1, which will make asan use dynamic shadow base.
Note:
  * you can not mix object files built with
asan+asan-force-dynamic-shadow=1 and with asan+asan-force-dynamic-shadow=0
  * this flag is expected to work, but does not have the same amount of
testing as the default mode. So, if something breaks, we may not be able to
help.

I don't think we support dynamic allocator range on x86_64 linux.

It might still be simpler to modify your code to use a range that doesn't
conflict with asan.

--kcc



On Thu, Feb 28, 2019 at 1:32 AM Jason Newton  wrote:

> Hello,
>
> I'm a long time fan/user of asan.  I was trying to use it in an
> application with a big chunk of virtual memory mapped to a fixed address
> range, it's only a fraction of the virtual address space (a significant
> one), but there's still plenty of bits to go around, and hopefully enough
> for asan to do it's thing.
>
> So I was trying to figure out how make asan coexist with this.  asan loads
> up first which then causes problems for the application after that.
> Looking at asan_allocator.h, I can see this:
>
>
> #else //From what I can tell a standard x86_64 intel machine on linux
> should land here.
>
> const uptr kAllocatorSpace = 0x6000ULL;
> const uptr kAllocatorSize = 0x400ULL; // 4T.
> typedef DefaultSizeClassMap SizeClassMap;
> # endif
> template 
> struct AP64 { // Allocator64 parameters. Deliberately using a short name.
> static const uptr kSpaceBeg = kAllocatorSpace;
>
> static const uptr kSpaceSize = kAllocatorSize;
>
>
> Not quite sure if these are the knobs I'm looking for -  or what the exact
> meaning is of kSpaceBeg/kAllocatorSpace
> Basically my thought is , could I restrict libasan so it only claims the
> virtual address space above the problematic region.
>
> Thoughts or pointers?
>
> -Jason
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Performance slowdown of ASAN

[Konstantin Serebryany]

Hi Guilherme,

Instrumenting all memory accesses is only one cause of slowdown.
Another equally important cause is poisoning the heap memory on malloc/free
and poisoning the stack memory on function entry/exit.
Yet another one, is the growth of total memory usage due to redzones and
quarantine (extra RAM usage typically costs extra CPU cycles)
If you don't look at these factors you are unlikely to get a good model.



--kcc

On Mon, Sep 3, 2018 at 12:28 PM Guilherme  wrote:

> Hi all,
>
> We are running a few experiments to try to predict the performance slowdown
> of Address Sanitizer. Our hypothesis is that an executable with more memory
> accesses would take longer than one with fewer. We tried to correlate
> the number of loads/stores in the LLVM IR with the slowdown introduced by
> ASAN but the correlation we've found is too weak to support our hypothesis.
>
> I am attaching a chart showing the correlation we've computed. We've used
> the following notation:
>
> time_ratio = (time without asan) / (time with asan)
> stores_visible = stores_instructions_IR / stores_total
> loads_visible = loads_instructions_IR / loads_total
>
> However, the hypothesis still makes sense for us. Therefore, we think we
> might be missing a few factors. So, if we would like to predict the ASAN
> performance overhead on a program, which instructions, other than
> loads/stores, are more likely to cause Address Sanitizer to slowdown the
> program?
>
> Regards,
>
> Guilherme
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Asan behaves differently in Docker than nativelly

[Konstantin Serebryany]

Hi Lukas,

Please try running docker with "--cap-add SYS_PTRACE".
LeakSanitizer uses ptrace and by default ptrace is disabled in docker.
If this doesn't help, please provide more details.

--kcc

On Thu, Aug 9, 2018 at 12:44 AM Lukas Woodtli 
wrote:

> Hi there
>
> We have some C++ testing applications that we run with a sanatizer (asan)
> enabled build.
> Now we decided to run these application in a Docker container. In the
> container
> asan reports some leaks that are not reported when run natively.
> At a first glance the reported issues seem to be false positives mainly
> occuring
> in static (or thread local) data.
>
> The OS is RHEL7 (also inside of Docker)
>
> Any hints why the allocator behaves differently in these environments.
>
> Regards,
> Lukas
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to use address sanitizer on a sub process

[Konstantin Serebryany]

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 executable for A using the compiler flags :
> -fsanitize=address -static-libasan
>
>  and linked the process using the flags
> -fsanitize=address -static-libasan -lasan.
>

You should never need -lasan.
If any piece of documentation tells you to use -lasan, please let us know,
we need to remove that.

-fsanitize=address at both compile and link-time should be sufficient.
-static-libasan is optional.



>
> However, when I launch Process A as a subprocess of process B, I am not
> getting any errors or warnings.
>

Maybe your program doesn't have bugs?


>
> How do I get the memory leaks in process A using Address Sanitizer?
>

Are you only looking for memory leaks or for other types of bugs too?
Unlike most other kinds of bugs, memory leaks are reported when the process
is exiting,
see https://clang.llvm.org/docs/LeakSanitizer.html


>
> Thanks and Regards
> Seshadri
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Address Sanitizer with Ruby Nokogiri module/Gem

[Konstantin Serebryany]

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 get:
>
> ./ruby ../script.rb
> Traceback (most recent call last):
> 7: from ../script.rb:1:in `'
> 6: from
> /usr/local/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:39:in
> `require'
> 5: from
> /usr/local/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:135:in
> `rescue in require'
> 4: from
> /usr/local/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:135:in
> `require'
> 3: from
> /usr/local/lib/ruby/gems/2.5.0/gems/nokogiri-1.8.0/lib/nokogiri.rb:28:in
> `'
> 2: from
> /usr/local/lib/ruby/gems/2.5.0/gems/nokogiri-1.8.0/lib/nokogiri.rb:32:in
> `rescue in '
> 1: from
> /usr/local/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
> `require'
> /usr/local/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
> `require': /usr/local/lib/libxml2.so.2: undefined symbol: __asan_init -
> /usr/local/lib/ruby/gems/2.5.0/gems/nokogiri-1.8.0/lib/nokogiri/nokogiri.so
> (LoadError)
>

Please provide mode details:
OS version
glibc version
compiler version (also, GCC or Clang?)
exact build flags

Also, what does the
/usr/local/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb
do?
Maybe it's just asking for too much? Maybe you should just relax the checks
made by this tool.
When you build libxml2.so.2 with asan, the library get a call
to __asan_init (and other similar functions) and those functions are not
present in the library -- only in the binary.





>
> Any ideas?
>
> Any body with Ruby experience and enabling ASan for Ruby Gems?
>
> Thanks,
>
> On Friday, May 18, 2018 at 10:16:00 PM UTC+2, kcc wrote:
>>
>> I have zero experience with Ruby, but if it is any similar to Python then
>> my recommendation is to build Ruby with AddressSanitizer.
>> If the build breaks with an LSAN report, just disable LSAN during the
>> build (ASAN_OPTIONS=detect_leaks=0)
>>
>> --kcc
>>
>>
>>
>> On Fri, May 18, 2018 at 3:15 AM MK  wrote:
>>
>>> Hi all,
>>>
>>> I am trying to compile Address Sanitizer in nokogiri Ruby gem.
>>>
>>> Compiled libxml2 and libxslt with Address Sanitizer like this:
>>>
>>> ./configure CFLAGS="-fsanitize=address,undefined -Wformat
>>> -Werror=format-security -Werror=array-bounds -g"
>>> CXXFLAGS="-fsanitize=address,undefined -Wformat -Werror=format-security
>>> -Werror=array-bounds -g" LDFLAGS="-fsanitize=address,undefined" CC="clang"
>>> CXX="clang++"
>>>
>>>
>>> And installed gem like this:
>>>
>>> sudo gem install nokogiri --version 1.8.0 -- --use-system-libraries
>>> --with-xml2-include=/home/user/Downloads/libxml2-2.9.3/include/
>>> --with-xml2-lib=/usr/local/lib/ --with-cflags=\"-fsanitize=address\"
>>> --with-ldflags=\"-fsanitize=address -lasan -lubsan\"
>>> --with-xslt-include=/home/user/Downloads/libxslt-1.1.28/
>>>
>>>
>>> However when I run sample Ruby script using Nokogiri
>>>
>>> script.rb
>>> #!/usr/bin/ruby
>>> require 'nokogiri'
>>> doc = File.open("sample.xml") { |f| Nokogiri::XML(f) }
>>>
>>>
>>> I get this message:
>>>
>>> ./script.rb ==30473==ASan runtime does not come first in initial library
>>> list; you should either link runtime to your application or manually
>>> preload it with LD_PRELOAD.
>>>
>>>
>>> When I do the preload:
>>>
>>>
>>>  LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.2 ./script.rb
>>> /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in
>>> `require':
>>> /var/lib/gems/2.3.0/gems/nokogiri-1.8.0/lib/nokogiri/nokogiri.so: undefined
>>> symbol: __asan_init -
>>> /var/lib/gems/2.3.0/gems/nokogiri-1.8.0/lib/nokogiri/nokogiri.so (LoadError)
>>> from
>>> /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
>>> from
>>> /var/lib/gems/2.3.0/gems/nokogiri-1.8.0/lib/nokogiri.rb:32:in `rescue in
>>> '
>>> from
>>> /var/lib/gems/2.3.0/gems/nokogiri-1.8.0/lib/nokogiri.rb:28:in `>> (required)>'
>>> from
>>> /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:127:in `require'
>>> from
>>> /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:127:in `rescue in
>>> require'
>>> from
>>> /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:40:in `require'
>>> from ./script.rb:2:in `'
>>>
>>> =
>>> ==30485==ERROR: LeakSanitizer: detected memory leaks
>>>
>>> Direct leak of 319176 byte(s) in 4259 object(s) allocated from:
>>> #0 0x7fce9ea4579a in __interceptor_calloc
>>> (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x9879a)
>>> #1 0x7fce9e5b4383 in ruby_xcalloc
>>> (/usr/lib/x86_64-linux-gnu/libruby-2.3.so.2.3+0x85383)
>>>
>>> .
>>> .
>>> .
>>> Do I have to build Ruby also with Address Sanitizer? Which unfortunately
>>> fails ...
>>>
>>> cd ruby-2.3.0
>>> 

Re: sanitizers on github

[Konstantin Serebryany]

Hi,

Just send a pull request.
Note that the actual code for the sanitizers is in the LLVM repo.
The "sanitizers" github repo is mostly used for docs & issues

--kcc

On Thu, May 17, 2018 at 6:35 PM Datta Prabhu Maddikunta 
wrote:

> Hi,
>
> I want to contribute to Sanitizers project on GitHub. How do I do that?
> Who owns the ownership of these projects? My github id is "dattapm".
>
> Appreciate your time.,
>
> Thanks.,
> Datta M
>
> --
> You received this message because you are subscribed to the Google Groups
> "thread-sanitizer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to thread-sanitizer+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Regarding ASAN algorithm

[Konstantin Serebryany]

Hi,
All shadow memory is zero at start-up (zero means "valid").
When a memory is allocated (by malloc, or by a stack frame), the shadow for
the redzones are marked as invalid.
When a memory is de-allocated, the corresponding shadow is marked as
invalid.

hth,

--kcc

On Thu, May 3, 2018 at 2:54 AM Harshith H  wrote:

> How is the value for shadow memory computed on start up of application ?
> which is then checked by instrumentation code
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ASAN ON CUSTOM OS

[Konstantin Serebryany]

On Sun, Apr 22, 2018 at 12:59 AM, Harshith H  wrote:

> HI ,
> We are trying to apply asan to our custom OS .
> There are set of libc functions and standard API'S intercepted . Can
> anyone help me with what criteria is used to intercept ? Why not other
> functions /methods .
>

Some functions are *replaced* by asan because asan needs them to behave
differently.
This is basically malloc and friends.

Other functions are intercepted because asan needs to inject extra
functionality.
E.g. for pthread_create we need to catch when a thread is created.

Most other functions are intercepted so that we see memory accesses inside
them and report the buggy ones (e.g. memcpy, strcmp, etc)

If you control the OS, it's likely better to build asan support into your
libc as opposed to intercepting the libc functions on the asan side.

--kcc



>
>
> Thank you
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: What the real instrumentation dose ASON do on the progarm?

[Konstantin Serebryany]

On Tue, Apr 3, 2018 at 8:12 PM, Jin Huang <54jin.hu...@gmail.com> wrote:

> I am wondering what ASON really did with the test program , especially the
> instrumentation part.
>

See https://www.usenix.org/system/files/conference/atc12/atc12-final39.pdf
and the link you mention below.


>
> I found a brief introduction here,https://github.com/
> google/sanitizers/wiki/AddressSanitizerAlgorithm and want to know some
> details , where shuoul I find the documents? or the sources code of address
> sanitizer?
>

The sources are in the LLVM repository.
Compiler pass:
https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/Instrumentation/AddressSanitizer.cpp
Run-time library:
https://github.com/llvm-mirror/compiler-rt/tree/master/lib/asan

hth,

--kcc


>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Intermittent 'AddressSanitizer CHECK failed' error

[Konstantin Serebryany]

+alekseys, who has been touching this code recently.

On Mon, Mar 26, 2018 at 12:24 PM, isarkisov via address-sanitizer <
address-sanitizer@googlegroups.com> wrote:

> We run ASAN on AARCH64 platoform (Brillo codebase) and intermittently run
> into the following error.  Any idea why and how to avoid this?
>
> =8465==AddressSanitizer CHECK failed: 
> external/compiler-rt/lib/sanitizer_common/sanitizer_allocator.h:1057 
> "((IsAligned(map_beg, page_size_))) != (0)" (0x0, 0x0)
> #0 0x7fa691e9ab  
> (/system/lib64/libclang_rt.asan-aarch64-android.so+0x6f9ab)
> #1 0x7fa692a5cb in __sanitizer::CheckFailed(char const*, int, char 
> const*, unsigned long long, unsigned long long) 
> (/system/lib64/libclang_rt.asan-aarch64-android.so+0x7b5cb)
> #2 0x7fa68cdf53  
> (/system/lib64/libclang_rt.asan-aarch64-android.so+0x1ef53)
> #3 0x7fa68cdafb  
> (/system/lib64/libclang_rt.asan-aarch64-android.so+0x1eafb)
> #4 0x7fa68cad73 in __cxa_finalize 
> (/system/lib64/libclang_rt.asan-aarch64-android.so+0x1bd73)
> #5 0x7fa6920a23 in operator new(unsigned long) 
> (/system/lib64/libclang_rt.asan-aarch64-android.so+0x71a23)
> #6 0xb04dd3 in std::__1::__allocate(unsigned long) 
> external/libcxx/include/new:168:10
> #7 0xb04dd3 in std::__1::allocator::allocate(unsigned 
> long, void const*) external/libcxx/include/memory:1720
> #8 0xb04dd3 in 
> std::__1::allocator_traits >::allocate(std::__1::allocator&, unsigned long) 
> external/libcxx/include/memory:1479
> #9 0xb04dd3 in std::__1::vector std::__1::allocator >::allocate(unsigned long) 
> external/libcxx/include/vector:928
>
> #10 0xb04dd3 in std::__1::vector std::__1::allocator >::vector(unsigned long, unsigned char
> const&) external/libcxx/include/vector:1099
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue 611: Disable asan on external SDK which uses dlopen with RTDL_DEEPBIND

[Konstantin Serebryany]

Yes, github is the perfect place. Let me take a look, I'll reply there.

On Fri, Mar 16, 2018 at 12:39 PM, Fernando Campos 
wrote:

> Hello!
>
> I posted in github this comment: https://github.com/google/
> sanitizers/issues/611#issuecomment-368566634
>
> Don't know if github was not the right place for this kind of questions.
> Let me try in this list...
>
> Hi!
> I have an environment in which I am using an external SDK. This SDK
> consist of a shared library I link with, and which makes use of dlopen to
> open other libX.so with RTLD_DEEPBIND flag. I'm not interested at all on
> sanitize the SDK, I only want to sanitize my own code.
>
> How should I proceed? I'm confused about the different
> -shared-libasan/-static-libasan options.
> As far as I understand, compiling with -static-libasan (GCC6) should
> inject all the sanitizer code in my binary and should have no effects on
> non-sanitized SDK, but I get an error on SDK trying to dlopen the .so:
> Couldn't load libXXX.so: System error code(-2): libXXX.so: cannot open
> shared object file: No such file or directory
>
> Using LD_LIBRARY_PATH to allow the SDK finding its libXXX.so I get the
> famous _int_free SEGV ASAN error. Seems like the SDK is redefining any
> alloc/free function, so there is a mismatch on symbol resolution (SDK vs
> Asan).
>
> Looks like linking with -fsanitize=address changes the order of symbols
> lookup/LD_PATH. I would need to isolate the SDK so it remains using libc or
> its own implementation (I don't know how internally works and I don't have
> access to source code neither).
>
> I want this behavior #871 (comment)
> ,
> but I'm not able to make the SDK run when my binary is using asan.
>
> I am open to use blacklist, suppression list, 
> *attribute*((no_sanitize("address")))
> or any other option, but I would like to understand the problem.
>
> Any hints?
> Thanks
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding "pass-through" ASan allocator

[Konstantin Serebryany]

On Wed, Jan 31, 2018 at 1:33 PM, Francis Ricci <francisjri...@gmail.com>
wrote:

> * Most system allocators have inline metadata (i.e. 8 or 16 bytes to
> the left of the chunk returned to the user). Those will have to be
> poisoned somehow. Also, if you don't fully know how your allocator
> works, you don't know what else remains unpoisoned nearby.
> * How to create redzones? If you create both left and right redzone,
> you probably waste too much space. If you create just one (e.g. right)
> how do you guarantee that there is one at the left.
>
> These seem like issues with replacing asan_allocator.cc, I was
> planning to go one level deeper and replace the sanitizer_common
> sanitizer_allocator.cc (which seems to be much more generic, and
> therefore easier to replace).
>

If you are brave :)

In our environments we never try anything like this -- we simply disable
tcmalloc and annotate various specialized allocators (e.g. freelists).
So, we won't be able to advise you on this effort.


>
> >  With our new ASAN (HWASAN, clang.llvm.org/docs/
> HardwareAssistedAddressSanitizerDesign.html) most of these things will
> become much simpler since there is no quarantine or redzones any more.
>
> Maybe I will just wait for the new toy...
>

On AArch64, it should be usable in a few months, assuming you can patch
your kernel (fingers crossed; and help is welcome!).
On x86_64 -- good luck :)  /  :(


>
> On Wed, Jan 31, 2018 at 4:27 PM, Konstantin Serebryany
> <konstantin.s.serebry...@gmail.com> wrote:
> > \
> >
> > On Wed, Jan 31, 2018 at 10:17 AM, Kuba Mracek <mra...@apple.com> wrote:
> >>
> >> If you're careful enough (and make sure the allocator itself is not
> >> instrumented, nor does it call *any* intercepted functions, or have
> some way
> >> of disabling interceptors when we're in the middle of an allocator
> call),
> >> this should be theoretically possible.
> >
> >
> > ... but your warranty is void after that. :)
> >
> >>
> >>
> >> Dan is right about the quarantine, but it should be possible to build
> the
> >> quarantine as another layer on top an existing allocator. The quarantine
> >> would just not call the underlaying free() unless the memory is to be
> >> released from the quarantine. Actually, I think the quarantine in ASan
> is
> >> already decoupled from the allocator and could probably be used against
> >> other allocators.
> >>
> >> Needless to say, doing this would require quite a lot of changes to the
> >> existing allocator(s).
> >>
> >> Kostya, are there some extra features in the sanitizer allocator(s)
> that a
> >> system/user allocator wouldn't have?
> >
> >
> > Off the top of my head:
> > * Most system allocators have inline metadata (i.e. 8 or 16 bytes to the
> > left of the chunk returned to the user). Those will have to be poisoned
> > somehow. Also, if you don't fully know how your allocator works, you
> don't
> > know what else remains unpoisoned nearby.
> > * How to create redzones? If you create both left and right redzone, you
> > probably waste too much space. If you create just one (e.g. right) how do
> > you guarantee that there is one at the left.
> > * Where do you store stack traces associated with allocation and other
> > metadata (thread is, user requested size)?
> > * Quarantine is a huge PITA
> > * How do you recycle the shadow after deallocating large heap chunks (aka
> > madvise don't need)?
> > * How do you report bugs with detailed position inside the heap chunk?
> > * probably a couple more
> >
> > 
> > With our new ASAN (HWASAN,
> > clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html)
> > most of these things will become much simpler since there is no
> quarantine
> > or redzones any more.
> > 
> >
> >
> >
> >
> >>
> >>
> >> Kuba
> >>
> >>
> >> On Jan 12, 2018, at 8:49 AM, Dan Liew <d...@su-root.co.uk> wrote:
> >>
> >> Hi,
> >>
> >> On 12 January 2018 at 08:37, Francis Ricci <francisjri...@gmail.com>
> >> wrote:
> >>
> >> Hi all,
> >>
> >> I may be missing something conceptually with the way ASan works, but
> >> is there any reason that ASan couldn't pass-through allocations to the
> >> user's allocator? For example:
> >>
> >> 1) User calls malloc()
> >> 2) ASan intercepts malloc(), does checks/adds metadata, etc
> >> 3) Instead of using the sanitizer allocator

Re: Adding "pass-through" ASan allocator

[Konstantin Serebryany]

\

On Wed, Jan 31, 2018 at 10:17 AM, Kuba Mracek  wrote:

> If you're careful enough (and make sure the allocator itself is not
> instrumented, nor does it call *any* intercepted functions, or have some
> way of disabling interceptors when we're in the middle of an allocator
> call), this should be theoretically possible.
>

... but your warranty is void after that. :)


>
> Dan is right about the quarantine, but it should be possible to build the
> quarantine as another layer on top an existing allocator. The quarantine
> would just not call the underlaying free() unless the memory is to be
> released from the quarantine. Actually, I think the quarantine in ASan is
> already decoupled from the allocator and could probably be used against
> other allocators.
>
> Needless to say, doing this would require quite a lot of changes to the
> existing allocator(s).
>
> Kostya, are there some extra features in the sanitizer allocator(s) that a
> system/user allocator wouldn't have?
>

Off the top of my head:
* Most system allocators have inline metadata (i.e. 8 or 16 bytes to the
left of the chunk returned to the user). Those will have to be poisoned
somehow. Also, if you don't fully know how your allocator works, you don't
know what else remains unpoisoned nearby.
* How to create redzones? If you create both left and right redzone, you
probably waste too much space. If you create just one (e.g. right) how do
you guarantee that there is one at the left.
* Where do you store stack traces associated with allocation and other
metadata (thread is, user requested size)?
* Quarantine is a huge PITA
* How do you recycle the shadow after deallocating large heap chunks (aka
madvise don't need)?
* How do you report bugs with detailed position inside the heap chunk?
* probably a couple more


With our new ASAN (HWASAN,
clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html)
most of these things will become much simpler since there is no quarantine
or redzones any more.






>
> Kuba
>
>
> On Jan 12, 2018, at 8:49 AM, Dan Liew  wrote:
>
> Hi,
>
> On 12 January 2018 at 08:37, Francis Ricci 
> wrote:
>
> Hi all,
>
> I may be missing something conceptually with the way ASan works, but
> is there any reason that ASan couldn't pass-through allocations to the
> user's allocator? For example:
>
> 1) User calls malloc()
> 2) ASan intercepts malloc(), does checks/adds metadata, etc
> 3) Instead of using the sanitizer allocator, ASan calls back into the
> user's malloc().
>
> Barring technical challenges here with the way interception works, is
> there any reason this couldn't work from an allocation perspective?
> Would it just be very slow? Or does the sanitizer allocator actually
> do a lot of extra work besides just allocating memory?
>
>
> I believe one of the reasons that ASan has a custom allocator is to
> detect use-after-free bugs.
> When memory is freed, that memory is placed in a quarantine area. By
> placing the freed memory
> in the quarantine, future calls to `malloc()` can't return the freed
> memory (unless the memory gets evicted from the quarantine) and ASan
> can record in its shadow
> memory that the region of memory that was freed should not be
> accessed. Then if the user's code tries to read or write to this freed
> memory
> ASan can report a use-after-free error.
>
> If you used your own allocator in ASan it might (and probably would
> given that its likely optimized for performance, not bug finding)
> return regions of memory that have previously been freed and thus ASan
> would miss use-after-free bugs.
>
> HTH,
> Dan.
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: llvm-symbolizer lookup next to binary

[Konstantin Serebryany]

On Mon, Nov 13, 2017 at 9:20 AM, Kuba Mracek <mra...@apple.com> wrote:

>
>
> On Nov 13, 2017, at 9:05 AM, Konstantin Serebryany <
> konstantin.s.serebry...@gmail.com> wrote:
>
>
>
> On Sat, Nov 11, 2017 at 3:48 AM, Christian Holler <chol...@mozilla.com> w
> rote:
>
>> Hello,
>>
>>
>> we're currently shipping an llvm-symbolizer binary next to the firefox
>>
>
> "shipping" as in "shipping to the testing farm" or as in "shipping to
> early adopters who run asan-ified firefox as their main browser"
> If the latter -- please don't.
> llvm-symbolizer deals with extremely complicated data format (DWARF) and
> is likely to have horrible security bugs.
>
>
> Isn't the same true for the ASan runtime per se?
>

To some extent, but much less so. At least ASan doesn't parse DWARF.


>
> Kuba
>
>
> If the former, I would simply suggest to have llvm-symbolizer in PATH on
> the testing machines (or some such)
>
>
>> binary in our Firefox+ASan tarball. Would it make sense for the asan-rt
>> to try and locate llvm-symbolizer also when it is not on PATH but in the
>> same directory as the running binary and executable? I realize we could
>> use ASan options or ASAN_SYMBOLIZER_PATH but that again requires custom
>> wrappers or early C code that modifies the default ASan options and I
>> figured this use case might not be so unusual. The target systems won't
>> have llvm-symbolizer installed.
>>
>>
>> Thanks,
>>
>> Chris
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: llvm-symbolizer lookup next to binary

[Konstantin Serebryany]

On Sat, Nov 11, 2017 at 3:48 AM, Christian Holler 
wrote:

> Hello,
>
>
> we're currently shipping an llvm-symbolizer binary next to the firefox
>

"shipping" as in "shipping to the testing farm" or as in "shipping to early
adopters who run asan-ified firefox as their main browser"
If the latter -- please don't.
llvm-symbolizer deals with extremely complicated data format (DWARF) and is
likely to have horrible security bugs.

If the former, I would simply suggest to have llvm-symbolizer in PATH on
the testing machines (or some such)


> binary in our Firefox+ASan tarball. Would it make sense for the asan-rt
> to try and locate llvm-symbolizer also when it is not on PATH but in the
> same directory as the running binary and executable? I realize we could
> use ASan options or ASAN_SYMBOLIZER_PATH but that again requires custom
> wrappers or early C code that modifies the default ASan options and I
> figured this use case might not be so unusual. The target systems won't
> have llvm-symbolizer installed.
>
>
> Thanks,
>
> Chris
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to build v8 engine with ASAN???

[Konstantin Serebryany]

Add -fsanitize=address to the compiler flags?
v8 is being routinely built with asan as part of the Chromium continuous
testing, so you can just build v8 as part of Chromium.
Or talk to the v8 folks -- they *probably* have a simple suggestion for
building v8 with asan w/o Chromium.

--kcc

On Tue, Sep 19, 2017 at 11:03 PM, Casper  wrote:

> How to build v8 engine with ASAN???
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: is that false alarm of "container-overflow"?

[Konstantin Serebryany]

On Tue, Aug 22, 2017 at 3:09 PM, Jennifer Liu 
wrote:

> Thanks for taking look at this.
>
> asan should already be enabled for all libs and binaries. Here is the
> output:
>

I remember that container-overflow was more problematic on Mac (compared to
Linux) since more libs are potentially uninstrumented.

In this case, try to add a printf that shows .size() and .capacity() of the
vector object at the time of acccess.
i.e. print 4 values:
  v.begin()
  v.begin() + v.capacity()
  v.begin() + v.size()
  ptr // the pointer that causes the crash.

if ptr is less than v.begin() + v.size() it's a false positive, as
explained at https://github.com/google/sanitizers/wiki/AddressSanitizerCo
ntainerOverflow#false-positives



>
> ==27158==ERROR: AddressSanitizer: container-overflow on address 
> 0x6250004b8992 at pc 0x00010f37fdf6 bp 0x7fff508fd5c0 sp 0x7fff508fd5b8
> READ of size 2 at 0x6250004b8992 thread T0
> #0 0x10f37fdf5 in CRsFecHeader::GetSourceBlockNumber() const 
> RsFecHeader.h:184
> #1 0x10f3872a7 in CMariRSRecoveryDecoder::flushSrcPackets(CRsFecHeader&) 
> MariRSRecoveryDecoder.cpp:722
> #2 0x10f38e3ee in CMariRSRecoveryDecoder::recover(CRsFecHeader&) 
> MariRSRecoveryDecoder.cpp:649
> #3 0x10f393365 in CMariRSRecoveryDecoder::receiveInd(unsigned int, 
> unsigned short, unsigned char const*, unsigned long, bool, unsigned int) 
> MariRSRecoveryDecoder.cpp:876
> #4 0x10f2fd206 in LLVMFuzzerTestOneInput fec_decode_fuzz.cpp:42
> #5 0x10f3f9a61 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, 
> unsigned long) (decode_fuzz_test:x86_64+0x1000fea61)
> #6 0x10f3f8553 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned 
> long, bool, fuzzer::InputInfo*) (decode_fuzz_test:x86_64+0x1000fd553)
> #7 0x10f3ff200 in fuzzer::Fuzzer::MutateAndTestOne() 
> (decode_fuzz_test:x86_64+0x100104200)
> #8 0x10f3ffac2 in fuzzer::Fuzzer::Loop() 
> (decode_fuzz_test:x86_64+0x100104ac2)
> #9 0x10f3de11a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned 
> char const*, unsigned long)) (decode_fuzz_test:x86_64+0x1000e311a)
> #10 0x10f3d022f in main (decode_fuzz_test:x86_64+0x1000d522f)
> #11 0x7fffc092a234 in start (libdyld.dylib:x86_64+0x5234)
>
> 0x6250004b8992 is located 4242 bytes inside of 8448-byte region 
> [0x6250004b7900,0x6250004b9a00)
> allocated by thread T0 here:
> #0 0x1107c7162  (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x63162)
> #1 0x10f3c1d05 in std::__1::__split_buffer std::__1::allocator&>::__split_buffer(unsigned long, unsigned 
> long, std::__1::allocator&) new:226
> #2 0x10f3bfe7b in std::__1::__split_buffer std::__1::allocator&>::__split_buffer(unsigned long, unsigned 
> long, std::__1::allocator&) __split_buffer:310
> #3 0x10f3beee5 in void std::__1::vector std::__1::allocator >::__push_back_slow_path const&>(fecPacket const&&&) vector:1567
> #4 0x10f392f02 in CMariRSRecoveryDecoder::receiveInd(unsigned int, 
> unsigned short, unsigned char const*, unsigned long, bool, unsigned int) 
> vector:1588
> #5 0x10f2fd206 in LLVMFuzzerTestOneInput fec_decode_fuzz.cpp:42
> #6 0x10f3f9a61 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, 
> unsigned long) (decode_fuzz_test:x86_64+0x1000fea61)
> #7 0x10f3f8553 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned 
> long, bool, fuzzer::InputInfo*) (decode_fuzz_test:x86_64+0x1000fd553)
> #8 0x10f3ff200 in fuzzer::Fuzzer::MutateAndTestOne() 
> (decode_fuzz_test:x86_64+0x100104200)
> #9 0x10f3ffac2 in fuzzer::Fuzzer::Loop() 
> (decode_fuzz_test:x86_64+0x100104ac2)
> #10 0x10f3de11a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned 
> char const*, unsigned long)) (decode_fuzz_test:x86_64+0x1000e311a)
> #11 0x10f3d022f in main (decode_fuzz_test:x86_64+0x1000d522f)
> #12 0x7fffc092a234 in start (libdyld.dylib:x86_64+0x5234)
>
> HINT: if you don't care about these errors you may set 
> ASAN_OPTIONS=detect_container_overflow=0.
> If you suspect a false positive see also: 
> https://github.com/google/sanitizers/wiki/AddressSanitizerContainerOverflow.
> SUMMARY: AddressSanitizer: container-overflow RsFecHeader.h:184 in 
> CRsFecHeader::GetSourceBlockNumber() const
> Shadow bytes around the buggy address:
>   0x1c4a000970e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x1c4a000970f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x1c4a00097100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x1c4a00097110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x1c4a00097120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x1c4a00097130: fc fc[fc]fc fc fc fc fc fc fc fc fc fc fc fc fc
>   0x1c4a00097140: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>   0x1c4a00097150: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>   0x1c4a00097160: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>   0x1c4a00097170: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>   

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

[Konstantin Serebryany]

On Sat, Jul 29, 2017 at 8:02 AM, Yuri Gribov <tetra2...@gmail.com> wrote:

> On Thu, Jul 27, 2017 at 10:51 PM, Konstantin Serebryany
> <konstantin.s.serebry...@gmail.com> wrote:
> > Just to make sure: all you are suggesting is to change the default
> value(s)
> > of flag(s), right?
>
> Yup.
>
> > I am reluctant to change the defaults here because core dumps are rarely
> > 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?
>

Given the amount of different environments where asan is used, almost any
kind of default flag change is a potential for a trouble.
We do it sometimes when there is a pressing need, but this one doesn't look
like one.

--kcc


>
> > On Wed, Jul 26, 2017 at 11:57 PM, Yuri Gribov <tetra2...@gmail.com>
> wrote:
> >>
> >> 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 platforms unconditionally? This is causing real usability
> >> issues (see
> >> https://stackoverflow.com/questions/45280910/gcc-
> address-sanitizer-core-dump-on-error).
> >>
> >> -I
> >>
> >> --
> >> 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+unsubscr...@googlegroups.com.
> >> For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > 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+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Konstantin Serebryany]

Just to make sure: all you are suggesting is to change the default value(s)
of flag(s), right?

I am reluctant to change the defaults here because core dumps are rarely
useful with asan reports and because they will cause more trouble then is
worth it (atexit timeout, disk full, etc)

--kcc

On Wed, Jul 26, 2017 at 11:57 PM, Yuri Gribov  wrote:

> 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 platforms unconditionally? This is causing real usability
> issues (see https://stackoverflow.com/questions/45280910/gcc-
> address-sanitizer-core-dump-on-error).
>
> -I
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making adaptive redzones less aggressive

[Konstantin Serebryany]

I can argue that this heuristic is totally relevant for 'int a[1100]'
because lots of scientific code uses single-dimensional arrays as
n-dimensional:

#define N 100
int a[N * N];
...
a[i * N + j];  // off-by-one in 'i' will lead to off-by-N

And no, I did not try to investigate if a better heuristic is possible.
The basis for the current heuristic is that it does not increase the memory
footprint (for globals) by more than X%.

--kcc






On Mon, Jul 17, 2017 at 2:41 AM, Yuri Gribov  wrote:

> 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 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 adaptation only considers size of array as a whole so would
> >> add similarly big redzone for same-sized
> >>
> >>   int a[1100];
> >>
> >> even though risk of large overflow offset here seems to be much lower.
> >>
> >> Has anyone considered selecting redzone based on array element size
> >> rather than array size? Firstly this would allow more intelligent
> >> redzone selection (current approach does not guarantee that generated
> >> redzone will cover one array element) and also reduce memory pressure
> >> (which is important for "embedded" targets).
> >
> > I totally agree that for compound type arrays the redzone size must be
> > based on the array element size.
> >
> > Not sure if we need to reduce the redzone size for big arrays of
> > scalars, as e.g. char arrays are sometimes used as opaque storage for
> > compound types.
>
> Good point.
>
> > Do you have any evidence how big is the memory overhead caused by
> > redzones in this case?
>
> Not yet, this is something we'll need to investigate (my question was
> mainly whether it makes sense to investigate this).
>
> -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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Address Sanitizer clashes with Dataflow Sanitizer

[Konstantin Serebryany]

On Fri, Jun 9, 2017 at 4:52 PM, 'Evgenii Stepanov' via address-sanitizer <
address-sanitizer@googlegroups.com> wrote:

> On Fri, Jun 9, 2017 at 4:26 PM, hariri via address-sanitizer
>  wrote:
> > Thanks for your reply Evgeniy.
> >
> >> It could be possible
> > to hack something, but it does not sound easy
> >
> > Could you please give me some pointers into what needs to be hacked to
> make
> > this possible?
>
> A few problems come to mind:
> 1. Shadow mappings of asan and dfsan probably overlap. ASan has a mode
> where shadow address is detemined at run time, it might help.
> 2. runtime libraries for asan and dfsan include the same code from
> lib/sanitizer_common. They must learn to share. See lib/lsan in
> compiler-rt for an example of a tool that can work either on its own,
> or with asan. This will also need build system changes to create a
> combined runtime library (asan + dfsan + sanitizer_common), and clang
> frontend changes to link it when necessary.
> 3. Do something about the interceptors. DFsan uses __dfsw_ -prefixed
> wrappers that update labels for some libc functions; need to make sure
> that asan interceptors (in lib/asan/asan_interceptors.cc) also run. It
> may just work out of the box.
>
> >
> >>  it's not clear to
> > me how one would tie them together.
> >
> > The scenario is the following: I am using libFuzzer to fuzz a library,
> and
> > libFuzzer works best
> > with a sanitizer like asan (as recommended by the documentation). What I
> > would like to do is
> > use taint information from the dataflow sanitizer to make fuzzing more
> > efficient and focus on
> > interesting parts of the input.
>
> The easiest way is to run two separate builds over the same corpus.
>

+1
We actually had some code in libFuzzer to work with dfsan and the idea was
to run with
dfsan to increase the coverage and separately run with asan to catch bugs.
I then deleted all this code from libFuzzer because it was a) not used and
b) made it much harder to do refactoring.
I still hope to get dfsan support back in at some point though --
data-flow-based mutations are too attractive.

I do not recommend you to invest time into running asan and dfsan in one
process -- simply too much work.

--kcc



>
> >
> > On Friday, June 9, 2017 at 2:41:57 PM UTC-7, Evgeniy Stepanov wrote:
> >>
> >> Hi,
> >>
> >> these tools were not designed to work together. It could be possible
> >> to hack something, but it does not sound easy. In particular, they use
> >> different techniques for intercepting libc calls and it's not clear to
> >> me how one would tie them together.
> >>
> >>
> >> On Fri, Jun 9, 2017 at 8:52 AM, hariri via address-sanitizer
> >>  wrote:
> >> > Hi,
> >> >
> >> > I am trying to use the dataflow sanitizer with the address sanitizer,
> >> > but
> >> > they clash together giving me a long sequence of errors due to
> multiple
> >> > definitions in both sanitizers:
> >> >
> >> >
> >> > clang-llvm/ninja-build-clang/lib/clang/5.0.0/lib/linux/
> libclang_rt.dfsan-x86_64.a(interception_linux.cc.o):
> >> > In function `__interception::GetRealFunctionAddress(char const*, \
> >> >
> >> > unsigned long*, unsigned long, unsigned long)':
> >> >
> >> >
> >> > clang-llvm/llvm/projects/compiler-rt/lib/interception/
> interception_linux.cc:22:
> >> > multiple definition of `__interception::GetRealFunctionAddress(char
> >> > const*,
> >> > unsigned long*, u\
> >> >
> >> > nsigned long, unsigned long)'
> >> >
> >> >
> >> > clang-llvm/ninja-build-clang/lib/clang/5.0.0/lib/linux/
> libclang_rt.asan-x86_64.a(interception_linux.cc.o):
> clang-llvm/llvm/projects/compiler-rt/\
> >> >
> >> > lib/interception/interception_linux.cc:22: first defined here
> >> >
> >> >
> >> > clang-llvm/ninja-build-clang/lib/clang/5.0.0/lib/linux/
> libclang_rt.dfsan-x86_64.a(interception_linux.cc.o):
> >> > In function `__interception::GetFuncAddrVer(char const*, char con\
> >> >
> >> > st*)':
> >> >
> >> >
> >> > clang-llvm/llvm/projects/compiler-rt/lib/interception/
> interception_linux.cc:28:
> >> > multiple definition of `__interception::GetFuncAddrVer(char const*,
> char
> >> > const*)'
> >> >
> >> >
> >> > clang-llvm/ninja-build-clang/lib/clang/5.0.0/lib/linux/
> libclang_rt.asan-x86_64.a(interception_linux.cc.o):
> clang-llvm/llvm/projects/compiler-rt/\
> >> >
> >> > lib/interception/interception_linux.cc:28: first defined here
> >> >
> >> >
> >> > clang-llvm/ninja-build-clang/lib/clang/5.0.0/lib/linux/
> libclang_rt.dfsan-x86_64.a(sanitizer_allocator.cc.o):
> >> > In function `atomic_load<__sanitizer::atomic_uint8_t>':
> >> >
> >> >
> >> > clang-llvm/llvm/projects/compiler-rt/lib/sanitizer_
> common/sanitizer_atomic_clang_x86.h:47:
> >> > multiple definition of `__sanitizer::internal_allocator()'
> >> >
> >> >
> >> > clang-llvm/ninja-build-clang/lib/clang/5.0.0/lib/linux/
> libclang_rt.asan-x86_64.a(sanitizer_allocator.cc.o):
> clang-llvm/llvm/projects/compiler-rt\
> >> >
> >> > 

Re: LeakSanitizer trigger dump of current heap state programatically

[Konstantin Serebryany]

Depending on what you mean by the heap state.
There is an experimental __sanitizer_print_memory_profile (only in asan,
not in standalone lsan)
which will print a simple heap profile. Not much else.

  // Prints stack traces for all live heap allocations ordered by total
  // allocation size until `top_percent` of total live heap is shown.
  // `top_percent` should be between 1 and 100.
  // At most `max_number_of_contexts` contexts (stack traces) is printed.
  // Experimental feature currently available only with asan on
Linux/x86_64.
  void __sanitizer_print_memory_profile(size_t top_percent,
size_t max_number_of_contexts);


On Fri, Mar 24, 2017 at 4:26 AM, Roger James 
wrote:

> Is there any way to trigger LeakSanitizer programmatically to dump the
> current heap state. I am trying to debug a transient heap allocation spike.
>
> Roger
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Konstantin Serebryany]

This is much harder than it sounds.
I've made an attempt ~2 years ago and it almost, but not quite entirely,
worked
https://github.com/google/sanitizers/wiki/AddressSanitizerIntraObjectOverflow
(Only for non POD objects in C++, so it won't directly apply to 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  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 this community, I've enabled the Asan for
> global
> >>> and stack buffer in my bare-mental platform firmware, thanks a lot.
> >>> But I find the current Asan doesn't support to protect the structure
> inner
> >>> elements, E.g. the global_array[11] in below code. Unfortunately, most
> of
> >>> important data are defined through structure in my firmware, and if
> the Asan
> >>> doesn't support to protect structure inner elements, most of my data
> memory
> >>> access will not be protected by Asan. So, could we let Asan support
> >>> structure inner elements?
> >>>
> >>> Well, I understand it is not safe to just instrument red-zone between
> >>> structure inner elements like current Asan does on global variable.
> We also
> >>> need to handle the sizeof(), offsetof() macro, the alignment pragma,
> and
> >>> maybe others. Could we extend Asan scope beyond IR to Clang front-end
> to do
> >>> some source-to-source conversion to handle these issue? E.g. for no
> >>> alignment enforced structure,  replace the structure inner elements
> with
> >>> red-zone instrumented version, and let the sizeof() be-aware of the
> size
> >>> change. Is it possible?
> >>
> >> Won't this break separate sanitization? E.g. if I have libfoo.so that
> has
> >> struct Foo as part of its ABI and I want to test it with ASan, I'll
> need to
> >> recompile not only libfoo.so, but all dependent libraries too to make
> sure
> >> they caught up the changed layout of struct Foo. This sounds like a bad
> idea
> >> for me.
> >> Or maybe I've just missed something?
> >
> > I think Steven's code is self-contained so he does not care. Also note
> > that you can get away without breaking ABI but just poisoning natural
> > padding in structures. I guess the main problem with sanitizing
> > structs is that they are often passed to "low-level"
> > memcmp/memcpy/memset/etc. functions which would result in spurious
> > errors.
>
> Also in C you don't get type information as easily as with C++'s new
> operator. Structs are allocated as untyped memory buffers via malloc
> and then casted to appropriate type. Compiler will have to figure out
> that newly allocated char*-pointer is meant to point to struct (which
> is not always possible e.g. if malloc happens in a different function
> in separate translation unit).
>
> -I
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Shadow gap for Linux mapping with MidMem

[Konstantin Serebryany]

Yea, this prelink thing is very confusing.
better just not use it when running asan -- I don't know if anyone is
continuously testing that asan works with prelink.

And yes, this is not a big deal.

--kcc

On Fri, Nov 4, 2016 at 3:10 PM, Kuba Brecka  wrote:

> Hi,
>
> I've been asked about this at the LLVM Dev Meeting by Eric Feng:  The ASan
> memory mapping for Linux with prelink looks like this (taken from
> asan_mapping.h):
>
> // || `[0x10007fff8000, 0x7fff]` || HighMem||
> // || `[0x02008fff7000, 0x10007fff7fff]` || HighShadow ||
> // || `[0x0050, 0x02008fff6fff]` || ShadowGap3 ||
> // || `[0x0030, 0x004f]` || MidMem ||
> // || `[0x000a7fff8000, 0x002f]` || ShadowGap2 ||
> // || `[0x00067fff8000, 0x000a7fff7fff]` || MidShadow  ||
> // || `[0x8fff7000, 0x00067fff7fff]` || ShadowGap  ||
> // || `[0x7fff8000, 0x8fff6fff]` || LowShadow  ||
> // || `[0x, 0x7fff7fff]` || LowMem ||
>
> There seems to be a part of HighShadow where the mapping doesn't point to
> any of the ShadowGaps, but instead it points to MidMem.  E.g. 
> MEM_TO_SHADOW(0x02008fff7000)
> == 0x004091ff6e00).  While this may not be a big deal, I'm just wondering
> if that's intentional.  If yes, this should be documented as a comment in
> asan_mapping.h.  This seems to have been done in r176250 without mentioning
> that a part of the shadow memory is not covered by a shadow gap anymore.
>
> Thanks,
> Kuba
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ASN for MIPS with either clang or gcc

[Konstantin Serebryany]

Sagar, Simon,
Could you please consult on ASAN  for MIPS?

On Fri, Oct 14, 2016 at 3:04 PM, Park Kit  wrote:

> Correction. ASN means ASAN of course. :-)
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Interceptors and system headers

[Konstantin Serebryany]

On Fri, Sep 30, 2016 at 8:33 AM, Kuba Brecka  wrote:

> Hi everyone,
>
> what is the reason for interceptors to *not* include system headers like
> pthread.h and time.h, and instead declare all the structures like
> “__sanitizer_tm” or “__sanitizer_pthread_attr_t”?  Why don’t we just
> include the system headers and use pthread_attr_t directly?
>

We tried this in the beginning and the portability nightmare was never
ending.
The way we have it now is terrible, yet still better than dealing with the
headers on all possible OSes.


>
> I’m asking because I’m trying to make a build configured with modules
> (LLVM_ENABLE_MODULES=1) work.  When modules are used, external functions
> must come from system headers and the declarations must match.
>
Just exclude sanitizer run-times form it :)

--kcc

>
> Thanks,
> Kuba
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Chromium ASAN builds

[Konstantin Serebryany]

On Mon, Aug 15, 2016 at 6:31 AM, 'Reid Kleckner' via address-sanitizer <
address-sanitizer@googlegroups.com> wrote:

> We believe this is somehow related to the gyp to gn migration, and
> hopefully someone will look into it this week.
>

Yep. https://bugs.chromium.org/p/chromium/issues/detail?id=636212


> Sent from phone
>
> On Aug 13, 2016 8:27 AM, "Hanno Böck"  wrote:
>
>> Hi,
>>
>> Looking at the asan chromium builds:
>> https://commondatastorage.googleapis.com/chromium-browser-
>> asan/index.html?prefix=linux-release/
>>
>> There's a sudden spike in the file size for the asan-linux-release
>> version on 22nd july. Older versions were slightly less than 1 GB,
>> newer ones 2,7 GB (later going back down to ~2,4 GB).
>>
>> What has happened there? Is there a reason why it's suddenly that much
>> bigger or is this a mistake?
>>
>> Also while I'm at it: I'm regularly playing with the chrome asan
>> builds and the huge directory index is a big hurdle when trying to
>> download it. While it's nice that one can also get older builds would it
>> be possible that there's a directory that contains links to only the
>> latest  two or three versions of each build?
>>
>
I'll forward this request to the ClusterFuzz folks.


>
>> --
>> Hanno Böck
>> https://hboeck.de/
>>
>> mail/jabber: ha...@hboeck.de
>> GPG: BBB51E42
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Porting ASAN

[Konstantin Serebryany]

+Rich (from MUSL) -- FYI

On Wed, Jul 27, 2016 at 2:48 AM, 'Alexander Potapenko' via
address-sanitizer  wrote:

> Hi Todd,
>
> you sure can build ASan with fewer interceptors. For example it's safe
> to comment everything from
> compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc
> out. Also, most of the interceptors from
> compiler-rt/lib/asan/asan_interceptors.cc (those that only read/write
> memory) are also safe to disable. There is a number of pthread_*
> interceptors that are necessary to track thread creation, but as long
> as you build only single-threaded programs you can even live without
> those.
>
> Can you please elabortate on how you are going to implement function
> interception? Using weak symbols will require static linking - will
> that be convenient for your users?
> Do you control the executable file format and/or the default system linker?
>
> TIA,
> Alex
>
> On Wed, Jul 27, 2016 at 12:08 AM, 'Todd Eisenberger' via
> address-sanitizer  wrote:
> > I'm looking at porting the llvm ASAN support to a new operating system
> > (initially focusing on the x86-64 and aarch64 architectures).  My long
> term
> > plan is to perform interception by having our libc (a fork of musl) and
> core
> > system library expose weak symbols that compiler-rt can override, rather
> > than performing the interception using the dynamic linker like the
> current
> > platforms do.
> >
> > As a short term step, is there a reasonable way to build compiler-rt with
> > fewer interceptors with the intent of compiling libc with ASAN support
> > instead of wrapping the libc functions?  I'm aware that if this is
> possible,
> > it would have performance implications, but I would like to initially
> focus
> > on getting the non-interceptor portion of the runtime to work in our
> > environment.
> >
> > Thanks,
> > Todd Eisenberger
> >
> > --
> > 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+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Alexander Potapenko
> Software Engineer
>
> Google Germany GmbH
> Erika-Mann-Straße, 33
> 80636 München
>
> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unable to use asan with XCode on Mac

[Konstantin Serebryany]

On Sun, May 8, 2016 at 10:03 AM, Amit Kumar  wrote:

> Hi,
> I am reviving this 3 years old thread. The good news is that address
> sanitizer is now officially supported by Apple in Xcode 7.
>
> Thanks everyone.
>
> Could it be a good idea to create a release build (highly optimized) in
> order to use with asan? I have created a debug build (all optimizations
> off) and it is working reasonably well with asan so I have no issues in
> using the debug build.
>

If performance of a debug build is ok for you, a highly optimized build
will not find anything new.
There are of course some exceptions, e.g. we once found a bug in the
optimizer itself with asan.
Or there could be bugs that depend on timing and don't trigger in debug
build.
Or some other kind of undefined behavior that will trigger a bug only in
optimized build and then will manifest as a memory corruption bug.


>
> I read on the asan page: "To get a reasonable performance add -O1 or
> higher."
> Does this imply that if performance is not an issue then disabling all
> optimizations (-O0) and creating a debug build may work the best?
>

Mostly yes. Although frankly I don't have much experience with using
asan+O0.
We always use it with O1 or O2.


>
> What is the optimization level used for chrome asan builds?
>

-O2.
In a large internal project we use -O1 but considering to migrate to -O2
due to better performance.



>
> Thanks,
> Amit
>
>
> On Tue, Oct 1, 2013 at 7:17 PM, Alexander Potapenko <
> ramosian.gli...@gmail.com> wrote:
>
>> Yes, right now you have to build Clang yourself. ASan isn't officially
>> supported by Apple, that's why it's disabled in Xcode.
>> See http://code.google.com/p/address-sanitizer/wiki/HowToBuild for the
>> build instructions. There's also pretty much information about using
>> the trunk Clang with Xcode on stackoverflow.com.
>>
>> On Tue, Oct 1, 2013 at 5:33 PM, Amit Kumar  wrote:
>> > I currently work on a product which has 200+ plugins and the code is
>> written
>> > in C++. This application works on both Mac and Windows. I have been
>> using
>> > Guard malloc to find memory related issues in this product. Guard
>> malloc has
>> > been very useful and it has found several issues in the codebase,
>> however,
>> > it also misses many issues. I have evaluated valgrind but that makes the
>> > application so slow that it is practically useless for our purpose.
>> > I was very much interested in evaluating address sanitizer. The problem
>> is
>> > that I am unable to use it.
>> >
>> > Earlier versions of Xcode used to support the flag -faddress-sanitizer,
>> > however even a basic cocoa application built using this used to crash.
>> In
>> > the newer versions of xcode, -faddress-sanitizer gives unsupported flag
>> > error. The newer way of specifying the flag -faddress=sanitize has
>> > apparently no effect.
>> > This is very discouraging for me that I am unable to use asan even with
>> a
>> > very simple cocoa application on mac.
>> > Do I need to build clang myself? Is there any hope that I will be able
>> to
>> > use asan on Mac.
>> > I have gone through the following link:
>> >
>> https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForMacImplementationDetails
>> >
>> > Thanks,
>> > Amit
>>
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: UBSan suppressions on embedded system

[Konstantin Serebryany]

On Tue, May 3, 2016 at 12:42 PM, 'Alexey Samsonov' via address-sanitizer <
address-sanitizer@googlegroups.com> wrote:

>
> On Tue, May 3, 2016 at 10:49 AM, Konstantin Serebryany <
> konstantin.s.serebry...@gmail.com> wrote:
>
>>
>>
>> On Tue, May 3, 2016 at 1:03 AM, 'Ilya' via address-sanitizer <
>> address-sanitizer@googlegroups.com> wrote:
>>
>>> Hello everybody,
>>> first of all: thanks for reading. I have questions regarding the
>>> UndefinedBehaviourSanitizer and didn't know where else to post them.
>>>
>>
>> Usually, ubsan-related questions get answered at  llvm-...@lists.llvm.org,
>> we we can reply too :)
>>
>>
>>
>>>
>>> I am currently working on an embedded system project, porting the UBSan
>>> RTL (GCC) to work with our stuff. After lots of ripping out this works,
>>> with a few side effects though (for example no support for flags in the RTL
>>> (yet)). To make this work in a long perspective I'd like to get rid of all
>>> current ubs. However, since low-level stuff is low-level, we have some
>>> occurrences of ub which are to be accepted and will last (a few null
>>> pointer dereferences, packed structures, etc..). I figured out how to get
>>> rid of some warnings (function-wise attributes),
>>>
>>
>> You mean, __attribute__((no_sanitizer("your-but-type"))), right?
>> That's the best.
>>
>>
>>> but this won't help with for example the packed structures.
>>>
>>> So I want to suppress the warnings in a few occasions. I however can't
>>> figure out, how exactly issue suppression (other than function-wise via
>>> attributes) works in the UBSan. I do see the suppression context being
>>> created, with the file being parsed. However the only usage of that in the
>>> UBSan I can find is the "IsVptrCheckSuppressed" function.
>>>
>>> So, main questions:
>>> Which file described in the Clang documentation is being parsed into the
>>> suppression context? (fsanitize-blacklist, or UBSAN_OPTIONS=suppressions
>>> =MyUBSan.supp ?)
>>>
>>
>> fsanitize-blacklist is a compile-time suppression mechanism -- the code
>> in the blacklist is not instrumented.
>> This would have been preferable, but AFIACT, gcc does not support this
>> flag. (correct me if I am wrong).
>>
>>
>>
>>> Is the suppression context used in another way that I don't see?
>>>
>>
>
>
>>
>>> And how is the other file used then?
>>>
>>
>> I am not sure I understand your question about
>> UBSAN_OPTIONS=suppressions=MyUBSan.supp
>> If you can provide a small example where something does not work as
>> expected (with the fresh clang) we can take a look.
>>
>
> Note that the fresh Clang has way better support for runtime suppressions,
> and allows you to suppress issues by the error kind.
>
>
>> Note that UBSAN_OPTIONS=suppressions=... is a run-time option and if you
>> hit the bug you are going to suppress very often
>> the suppression will slow down the run significantly.
>>
>
> No, I believe UBSan report deduplication would kick in here: when we first
> try to print an error report associated with a PC, we will
> check if it should be suppressed (this can be expensive, as it might
> require symbolization). All further attempts to report the same error
> would be silently and quickly ignored.
>

quickly is in "quicker than the first time".
Still pretty slow if you have a report in a hot spot.


>
>
>>
>> --kcc
>>
>>>
>>> Thank you, for taking the time and the great tools,
>>> Ilya
>>>
>>> --
>>> 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+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Alexey Samsonov, Mountain View, CA
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: UBSan suppressions on embedded system

[Konstantin Serebryany]

On Tue, May 3, 2016 at 1:03 AM, 'Ilya' via address-sanitizer <
address-sanitizer@googlegroups.com> wrote:

> Hello everybody,
> first of all: thanks for reading. I have questions regarding the
> UndefinedBehaviourSanitizer and didn't know where else to post them.
>

Usually, ubsan-related questions get answered at  llvm-...@lists.llvm.org,
we we can reply too :)



>
> I am currently working on an embedded system project, porting the UBSan
> RTL (GCC) to work with our stuff. After lots of ripping out this works,
> with a few side effects though (for example no support for flags in the RTL
> (yet)). To make this work in a long perspective I'd like to get rid of all
> current ubs. However, since low-level stuff is low-level, we have some
> occurrences of ub which are to be accepted and will last (a few null
> pointer dereferences, packed structures, etc..). I figured out how to get
> rid of some warnings (function-wise attributes),
>

You mean, __attribute__((no_sanitizer("your-but-type"))), right?
That's the best.


> but this won't help with for example the packed structures.
>
> So I want to suppress the warnings in a few occasions. I however can't
> figure out, how exactly issue suppression (other than function-wise via
> attributes) works in the UBSan. I do see the suppression context being
> created, with the file being parsed. However the only usage of that in the
> UBSan I can find is the "IsVptrCheckSuppressed" function.
>
> So, main questions:
> Which file described in the Clang documentation is being parsed into the
> suppression context? (fsanitize-blacklist, or UBSAN_OPTIONS=suppressions=
> MyUBSan.supp ?)
>

fsanitize-blacklist is a compile-time suppression mechanism -- the code in
the blacklist is not instrumented.
This would have been preferable, but AFIACT, gcc does not support this
flag. (correct me if I am wrong).



> Is the suppression context used in another way that I don't see?
>
> And how is the other file used then?
>

I am not sure I understand your question about
UBSAN_OPTIONS=suppressions=MyUBSan.supp
If you can provide a small example where something does not work as
expected (with the fresh clang) we can take a look.
Note that UBSAN_OPTIONS=suppressions=... is a run-time option and if you
hit the bug you are going to suppress very often
the suppression will slow down the run significantly.

--kcc

>
> Thank you, for taking the time and the great tools,
> Ilya
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: configure scripts, pthread detection and asan

[Konstantin Serebryany]

On Wed, Jan 20, 2016 at 9:40 AM, Hanno Böck <ha...@hboeck.de> wrote:

> On Wed, 20 Jan 2016 09:14:53 -0800
> Konstantin Serebryany <konstantin.s.serebry...@gmail.com> wrote:
>
> > Are you talking about gcc or clang?
>
> gcc in this case.
>
> > In gcc looks like this does not happen.
> > (I'd say this needs to be fixed in gcc, just for compatibility, at
> > least)
>
> Okay, so should we open a bug report for gcc?
>

It won't hurt. I don't know what the gcc folks think about this,
but once we file a bug we'll know. :)


> Anyway, given that the gcc-deployment-to-distro process is taking quite
> a while I wonder if corresponding configure changes should be attempted
> anyway.
>

As Dmitry suggested, if you always use "-fsanitize=address -lpthread" it
will work with both clang and gcc.
So it might be the simplest fix (no need to change the config scripts)
Just document it that -lpthread is there due to the gcc bug/feature.


>
> --
> Hanno Böck
> http://hboeck.de/
>
> mail/jabber: ha...@hboeck.de
> GPG: BBB51E42
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: configure scripts, pthread detection and asan

[Konstantin Serebryany]

Are you talking about gcc or clang?

In clang, the driver adds -lpthread to the linker command.

% clang -fsanitize=address ./heap-buffer-overflow.c -v 2>&1 | grep thread
--color
...-lpthread -lrt -lm -ldl -lgcc...

In gcc looks like this does not happen.
(I'd say this needs to be fixed in gcc, just for compatibility, at least)



On Wed, Jan 20, 2016 at 5:26 AM, 'Dmitry Vyukov' via address-sanitizer <
address-sanitizer@googlegroups.com> wrote:

> On Wed, Jan 20, 2016 at 2:22 PM, Hanno Böck  wrote:
> > Hi,
> >
> > I stumbled upon an issue that I'm not sure what the best fix is and
> > wanted to ask people here for opinions.
> >
> > There are a couple of packages that have a check in the configure
> > script that will check for the presence of the pthread_create function.
> > The check works as far as I understand as follows:
> > * check whether pthread_create is available without a flag
> > * check whether pthread_create is available with -lpthread
> >
> > Now here's the problem: libasan contains a pthread_create function.
> > Therefore the configure scripts will assume that pthread is available.
> > However libasan doesn't contain the full pthread functionality, other
> > functions like pthread_mutex_create aren't available.
> >
> > Therefore:
> > * configure script thinks we don't need -lpthread
> > * application uses pthread functionality that's not in libasan
> > * compilation fails
> >
> >
> > I have first encountered this in sqlite, upstream has now fixed this by
> > checking for a different pthread function (patch came from me):
> > https://www.sqlite.org/cgi/src/info/9c3a0dc2e8bf202c
> >
> > Now I wonder - is this a good solution? I know of at least three other
> > packages (poppler, openldap, p11-kit) that have the same issue and
> > wonder if I should send similar patches or if there's a better / more
> > clean solution to this.
>
>
> FWIW you can add -lpthread whenever you add -fsanitize=address.
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Stack oob not detected with -O2

[Konstantin Serebryany]

In LLVM this will also be non-trivial,
but I expect it to be counter-productive because asan will inhibit many
optimizations.
Easier to just run with -O0 periodically. I know this is actually not easy
at all. :(

What we can and should do is to teach llvm to emit a proper trap.

Consider my example:

int bar() { return 3; }
int foo() {
  int x[3] = {1, 2, 3};
  return x[bar()];
}


% clang -c -O2   sbo.cc -emit-llvm -o - -S
define i32 @_Z3foov() #0 {
entry:
  ret i32 undef
}


Here, if you use -O2, the compiler will optimize the illegal code into ret
i32 undef,
but it will not crash, sadly. Maybe it should.

Same thing in your example:
  %call = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x
i8], [4 x i8]* @.str, i64 0, i64 0), i32 undef)


I'd suggest you to either start a discussion at llvm-dev or file a LLVM
bug.

BTW, -fsanitize=bounds will catch these bugs.

--kcc


On Sun, Jan 17, 2016 at 3:24 AM, Yuri Gribov  wrote:

> 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 much better than -O0.
>
> This isn't so easy with GCC which tends to start "optimizing" code
> long before GIMPLE. AFAIR in my case erroneous memory access was
> removed during parsing.
>
> > On Friday, January 15, 2016 at 5:58:36 PM UTC+1, kcc 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 we miss this way; some for sure.
> >>
> >> On Fri, Jan 15, 2016 at 8:51 AM, Hanno Böck  wrote:
> >>>
> >>> Hi,
> >>>
> >>> I just saw this tweet by John Regehr:
> >>> https://twitter.com/johnregehr/status/688033344580399104
> >>>
> >>> He found a code example with a pretty obvious out of bounds stack read
> >>> that asan doesn't catch with -O or -O2 (equivalent). I checked this
> >>> with both current gcc and clang.
> >>>
> >>> This is a stripped down example:
> >>> int main() {
> >>> int b[1] = {0};
> >>> int a=-1;
> >>> printf("%i\n", b[a]);
> >>> }
> >>>
> >>>
> >>> I am a bit surprised, because this looks like a poster child example of
> >>> the kind of bug asan can find. But somehow the optimization
> >>> seems to break the asan check here.
> >>>
> >>> I now wonder how many bugs keep being hidden because of this, as -O2 is
> >>> a pretty common default setting for compilations.
> >>>
> >>>
> >>> --
> >>> Hanno Böck
> >>> http://hboeck.de/
> >>>
> >>> mail/jabber: ha...@hboeck.de
> >>> GPG: BBB51E42
> >>>
> >>> --
> >>> 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-saniti...@googlegroups.com.
> >>> For more options, visit https://groups.google.com/d/optout.
> >>
> >>
> > --
> > 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+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Stack oob not detected with -O2

[Konstantin Serebryany]

+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 we miss this way; some for sure.

On Fri, Jan 15, 2016 at 8:51 AM, Hanno Böck  wrote:

> Hi,
>
> I just saw this tweet by John Regehr:
> https://twitter.com/johnregehr/status/688033344580399104
>
> He found a code example with a pretty obvious out of bounds stack read
> that asan doesn't catch with -O or -O2 (equivalent). I checked this
> with both current gcc and clang.
>
> This is a stripped down example:
> int main() {
> int b[1] = {0};
> int a=-1;
> printf("%i\n", b[a]);
> }
>
>
> I am a bit surprised, because this looks like a poster child example of
> the kind of bug asan can find. But somehow the optimization
> seems to break the asan check here.
>
> I now wonder how many bugs keep being hidden because of this, as -O2 is
> a pretty common default setting for compilations.
>
>
> --
> Hanno Böck
> http://hboeck.de/
>
> mail/jabber: ha...@hboeck.de
> GPG: BBB51E42
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Experimental detection of usage on an uninitialized memory

[Konstantin Serebryany]

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.
> >
> > 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 memory
> >
> > GCC started to annotate all class ctors and dtors with memory clobber
> store:
> > -flifetime-store
> >
> https://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Optimize-Options.html#Optimize-Options
> >
> > Looks Firefox suffers from many of these errors and segfaults during
> startup
> > with latest GCC and link-time optimization.
> > Let's assume following example:
> >
> > #include 
> > #include 
> > #include 
> > #include 
> >
> > struct A
> > {
> >   char i[100];
> >   A() {}
> >   ~A() {}
> > };
> >
> > int get_value (int *a, int i)
> > {
> >   return a[i];
> > }
> >
> > int main()
> > {
> >   int *ar = (int *)malloc (111);
> >   *ar = 123;
> >   fprintf (stderr, "memory: %p\n", ar);
> >
> >   A* ap = new(ar) A;
> >   ap->~A();
> >
> >   get_value (ar, 10); // use of uninitialized memory
> >
> >   return 0;
> > }
> >
> > As you can see, calling get_value is an invalid operation. However, e.g.
> > valgrind tool is unable to catch these as the value is initialized.
> > I came with an experimental patch to address sanitizer that annotates
> every
> > memory clobber to call memory poisoning. On the other hand,
> > every memory store must unpoison the memory.
>
> This has been brought up before in
> https://github.com/google/sanitizers/issues/73 but guys decided to
> firstly do this in MSan. I guess adding this to ASan as an option
> would be cool because it's much easier to integrate (I'm not an owner
> or maintainer though so speaking for myself here).
>

Correct. In msan this feature is already implemented:
http://clang.llvm.org/docs/MemorySanitizer.html#use-after-destruction-detection
I frankly don't know how to correctly implement it in asan
because asan's shadow does not distinguish between reads and writes.


>
> > Sample output from patched GCC & sanitizer:
> >
> > ==12358==ERROR: AddressSanitizer: heap-clobbered-memory-read on address
> > 0x60b0afb8 at pc 0x00400ad1 bp 0x7fffdca0 sp 0x7fffdc98
> > READ of size 4 at 0x60b0afb8 thread T0
> > #0 0x400ad0 in get_value(int*, int) (/tmp/a.out+0x400ad0)
> > #1 0x400bca in main (/tmp/a.out+0x400bca)
> > #2 0x7621960f in __libc_start_main (/lib64/libc.so.6+0x2060f)
> > #3 0x4009a8 in _start (/tmp/a.out+0x4009a8)
> >
> > 0x60b0afb8 is located 40 bytes inside of 111-byte region
> > [0x60b0af90,0x60b0afff)
> > allocated by thread T0 here:
> > #0 0x76f02128 in __interceptor_malloc
> > ../../../../libsanitizer/asan/asan_malloc_linux.cc:38
> > #1 0x400ae9 in main (/tmp/a.out+0x400ae9)
> > #2 0x7621960f in __libc_start_main (/lib64/libc.so.6+0x2060f)
> >
> > SUMMARY: AddressSanitizer: heap-clobbered-memory-read
> (/tmp/a.out+0x400ad0)
> > in get_value(int*, int)
> > Shadow bytes around the buggy address:
> >   0x0c167fff95a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> >   0x0c167fff95b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> >   0x0c167fff95c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> >   0x0c167fff95d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> >   0x0c167fff95e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> > =>0x0c167fff95f0: fa fa f0 f0 f0 f0 f0[f0]f0 f0 f0 f0 f0 f0 00 07
> >   0x0c167fff9600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> >   0x0c167fff9610: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> >   0x0c167fff9620: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> >   0x0c167fff9630: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> >   0x0c167fff9640: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> > Shadow byte legend (one shadow byte represents 8 application bytes):
> >   Addressable:   00
> >   Partially addressable: 01 02 03 04 05 06 07
> >   Heap left redzone:   fa
> >   Heap right redzone:  fb
> >   Heap clobbered memoryf0
> >
> > Well, the implementation currently has granularity equal to 8 bytes and
> > every clobber/store must be considered conservatively. Ideally, I would
> like
> > to be able to clobber (mark store)
> > of every byte. Another issues is that I am unable to clear clobber shadow
> > byte for stack memory after a frame is unwinded, not sure where to find a
> > place where stacks are prepared?
>
> Current implementation only unpoisons stack redzones on exit from
> function (see calls to asan_clear_shadow in
> asan_emit_stack_protection). You'll probably have to change this to
> unpoison the entire frame (if it contains C++ objects with non-trivial
> dtors).
>
> > 2) memory access checks based on TBAA
> >
> > Every memory access in compiler is connected to an alias 

Re: logging both to console and logfile (feature request)

[Konstantin Serebryany]

On Sat, Oct 31, 2015 at 1:32 AM, Hanno Böck <ha...@hboeck.de> wrote:

> On Fri, 30 Oct 2015 23:06:21 -0700
> Konstantin Serebryany <konstantin.s.serebry...@gmail.com> wrote:
>
> > You are the first one to ask.
> >
> > If we were to implement it, I'd rather have another flag, e.g.
> > also_log_to_stderr (ignored w/o log_path, false by default).
>
> I'm fine with that, too. Would be great if you could implement that.
>
> The code is already too complicated.
If we are to add any additional complexity, we at least need to understand
why that's needed.




> The other solution would be a bit more flexible, as it could also
> specify multiple log files, but I don't need that.
>
> --
> Hanno Böck
> http://hboeck.de/
>
> mail/jabber: ha...@hboeck.de
> GPG: BBB51E42
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: logging both to console and logfile (feature request)

[Konstantin Serebryany]

Hi Hanno!


On Fri, Oct 30, 2015 at 2:08 PM, Hanno Böck  wrote:

> Hi,
>
> I was wondering if it would be possible to log the asan output both to
> the console (stderr) and a log file.
>
> It seems right now this is not possible (at least if I interpret the
> code correctly). You can only have one or the other, not both.
>
> Could this be added? E.g. one could imagine having a separator in the
> log_path option in ASAN_OPTIONS that could be set to something like
> log_path=/var/log/asan/asan-out;stderr
>
> What do you think?
>
> Just curious, why would you need this?
You are the first one to ask.

If we were to implement it, I'd rather have another flag, e.g.
also_log_to_stderr (ignored w/o log_path, false by default).


--kcc

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: asan reporting behavior on global arrays inconsistent

[Konstantin Serebryany]

Hi Hanno!

First, is that clang or gcc, and which version?
Second, is that C or C++?
If this is C, try adding -fno-common (in C, some of the globals are not
instrumented with asan unless you use -fno-common).
Finally, artificial tests like this are often misleading because the
compiler statically sees the bug and should warn about it,
but also can optimize the code away before asan has a chance to instrument
the code.
Try to prepare a test where the bug is not easy to discover statically.

On Sun, Jul 26, 2015 at 12:20 PM, Hanno Böck ha...@hboeck.de wrote:

 Hi,

 I noted some unexpected behaviour by asan. See this simple example:
 int a[1]={0};
 int main() {
 int b=a[1];
 }

 A trivial out of bounds array access to a.
 As expected compiling and running with asan will report a
 global-buffer-overflow. However if you change it to this:
 int a[1];
 int main() {
 int b=a[1];
 }
 asan will let it pass without an error.


 The only difference is if the global array a is pre-initialized with a
 value or not.

 Is this somehow expected or a known limitation of asan or is this a bug?

 cu,
 --
 Hanno Böck
 http://hboeck.de/

 mail/jabber: ha...@hboeck.de
 GPG: BBB51E42

 --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: False positive with boost::any_range with non-reference Reference type?

[Konstantin Serebryany]

On Sun, Jun 21, 2015 at 7:04 PM, Stefan Haller li...@haller-berlin.de
wrote:

 I'd be willing to work on a patch (it looks like the fix itself is
 straight-forward), but I'd need some guidance as to how to write the
 tests and where to put them,


You may take a look at
https://github.com/llvm-mirror/libcxx/blob/master/test/std/containers/sequences/vector/asan.pass.cpp


 so I'm not sure this would be efficient.

 In case anyone else wants to give it a go, here's another test case that
 doesn't depend on boost, so this might serve as a basis for a test:

 #include vector
 #include cassert

 /* Stupid toy iterator; it implements just enough so that the code
below compiles, and so that the vector::insert specialization
for non-forward_iterators is taken. */
 class MyInputIter : public std::iteratorstd::input_iterator_tag, int
 {
 public:
   MyInputIter(int* ptr) : ptr_(ptr) {}
   friend bool operator!=(const MyInputIter i1, const MyInputIter i2)
 { return i1.ptr_ != i2.ptr_; }
   MyInputIter operator++() { ++ptr_; return *this; }
   int operator*() const { return *ptr_; }
 private:
   int* ptr_;
 };

 int main(int argc, const char * argv[])
 {
 std::vectorint v;
 v.reserve(1);
 int i = 42;
 v.insert(v.begin(), MyInputIter(i), MyInputIter(i + 1));
 assert(v[0] == 42);
 return 0;
 }

 -Stefan


 Konstantin Serebryany konstantin.s.serebry...@gmail.com wrote:

  On Sat, Jun 20, 2015 at 8:45 AM, Anna Zaks zaks.a...@gmail.com wrote:
 
 
  On Friday, June 19, 2015 at 8:03:04 PM UTC-7, kcc wrote:
  We've seen a similar case when a library (I think it was boost) was not
 instrumented with asan
  and as the result some parts of std::vector implementation did not have
 the instrumentation
  (there was a a kind of ODR violation: instrumented  bits of std::vector
 were mixed with non-instrumented bits). The solution was to instrument
 boost too.
  This situation is specific to container-overflow bugs, so you may just
 disable this functionality for now
  (ASAN_OPTIONS=detect_container_overflow=0)
 
  On Sat, Jun 20, 2015 at 5:18 AM, Anna Zaks zaks...@gmail.com wrote:
  I can reproduce this.
 
  The error happens in the call to __alloc_traits::construct inside of
   vector_Tp, _Allocator::insert(const_iterator __position,
 _InputIterator __first, _InputIterator __last)
 
  That insert method does not seem to call __RAII_IncreaseAnnotator.
 
 
  Do you mean that the code is not there, or that it is not getting called?
 
  Code is not there:
 
 
 
 
  template class _Tp, class _Allocator
  template class _InputIterator
  typename enable_if
  
   __is_input_iterator  _InputIterator::value 
  !__is_forward_iterator_InputIterator::value 
  is_constructible
 _Tp,
 typename iterator_traits_InputIterator::reference::value,
  typename vector_Tp, _Allocator::iterator
  ::type
  vector_Tp, _Allocator::insert(const_iterator __position,
 _InputIterator __first, _InputIterator __last)
  {
  #if _LIBCPP_DEBUG_LEVEL = 2
  _LIBCPP_ASSERT(__get_const_db()-__find_c_from_i(__position) ==
 this,
  vector::insert(iterator, range) called with an iterator not
   referring to this vector);
  #endif
  difference_type __off = __position - begin();
  pointer __p = this-__begin_ + __off;
  allocator_type __a = this-__alloc();
  pointer __old_last = this-__end_;
  for (; this-__end_ != this-__end_cap()  __first != __last;
 ++__first)
  {
  __alloc_traits::construct(__a,
 _VSTD::__to_raw_pointer(this-__end_),
*__first); // --- OVERFLOW IS
 REPORTED HERE.
  ++this-__end_;
 
  It's quite surprising that we haven't seen this before...
  The fix should be somewhere here, similar to other methods of
 std::vector.
  I won't be able to work on it until mid July (vacation, no access to a
 proper PC),
  but anyone is welcome to send a fix (with a test).
 
  }
  ...
 
 
  Anna.
 
  On Friday, June 19, 2015 at 5:17:56 PM UTC-7, Alexey Samsonov wrote:
  +Kuba, Anna
 
  in case they have any ideas, or are able to reproduce it under Apple
 Clang.
 
  On Thu, Jun 18, 2015 at 9:37 AM, Stefan Haller li...@haller-berlin.de
 wrote:
  I'm getting a container overflow failure that I think is a false
  positive; but I don't understand what's going on, so I'm posting here
  instead of filing an issue. Here's the most stripped-down example that I
  could come up with:
 
  #include vector
  #include boost/range/any_range.hpp
 
  template typename T
  using AnyRange =
  boost::any_rangeT,
   boost::random_access_traversal_tag,
   T,
   std::ptrdiff_t;
 
  int main(int argc, const char * argv[])
  {
  std::vectorint v{1, 2, 3};
  v.erase(v.begin() + 1);
  int i = 42;
  AnyRangeint range{i, i + 1};
  v.insert(v.begin() + 1, boost::begin(range), boost::end(range));
  assert(v[0] == 1);
  assert(v[1] == 42);
  assert(v[2

Re: False positive with boost::any_range with non-reference Reference type?

[Konstantin Serebryany]

We've seen a similar case when a library (I think it was boost) was not
instrumented with asan
and as the result some parts of std::vector implementation did not have the
instrumentation
(there was a a kind of ODR violation: instrumented  bits of std::vector
were mixed with non-instrumented bits). The solution was to instrument
boost too.
This situation is specific to container-overflow bugs, so you may just
disable this functionality for now
(ASAN_OPTIONS=detect_container_overflow=0)

On Sat, Jun 20, 2015 at 5:18 AM, Anna Zaks zaks.a...@gmail.com wrote:

 I can reproduce this.

 The error happens in the call to __alloc_traits::construct inside of
  vector_Tp, _Allocator::insert(const_iterator __position, _InputIterator
 __first, _InputIterator __last)

 That insert method does not seem to call __RAII_IncreaseAnnotator.


Do you mean that the code is not there, or that it is not getting called?


 Anna.

 On Friday, June 19, 2015 at 5:17:56 PM UTC-7, Alexey Samsonov wrote:

 +Kuba, Anna

 in case they have any ideas, or are able to reproduce it under Apple
 Clang.

 On Thu, Jun 18, 2015 at 9:37 AM, Stefan Haller li...@haller-berlin.de
 wrote:

 I'm getting a container overflow failure that I think is a false
 positive; but I don't understand what's going on, so I'm posting here
 instead of filing an issue. Here's the most stripped-down example that I
 could come up with:

 #include vector
 #include boost/range/any_range.hpp

 template typename T
 using AnyRange =
 boost::any_rangeT,
  boost::random_access_traversal_tag,
  T,
  std::ptrdiff_t;

 int main(int argc, const char * argv[])
 {
 std::vectorint v{1, 2, 3};
 v.erase(v.begin() + 1);
 int i = 42;
 AnyRangeint range{i, i + 1};
 v.insert(v.begin() + 1, boost::begin(range), boost::end(range));
 assert(v[0] == 1);
 assert(v[1] == 42);
 assert(v[2] == 3);
 return 0;
 }

 This triggers the container overflow error inside the insert call, when
 it tries to copy-construct the int at v.end(), which is inside the
 allocated memory of the vector.

 Replacing the insert line with

 v.insert(v.begin() + 1, i, i + 1);

 makes it work.  Also, changing the Reference argument of the any_range
 (third template argument) to T or const T also makes it work. And
 of course, running the test without AddressSanitizer succeeds, so it
 doesn't look like it's actually overwriting memory.

 I tested this with boost 1.55 and 1.56. I'm on Mac OS X 10.10, with
 clang++ version Apple LLVM version 7.0.0 (clang-700.0.53), x86_64.
 AddressSanitizer is the one that comes bundled with the Xcode 7 beta
 (not sure how to find out which version or revision that is).

 Any idea what's going on?

 Thanks, Stefan.

 --
 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-saniti...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.




 --
 Alexey Samsonov, Mountain View, CA

  --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue 246 in address-sanitizer: Porting to a new target (AArch64)

[Konstantin Serebryany]

On Wed, Mar 25, 2015 at 4:33 AM, Renato Golin renato.go...@linaro.org wrote:
 On 24 March 2015 at 15:46, Konstantin Serebryany
 konstantin.s.serebry...@gmail.com wrote:
 is there a way to initialize ASAN  mapping for Aarch64  during  runtime ?

 This *is* happening at run-time.
 Did you talk to others from Linaro who already reported to have
 working asan on aarch64?
 Renato?

 Hi Kostya,

 There are multiple issues here...

 Venkat was working on TSAN for AArch64 and got caught in a virtual
 address problem. Not only AArch64 has less virtual address bits (39 or
 42, as opposed to 48 in x86_64),

Is it only 39 and 42, or is there a 3-rd option?


 but they're different and there is no
 generic solution. That's when he started working on ASAN to get the
 64-bit allocator working, and the virtual address space became an
 issue once again. In the end, for the sanitizers to work well on all
 AArch64 variations, we need to solve the virtual address issue.

 IIRC, ASAN has some macros to define the address ranges, so at least
 part of the ranges logic is not runtime based, right?

The values that define the location of the shadow are initialized at startup,
so it should not be a problem.

The values for Allocator64 have to be compile-time constants for
better performance,
but  Allocator64 is not going to work on 39 (and probably on 42) bits anyway.
We'll need to use Allocator32.


 I think the most
 sane way to proceed is to:

 1. Detect this at runtime and behave accordingly. This way we can use
 the same binaries on all AArch64 machines.
 2. Detect this at configure time and hard-code the ranges. This way we
 can not penalise the architectures where that is constant, ex. x86_64.
 3. Make into a cmake/configure option. This is especially important
 for cross-compilation.

 Does that sound sensible?

 cheers,
 --renato

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue 246 in address-sanitizer: Porting to a new target (AArch64)

[Konstantin Serebryany]

On Wed, Mar 25, 2015 at 10:23 AM, Venkataramanan Kumar
venkataramanan.ku...@linaro.org wrote:
 Hi Konstantin/Renato,

 The values that define the location of the shadow are initialized at 
 startup,
 so it should not be a problem.

 Excellent!


 The Shadow offset, I need to set 139 for Aarch64 (42 bit VA) and
 136 for Aarch64 (39 bit VA).

 In asan_mapping.h,  it is defined as static const u64
 kAArch64_ShadowOffset64 = 1ULL  36.


Why 1ULL  36 or some other smaller value will not work for both?


 If I understand correctly, I need to initialize this at startup in
 both places,  compiler-rt/lib/asan and LLVM 's instrumentation place
 lib/Transforms/Instrumentation/AddressSanitizer.cpp ?

 The values for Allocator64 have to be compile-time constants for
 better performance,
 but  Allocator64 is not going to work on 39 (and probably on 42) bits 
 anyway.
 We'll need to use Allocator32.

 For Aarch64 with 42 VA bit I need to turn on Allocator64
Why?

 and for 39
 bit VA I need to turn on Allocator32.
 ASAN/TSAN does not work when allocator32 is on for 42bit VA.

Let's not mix asan and tsan.
What's wrong with asan when allocator32 is on for 42bit VA?

 So I also need to detect and switch allocator types based on VA.


 On 25 March 2015 at 22:21, Renato Golin renato.go...@linaro.org wrote:
 On 25 March 2015 at 16:41, Konstantin Serebryany
 konstantin.s.serebry...@gmail.com wrote:
 Is it only 39 and 42, or is there a 3-rd option?

 As far as I know, only these two.


 The values that define the location of the shadow are initialized at 
 startup,
 so it should not be a problem.

 Excellent!


 The values for Allocator64 have to be compile-time constants for
 better performance,
 but  Allocator64 is not going to work on 39 (and probably on 42) bits 
 anyway.
 We'll need to use Allocator32.

 That's our conclusion, too.

 I think the next step is to implement the run-time check for AArch64.

 Thanks for the help!

 cheers,
 --renato

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue 246 in address-sanitizer: Porting to a new target (AArch64)

[Konstantin Serebryany]

On Wed, Mar 25, 2015 at 2:53 PM, Renato Golin renato.go...@linaro.org wrote:
 On 25 March 2015 at 21:40, Konstantin Serebryany
 konstantin.s.serebry...@gmail.com wrote:
 Or we are stuck with 39 and 42 for a long time?

 Yes.

 There are a lot of production hardware using 39/42, we won't see them
 disappear any time soon. I'd risk to say, never. After all, ARM7TDMI
 is still one of the most popular ARM chips year on year, and it's
 already 17 years old.

 If we want it to run on current and near future hardware, we must support 
 39/42.

Then forget about Allocator64.
We need to either use Allocator32 (which is fine, imho. it works
pretty well on ARM, x86_32, MIPS, etc)
or invent something else (but I can't see why we should do that).

With tsan, I am quite reluctant to support 39, even 42 may be a challenge.


 cheers,
 --renato

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue 246 in address-sanitizer: Porting to a new target (AArch64)

[Konstantin Serebryany]

 OK. Let me start with this test case.

 #include stdio.h

 int  main()
 {
 printf(Hello World\n);
 return 0;
 }

 /home/venkataramanan.kumar/
 LLVM/TSAN_port/Build/./bin/clang
 --driver-mode=g++ -fsanitize=address  test.c

 [venkataramanan.kumar@amd-01 ~]$ ./a.out
 ASAN:SIGSEGV
 =
 ==25303==ERROR: AddressSanitizer: SEGV on unknown address
 0x007fff96387c (pc 0x004c1dfc bp 0x03fffcb1c460 sp 0x03fffcb1c3e0
 T0)
 #0 0x4c1dfb  (/home/venkataramanan.kumar/a.out+0x4c1dfb)
 #1 0x3ff9c790c93  (/lib64/libc.so.6+0x20c93)
 #2 0x41b1f3  (/home/venkataramanan.kumar/a.out+0x41b1f3)

 AddressSanitizer can not provide additional info.
 ==25303==ABORTING


 Now I am running under gdb

 [venkataramanan.kumar@amd-01 ~]$ gdb ./a.out
 GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-62.sa1.4
 Copyright (C) 2013 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type show copying
 and show warranty for details.
 This GDB was configured as aarch64-redhat-linux-gnu.
 For bug reporting instructions, please see:
 http://www.gnu.org/software/gdb/bugs/...
 Reading symbols from /home/venkataramanan.kumar/a.out...done.
 (gdb) r
 Starting program: /home/venkataramanan.kumar/./a.out
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 Hello World
 [Inferior 1 (process 25306) exited normally]
 Missing separate debuginfos, use: debuginfo-install
 glibc-2.17-68.sa1.4.aarch64 libgcc-4.8.3-8.sa1.4.aarch64
 libstdc++-4.8.3-8.sa1.4.aarch64

 It ran to completion.


Interesting. So, w/ gdb the test passes, w/o gdb it fails.
Try few things:

Run w/o gdb but with ASLR off (is there ASLR on AArch64?). Use setarch for that.

Run w/ gdb but with ASLR on (disable-randomization off). If you get a
crash with gdb, type 'dis' and send the result here.

build the following code with -S and with '-S -o - -emit-llvm' and
send the results:
void foo(long *x)  { *x = 0; }

--kcc




 ASAN:SIGSEGV
 ==
 ===
 ==6221==ERROR: AddressSanitizer: SEGV on unknown address
 0x007ffd1329f4 (pc 0x004c1e64 bp 0x03ffe8995090 sp 0x03ffe8994fa0
 T0)
 #0 0x4c1e63 in main
 /home/venkataramanan.kumar/LLVM/TSAN_port/compiler-rt/test/asan/TestCases/Linux/coverage-direct-large.cc:52
 #1 0x3ffb2730c93 in __libc_start_main (/lib64/libc.so.6+0x20c93)

 What this error mean?
 Stack address 0x03ffe8994fa0 when I do 0x03ffe8994fa0  0x3, I get
 this address 0x007ffd1329f4,

 address 0x007ffd1329f4 is illegal. Why this address is accessed?

 Between my cat /proc/self/maps look like that.

 venataramanan.kumar@amd-01 ~]$ cat /proc/self/maps
 0040-0041 r-xp  08:04 16890529
   /usr/bin/cat
 0041-0042 r--p  08:04 16890529
   /usr/bin/cat
 0042-0043 rw-p 0001 08:04 16890529
   /usr/bin/cat
 07a3-07a6 rw-p  00:00 0  
 [heap]
 3ff85ca-3ff8c54 r--p  08:04 34089040
   /usr/lib/locale/locale-archive
 3ff8c54-3ff8c6a r-xp  08:04 33642757
   /usr/lib64/libc-2.17.so
 3ff8c6a-3ff8c6b r--p 0015 08:04 33642757
   /usr/lib64/libc-2.17.so
 3ff8c6b-3ff8c6c rw-p 0016 08:04 33642757
   /usr/lib64/libc-2.17.so
 3ff8c6d-3ff8c6e r--p  00:00 0
 [vvar]
 3ff8c6e-3ff8c6f r-xp  00:00 0
 [vdso]
 3ff8c6f-3ff8c71 r-xp  08:04 33642750
   /usr/lib64/ld-2.17.so
 3ff8c71-3ff8c72 r--p 0001 08:04 33642750
   /usr/lib64/ld-2.17.so
 3ff8c72-3ff8c73 rw-p 0002 08:04 33642750
   /usr/lib64/ld-2.17.so
 3ffc0d8-3ffc0db rw-p  00:00 0
 [stack]


 regards,
 Venkat.




 regards,
 Venkat,


 On 26 January 2015 at 20:50,  address-saniti...@googlecode.com wrote:

 Comment #16 on issue 246 by svha...@gmail.com: Porting to a new target
 (AArch64)
 https://code.google.com/p/address-sanitizer/issues/detail?id=246

 FYI, following patch makes ASAN work fine on 42-bit AS, but will break the
 39-bit AS and won't fix 48-bit one.  So we really need something more
 dynamic.

 --- libsanitizer/asan/asan_allocator.h  (revision 219833)
 +++ libsanitizer/asan/asan_allocator.h  (working copy)
 @@ -100,6 +100,10 @@
  # if defined(__powerpc64__)
  const uptr kAllocatorSpace =  0xa00ULL;
  const uptr kAllocatorSize  =  0x200ULL;  // 2T.
 +# elif defined(__aarch64__)
 +// Valid only for 42-bit VA
 +const uptr kAllocatorSpace =  0x100ULL;
 +const uptr kAllocatorSize  =  0x100ULL;  // 1T.
  # else
  const uptr kAllocatorSpace = 0x6000ULL;
  const uptr kAllocatorSize  =  0x400ULL;  // 4T.
 --- 

Re: Issue 246 in address-sanitizer: Porting to a new target (AArch64)

[Konstantin Serebryany]

On Thu, Mar 19, 2015 at 7:39 AM, Venkataramanan Kumar
venkataramanan.ku...@linaro.org wrote:
 Hi I tried using patch suggested on aarch64 machine which is 42 VA.

 In addition, I set shadow offset as below in asan_mapping.h
 static const u64 kAArch64_ShadowOffset64 = 1ULL  39;

 ASAN builds but when I do make check-asan, I get lot of failures.

  Expected Passes: 40
  Expected Failures  : 6
  Unsupported Tests  : 129
  Unexpected Failures: 135

 The errors are looking like this

 Command Output (stderr):
 --
 ==32641==AddressSanitizer: failed to intercept '__isoc99_printf'
 ==32641==AddressSanitizer: failed to intercept '__isoc99_sprintf'
 ==32641==AddressSanitizer: failed to intercept '__isoc99_snprintf'
 ==32641==AddressSanitizer: failed to intercept '__isoc99_fprintf'
 ==32641==AddressSanitizer: failed to intercept '__isoc99_vprintf'
 ==32641==AddressSanitizer: failed to intercept '__isoc99_vsprintf'
 ==32641==AddressSanitizer: failed to intercept '__isoc99_vsnprintf'
 ==32641==AddressSanitizer: failed to intercept '__isoc99_vfprintf'
 ==32641==AddressSanitizer: libc interceptors initialized
 || `[0x0100, 0x03ff]` || HighMem||
 || `[0x00a0, 0x00ff]` || HighShadow ||
 || `[0x0090, 0x009f]` || ShadowGap  ||
 || `[0x0080, 0x008f]` || LowShadow  ||
 || `[0x, 0x007f]` || LowMem ||
 MemToShadow(shadow): 0x0090 0x0091 0x0094 
 0x009f
 redzone=16
 max_redzone=2048
 quarantine_size_mb=256M
 malloc_context_size=30
 SHADOW_SCALE: 3
 SHADOW_GRANULARITY: 8
 SHADOW_OFFSET: 80
 ==32641==Installed the sigaction for signal 11
 ==32641==Installed the sigaction for signal 7
 ==32641==T0: stack [0x03ffdd28,0x03ffdda8) size 0x80;
 local=0x03ffdda75ef0
 ==32641==AddressSanitizer Init done
 ASAN:SIGSEGV
 =
 ==32641==ERROR: AddressSanitizer: SEGV on unknown address
 0x007ffbb4ebc0 (pc 0x004c1e1c bp 0x03ffdda75ec0 sp 0x03ffdda75e00
 T0)
 #0 0x4c1e1b in main
 /home/venkataramanan.kumar/LLVM/TSAN_port/compiler-rt/test/asan/TestCases/Linux/coverage-disabled.cc:18
 #1 0x3ffaa1b0c93 in __libc_start_main (/lib64/libc.so.6+0x20c93)
 #2 0x41b1f3 in _start
 (/home/venkataramanan.kumar/LLVM/TSAN_port/Build/projects/compiler-rt/test/asan/AARCH64LinuxConfig/TestCases/Linux/Output/coverage-disabled.cc.tmp+0x41b1f3)

 AddressSanitizer can not provide additional info.
 SUMMARY: AddressSanitizer: SEGV
 /home/venkataramanan.kumar/LLVM/TSAN_port/compiler-rt/test/asan/TestCases/Linux/coverage-disabled.cc:18
 main
 ==32641==ABORTING

 No idea what is going wrong? Am I missing something here?

Hard to tell w/o being able to reproduce. I can work as a remote
debugger for you, if you wish.
Let's start from something more trivial than coverage-disabled.cc
(e.g. start from a hello world) and run it under gdb.


 regards,
 Venkat,


 On 26 January 2015 at 20:50,  address-saniti...@googlecode.com wrote:

 Comment #16 on issue 246 by svha...@gmail.com: Porting to a new target
 (AArch64)
 https://code.google.com/p/address-sanitizer/issues/detail?id=246

 FYI, following patch makes ASAN work fine on 42-bit AS, but will break the
 39-bit AS and won't fix 48-bit one.  So we really need something more
 dynamic.

 --- libsanitizer/asan/asan_allocator.h  (revision 219833)
 +++ libsanitizer/asan/asan_allocator.h  (working copy)
 @@ -100,6 +100,10 @@
  # if defined(__powerpc64__)
  const uptr kAllocatorSpace =  0xa00ULL;
  const uptr kAllocatorSize  =  0x200ULL;  // 2T.
 +# elif defined(__aarch64__)
 +// Valid only for 42-bit VA
 +const uptr kAllocatorSpace =  0x100ULL;
 +const uptr kAllocatorSize  =  0x100ULL;  // 1T.
  # else
  const uptr kAllocatorSpace = 0x6000ULL;
  const uptr kAllocatorSize  =  0x400ULL;  // 4T.
 --- libsanitizer/sanitizer_common/sanitizer_platform.h  (revision 219833)
 +++ libsanitizer/sanitizer_common/sanitizer_platform.h  (working copy)
 @@ -79,7 +79,7 @@
  // For such platforms build this code with
 -DSANITIZER_CAN_USE_ALLOCATOR64=0 or
  // change the definition of SANITIZER_CAN_USE_ALLOCATOR64 here.
  #ifndef SANITIZER_CAN_USE_ALLOCATOR64
 -# if defined(__aarch64__) || defined(__mips64)
 +# if defined(__mips64)
  #  define SANITIZER_CAN_USE_ALLOCATOR64 0
  # else
  #  define SANITIZER_CAN_USE_ALLOCATOR64 (SANITIZER_WORDSIZE == 64)
 @@ -88,10 +88,10 @@

  // The range of addresses which can be returned my mmap.
  // FIXME: this value should be different on different platforms,
 -// e.g. on AArch64 it is most likely (1ULL  39). Larger values will still
 work
 +// e.g. on AArch64 it is most likely (1ULL  42). Larger values will still
 work
  // but will consume more memory for TwoLevelByteMap.
  #if defined(__aarch64__)
 -# define SANITIZER_MMAP_RANGE_SIZE FIRST_32_SECOND_64(1ULL  32, 1ULL 
 39)
 +# define SANITIZER_MMAP_RANGE_SIZE FIRST_32_SECOND_64(1ULL  32, 1ULL 
 

Re: hudson/jenkins plugin for asan/tsan?

[Konstantin Serebryany]

Nope. Asan may produce the stack frames in use-specified format,
which is part of what you need:
https://code.google.com/p/address-sanitizer/wiki/CallStack

--kcc


On Fri, Dec 5, 2014 at 8:19 AM, Robert Henry r...@newrelic.com wrote:

 Is there a Hudson/Jenkins (a continuous-integration infrastructure) plugin
 or solution to consume the output of asan or tsan?

 Valgrind in some execution modes can produce an xml file which can be
 consumed by Hudson, cf https://wiki.jenkins-ci.
 org/display/JENKINS/Valgrind+Plugin

 --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Dealing with custom allocators

[Konstantin Serebryany]

We haven't tried anything automated here.
In a dozen of cases our users had to annotate their code
with __asan_[un]poison_memory_region,
but indeed this is labor-intensive and is still weaker than what asan's
malloc provides (usually, no quarantine, no adaptive redzones, etc)

On Wed, Dec 3, 2014 at 6:20 AM, Yury Gribov y.gri...@samsung.com wrote:

 Hi all,

 As we all know ASan only instruments standard allocators (malloc/free,
 new/delete) so if sanitized application uses a custom allocator on top of
 mmap or libc, precision of heap overflow detection could significantly
 decrease.  This may be a problem when one wants to sanitize e.g. full
 distribution - manual inspection of packages and addition of custom poisons
 may take weeks of work.  Has anyone tried to automate this in any way?
 There are some experimental approaches to this (e.g. MemBrush)


Interesting!



 or at the very least I could grep for functions with interesting names
 (.*alloc.*) and then inspect them manually.


There is also *FreeList* kind of names.

--kcc



 -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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why GCC's asan depends on on Microsoft Visual C++ runtime library?

[Konstantin Serebryany]

On Fri, Nov 7, 2014 at 1:13 PM, Constantine Tarasenkov iam...@gmail.com
wrote:

 If you are using mingw, we can assume they won't be called.

 Linker gives me error because it can't find these symbols, it should be
 ifdef'ed with _MSC_VER otherwise user is forced to link against
 msvcrt40.dll.

 However, so far as I know nobody has been testing ASan on Windows with
 anything over than MSVC and Clang, so this would all be new territory.

 Since you guys contributing windows related code to GCC, you can expect to
 see more people like me who will try to use GCC on Windows :)


We are working on Clang+ASan on windows, but not on GCC on Windows.



 On Wednesday, November 5, 2014 9:15:09 PM UTC+3, Reid Kleckner wrote:

 ASan doesn't depend on those symbols, it's merely trying to intercept
 them in case they ever get called. If you are using mingw, we can assume
 they won't be called. An ifdef, or something cleaner, would probably be
 appropriate. However, so far as I know nobody has been testing ASan on
 Windows with anything over than MSVC and Clang, so this would all be new
 territory.

 On Wed, Nov 5, 2014 at 3:16 AM, Constantine Tarasenkov iam...@gmail.com
 wrote:

 This code:
 https://github.com/gcc-mirror/gcc/blob/141eb62b/libsanitizer/asan/asan_
 interceptors.cc#L721-L722

 Depends on VIsual C++ specific library called msvcrt40.dll, which is not
 available in MinGW or MinGW-w64. I know it doesn't tested yet to work with
 these compilers, but I'm not sure under which license msvcrt40.dll is
 distributed, where I should get it and will it be legal to download it from
 Internet and distribute with my programs.

 If it means that no one will be able to compile asan for windows without
 Visual C++ runtime library, I'll find it funny because we're talking about
 GCC :) Maybe it should be enclosed in MSVC specific ifdef's or something?

 --
 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-saniti...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


  --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: AddressSanitizer and issue suppression

[Konstantin Serebryany]

On Fri, Sep 26, 2014 at 12:26 AM, Alexander Potapenko
ramosian.gli...@gmail.com wrote:
 We just need a separate error reporting function that'll be called
 exclusively from interceptors. It doesn't have to be noreturn, because the
 interceptors themselves aren't.

yep


 On Sep 26, 2014 8:52 AM, 'Alexey Samsonov' via address-sanitizer
 address-sanitizer@googlegroups.com wrote:


 On Thu, Sep 25, 2014 at 9:46 PM, Konstantin Serebryany
 konstantin.s.serebry...@gmail.com wrote:

 I don't think this is what we want.
 I'd rather suppress by one of the frames in the stack where strcasecmp is
 called
 (This may, of course, be the #0 frame with strcasecmp)


 Sure. But it would be great to be able to disable interceptors in ASan
 while still keeping __asan_report_error  noreturn.



 On Thu, Sep 25, 2014 at 6:17 PM, 'Alexey Samsonov' via
 address-sanitizer address-sanitizer@googlegroups.com wrote:
  Can you add a new suppression kind that would disable certain
  interceptors?
  E.g. the following line in suppressions file:
 
  interceptor:strcasecmp
 
  will disable the checks in this interceptor (in case of ASan it would
  turn
  COMMON_INTERCEPTOR_READ_RANGE to nop).
 
 
  On Thu, Sep 25, 2014 at 4:49 PM, Konstantin Serebryany
  konstantin.s.serebry...@gmail.com wrote:
 
  On Thu, Sep 25, 2014 at 2:16 AM, 'Alexander Potapenko' via
  address-sanitizer address-sanitizer@googlegroups.com wrote:
   Some time ago I've been thinking about adding a flag for each
   interceptor that disables checks in that interceptor similar to
   replace_intrin flag.
   Using suppressions for that sounds more flexible, but we must make
   sure the users do not try to suppress errors in instrumented code.
 
  Correct.
 
   (For example we could print a warning about that when a suppression
   matches the report that didn't originate from an interceptor)
  SGTM
 
  
   On Thu, Sep 25, 2014 at 4:08 AM, 'Alexey Samsonov' via
   address-sanitizer address-sanitizer@googlegroups.com wrote:
   I haven't looked at the code in a while, but this should be
   possible.
   We
   already have a global suppression context in sanitizer_common.
  
   On Wed, Sep 24, 2014 at 4:47 PM, Konstantin Serebryany
   konstantin.s.serebry...@gmail.com wrote:
  
   We probably can reuse
   lib/sanitizer_common/sanitizer_suppressions.h to
   suppress errors that come from the interceptors...
   Thoughts?
  
   On Wed, Sep 24, 2014 at 4:39 PM, 'Dmitry Vyukov' via
   address-sanitizer
   address-sanitizer@googlegroups.com wrote:
+tetra2005
   
   
On Wed, Sep 24, 2014 at 4:31 PM, Kuba Brecka
kuba.bre...@gmail.com
wrote:
Hi,
   
I'm trying to explore the possibilities of extending ASan to be
able to
continue execution after an error is found and a report printed
out. I
understand that the fact that ASan is currently
aborting/exiting on
a
report
is totally intentional and that there are some good reasons for
it,
e.g.
that it's not safe to continue because the memory is corrupted,
or
that
the
UnreachableInst/doesNotReturn play an important role for
optimizations.
   
However, I believe that there may be some valid reasons to
allow
continuing
program execution, like when there's a bug in a system library.
This
can
easily happen even when this library itself is not
instrumented,
due to
wrappers/interceptors affecting system libraries as well. So
doing
something
like...
   
a = malloc(15);
memset(a, 0, 16);
   
...in a system library would get caught by ASan, and it's
definitely a
bug.
On the other hand, in this specific case, without ASan, this
alone
would
(almost certainly) never crash or cause *real* memory
corruption,
since
malloc allocates 16 bytes anyway. We want to learn about the
bug
(to be
able
to fix it), but I think we also want to be able to continue
using
ASan
before a new version of the library is shipped with an OS
update.
   
I am mainly interested in wrappers/interceptors only, because
the
reports
invoked by instrumentation cannot happen in a library function
(since
it's
not instrumented) and if a bug in a library triggers a report
to be
produced
in user's instrumented code, he can blacklist that function or
use
__attribute__((no_sanitize_address)). It seems to me it should
be
possible
to modify the error reporting (in the wrappers only) not to be
fatal,
and if
that decision whether to abort or not (let's say via a
suppression
list) is
done only in the case when a poisoned memory access is
detected, it
shouldn't have any significant performance hit.
   
I noticed that there is an issue suppression mechanism in
ThreadSanitizer
and I'm aware that the circumstances for this feature in TSan
are
different.
However, I'd still like

Re: AddressSanitizer's allocator

[Konstantin Serebryany]

On Fri, Sep 26, 2014 at 1:29 AM, Jonas Wagner jonas.wag...@epfl.ch wrote:
 Thanks a lot for all these replies! They really help me understand the
 design.

 When I measured performance of sanitizer allocator against tcmalloc on
 a large real application that calls malloc a lot, sanitizer allocator
 was 10% faster.

 This is interesting! It probably means there are no large gains to get here…

 My motivation comes from the gcc SPEC benchmark; here are a few numbers:

 Raw ASan slowdown: 1.91x
 removing checks (-mllvm -asan-instrument-*=0) reduces overhead by: 39.7%
 removing stack poisoning (-mllvm -asan-stack=0) increases overhead by 5.58%
 (?)
 removing interception (replace_str=0:replace_intrin=0) reduces overhead by
 1.03%
 removing quarantine (quarantine_size=0) reduces overhead by 12.17%
 removing heap poisoning (poison_heap=0) reduces overhead by 22.12%

 Compared to other SPEC benchmarks, the fraction of overhead due to checks is
 very low for gcc. Much overhead seems to come from heap poisoning and from
 the quarantine queue, but there are also some 30% of overhead that hide
 elsewhere… I suspect that the allocator might be to blame. This suspicion
 arose because perf showed a high number of samples in the allocator.

 (Note that these numbers might contain measurement inaccuracies, and that I
 have only looked at single factors, not combinations of them. All of these
 were measured with malloc_context_size=0.)

 Even if we switch to tcmalloc, we still need quarantine on top of it.
 And quarantine kills cache locality.

 This makes sense :(

 Another major feature of the allocator compared to wrapping the system
 malloc
 is that asan's allocator insures that the left redzone of a chunk is
 always the right redzone of preceding chunk.

 This is smart, and seems indeed impossible to do when wrapping the system
 malloc. How does this interact with adaptive redzone sizes? Could it happen
 that a large object is located right after a small one, and thus the left
 redzone of the large object is smaller than desired?

 One of the low hanging fruits is disabling allocator stats for asan.

 That sounds possible.

 Also, when looking at the code, I also saw that the allocator initializes
 the newly allocated memory. Setting max_malloc_fill_size=0 in ASAN_OPTIONS
 saved 2% or so for the gcc SPEC benchmark. I guess the initialization is
 done to erase pointers and detect more cases of use-after-free?

This is a poor-man's detector of uninitialized data. Not strictly necessary.


 I’ll look a bit more into this, and try to come up with other optimization
 ideas. Additional suggestions are welcome!

 Best,
 Jonas

 --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: AddressSanitizer and issue suppression

[Konstantin Serebryany]

On Thu, Sep 25, 2014 at 2:16 AM, 'Alexander Potapenko' via
address-sanitizer address-sanitizer@googlegroups.com wrote:
 Some time ago I've been thinking about adding a flag for each
 interceptor that disables checks in that interceptor similar to
 replace_intrin flag.
 Using suppressions for that sounds more flexible, but we must make
 sure the users do not try to suppress errors in instrumented code.

Correct.

 (For example we could print a warning about that when a suppression
 matches the report that didn't originate from an interceptor)
SGTM


 On Thu, Sep 25, 2014 at 4:08 AM, 'Alexey Samsonov' via
 address-sanitizer address-sanitizer@googlegroups.com wrote:
 I haven't looked at the code in a while, but this should be possible. We
 already have a global suppression context in sanitizer_common.

 On Wed, Sep 24, 2014 at 4:47 PM, Konstantin Serebryany
 konstantin.s.serebry...@gmail.com wrote:

 We probably can reuse lib/sanitizer_common/sanitizer_suppressions.h to
 suppress errors that come from the interceptors...
 Thoughts?

 On Wed, Sep 24, 2014 at 4:39 PM, 'Dmitry Vyukov' via address-sanitizer
 address-sanitizer@googlegroups.com wrote:
  +tetra2005
 
 
  On Wed, Sep 24, 2014 at 4:31 PM, Kuba Brecka kuba.bre...@gmail.com
  wrote:
  Hi,
 
  I'm trying to explore the possibilities of extending ASan to be able to
  continue execution after an error is found and a report printed out. I
  understand that the fact that ASan is currently aborting/exiting on a
  report
  is totally intentional and that there are some good reasons for it,
  e.g.
  that it's not safe to continue because the memory is corrupted, or that
  the
  UnreachableInst/doesNotReturn play an important role for optimizations.
 
  However, I believe that there may be some valid reasons to allow
  continuing
  program execution, like when there's a bug in a system library. This
  can
  easily happen even when this library itself is not instrumented, due to
  wrappers/interceptors affecting system libraries as well. So doing
  something
  like...
 
  a = malloc(15);
  memset(a, 0, 16);
 
  ...in a system library would get caught by ASan, and it's definitely a
  bug.
  On the other hand, in this specific case, without ASan, this alone
  would
  (almost certainly) never crash or cause *real* memory corruption, since
  malloc allocates 16 bytes anyway. We want to learn about the bug (to be
  able
  to fix it), but I think we also want to be able to continue using ASan
  before a new version of the library is shipped with an OS update.
 
  I am mainly interested in wrappers/interceptors only, because the
  reports
  invoked by instrumentation cannot happen in a library function (since
  it's
  not instrumented) and if a bug in a library triggers a report to be
  produced
  in user's instrumented code, he can blacklist that function or use
  __attribute__((no_sanitize_address)). It seems to me it should be
  possible
  to modify the error reporting (in the wrappers only) not to be fatal,
  and if
  that decision whether to abort or not (let's say via a suppression
  list) is
  done only in the case when a poisoned memory access is detected, it
  shouldn't have any significant performance hit.
 
  I noticed that there is an issue suppression mechanism in
  ThreadSanitizer
  and I'm aware that the circumstances for this feature in TSan are
  different.
  However, I'd still like to discuss the possibilities and opinions on
  this
  topic.
 
  Thank you for any feedback!
 
  Kuba
 
  --
  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+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.
 
  --
  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+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.

 --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.




 --
 Alexey Samsonov, Mountain View, CA

 --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.



 --
 Alexander Potapenko
 Software Engineer
 Google Moscow

 --
 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: AddressSanitizer's allocator

[Konstantin Serebryany]

On Thu, Sep 25, 2014 at 8:49 AM, 'Dmitry Vyukov' via address-sanitizer
address-sanitizer@googlegroups.com wrote:
 On Thu, Sep 25, 2014 at 7:44 AM, Jonas Wagner jonas.wag...@epfl.ch wrote:
 Dear AddressSanitizer developers,

 I'm thinking about ways to optimize the performance of ASan's allocator.
 There are a few benchmarks where a large fraction of the overhead comes from
 the allocator and the quarantine queue, rather than the checks themselves
 (e.g., gcc from SPEC2006).

 When I looked at the allocator, I was surprised that it is implemented
 inside ASan's runtime library (or rather, in sanitizer_common). This is
 unlike other intercepted functions such as strcpy, which forward to the
 implementation from libc. What is the reason for this?

 Would it be possible to implement asan_malloc as a decorator on top of libc
 malloc? Or on top of an existing implementation such as tcmalloc? This seems
 desirable to me because these are highly tuned. It might also simplify the
 sanitizer codebase.

 I'm sure this case has been considered. What are the reasons for the current
 design?

 Besides this question, I wonder if there are other ways of optimizing the
 allocator or the quarantine mechanism. If you can think of any (relatively)
 low-hanging fruit, I'd be motivated to give it a try.


 Hi Jonas,

 When I measured performance of sanitizer allocator against tcmalloc on
 a large real application that calls malloc a lot, sanitizer allocator
 was 10% faster. You are free to do you own measurements. Maybe you
 will discover some inefficiency in the allocator that you can fix.


 One historical reason for using own allocator is that we needed the
 meta information that is not covered by shadow, so it can't be a
 simple prefix/postfix of the memory block itself. We don't use the
 meta info anymore.

We never used out-of-chunk metadata in asan.
We did use it in tsan -- not any more.
We still use it in msan.

Another major feature of the allocator compared to wrapping the system malloc
is that asan's allocator insures that the left redzone of a chunk is
always the right redzone of preceding chunk.
You can not achieve that with external malloc w/o adding too many redzones.


 Even if we switch to tcmalloc, we still need quarantine on top of it.
 And quarantine kills cache locality. You remove that overhead simply
 by switching to a different allocator.

 One of the low hanging fruits is disabling allocator stats for asan.
 The stats are required for tsan, but asan keeps own stats. So it's
 possible to implement a NoOpStats class for asan, and parametrize the
 allocator with that class. I don't know of any other low hanging
 fruits.

I would love to see good malloc benchmarks, multi-threaded and not, in
our code base... This will really help.

--kcc


 Also note that the allocator must scale well for high core counts.

 --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: AddressSanitizer and issue suppression

[Konstantin Serebryany]

We probably can reuse lib/sanitizer_common/sanitizer_suppressions.h to
suppress errors that come from the interceptors...
Thoughts?

On Wed, Sep 24, 2014 at 4:39 PM, 'Dmitry Vyukov' via address-sanitizer
address-sanitizer@googlegroups.com wrote:
 +tetra2005


 On Wed, Sep 24, 2014 at 4:31 PM, Kuba Brecka kuba.bre...@gmail.com wrote:
 Hi,

 I'm trying to explore the possibilities of extending ASan to be able to
 continue execution after an error is found and a report printed out. I
 understand that the fact that ASan is currently aborting/exiting on a report
 is totally intentional and that there are some good reasons for it, e.g.
 that it's not safe to continue because the memory is corrupted, or that the
 UnreachableInst/doesNotReturn play an important role for optimizations.

 However, I believe that there may be some valid reasons to allow continuing
 program execution, like when there's a bug in a system library. This can
 easily happen even when this library itself is not instrumented, due to
 wrappers/interceptors affecting system libraries as well. So doing something
 like...

 a = malloc(15);
 memset(a, 0, 16);

 ...in a system library would get caught by ASan, and it's definitely a bug.
 On the other hand, in this specific case, without ASan, this alone would
 (almost certainly) never crash or cause *real* memory corruption, since
 malloc allocates 16 bytes anyway. We want to learn about the bug (to be able
 to fix it), but I think we also want to be able to continue using ASan
 before a new version of the library is shipped with an OS update.

 I am mainly interested in wrappers/interceptors only, because the reports
 invoked by instrumentation cannot happen in a library function (since it's
 not instrumented) and if a bug in a library triggers a report to be produced
 in user's instrumented code, he can blacklist that function or use
 __attribute__((no_sanitize_address)). It seems to me it should be possible
 to modify the error reporting (in the wrappers only) not to be fatal, and if
 that decision whether to abort or not (let's say via a suppression list) is
 done only in the case when a poisoned memory access is detected, it
 shouldn't have any significant performance hit.

 I noticed that there is an issue suppression mechanism in ThreadSanitizer
 and I'm aware that the circumstances for this feature in TSan are different.
 However, I'd still like to discuss the possibilities and opinions on this
 topic.

 Thank you for any feedback!

 Kuba

 --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

 --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Small improvements to run_spec_clang_asan.sh

[Konstantin Serebryany]

On Fri, Sep 19, 2014 at 5:13 AM, 'Evgeniy Stepanov' via
address-sanitizer address-sanitizer@googlegroups.com wrote:
 CLANG=${CLANG:-clang}
 You probably need the same for CLANGXX

 Why are you disabling leak detection? It is on by default, which means
 you are benchmarking not the same thing that users run.
 At least make it an option.

i disable lsan in my local copy of this script because there are leaks
in several benchmarks :)


 I don't understand this LD_LIBRARY_PATH magic, what's its for?



 On Fri, Sep 19, 2014 at 3:26 PM, Alexander Potapenko gli...@google.com 
 wrote:
 CC kcc, eugenis

 On Thu, Sep 18, 2014 at 7:25 PM, Yuri Gribov tetra2...@gmail.com wrote:
 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 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.



 --
 Alexander Potapenko
 Software Engineer
 Google Moscow

 --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Branch weights for slow paths

[Konstantin Serebryany]

I can confirm that the performance on spec (test data) looks great.
These are the number on my machine (the smaller the better).
 no weightswith weights   diff
   400.perlbench,10.40,10.30, 0.99
   401.bzip2,11.70,10.70, 0.91
 403.gcc, 2.52, 2.77, 1.10
 429.mcf, 4.15, 3.60, 0.87
   445.gobmk,38.20,36.10, 0.95
   456.hmmer, 7.24, 6.44, 0.89
   458.sjeng, 7.90, 7.23, 0.92
  462.libquantum, 0.08, 0.09, 1.03
 464.h264ref,35.10,27.80, 0.79
 471.omnetpp, 1.44, 1.34, 0.93
   473.astar,14.80,13.60, 0.92
   483.xalancbmk, 0.46, 0.43, 0.94
433.milc,11.50,11.00, 0.96
444.namd,17.90,16.90, 0.94
  447.dealII,27.60,28.40, 1.03
  450.soplex, 0.11, 0.11, 1.02
  453.povray, 1.53, 1.50, 0.98
 470.lbm, 3.68, 3.51, 0.95
 482.sphinx3, 2.46, 2.34, 0.95
I will re-run with ref data overnight.
Please send the patch to llvm-commits (
https://code.google.com/p/address-sanitizer/wiki/HowToContribute)
and I will apply it (or you can do it if you have commit access)

Thanks for reminding us about this low hanging fruit!

--kcc


On Thu, Aug 28, 2014 at 5:31 AM, Jonas Wagner jonas.wag...@epfl.ch wrote:

 Hi,


 The change to add weights is trivial.
 I am not against it and the patch is welcome, but it will need to be
 accompanied with SPEC performance numbers.


 I modified ASan and did a quick run on SPEC. Results are available in this
 spreadsheet [1]. Detailed output from perf stat, including standard
 deviations from three runs, is available at [2].

 Overall, it seems that branch weights reduce the runtime of SPEC
 benchmarks by about 3% on average, and reduce branch misses by about 8%.
 Results vary quite strongly between benchmarks, but branch weights seem to
 be beneficial for 14 out of 16.

 This uses just the SPEC test workload, so the results might not be very
 precise. I'll re-run with longer workloads to confirm.

 A patch is attached.

 Cheers,
 Jonas


 [1]:
 https://docs.google.com/spreadsheets/d/1t5sMnBMXWr5BXM8jZiW_G2XSTtVczaOrPyPAEMXL9qc/
 [2]:
 https://drive.google.com/open?id=0B8pYrLJnKwDSa3lQaXdudGdrNFUauthuser=0

 --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Branch weights for slow paths

[Konstantin Serebryany]

On Wed, Aug 27, 2014 at 9:07 AM, Jonas Wagner jonas.wag...@epfl.ch wrote:
 Hi,

 I am investigating the performance of AddressSanitizer checks. In the
 process, I've found a few checks that look as follows:

  1: 0.27 |mov%rax,%rcx
  2: 0.01 |shr$0x3,%rcx
  3: 0.03 |mov0x7fff8000(%rcx),%cl
  4: 0.57 |test   %cl,%cl
  5: 0.29 | |je abe
  6:  | |  mov%eax,%edx
  7:  | |  and$0x7,%edx
  8:  | |  add$0x3,%edx
  9:  | |  movsbl %cl,%ecx
 10:  | |  cmp%ecx,%edx
 11:  | |  jge1208
 12: 0.25 | abe:| movl   $0xdeadbeef,(%rax)

 The address being tested is in %rax. This is for a four-byte load, so there
 is a fast path and a slow path. The numbers to the left are samples from the
 perf sampling profiler, and indicate the cost of each line. From these it
 seems that the slow path is never taken.

 What is intriguing is that the compiler (clang in this case) places the slow
 path block in-line, thus the branch on line five is likely to be
 mispredicted. This is not the case for the branch on line 11.

 Is this the desired behavior? I.e., are these slow paths often taken?

This is the main question and I don't know the answer.
Most likely on some apps adding branch weights will be a loss and on
other apps it will be a gain.

Example:

#include stdlib.h
#include stdio.h
void store(int *a) {
  *a = 0;
}

int main(int argc, char **argv) {
  size_t off = argc == 1 ? 7 : atoi(argv[1]);
  int *x = new int[3];
  printf(offset: %zd\n, off);
  for (int i = 0; i  1; i++)
store(x + off);
  delete [] x;
}


This is the profile if I run ./a.out 0

   │004b49e0 store(int*):
 19.00 │  push   %rax
 31.11 │  mov%rdi,%rax
   │  shr$0x3,%rax
   │  mov0x7fff8000(%rax),%al
 31.45 │  test   %al,%al
   │↓ je 21
   │  mov%edi,%ecx
   │  and$0x7,%ecx
   │  add$0x3,%ecx
   │  movsbl %al,%eax
   │  cmp%eax,%ecx
   │↓ jge29
 14.82 │21:   movl   $0x0,(%rdi)
  0.11 │  pop%rax
  3.51 │← retq


This is the profile if I run ./a.out 2

   │004b49e0 store(int*):
 17.38 │  push   %rax
  3.67 │  mov%rdi,%rax
   │  shr$0x3,%rax
   │  mov0x7fff8000(%rax),%al
 17.50 │  test   %al,%al
   │↓ je 21
  7.34 │  mov%edi,%ecx
   │  and$0x7,%ecx
   │  add$0x3,%ecx
 12.73 │  movsbl %al,%eax
  6.00 │  cmp%eax,%ecx
   │↓ jge29
   │21:   movl   $0x0,(%rdi)
   │  pop%rax
 35.37 │← retq



 Or is
 this layout desirable for other reasons?

 If this is not the desired behavior, is it a compiler problem? Should clang
 be able to recognize this pattern and automatically guess branch weights?

 If it's not a compiler problem, would it make sense to specify branch
 weights in AddressSanitizer? Currently, AddressSanitizer does not add any
 weights to the branches it creates.

The change to add weights is trivial.
I am not against it and the patch is welcome, but it will need to be
accompanied with SPEC performance numbers.

--kcc


 Cheers,
 Jonas

 --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Konstantin Serebryany]

Do you have a reproducer?

On Wed, Aug 6, 2014 at 6:04 AM, ji wang mason.wan...@gmail.com wrote:
 First: Double Free
 =
 ==2415==ERROR: AddressSanitizer: attempting double-free on 0xb4c28b20 in
 thread T16777215:
 ==2415==AddressSanitizer CHECK failed:
 ../../../.././../gcc/gcc-4.9/libsanitizer/asan/asan_report.cc:586
 ((free_stack-size))  ((0)) (0x0, 0x0)
 #0 0xb67af94f (/system/lib/libasan.so.1+0x3f94f)
 #1 0xb67b2f8b (/system/lib/libasan.so.1+0x42f8b)
 #2 0xb67ae137 (/system/lib/libasan.so.1+0x3e137
 ...
 ... ...
 According to the asan code, free_stack maybe should not be empty, should
 print something like “freed by thread T0 here:... ...previously allocated by
 thread T0 here:... ...
 And of cource It's important, for what reason we may lose this part log
 print or somethine went wrong on my asan?

 Second: UseAfterFree
 =
 ==4782==ERROR: AddressSanitizer: heap-use-after-free on address 0xadb64ff7
 at pc 0xb5916e87 bp 0xb09ff8bc sp 0xb09ff8b4
 WRITE of size 1 at 0xadb64ff7 thread T16777215
 #0 0xb5916e85 (/system/lib/libstagefright.so+0x12ce85)
 #1 0xb59185b3 (/system/lib/libstagefright.so+0x12e5b3)
...

 0xadb64ff7 is located 7 bytes inside of 8-byte region
 [0xadb64ff0,0xadb64ff8)
 ==4782==AddressSanitizer CHECK failed:
 ../../../.././../gcc/gcc-4.9/libsanitizer/asan/asan_allocator2.cc:234
 ((id)) != (0) (0x0, 0x0)
 #0 0xb65cd94f (/system/lib/libasan.so.1+0x3f94f)
 #1 0xb65d0f8b (/system/lib/libasan.so.1+0x42f8b)
 #2 0xb65a2637 (/system/lib/libasan.so.1+0x14637)
...
 #6 0xb58ff04f (/system/lib/libstagefright.so+0x12c04f)
 #7 0xb59273d3 (/system/lib/libstagefright.so+0x1543d3)
 This one is the CHECK(id); error, what this id for? And more, the
 stack printed first and second which I maked red colour is the same, this is
 werid, why?

 --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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.

[Konstantin Serebryany]

On Mon, Jul 28, 2014 at 1:25 PM, ji wang mason.wan...@gmail.com wrote:
 Hi, kcc

On Linux, you typically have to link the asan run-time to the
executable, but see
https://code.google.com/p/address-sanitizer/wiki/AsanAsDso

 Do we have to use LD_PRELOAD to preload this asan run-time Dso to the
 process before this Asan instrumented executable run?And why?
 I've tried not preload the asan run-time at first, and I got the

Please give more context: where did you try that and what exactly did you do.

 AddressSanitizer: failed to intercept 'memcpy' error, And I tried to fix
 it by this modification of the code:

 --- a/gcc-4.9/libsanitizer/interception/interception_linux.cc
 +++ b/gcc-4.9/libsanitizer/interception/interception_linux.cc
 @@ -12,13 +12,31 @@

  namespace __interception {
  bool GetRealFunctionAddress(const char *func_name, uptr *func_addr,
  uptr real, uptr wrapper) {
 +  char *err;
 +  void *handle = dlopen(libc.so, RTLD_NOW);
 -  *func_addr = (uptr)dlsym(RTLD_NEXT, func_name);
 +  *func_addr = (uptr)dlsym(handle, func_name);
 +  err = (char *)dlerror();
 +  if(err){
 +   Printf(---GetRealFunctionAddress: error in dlsym: (%s)\n, err);
 +  }
 +  dlclose(handle);

return real == wrapper;
  }
 And after this modification, everything went ok. Dose this code modified
 properly? Or have any side effect?


 --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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.

[Konstantin Serebryany]

On Mon, Jul 28, 2014 at 2:04 PM, ji wang mason.wan...@gmail.com wrote:
 Do we have to use LD_PRELOAD to preload this asan run-time Dso to the
 process before this Asan instrumented executable run?And why?
 I've tried not preload the asan run-time at first, and I got the

Please give more context: where did you try that and what exactly did you
 do.

 I am using Asan DSO enabled GCC4.9 android toolchain to test one shared lib
 on android platform. And only this lib recompiled with Asan.

 When I loaded this recompiled lib and got AddressSanitizer: failed to
 intercept 'memcpy' error, LD_PRELOAD can fix it but I don't want
 use it because in some situation I really don't know where to place this
 LD_PRELOAD thing and even I know the place still a litte diffcult to use it.
 So I modified the code like I post in my last reply.
 And now I want to know do we have to use LD_PRELOAD to preload the asan DSO?
 so the same on android,arm,X86 platform? and why? and does my modification
 have any side effect?

The instructions about using DSO are really about regular Linux, not Android
(Which is Evgeniy's land. Please make sure the asan-Android wiki is up to date)

--kcc



 --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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.

[Konstantin Serebryany]

What's wrong with the existing documentation at
https://code.google.com/p/address-sanitizer/ ?
Please post specific questions.

--kcc

On Fri, Jul 25, 2014 at 4:32 PM, ji wang mason.wan...@gmail.com wrote:
 Especially the way that how to test a shared lib using GCC4.9 asan. thanks

 --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Stack instrumentation for kernel.

[Konstantin Serebryany]

On Fri, Jun 20, 2014 at 4:50 PM, Andrey Ryabinin ryabinin@gmail.com wrote:
 2014-06-20 16:16 GMT+04:00 Yuri Gribov tetra2...@gmail.com:
 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-instrumentation-with-call-threshold=0. As Dmitry pointed out, we
 could hide all these --param's under -fsanitize=kernel-address.

 @Andrey: did I miss anything in CFLAGS?


 --param asan-memintrin=0 --param asan-fixed-shadow-offset=0

 And with  --param asan-stack=1 it also works now.

rockroll!


 Am I right to assume that params hidden under -fsantize=kernel-addres
 could be overwritten if anyone wants to enable
 for e.g. stack instrumentation? Like this:
 -fsanitize=kernel-address --param asan-stack=1

I think so, yes.


 -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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.



 --
 Best regards,
 Andrey Ryabinin

 --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Manually poisoning reads but not writes, unpoison on write.

[Konstantin Serebryany]

Hi Nicolas.

This sounds more like msan:
https://code.google.com/p/memory-sanitizer/wiki/MemorySanitizer

--kcc

On Wed, Jun 18, 2014 at 11:05 AM, Nicolas Hillegeer
nicolashilleg...@gmail.com wrote:
 Hi, I'm not sure if this is exactly the right place but some linkes on the
 web told me that it was so here goes:

 At the neovim project (https://github.com/neovim/neovim) we're refactoring
 the codebase and we've got a few hairy cases:

 - we'd like to replace strncpy with strlcpy. strncpy zero-fills the part of
 the buffer after
 - we'd like to replace a growing array that memsets the extra memory to 0
 with one that doesn't

 Most call-sites are safe to transform as-is, because the zero-filling wasn't
 used, but some aren't. This could be
 because the memory region is used in some other function way up or down the
 call-stack. It's very difficult to
 ascertain that a conversion is perfectly safe.

 This is where I thought that manually poisoning the memory that used to be
 zero-filled would be a good idea. There
 is a snag however: when the poisoned memory is written to before it's read,
 that's fine. Because that counts more or less
 as initializing. Yet if the poisoned memory is first read, then it should
 abort.

 I searched and found the Address Sanitizer manual poisoning wiki page:
 https://code.google.com/p/address-sanitizer/wiki/ManualPoisoning

 But at first glance, it doesn't seem like it could do
 read-until-write-poisoning. Is what I want doable? If not with ASan, perhaps
 with
 some other tool or with ASan in the future?

 Kind regards,
 Nicolas

 --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Future of -fsanitize-recover

[Konstantin Serebryany]

On Tue, Jun 10, 2014 at 11:56 AM, Yuri Gribov tetra2...@gmail.com wrote:
 All,

 Are there plans to extend -fsanitize-recover beyond UBSan? It seems
 that adding this functionality to e.g. ASan would be trivial.

I do not plan to add such functionality to asan and I am strongly
opposed to it.
It will create more problems to users and developers than it will solve.

What are your reasons?


 -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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Future of -fsanitize-recover

[Konstantin Serebryany]

On Tue, Jun 10, 2014 at 12:10 PM, Yuri Gribov tetra2...@gmail.com wrote:
 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 reduce debugging time.

Sometimes -- yes. But there are downsides: one bug may trigger another
report and the user will spend time investigating more reports than
needed.


 It will create more problems to users and developers than it will solve.

 Agreed, it may cause false positives, duplicated reports, etc. But it
 does not have to be enabled by default.

These, and many more.
Next time, someone will request suppressions.

I remain unconvinced...


 -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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Stack instrumentation for kernel.

[Konstantin Serebryany]

On Tue, May 27, 2014 at 1:37 PM, Yuri Gribov tetra2...@gmail.com wrote:
 On Mon, May 26, 2014 at 7:57 PM, 'Dmitry Vyukov' via address-sanitizer
 address-sanitizer@googlegroups.com 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 approach most (i.e. insert calls to
 __kasan_instrument_stack/__kasan_uninstrument_stack at start/end of
 function).

alternative to __kasan_instrument_stack is to implement
__asan_get_shadow_ptr(addr) and then reuse the existing inline stack
instrumentation.



 --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Out-of-line memory checks

[Konstantin Serebryany]

On Mon, Apr 21, 2014 at 1:03 PM, Yuri Gribov tetra2...@gmail.com wrote:
 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?
That too, but we also need to be able to unwind properly.
Generally, unless we call GET_CALLER_PC_BP_SP directly from the
function called from the user code
we are not guaranteed to get correct stack trace (since asan-rt is
built w/o frame pointers).


 My version lacked the UNLIKELY trick. fixed.

 Cool, upstream code seems to run really fast now: 16 sec. (vs my 17.8
 sec.). Looks like outline overhead is only 300% now (compared to 200%
 for normal inline ASan) which is probably acceptable. And we'll have
 to work around ABI to improve further.

 Some suggestions:
 * can we move separate calls for begin/end for intrinsics (and larger
 memory accesses) into callbacks ?
 * can we remove check for size == 0 and perform it in callback instead ?
 I can submit a patch if you are ok with those.

Hold on a bit here. First, my recent patches have a bug around
handling of memsetco,
second I am considering to competely replace memsetco calls with
another function call -- this will solve some other problems as well,
but it needs performance evaluation...


 BTW note that we will suffer significant PLT penalty in sanitized shared libs.

Don't use shared libs :)

--kcc


 -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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Out-of-line memory checks

[Konstantin Serebryany]

On Mon, Apr 21, 2014 at 2:29 PM, Yuri Gribov tetra2...@gmail.com wrote:
 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...

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



 -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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Out-of-line memory checks

[Konstantin Serebryany]

On Mon, Apr 21, 2014 at 3:31 PM, Yuri Gribov tetra2...@gmail.com wrote:
 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 needs (pathalogical codes with
 thousands memory accesses) but will slow down my usecase quite a bit
 (I admit that I may be the only one who's interested though).

 I can probably get away with manually adding -lmy_private_asan_checks
 to CFLAGS to override default Asan callback implemenation with it's
 PLT overheads but IMHO making upstream implementation slower than
 necessary is questionable.

 Hold on a bit here. First, my recent patches have a bug around
 handling of memsetco,
 second I am considering to competely replace memsetco calls with
 another function call -- this will solve some other problems as well,
 but it needs performance evaluation...

 Cool, ping us when it's in.

It's there.
asan may still emit inlined checks for things like 'long double'


 -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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Out-of-line memory checks

[Konstantin Serebryany]

On Mon, Apr 21, 2014 at 7:10 PM, Yuri Gribov tetra2...@gmail.com wrote:
 asan may still emit inlined checks for things like 'long double'

 Is this intentional?

Just not done yet.

 How about replacing these with a call to
 __asan_{load,store}N?

Yep.

--kcc


 -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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Out-of-line memory checks

[Konstantin Serebryany]

Meanwhile we've made the first step for Out-of-line memory checks.

http://llvm.org/viewvc/llvm-project?view=revisionrevision=206387 and
http://llvm.org/viewvc/llvm-project?view=revisionrevision=206383
introduce a new hidden flag -mllvm
-asan-instrumentation-with-call-threshold=N which will use callbacks
instead of inline checks
when the function has more than N memory accesses.
The plan is to set N to something like 1 by default.
We did it because we are desperate with
http://llvm.org/bugs/show_bug.cgi?id=17409 and
because the same thing will help us experimenting with kernel-asan
(kasan has different and yet-unstable shadow mapping).

--kcc

On Mon, Mar 31, 2014 at 4:04 PM, Yuri Gribov tetra2...@gmail.com wrote:
 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.

 Also, ARM calls do not save return address on stack, but store it in
 LR register - that's one less memory store on the fast path.

 +1

 -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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Out-of-line memory checks

[Konstantin Serebryany]

btw, I've run SPEC (test data, C only) and it shows that out-of-line
instrumentation is 2x slower.
This is x86_64, but I doubt that ARM will be any different.

(second column is with out-of-line instrumentation, third is with regular
inline instrumentation)

   400.perlbench, 9.79, 8.31, 0.85
   401.bzip2,19.00, 9.59, 0.50
 403.gcc, 2.79, 2.64, 0.95
 429.mcf, 4.92, 4.01, 0.82
   445.gobmk,37.30,29.20, 0.78
   456.hmmer,10.60, 4.88, 0.46
   458.sjeng, 9.63, 6.44, 0.67
  462.libquantum, 0.16, 0.08, 0.52
 464.h264ref,56.50,26.60, 0.47
433.milc,21.70, 9.93, 0.46
 470.lbm, 5.85, 3.00, 0.51
 482.sphinx3, 3.55, 2.02, 0.57

--kcc


On Thu, Apr 17, 2014 at 12:45 PM, Konstantin Serebryany 
konstantin.s.serebry...@gmail.com wrote:

 Meanwhile we've made the first step for Out-of-line memory checks.

 http://llvm.org/viewvc/llvm-project?view=revisionrevision=206387 and
 http://llvm.org/viewvc/llvm-project?view=revisionrevision=206383
 introduce a new hidden flag -mllvm
 -asan-instrumentation-with-call-threshold=N which will use callbacks
 instead of inline checks
 when the function has more than N memory accesses.
 The plan is to set N to something like 1 by default.
 We did it because we are desperate with
 http://llvm.org/bugs/show_bug.cgi?id=17409 and
 because the same thing will help us experimenting with kernel-asan
 (kasan has different and yet-unstable shadow mapping).

 --kcc

 On Mon, Mar 31, 2014 at 4:04 PM, Yuri Gribov tetra2...@gmail.com wrote:
  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.
 
  Also, ARM calls do not save return address on stack, but store it in
  LR register - that's one less memory store on the fast path.
 
  +1
 
  -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+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Out-of-line memory checks

[Konstantin Serebryany]

On Thu, Apr 17, 2014 at 3:36 PM, Yuri Gribov tetra2...@gmail.com wrote:

  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.

Sorry.


  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.

--kcc



 -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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Out-of-line memory checks

[Konstantin Serebryany]

On Thu, Apr 17, 2014 at 4:56 PM, Yuri Gribov tetra2...@gmail.com wrote:

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

regular asan instrumentation requires 1 load.
a call, which itself does 1 load, costs two more loads (call and ret),
besides the call puts more pressure on the reg allocator which causes more
spills.

--kcc





 -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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: /dev/byte8

[Konstantin Serebryany]

Not sure I understood your proposal and even less sure what it is going to
accomplish..
More details?


On Tue, Apr 1, 2014 at 4:42 AM, Yuri Gribov tetra2...@gmail.com wrote:

 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 can be efficiently mmapped to
 userspace.

 Something like this could theoretically be used to get rid of zero
 check in Asan poison checks on Linux systems (we can just mmap
 /dev/byte8 to shadow). Portability of generated code would of course
 go right out the window...

 -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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: /dev/byte8

[Konstantin Serebryany]

Ah, yea, that would be an interesting experiment.
I'd expect more savings in code size and fewer savings in CPU time.
And unless the savings are really big I'd probably not want the change in
trunk
(we can't make it the only mode; having too modes is too much extra
complexity)

--kcc


On Tue, Apr 1, 2014 at 5:10 AM, Yuri Gribov tetra2...@gmail.com wrote:

  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 = *shadow_address;
 byte last_accessed_byte = (address  7) + kAccessSize - 1;
 if (last_accessed_byte = shadow_value) {
 ReportError(address, kAccessSize, kIsWrite);
 }

 -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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Underusage of LIKELY macro in ASan sources

[Konstantin Serebryany]

On Sat, Mar 29, 2014 at 2:55 PM, Yuri Gribov tetra2...@gmail.com wrote:

 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?


I don't think this is intentional. I actually think they were lost during
some refactoring.
We should probably have such in the implementation of CHECK*

--kcc



 -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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Debug info broken for ASan-instrumented binaries

[Konstantin Serebryany]

For this case cfe-dev (or llvmdev) is actually more relevant, Alexey will
reply to you shortly.

--kcc


On Mon, Mar 31, 2014 at 6:22 AM, Richtarsky, Martin 
martin.richtar...@sap.com wrote:

 Hi,

 I posted this on cfe-dev before, but perhaps this is more appropriate.

 I noticed that debugging of AddressSanitizer-instrumented clang debug
 binaries
 is basically impossible since all the symbols are optimized out. It looks
 like
 there is something wrong with debug info. I'm getting the same behavior
 on 3.4 and trunk. Interestingly it works for -fsanitize=undefined. Is this
 a known
 issue? There are several related bugs but they are fixed already, e.g.
 http://llvm.org/bugs/show_bug.cgi?id=11818

 # cat UnitAsanStackOOB.cpp
 int main()
 {
 const int len = 10;
 char buffer[len];
 char *p = buffer[0];
 p[len] = 1;
 return 0;
 }

 # clang++ -g -o oob_trunk_add -fsanitize=address UnitAsanStackOOB.cpp
 # gdb oob_trunk_add
 GNU gdb (GDB) 7.5.1
 Reading symbols from
 /local/build/git5/sys/src/clang/AddressSanitizer/test/oob_trunk_add...done.
 (gdb) b main
 Breakpoint 1 at 0x495a4a: file UnitAsanStackOOB.cpp, line 3.
 (gdb) run
 Starting program:
 /local/build/git5/sys/src/clang/AddressSanitizer/test/oob_trunk_add
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 Breakpoint 1, main () at UnitAsanStackOOB.cpp:3
 3   const int len = 10;
 (gdb) n
 5   char *p = buffer[0];
 (gdb) n
 6   p[len] = 1;
 (gdb) p p
 $1 = optimized out
 (gdb) p len
 $2 = optimized out

 # clang++ -g -o oob_trunk_und -fsanitize=undefined UnitAsanStackOOB.cpp
 # gdb oob_trunk_und
 GNU gdb (GDB) 7.5.1
  (gdb) b main
 Breakpoint 1 at 0x426280: file UnitAsanStackOOB.cpp, line 2.
 (gdb) run
 Starting program:
 /local/build/git5/sys/src/clang/AddressSanitizer/test/oob_trunk_und
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 Breakpoint 1, main () at UnitAsanStackOOB.cpp:2
 2   {
 (gdb) n
 3   const int len = 10;
 (gdb) n
 5   char *p = buffer[0];
 (gdb) n
 6   p[len] = 1;
 (gdb) p p
 $1 = 0x7fff975e 
 (gdb) p len
 $2 = 10

 # clang++ -v
 clang version 3.5.0 (trunk 204863)
 Target: x86_64-unknown-linux-gnu
 Thread model: posix
 Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/4.3
 Selected GCC installation: /usr/lib64/gcc/x86_64-suse-linux/4.3
 Candidate multilib: .;@m64
 Candidate multilib: 32;@m32
 Selected multilib: .;@m64

 Best regards,
 Martin

 --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Avoid reserving shadow for kernel area

[Konstantin Serebryany]

On my 64-bit linux box running a 32-bit app I see this:
% cat addr.c
#include stdio.h
#include stdlib.h

int main() {
  int local;
  printf(%p %p %p\n, main, local, malloc(10));
}

% g++ addr.c -m32  ./a.out
0x8048414 0xff95481c 0x99de008
%

Stack is at 0xff95481c, so, the app uses the entire 4Gb range.
What can be optimized here?

--kcc


On Tue, Mar 18, 2014 at 3:15 PM, Yuri Gribov tetra2...@gmail.com wrote:

 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 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ARM support

[Konstantin Serebryany]

Roberto,

ARM (32-bit) is fully supported, we run ASAN on Android devices.
If you mean regular ARM-Linux, it's a matter of someone setting a build bot
and ensuring that it works (and maybe sending a couple of patches).
Patches to support AArch64 has been applied recently as well, but I don't
have accesses to AArch64 machines so I can't tell if it is already fully
usable.

--kcc


On Wed, Feb 26, 2014 at 9:20 AM, rmartell...@gmail.com wrote:

 Hi,

 is there in the road-map the support for ARM architecture ?

 Many thanks,
 R.

  --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Konstantin Serebryany]

On Thu, Feb 6, 2014 at 1:59 PM, Yuri Gribov tetra2...@gmail.com wrote:

  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 sanitized and some aren't (in real world you don't always
 have the luxury of full app rebuild); LD_PRELOAD would allow you to
 override malloc and friends and enable ASan even in that case

There is no disagreement here.
Note that the only way ASAN is used on Android, Mac and iOS (and Windows?)
is through dynamic run-time.
But: we are using dynamic run-time for python in one of our settings
and the experience is so painful that we don't want to advertise
asan-as-dso on Linux,
where static run-time works well for the majority of use cases.
There are some bugs specific to using asan as a shared library, e.g.
https://code.google.com/p/address-sanitizer/issues/detail?id=147

--kcc



 -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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Issue 73 in address-sanitizer: Detect Use after destruction (but before free)

[Konstantin Serebryany]

Why???


On Thu, Feb 6, 2014 at 7:43 PM, Timur Iskhodzhanov timur...@google.comwrote:

 You might be required to use placement new first thing after the dtor.

 --
 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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.


-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.