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.
