Skip to content
7 changes: 7 additions & 0 deletions compiler-rt/lib/asan/asan_flags.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -240,6 +240,13 @@ void InitializeFlags() {

DisplayHelpMessages(&asan_parser);
ProcessFlags();

// TODO: Update other globals and data structures that may need to change
// after initialization due to new flags potentially being set changing after
// `__asan_default_options` is registered.
// See GH issue 'https://github.com/llvm/llvm-project/issues/117925' for
// details.
SetAllocatorMayReturnNull(common_flags()->allocator_may_return_null);
});

# if CAN_SANITIZE_UB
Expand Down
6 changes: 5 additions & 1 deletion compiler-rt/lib/sanitizer_common/sanitizer_allocator.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -85,8 +85,12 @@ static void NORETURN ReportInternalAllocatorOutOfMemory(uptr requested_size) {

void *InternalAlloc(uptr size, InternalAllocatorCache *cache, uptr alignment) {
void *p = RawInternalAlloc(size, cache, alignment);
if (UNLIKELY(!p))
if (UNLIKELY(!p)) {
if (AllocatorMayReturnNull()) {
return nullptr;
}
ReportInternalAllocatorOutOfMemory(size);
}
return p;
}

Expand Down
19 changes: 18 additions & 1 deletion compiler-rt/lib/sanitizer_common/sanitizer_win.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -164,7 +164,24 @@ void UnmapOrDie(void *addr, uptr size, bool raw_report) {
static void *ReturnNullptrOnOOMOrDie(uptr size, const char *mem_type,
const char *mmap_type) {
error_t last_error = GetLastError();
if (last_error == ERROR_NOT_ENOUGH_MEMORY)

// Assumption: VirtualAlloc is the last system call that was invoked before
// this method.
// VirtualAlloc emits one of 2 error codes when running out of memory
// 1. ERROR_NOT_ENOUGH_MEMORY:
// There's not enough memory to execute the command
// 2. ERROR_INVALID_PARAMETER:
// VirtualAlloc will return this if the request would allocate memory at an
// address exceeding or being very close to the maximum application address
// (the `lpMaximumApplicationAddress` field within the `SystemInfo` struct).
// This does not seem to be officially documented, but is corroborated here:
// https://stackoverflow.com/questions/45833674/why-does-virtualalloc-fail-for-lpaddress-greater-than-0x6ffffffffff

// Note - It's possible that 'ERROR_COMMITMENT_LIMIT' needs to be handled here
// as well. It is currently not handled due to the lack of a reproducer that
// induces the error code.
Comment on lines +180 to +182
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Funnily enough, we're applying a patch to add ERROR_COMMITMENT_LIMIT downstream. It was submitted as https://reviews.llvm.org/D130781 but never ended up being merged.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That looks reasonable to me. Want to send it again as a PR? I think we could merge that without a test case.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice. Please tag me on that PR if you end up opening it, @glandium. Can also assist in opening it if you don't find the cycles, I think the phabricator bug report suffices to me as well to just add it the check without a repro.

if (last_error == ERROR_NOT_ENOUGH_MEMORY ||
Copy link
Collaborator

@vitalybuka vitalybuka Dec 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems fine, CC @barcharcraz @zmodem

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems fine to me to.

last_error == ERROR_INVALID_PARAMETER)
return nullptr;
ReportMmapFailureAndDie(size, mem_type, mmap_type, last_error);
}
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
// RUN: %clangxx_asan -O0 %s -o %t
// RUN: %run %t 2>&1
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you need to pipe the output through FileCheck for the CHECK comment below to do anything.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, good catch, thanks for letting me know. I was somehow under the impression that the CHECK pattern was implicitly always checked. I merged the tests, based on your suggestion, so that address this issue as well.

// CHECK: Success

#include <cstdint>
#include <cstdio>
#include <cstdlib>
#include <limits>

// On Windows, flags configured through the user-defined function `__asan_default_options`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and allocator_may_return_null_limits.cpp are really variations of the same test. I wonder if they could be folded together?

For example, the __asan_default_options() definition could be guarded by an #ifdef and then you could run multiple invocations on the same file. Something like:

// RUN: %clangxx_asan -DASAN_DEFAULT_OPTIONS %s -o %t
// RUN: %run %t 2>&1 | FileCheck --check-prefix=RETURN_NULL
// RUN: %clangxx_asan %s -o %t
// RUN: %env_asan_opts=allocator_may_return_null=1 %run %t 2>&1 | FileCheck --check-prefix=RETURN_NULL
// RUN: %env_asan_opts=allocator_may_return_null=0 not %run %t 2>&1 | FileCheck --check-prefix=ABORT

Copy link
Contributor Author

@davidmrdavid davidmrdavid Dec 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, good idea! I actually had a local branch where I'm tackling #117925 more generally, and I had already combined the tests there. So I'm porting that over, here: ebc3d0d

// are suspected to not always be honored according to this GH issue:
// https://github.com/llvm/llvm-project/issues/117925
// This issue is resolved for the `allocator_may_return_null` flag, but not for all others.
// This test ensures we do not regress on `allocator_may_return_null` specifically.
extern "C" __declspec(dllexport) extern const char *__asan_default_options() {
return "allocator_may_return_null=1";
}

int main() {
// Attempt to allocate an excessive amount of memory, which should
// terminate the program unless `allocator_may_return_null` is set.
size_t max = std::numeric_limits<size_t>::max();

free(malloc(max));
printf("Success");
return 0;
}
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
// RUN: %clangxx_asan -O0 %s -o %t
// RUN: %env_asan_opts=allocator_may_return_null=0 not %run %t 2>&1 | FileCheck %s --check-prefix=CHECK1
// RUN: %env_asan_opts=allocator_may_return_null=1 %run %t 2>&1 | FileCheck %s --check-prefix=CHECK2

// CHECK1: exceeds maximum supported size
// CHECK1: ABORT

// CHECK2: Success

#include <cstdint>
#include <cstdio>
#include <cstdlib>
#include <limits>

int main() {
// Attempt to allocate an excessive amount of memory, which should
// terminate the program unless `allocator_may_return_null` is set.
size_t max = std::numeric_limits<size_t>::max();

free(malloc(max));
printf("Success");
return 0;
}
Loading