This is an archive of the discontinued LLVM Phabricator instance.

[Sanitizers] Secondary allocator respects allocator_may_return_null=1.
ClosedPublic

Authored by alekseyshl on Jun 15 2017, 9:55 AM.

Details

Summary

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.

Diff Detail

Repository
rL LLVM

Event Timeline

alekseyshl created this revision.Jun 15 2017, 9:55 AM
kcc added a subscriber: kcc.Jun 15 2017, 10:46 AM

Code LGTM. What about a test?

In D34243#781428, @kcc wrote:

Code LGTM. What about a test?

I have not figured out a reliable way to test mmap's out of memory condition, especially for 64 bits.

Do you want me to change that for the Scudo secondary as well, or can you bundle it with this?

Do you want me to change that for the Scudo secondary as well, or can you bundle it with this?

Forget that, apparently we are already doing it!

  • Adding OOM test.
eugenis added inline comments.Jun 15 2017, 4:03 PM
test/asan/TestCases/Linux/allocator_oom_test.cc
45 ↗(On Diff #102738)

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?

alekseyshl added inline comments.Jun 15 2017, 4:16 PM
test/asan/TestCases/Linux/allocator_oom_test.cc
45 ↗(On Diff #102738)

Because of "ulimit -v 22024290304" (there's quite a lot less than 1T memory left after all internal ASan allocations).

alekseyshl marked 2 inline comments as done.Jun 16 2017, 11:14 AM

Are we ok with this change?

kcc accepted this revision.Jun 16 2017, 11:17 AM

LGTM

This revision is now accepted and ready to land.Jun 16 2017, 11:17 AM
eugenis accepted this revision.Jun 16 2017, 11:33 AM
This revision was automatically updated to reflect the committed changes.
rnk added a subscriber: rnk.Jun 16 2017, 12:55 PM

Can you update the OOM message in the windows tests? http://lab.llvm.org:8011/builders/sanitizer-windows/builds/12993

alekseyshl added a comment.EditedJun 16 2017, 1:10 PM
In D34243#782636, @rnk wrote:

Can you update the OOM message in the windows tests? http://lab.llvm.org:8011/builders/sanitizer-windows/builds/12993

D34292

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
alekseyshl added a comment.EditedJun 20 2017, 12:06 PM

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

D34414 should resolve it and sorry for the trouble!