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