[llvm-dev] Temporary disable ASan's allocator check
Kostya Serebryany via llvm-dev
llvm-dev at lists.llvm.org
Wed Sep 6 17:20:50 PDT 2017
On Wed, Sep 6, 2017 at 2:42 PM, Jonas Devlieghere <jdevlieghere at apple.com>
> 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
% ./a.out malloc
==2503==WARNING: AddressSanitizer failed to allocate 0x10000000001 bytes
==2503==AddressSanitizer's allocator is terminating the process instead of
==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
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
but unless absolutely necessary I'd try to avoid this. Lots of things may
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.
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev