On Fri, Sep 26, 2014 at 12:26 AM, Alexander Potapenko <ramosian.gli...@gmail.com> wrote: > 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.
yep > > On Sep 26, 2014 8:52 AM, "'Alexey Samsonov' via address-sanitizer" > <address-sanitizer@googlegroups.com> wrote: >> >> >> 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. > > -- > 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.
