Context: https://github.com/google/sanitizers/issues/740.
Making secondary allocator to respect allocator_may_return_null=1 flag
and return nullptr when "out of memory" happens.
More changes in primary allocator and operator new will follow.
Differential D34243
[Sanitizers] Secondary allocator respects allocator_may_return_null=1. alekseyshl on Jun 15 2017, 9:55 AM. Authored by
Details Context: https://github.com/google/sanitizers/issues/740. Making secondary allocator to respect allocator_may_return_null=1 flag More changes in primary allocator and operator new will follow.
Diff Detail
Event TimelineComment Actions I have not figured out a reliable way to test mmap's out of memory condition, especially for 64 bits. Comment Actions Do you want me to change that for the Scudo secondary as well, or can you bundle it with this?
Comment Actions Can you update the OOM message in the windows tests? http://lab.llvm.org:8011/builders/sanitizer-windows/builds/12993 Comment Actions The new test case fails on SystemZ, making all our build bots red. The problem seems to be that the size of the shadow areas is bigger on SystemZ, which means after the ulimit -v, already the ASAN initialization fails since it can no longer allocate the shadow area: ==63256==ERROR: AddressSanitizer failed to allocate 0x2000000001000 (562949953425408) bytes at address ffffffffff000 (errno: 12) ==63256==ReserveShadowMemoryRange failed while trying to map 0x2000000001000 bytes. Perhaps you're using ulimit -v Program received signal SIGABRT, Aborted. 0x000003fffd83d4f8 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 54 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); (gdb) bt #0 0x000003fffd83d4f8 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 #1 0x000003fffd83edee in __GI_abort () at abort.c:89 #2 0x0000000001104d8a in __sanitizer::Abort () at /home/uweigand/llvm/llvm-head/projects/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cc:146 #3 0x00000000010e2918 in __asan::ReserveShadowMemoryRange (beg=4503599627366400, end=<optimized out>, name=0x1114c72 "low shadow") at /home/uweigand/llvm/llvm-head/projects/compiler-rt/lib/asan/asan_rtl.cc:99 #4 0x00000000010e5302 in __asan::InitializeShadowMemory () at /home/uweigand/llvm/llvm-head/projects/compiler-rt/lib/asan/asan_rtl.cc:472 #5 __asan::AsanInitInternal () at /home/uweigand/llvm/llvm-head/projects/compiler-rt/lib/asan/asan_rtl.cc:555 #6 0x000003fffdf91a44 in _dl_init (main_map=0x3fffdfa70d8, argc=<optimized out>, argv=0x3fffffff2c8, env=0x3fffffff2d8) at dl-init.c:105 #7 0x000003fffdf80fbc in _dl_start_user () from /lib/ld64.so.1 |
This is fragile, but I don't really see a better way. Maybe add a while (x) loop around the allocation in case one is not enough?
Btw, why does allocating (1<<40) - (1ULL << 30) fail?