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