[llvm-dev] Temporary disable ASan's allocator check

[Kostya Serebryany via llvm-dev]

On Wed, Sep 6, 2017 at 2:42 PM, Jonas Devlieghere <jdevlieghere at apple.com>
wrote:

>
> On Sep 6, 2017, at 9:14 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>
>
> On Wed, Sep 6, 2017 at 8:43 AM, Jonas Devlieghere via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>
>> Is it possible to change the value of ASan's allocator_may_return_null at
>> runtime or somehow disable this check temporarily? If I install an LLVM
>> bad_alloc_error_handler, ASan's allocator wrapper detects this first and
>> terminates the process instead of returning 0, preventing the custom
>> handler from being called.
>>
>
> Is this question related to "r312582 - Revert "[Decompression] Fail
> gracefully when out of memory”"?
>
>
> It is! Though even if we don't need it, I’d still be interested to know
> whether this is possible.
>

I'm not sure what you are asking for, exactly.
Here is how it works:

% clang++ -fsanitize=address
 ~/llvm/projects/compiler-rt/test/asan/TestCases/allocator_returns_null.cc

% ./a.out malloc
==2503==WARNING: AddressSanitizer failed to allocate 0x10000000001 bytes
==2503==AddressSanitizer's allocator is terminating the process instead of
returning 0
==2503==If you don't like this behavior set allocator_may_return_null=1

% ASAN_OPTIONS=allocator_may_return_null=1 ./a.out malloc
==2513==WARNING: AddressSanitizer failed to allocate 0x10000000001 bytes
errno: 12
x: 0

So you can change the value of allocator_may_return_null at startup.
There is no way to change this while the process is running.

You can set allocator_may_return_null per binary
using __asan_default_options
(see llvm/projects/compiler-rt/include/sanitizer/asan_interface.h)
but unless absolutely necessary I'd try to avoid this. Lots of things may
go wrong.

If the answer is no, I wonder how useful error handler is (which isn't
> currently used, at least not upstream).
>

Imho, an error handler that tries to recover from OOM is a very dangerous
thing and should be avoided.
This essentially introduces a very fragile code to the least tests path.

--kcc


>
>
>
>>
>> Thanks,
>> Jonas
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170906/844c7301/attachment-0001.html>