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 < [email protected]> wrote: > 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. > -- 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.
