llvm dev - Sep 2017 - Temporary disable ASan's allocator check

> 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 <mailto: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. If the answer is no, I wonder how useful error handler
is (which isn't currently used, at least not upstream).
>  
> 
> Thanks,
> Jonas
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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/1969616c/attachment.html>

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>

> On Sep 7, 2017, at 1:20 AM, Kostya Serebryany <kcc at google.com>
wrote:
> 
> 
> 
> On Wed, Sep 6, 2017 at 2:42 PM, Jonas Devlieghere <jdevlieghere at
apple.com <mailto:jdevlieghere at apple.com>> wrote:
> 
>> On Sep 6, 2017, at 9:14 PM, Kostya Serebryany <kcc at google.com
<mailto: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 <mailto: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. 
I considered doing that for my test case, but fuzzing (with ASan) would still
trigger a crash.
> There is no way to change this while the process is running.
That answers my question, thanks! 
> 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. 
I totally agree, and in that respect it’s probably a good thing that it can’t be
disabled at run time.
> 
> --kcc 
>  
> 
>>  
>> 
>> Thanks,
>> Jonas
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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/20170907/ea93f86e/attachment.html>