Re: AddressSanitizer and issue suppression

2014-10-24 Thread tetra2005x
On Fri, Sep 26, 2014 at 12:26 AM, Alexander Potapenko ramosia...@gmail.com javascript: 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. Sounds like a match

Re: AddressSanitizer and issue suppression

2014-09-26 Thread Alexander Potapenko
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 address-sanitizer@googlegroups.com wrote: On Thu, Sep

Re: AddressSanitizer and issue suppression

2014-09-26 Thread Konstantin Serebryany
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,

Re: AddressSanitizer and issue suppression

2014-09-26 Thread 'Alexey Samsonov' via address-sanitizer
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. Sure. The relevant parts are

Re: AddressSanitizer and issue suppression

2014-09-25 Thread 'Alexander Potapenko' via address-sanitizer
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. (For example we

Re: AddressSanitizer and issue suppression

2014-09-25 Thread Konstantin Serebryany
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

Re: AddressSanitizer and issue suppression

2014-09-25 Thread 'Alexey Samsonov' via address-sanitizer
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,

Re: AddressSanitizer and issue suppression

2014-09-25 Thread 'Alexey Samsonov' via address-sanitizer
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

Re: AddressSanitizer and issue suppression

2014-09-24 Thread 'Dmitry Vyukov' via address-sanitizer
+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

Re: AddressSanitizer and issue suppression

2014-09-24 Thread Konstantin Serebryany
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