Comment #7 on issue 345 by google.8...@spamgourmet.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
I am not a regular committer on llvm or gcc. I posted the original
attachment as a demons
Updates:
Status: Fixed
Comment #14 on issue 344 by samso...@google.com: Clang driver incorrectly
handles -Wl,-r flag
https://code.google.com/p/address-sanitizer/issues/detail?id=344
FWIW, I've submitted r218541, so that now sanitizer runtimes won't be
passed to the linker if user pr
On Fri, Sep 26, 2014 at 4:08 PM, Jonas Wagner wrote:
> Also, this might be very interesting for the stack, too. I think even a
> slightly randomized stack layout (through random redzone sizes or variable
> reordering) could make it harder to write exploits. I know ASan is a
> debugging tool more t
On Fri, Sep 26, 2014 at 1:29 AM, Jonas Wagner wrote:
> Thanks a lot for all these replies! They really help me understand the
> design.
>>
>> When I measured performance of sanitizer allocator against tcmalloc on
>> a large real application that calls malloc a lot, sanitizer allocator
>> was 10% f
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 a
On Fri, Sep 26, 2014 at 12:26 AM, Alexander Potapenko
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
Hi,
> Compared to other SPEC benchmarks, the fraction of overhead due to checks
> is
> > very low for gcc. Much overhead seems to come from heap poisoning and
> from
> > the quarantine queue, but there are also some 30% of overhead that hide
> > elsewhere… I suspect that the allocator might be to
On Fri, Sep 26, 2014 at 12:29 PM, Jonas Wagner wrote:
> Thanks a lot for all these replies! They really help me understand the
> design.
>>
>> When I measured performance of sanitizer allocator against tcmalloc on
>> a large real application that calls malloc a lot, sanitizer allocator
>> was 10%
Thanks a lot for all these replies! They really help me understand the
design.
When I measured performance of sanitizer allocator against tcmalloc on
> a large real application that calls malloc a lot, sanitizer allocator
> was 10% faster.
>
This is interesting! It probably means there are no larg
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,
10 matches
Mail list logo
