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.

Reply via email to