On Thu, Sep 25, 2014 at 2:16 AM, 'Alexander Potapenko' via address-sanitizer <[email protected]> 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 <[email protected]> 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 >> <[email protected]> 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 >>> <[email protected]> wrote: >>> > +tetra2005 >>> > >>> > >>> > On Wed, Sep 24, 2014 at 4:31 PM, Kuba Brecka <[email protected]> >>> > 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 [email protected]. >>> >> 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 [email protected]. >>> > 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 [email protected]. >>> 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 [email protected]. >> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
