We just need a separate error reporting function that'll be called exclusively from interceptors. It doesn't have to be noreturn, because the interceptors themselves aren't. On Sep 26, 2014 8:52 AM, "'Alexey Samsonov' via address-sanitizer" < [email protected]> wrote:
> > On Thu, Sep 25, 2014 at 9:46 PM, Konstantin Serebryany < > [email protected]> 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 <[email protected]> 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 >> > <[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. >> >> -- >> 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. > -- 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.
