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. (For example we could print a warning about that when a suppression matches the report that didn't originate from an interceptor)
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.
