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

[Jonas Devlieghere via llvm-dev]

> 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>