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 woul
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 wrote:
> Can you add a new suppression kind that wou
Updates:
Owner: konstant...@gmail.com
Comment #6 on issue 345 by konstant...@gmail.com: Use Linux
madvise(MADV_DONTDUMP) to exclude ASan shadow regions from core dumps
https://code.google.com/p/address-sanitizer/issues/detail?id=345
(No comment was entered for this change.)
--
You re
Comment #5 on issue 345 by dvyu...@google.com: Use Linux
madvise(MADV_DONTDUMP) to exclude ASan shadow regions from core dumps
https://code.google.com/p/address-sanitizer/issues/detail?id=345
Can somebody please summarize whether here is something actionable for me
to do or not (I am assign
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, Kon
On Thu, Sep 25, 2014 at 8:49 AM, 'Dmitry Vyukov' via address-sanitizer
wrote:
> On Thu, Sep 25, 2014 at 7:44 AM, Jonas Wagner wrote:
>> Dear AddressSanitizer developers,
>>
>> I'm thinking about ways to optimize the performance of ASan's allocator.
>> There are a few benchmarks where a large frac
On Thu, Sep 25, 2014 at 2:16 AM, 'Alexander Potapenko' via
address-sanitizer 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 mu
Comment #13 on issue 344 by dvyu...@google.com: Clang driver incorrectly
handles -Wl,-r flag
https://code.google.com/p/address-sanitizer/issues/detail?id=344
We did wrappers a lot as well. It's probably the most practical solution.
But it does not look like something that end user must be doi
On Thu, Sep 25, 2014 at 7:44 AM, Jonas Wagner wrote:
> Dear AddressSanitizer developers,
>
> I'm thinking about ways to optimize the performance of ASan's allocator.
> There are a few benchmarks where a large fraction of the overhead comes from
> the allocator and the quarantine queue, rather than
Dear AddressSanitizer developers,
I'm thinking about ways to optimize the performance of ASan's allocator.
There are a few benchmarks where a large fraction of the overhead comes
from the allocator and the quarantine queue, rather than the checks
themselves (e.g., gcc from SPEC2006).
When I looke
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 co
Comment #12 on issue 344 by tetra2...@gmail.com: Clang driver incorrectly
handles -Wl,-r flag
https://code.google.com/p/address-sanitizer/issues/detail?id=344
This level of control is generally impossible in an arbitrary C/C++
project out
there. One better pray that the build system at lea
12 matches
Mail list logo
