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

[Yuri Gribov]

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

Yeah...

> The packed structures cause "misaligned pointer access".

Hm, now that sounds as a bug in implementation. Could you file it
(with repro) to GCC BZ?

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

['Ilya' via address-sanitizer]

> Worst case you could wrap problematic code in #ifdef 
> __SANITIZE_UNDEFINED__ and provide dedicated implementation. What's 
> the problem with packed stuff though? 
>

Yep, but I'd like to avoid that if possible :)
The packed structures cause "misaligned pointer access".

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

['Ilya' via address-sanitizer]

Hello everybody,

> Usually, ubsan-related questions get answered at  llvm...@lists.llvm.org 
> , we we can reply too :) 
>
 
 first thanks for the quick responses. (We had some national holidays going 
on here, so my answer comes quite late - sorry for that.)

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

Still a WONTFIX :( (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978)
 

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

It's not a "does not work as expected", more a "I don't understand what's 
going on in the sourcecoude".
If I got that right, there's the suppression context, initialized from the 
file on ubsan_init() or rather InitializeSuppressions(). 
However the resultung suppression_ctx object is only used by 
"__ubsan::IsVptrCheckSuppressed". 
So I therefore don't 
really understand how the suppression is working for the other functions. 
This understanding however might be crucial for
me to utilize it to suppress the lasting ubs.

The slowdown could be acceptable, so I'm not worrying about that currently.

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