`memory_manager::alloc` should return error on OOM

[wks]

TODO:

• Make memory_manager::alloc and memory_manager::alloc_with_options return Result<Address, AllocError>.
  • Make them return error when OOM happens, even when at a safe point.
• Write in the documentation that Collection::out_of_memory will return.
• Refactor the allocation code (specifically Allocator::alloc_once_inline) for the changed APIs mentioned above.

The JikesRVM legacy

Our memory allocation architecture is ported from JikesRVM. In JikesRVM, MemoryManager.allocateSpace never returns null, even in the case of OOM. When OOM happens, MMTk calls Collection.outOfMemory(). The VM implements this method by throwing an exception.

public class Collection extends org.mmtk.vm.Collection {
  @Override
  @UninterruptibleNoWarn
  public void outOfMemory() {
    throw RVMThread.getOutOfMemoryError();
  }
}

This works because JikesRVM's (JIT and AoT) compilers compile both VM and MMTk code using the same ABI. The uniform stack layout and the uniform stack unwinding mechanism allow an exception to be thrown from Collection.outOfMemory() into MMTk frames, and then into VM frames, and then all the way to application frames, where the exception can be caught and handled.

The JikesRVM has always assumed that Collection.outOfMemory() never returns.

        if (failWithOOM) {
          VM.collection.outOfMemory();
          VM.assertions.fail("Not Reached"); // THIS IS UNREACHABLE!
          return Address.zero();
        }

There is no way to express in Java that a function never returns (like Rust's fn () -> !), so JikesRVM uses assertions. The return statement is there to make compilation successful.

It doesn't work in the Rust MMTk

In Rust MMTk, the VM binding cannot unwind the stack in Collection::out_of_memory, at least not in a portable way. When using the Rust MMTk, the VM, the MMTk core and the application code may have different ABIs. Take the OpenJDK binding for example.

• The VM and the C++ part of the VM binding are implemented in C++ and are AoT compiled.
• MMTk and the Rust part of the binding are implemented in Rust and are AoT compiled.
• The application code is provided as bytecode, and is either interpreted or JIT compiled.

If Collection::out_of_memory were to throw an exception directly, it will throw from C++ code (VM and VM binding) to Rust (VM binding and MMTk core) to JIT-compiled machine code. This crosses three languages. Rust doesn't have the concept of exceptions (while panic!() is implemented with some form of stack unwinding), and C++ exceptions and Java exceptions are implemented in different ways.

The only safe way to transfer control back to the application is returning frame by frame out of memory_manager::alloc.

Proposed API changes

Allocation

First of all, memory_manager::alloc and memory_manager::alloc_with_options shall be able to return error values.

pub fn memory_manager::alloc(...) -> Result<Address, AllocationFailure> { ... }
pub fn memory_manager::alloc_with_options(...) -> Result<Address, AllocationFailure> { ... }

pub enum AllocationFailure {
    /// The memory has exhausted.  The VM binding should raise out-of-memory error to the application.
    OutOfMemory,
    /// The allocation is not at a safepiont, but the allocation could not be satisfied without a GC.
    WouldBlock,
}

Currently, these are the two possible errors the VM binding could get.

The caller of alloc should match against the Result<Address, AllocationFailure> and handle errors accordingly. Specifically, if it is Err(AllocationFailure::OutOfMemory), it should raise OOM exception.

The application code can be either interpreted or compiled. Handling errors in the interpreter is straightforward.

JIT-compiled code needs some tricks. First of all, the JIT-compiled code should use bump-pointer fast paths when possible. For the slow path, the VM binding is advised to wrap the raw memory_manager::alloc(...) -> Result<..., ...> into a function void* mmtk_alloc(...). It shall follow the C calling convention so that it is easy to emit code to call from JIT-compiled code to the runtime. When successful, it will simply return the pointer. When failed, there are two strategies.

1. Returning 0 to the JIT-compiled code, and generate a check instruction after each allocation slow path and branch to a code stub that throws OutOfMemoryError.
2. Modifying the return address before returning from void* mmtk_alloc(...) and use a return barrier to raise the exception.

Using return barrier can eliminate a check on the code path where the allocation is successful. But it is probably not that important because it is the slow path.

About the existing AllocationError

We currently have the AllocationError type which is currently used by Collection::out_of_memory

pub enum AllocationError {
    /// The specified heap size is too small for the given program to continue.
    HeapOutOfMemory,
    /// The OS is unable to mmap or acquire more memory. Critical error. MMTk expects the VM to
    /// abort if such an error is thrown.
    MmapOutOfMemory,
}

AllocationError::HeapOutOfMemory is equivalent to the AllocationFailure::OutOfMemory I proposed.

AllocationError::MmapOutOfMemory, as the doc says, is a critical error and should result in immediate VM termination.

There is no equivalent to AllocationFailure::WouldBlock.

We probably should let AllocationError and AllocationFailure to coexist because they are used by two different API functions and have different sets of values.

Collection::out_of_memory

We need to explicitly document that this function is expected to return.

Even though the VM binding cannot unwind the stack from within Collection::out_of_memory in a portable way, it still allows the VM binding to set thread-local states so that after returning from memory_manager::alloc, it can check the state and handle OOM errors. I (Kunshan) am not sure how useful this is, given that alloc is able to return Err(AllocationFailure::OutOfMemory), but we'd better keep it for a while just in case any VM actually needs that. For example, it can still panic fast when AllocationError::MmapOutOfMemory happens.

I am not sure if we should allow the VM binding to override Collection::out_of_memory and translate AllocationError::MmapOutOfMemory into a AllocationFailure::OutOfMemory to be returned from memory_manager::alloc. When mmap cannot allocate more memory, it doesn't mean the VM cannot continue. If the VM has pre-allocated OutOfMemoryError object instances, it can still unwind the stack (without stack trace or with limited stack trace) and let the application "limp" for a while and shut down gracefully.

Proposed refactoring

We need an InternalAllocationFailure type.

pub(crate) enum InternalAllocationFailure {
    BadRequest,
    Retry,
    WouldBlock,    
}

Space::acquire and its sub-functions Space::get_new_pages_and_initialize and Space::not_acquiring need to distinguish between two cases:

1. If it is at safepoint and it blocked for GC, it shall return Err(Retry).
2. If it is not at safepoint but GC is needed, it shall return Err(NeedGC).

All functions in the call chain to Space::acquire, such as BumpAllocator::acquire_block and ImmixSpace::get_clean_block, should forward that error to their callers such as ImmixAllocator::acquire_clean_block all the way up to Allocator::alloc_slow_inline. During this path, some functions may check for obvious allocation errors (Space::handle_obvious_oom_request). If that fails, it should return Err(BadRequest).

Allocator::alloc_slow_inline should match against the errors.

• When InternalAllocationFailure::BadRequest, it should immediately fail with OOM. (This fixes the problem Fix infinite loop if we return from Collection::out_of_memory #1473 is trying to solve.)
• When InternalAllocationFailure::WouldBlock, it should immediately return AllocationFailure::WouldBlock. (We don't need to check if we are at safepoint now because Space::acquire checked it for us.)
• When InternalAllocationFailure::Retry, it should loop and try allocating again. But if after an emergency collection it still returns Retry, it shall fail with OOM.

When OOM, it shall call Collection::out_of_memory (if AllocationOptions::allow_oom_call is true) and then return AllocationFailure::OutOfMemory.

Performance concerns

The VM should use bump pointer fast paths whenever possible, and avoid calling memory_manager::alloc for most of the allocations. This means all of the API changes and refactoring happen on the slow paths. We shouldn't see obvious performance change with plans that support bump-pointer allocation, which should be everything except MarkSweep and PageProtect.

Related issues

#1223 proposed introducing NonZeroAddress because successful allocations should never return Address::ZERO. It mentioned returning error states using None, while this PR proposes using Err(...).

But regardless whether we introduce NonZeroAddress, once we started using Result<Address, AllocationFailure> or Result<Address, InternalAllocationFailure>, we should stop checking against Address::ZERO and start using Err(...) to report errors.

[qinsoon]

I find this issue is missing a key point: the real importance is that whether a runtime can rewind Rust frames or not.

Many things discussed by the issue are actually unrelated, including

• C++/Rust is AOT compiled. Language code is JIT'd.
• C++ has exceptions, and Rust does not have exceptions.
• JikesRVM and old MMTk is written in the same language (Java) which use the same exception mechanism.
• C++ exceptions and Java exceptions are implemented differently.

As long as a runtime can rewind Rust frames, it is okay to throw exceptions from out_of_memory.

---

In practice, it is very common that a runtime is capable of throwing a language-level exception from its native runtime code (e.g. OpenJDK throws a Java exception from its C++ runtime, Julia throws a Julia exception from its C runtime). This means the runtimes can rewind the native runtime frames. Even in JikesRVM where we would think they don't need to throw from native code, some exceptions are from hardware exceptions, and JikesRVM generates Java exceptions in signal handlers. So JikesRVM is also capable of handling native frames during unwinding.

Rust intends to use the same ABI. Thus any runtime that is capable of rewind native frames can in practice rewind Rust frames. This is not guaranteed, but we haven't seen a counter example yet.

---

So I don't see good reasons to support the idea of forbidding out_of_memory to throw (and forcing alloc to return error).

[wks]

@qinsoon There are several problems of throwing exceptions across language boundaries.

• destructors
• noexcept and -fno-exceptions

Destructor

In C++, if an exception is thrown and caught across stack frames, it will call the destructors of local variables in intermediate frames. Objects such as std::string and std::vector will free their malloc buffers, and std::istream will close its underlying file. To implement this, the ABI allows language runtimes to provide "personality functions" to handle such things in language-specific ways. But this is not always reliable.

Here is an example. A runnable project is here: rustcppthrowtest.tar.gz

The C++ part:

#include <cstdio>

extern "C" void catcher(void (*callback)()) {
    try {
        printf("[catcher] Calling rust_in_the_middle...\n");
        callback();
        printf("[catcher] Returned from rust_in_the_middle.\n");
    } catch (const int& exc) {
        printf("[cathcer] caught int exception from rust_in_the_middle: %d\n", exc);
    }
    return;
}

extern "C" void thrower() {
    printf("[thrower] Throwing exception...\n");
    throw 42;
}

catcher will call a callback provided by Rust code, and callback will then call thrower().

The Rust part:

unsafe extern "C" {
    unsafe fn thrower();
    unsafe fn catcher(callback: extern "C" fn());
}

struct DroppableResource {
    value: i32,
}

impl Drop for DroppableResource {
    fn drop(&mut self) {
        println!("[drop] Dropping DroppableResource. value: {}", self.value);
    }
}

pub extern "C" fn rust_in_the_middle() {
    println!("[rust_in_the_middle] Constructing DroppableResource...");
    let _dr = DroppableResource { value: 99 };

    if std::env::var("DONT_CALL").is_ok() {
        println!("[rust_in_the_middle] Will not call thrower.  Returning directly...");
    } else {
        println!("[rust_in_the_middle] Calling thrower...");
        unsafe {
            thrower();
        }
        println!("[rust_in_the_middle] Returned from thrower.");
    }
}

fn main() {
    println!("[main] Calling catcher...");
    unsafe {
        catcher(rust_in_the_middle);
    }
    println!("[main] Returned from catcher.");
}

main() calls catcher() which calls rust_in_the_middle which calls thrower() which throws an exception. rust_in_the_middle constructs a DroppableResource and calls thrower implemented in C++. The problem is, if you run the program, then DroppableResource::drop() will never be called.

$ cargo run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/debug/rustcppthrowtest`
[main] Calling catcher...
[catcher] Calling rust_in_the_middle...
[rust_in_the_middle] Constructing DroppableResource...
[rust_in_the_middle] Calling thrower...
[thrower] Throwing exception...
[cathcer] caught int exception from rust_in_the_middle: 42
[main] Returned from catcher.

But if rust_in_the_middle doesn't call thrower, then DroppableResource::drop() will be called normally.

$ DONT_CALL=1 cargo run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/debug/rustcppthrowtest`
[main] Calling catcher...
[catcher] Calling rust_in_the_middle...
[rust_in_the_middle] Constructing DroppableResource...
[rust_in_the_middle] Will not call thrower.  Returning directly...
[drop] Dropping DroppableResource. value: 99
[catcher] Returned from rust_in_the_middle.
[main] Returned from catcher.

This means two things

1. The Rust compiler does generate stack unwinding information (on Linux it is DWARF in the .eh_frame section), which is enough for debugging.
2. The C++ runtime is not aware of Rust-specific frame clean-up. I don't know the exact cause. Maybe the Rust compiler didn't generate metadata for dropping local variables during stack unwinding, or maybe it did but the C++ runtime is not aware of it.

But calling drop() is crucial for the correctness of Rust programs. If the exception-throwing mechanism is not able to call drop() properly, we must not use exceptions.

noexcept and -fno-exceptions

Some C++ functions are annotated with noexcept. Some C++ projects (notably Android) compiles the entire project with -fno-exceptions, effectively making every function noexcept.

When an exception is thrown across a noexcept function, the program will terminate immediately. Implementation-wise, such functions don't have exception-handling metadata (may have debugging metadata), and it is impossible to handle exceptions across those functions.

The case of OpenJDK

OpenJDK does raise Java exception in C++, but not via the C++ exception handling mechanism. But to do this, jni_Throw calls thread->set_pending_exception, but jni_Throw itself still returns 0 to indicate success. The exception will be raised in Java after returning from the C/C++ native function back to Java.

The point is, this mechanism doesn't depend on C++'s exception handling. OpenJDK runtime functions still return.

CollectedHeap::mem_allocate can return NULL

• to MemAllocator::mem_allocate_outside_tlab
• then to MemAllocator::mem_allocate_slow
• then to MemAllocator::mem_allocate
• then to MemAllocator::allocate

MemAllocator::allocate creates a local MemAllocator::Allocation instance. In the destructor Allocation::~Allocation, it calls MemAllocator::Allocation::check_out_of_memory. It checks the return value from MemAllocator::mem_allocate. If it is null, it will throw an exception, but it is not necessarily the user-visible OutOfMemoryError.

bool MemAllocator::Allocation::check_out_of_memory() {
  // ...
  if (obj() != nullptr) {
    return false;
  }

  const char* message = _overhead_limit_exceeded ? "GC overhead limit exceeded" : "Java heap space";
  if (!_thread->in_retryable_allocation()) {
    // ...
    oop exception = _overhead_limit_exceeded ?
        Universe::out_of_memory_error_gc_overhead_limit() :
        Universe::out_of_memory_error_java_heap();
    THROW_OOP_(exception, true);
  } else {
    THROW_OOP_(Universe::out_of_memory_error_retry(), true);
  }
}

Then MemAllocator::allocate returns

• to CollectedHeap::obj_allocate
• then to InstanceKlass::allocate_instance
• then to OptoRuntime::new_instance_C

new_instance_C will check for pending exception, and will call the deoptimizer if there is pending exception.

When using MMTk, the MMTk-side allocation slow path is wrapped in MMTkHeap::mem_allocate, and MMTkHeap is a subclass of CollectedHeap. So the same logic applies. If it is out of memory, it can return nullptr, too, and the OpenJDK runtime will handle the OutOfMemoryError.

[qinsoon]

Destructor is a valid concern. We will not expect the runtime to clean up Rust frames with destructors. We should understand how it may affect us. It is possible that at the point of out_of_memory, we don't have anything on the stacks that require Drop to clean up. Alternatively, we could try to avoid Drop in certain code paths so those frames can just be collapsed without properly clean up.

noexcept seems unimportant to the discussion. It is just a way to de-feature/restrict the implementation language for various reasons (e.g. simplify control flows). If we avoid Drop in allocators, it is also a way to de-feature the implementation language.

We have seen runtimes that return from out_of_memory, and we have also seen runtimes that do not return from out_of_memory (Julia and JikesRVM). We better support both cases if possible.

[wks]

It's not just Drop. The execution of functions terminate prematurely if it is unwound by exception. As seen in the console output in #1475 (comment), the message "[rust_in_the_middle] Returned from thrower." is never printed. So even if we use manual resource management (e.g. pr.reserve_pages(pages) and pr.clear_request(pages_reserved) pair), the clean-up will still be skipped if the stack is unwound in the middle.

The reason why I mentioned noexcept is that some VMs (e.g. Android) have to raise OOM error after memory_manager::alloc returns instead of throwing C++ exceptions in side Collection::out_of_memory. Therefore it makes sense to enhance the memory_manager::alloc API by providing richer error info.

I still believe it is an error to throw C++ exceptions or use C's setjmp/longjmp inside Collection::out_of_memory because of missing destructor calls. We usually believe when OOM error is raised, the process should terminate immediately. For this reason, we may think it is benign to miss some destructor calls. But if the program tries to recover from OOM error, the process will stay in the inconsistent state, and fatal problems will eventually emerge.

Julia uses setjump/longjump to implement jl_throw_out_of_memory_error(), but it should be easy to avoid calling it in Collection::out_of_memory. We can add a check at the end of fn mmtk_alloc and call jl_throw_out_of_memory_error() when memory_manager::alloc returns null. Because there are no Rust frames between mmtk_alloc and the application, and mmtk_alloc itself doesn't have any clean-up to do, doing longjmp from there should be safe.

It is similar for JikesRVM.

[qinsoon]

The execution of functions terminate prematurely if it is unwound by exception. As seen in the console output in #1475 (comment), the message "[rust_in_the_middle] Returned from thrower." is never printed. So even if we use manual resource management (e.g. pr.reserve_pages(pages) and pr.clear_request(pages_reserved) pair), the clean-up will still be skipped if the stack is unwound in the middle.

Whatever should be executed after its return will not be executed. The pair of pr.reserve_pages(pages) and pr.clear_request(pages_reserved) is not an issue -- we should deal with them properly before calling a function that may not return.

I agree on destructor/drop as those are implicit, and may execute or miss without us noticing them.

I still believe it is an error to throw C++ exceptions or use C's setjmp/longjmp inside Collection::out_of_memory because of missing destructor calls.

If there is no missing destructor call, there is no error. We should verify how the current code base behave, and if we could do any refactoring to avoid it.

[qinsoon]

I got Codex to write a script to check all the callers of out_of_memory, and see if there is any drop that may be skipped if out_of_memory does not return. The scripts parses MIR and check for drops in potential callers of out_of_memory.

The results below suggests there are 5 callers that have Drop -- all of them are related with Space::get_new_pages_and_initialize and handle_mmap_error. The types that are Drop are Mutex and MmapError. However, in those cases, we call out_of_memory with MmapError which we do not expect out_of_memory to return. So those are benign.

The script can be found in #1477. It is just a demonstration that we could systematically find violations to drop, and we could potentially support bindings that do not return from out_of_memory.

---

The following is the logs from the script:

Direct out_of_memory callsites:
  SAFE allocator::Allocator::alloc_slow_inline @ MIR line 113878 calls <Self as allocator::Allocator>::out_of_memory
  SAFE allocator::Allocator::handle_obvious_oom_request @ MIR line 112941 calls <Self as allocator::Allocator>::out_of_memory
  SAFE allocator::Allocator::out_of_memory @ MIR line 112972 calls <::VMCollection as collection::Collection>::out_of_memory
  SAFE util::os::memory::OSMemory::handle_mmap_error::{closure#0} @ MIR line 186960 calls <::VMCollection as collection::Collection>::out_of_memory

Reachable caller edges:
  SAFE alloc_slow @ MIR line 49605 calls <mutator_context::Mutator as mutator_context::MutatorContext>::alloc_slow
    resolved callees: alloc_slow, mutator_context::<impl at src/plan/mutator_context.rs:180:1: 180:55>::alloc_slow
  SAFE alloc_slow_with_options @ MIR line 49623 calls <mutator_context::Mutator as mutator_context::MutatorContext>::alloc_slow_with_options
    resolved callees: alloc_slow_with_options, mutator_context::<impl at src/plan/mutator_context.rs:180:1: 180:55>::alloc_slow_with_options
  SAFE alloc_with_options @ MIR line 49588 calls <mutator_context::Mutator as mutator_context::MutatorContext>::alloc_with_options
    resolved callees: alloc_with_options, mutator_context::<impl at src/plan/mutator_context.rs:180:1: 180:55>::alloc_with_options
  SAFE allocator::Allocator::alloc_slow @ MIR line 113042 calls <Self as allocator::Allocator>::alloc_slow_inline
    resolved callees: allocator::Allocator::alloc_slow_inline
  SAFE allocator::Allocator::alloc_slow_inline @ MIR line 113454 calls <Self as allocator::Allocator>::alloc_slow_once_precise_stress
    resolved callees: allocator::Allocator::alloc_slow_once_precise_stress, bumpallocator::<impl at src/util/alloc/bumpallocator.rs:84:1: 84:56>::alloc_slow_once_precise_stress, free_list_allocator::<impl at src/util/alloc/free_list_allocator.rs:35:1: 35:60>::alloc_slow_once_precise_stress, immix_allocator::<impl at src/util/alloc/immix_allocator.rs:48:1: 48:57>::alloc_slow_once_precise_stress, markcompact_allocator::<impl at src/util/alloc/markcompact_allocator.rs:32:1: 32:63>::alloc_slow_once_precise_stress
  SAFE allocator::Allocator::alloc_slow_inline @ MIR line 113458 calls <Self as allocator::Allocator>::alloc_slow_once_traced
    resolved callees: allocator::Allocator::alloc_slow_once_traced
  SAFE allocator::Allocator::alloc_slow_inline @ MIR line 113878 calls <Self as allocator::Allocator>::out_of_memory
    resolved callees: allocator::Allocator::out_of_memory
  SAFE allocator::Allocator::alloc_slow_once_precise_stress @ MIR line 114396 calls <Self as allocator::Allocator>::alloc_slow_once_traced
    resolved callees: allocator::Allocator::alloc_slow_once_traced
  SAFE allocator::Allocator::alloc_slow_once_traced @ MIR line 114262 calls <Self as allocator::Allocator>::alloc_slow_once
    resolved callees: bumpallocator::<impl at src/util/alloc/bumpallocator.rs:84:1: 84:56>::alloc_slow_once, free_list_allocator::<impl at src/util/alloc/free_list_allocator.rs:35:1: 35:60>::alloc_slow_once, immix_allocator::<impl at src/util/alloc/immix_allocator.rs:48:1: 48:57>::alloc_slow_once, large_object_allocator::<impl at src/util/alloc/large_object_allocator.rs:23:1: 23:63>::alloc_slow_once, malloc_allocator::<impl at src/util/alloc/malloc_allocator.rs:23:1: 23:58>::alloc_slow_once, markcompact_allocator::<impl at src/util/alloc/markcompact_allocator.rs:32:1: 32:63>::alloc_slow_once
  SAFE allocator::Allocator::alloc_slow_with_options @ MIR line 113077 calls <Self as allocator::Allocator>::alloc_slow
    resolved callees: allocator::Allocator::alloc_slow
  SAFE allocator::Allocator::alloc_with_options @ MIR line 113017 calls <Self as allocator::Allocator>::alloc
    resolved callees: bumpallocator::<impl at src/util/alloc/bumpallocator.rs:84:1: 84:56>::alloc, free_list_allocator::<impl at src/util/alloc/free_list_allocator.rs:35:1: 35:60>::alloc, immix_allocator::<impl at src/util/alloc/immix_allocator.rs:48:1: 48:57>::alloc, large_object_allocator::<impl at src/util/alloc/large_object_allocator.rs:23:1: 23:63>::alloc, malloc_allocator::<impl at src/util/alloc/malloc_allocator.rs:23:1: 23:58>::alloc, markcompact_allocator::<impl at src/util/alloc/markcompact_allocator.rs:32:1: 32:63>::alloc
  SAFE allocator::Allocator::handle_obvious_oom_request @ MIR line 112941 calls <Self as allocator::Allocator>::out_of_memory
    resolved callees: allocator::Allocator::out_of_memory
  SAFE bumpallocator::<impl at src/util/alloc/bumpallocator.rs:176:1: 176:38>::acquire_block @ MIR line 118381 calls <bumpallocator::BumpAllocator as allocator::Allocator>::handle_obvious_oom_request
    resolved callees: allocator::Allocator::handle_obvious_oom_request
  SAFE bumpallocator::<impl at src/util/alloc/bumpallocator.rs:176:1: 176:38>::acquire_block @ MIR line 118417 calls <dyn space::Space as space::Space>::acquire
    resolved callees: lockfreeimmortalspace::<impl at src/policy/lockfreeimmortalspace.rs:103:1: 103:60>::acquire, space::Space::acquire
  SAFE bumpallocator::<impl at src/util/alloc/bumpallocator.rs:176:1: 176:38>::acquire_block @ MIR line 118531 calls <bumpallocator::BumpAllocator as allocator::Allocator>::alloc
    resolved callees: bumpallocator::<impl at src/util/alloc/bumpallocator.rs:84:1: 84:56>::alloc
  SAFE bumpallocator::<impl at src/util/alloc/bumpallocator.rs:176:1: 176:38>::acquire_block @ MIR line 118543 calls <bumpallocator::BumpAllocator as allocator::Allocator>::alloc_slow_once_precise_stress
    resolved callees: allocator::Allocator::alloc_slow_once_precise_stress, bumpallocator::<impl at src/util/alloc/bumpallocator.rs:84:1: 84:56>::alloc_slow_once_precise_stress
  SAFE bumpallocator::<impl at src/util/alloc/bumpallocator.rs:84:1: 84:56>::alloc @ MIR line 117534 calls <bumpallocator::BumpAllocator as allocator::Allocator>::alloc_slow
    resolved callees: allocator::Allocator::alloc_slow
  SAFE bumpallocator::<impl at src/util/alloc/bumpallocator.rs:84:1: 84:56>::alloc_slow_once @ MIR line 117842 calls bumpallocator::BumpAllocator::acquire_block
    resolved callees: bumpallocator::<impl at src/util/alloc/bumpallocator.rs:176:1: 176:38>::acquire_block
  SAFE bumpallocator::<impl at src/util/alloc/bumpallocator.rs:84:1: 84:56>::alloc_slow_once_precise_stress @ MIR line 117987 calls bumpallocator::BumpAllocator::acquire_block
    resolved callees: bumpallocator::<impl at src/util/alloc/bumpallocator.rs:176:1: 176:38>::acquire_block
  SAFE bumpallocator::<impl at src/util/alloc/bumpallocator.rs:84:1: 84:56>::alloc_slow_once_precise_stress @ MIR line 118055 calls bumpallocator::BumpAllocator::acquire_block
    resolved callees: bumpallocator::<impl at src/util/alloc/bumpallocator.rs:176:1: 176:38>::acquire_block
  SAFE copy::<impl at src/util/copy/mod.rs:65:1: 65:44>::alloc_copy @ MIR line 128528 calls <CopySpaceCopyContext as PolicyCopyContext>::alloc_copy
    resolved callees: copyspace::<impl at src/policy/copyspace.rs:327:1: 327:67>::alloc_copy
  SAFE copy::<impl at src/util/copy/mod.rs:65:1: 65:44>::alloc_copy @ MIR line 128537 calls <immixspace::ImmixCopyContext as PolicyCopyContext>::alloc_copy
    resolved callees: immixspace::<impl at src/policy/immix/immixspace.rs:1083:1: 1083:63>::alloc_copy
  SAFE copy::<impl at src/util/copy/mod.rs:65:1: 65:44>::alloc_copy @ MIR line 128546 calls <immixspace::ImmixHybridCopyContext as PolicyCopyContext>::alloc_copy
    resolved callees: immixspace::<impl at src/policy/immix/immixspace.rs:1130:1: 1130:69>::alloc_copy
  SAFE copyspace::<impl at src/policy/copyspace.rs:327:1: 327:67>::alloc_copy @ MIR line 18747 calls <bumpallocator::BumpAllocator as allocator::Allocator>::alloc
    resolved callees: bumpallocator::<impl at src/util/alloc/bumpallocator.rs:84:1: 84:56>::alloc
  SAFE free_list_allocator::<impl at src/util/alloc/free_list_allocator.rs:130:1: 130:42>::acquire_global_block @ MIR line 124790 calls native_ms::global::MarkSweepSpace::acquire_block
    resolved callees: native_ms::global::<impl at src/policy/marksweepspace/native_ms/global.rs:293:1: 293:39>::acquire_block
  SAFE free_list_allocator::<impl at src/util/alloc/free_list_allocator.rs:130:1: 130:42>::find_free_block_stress::{closure#1} @ MIR line 123826 calls free_list_allocator::FreeListAllocator::acquire_global_block
    resolved callees: free_list_allocator::<impl at src/util/alloc/free_list_allocator.rs:130:1: 130:42>::acquire_global_block
  SAFE free_list_allocator::<impl at src/util/alloc/free_list_allocator.rs:35:1: 35:60>::alloc @ MIR line 123041 calls <free_list_allocator::FreeListAllocator as allocator::Allocator>::alloc_slow
    resolved callees: allocator::Allocator::alloc_slow
  SAFE free_list_allocator::<impl at src/util/alloc/free_list_allocator.rs:35:1: 35:60>::alloc_slow_once @ MIR line 123158 calls free_list_allocator::FreeListAllocator::acquire_global_block
    resolved callees: free_list_allocator::<impl at src/util/alloc/free_list_allocator.rs:130:1: 130:42>::acquire_global_block
  SAFE free_list_allocator::<impl at src/util/alloc/free_list_allocator.rs:35:1: 35:60>::alloc_slow_once_precise_stress @ MIR line 123304 calls free_list_allocator::FreeListAllocator::acquire_global_block
    resolved callees: free_list_allocator::<impl at src/util/alloc/free_list_allocator.rs:130:1: 130:42>::acquire_global_block
  SAFE immix_allocator::<impl at src/util/alloc/immix_allocator.rs:169:1: 169:39>::acquire_clean_block @ MIR line 121543 calls immixspace::ImmixSpace::get_clean_block
    resolved callees: immixspace::<impl at src/policy/immix/immixspace.rs:282:1: 282:35>::get_clean_block
  SAFE immix_allocator::<impl at src/util/alloc/immix_allocator.rs:169:1: 169:39>::acquire_clean_block @ MIR line 121710 calls <immix_allocator::ImmixAllocator as allocator::Allocator>::alloc
    resolved callees: immix_allocator::<impl at src/util/alloc/immix_allocator.rs:48:1: 48:57>::alloc
  SAFE immix_allocator::<impl at src/util/alloc/immix_allocator.rs:169:1: 169:39>::alloc_slow_hot @ MIR line 120755 calls <immix_allocator::ImmixAllocator as allocator::Allocator>::alloc_slow_inline
    resolved callees: allocator::Allocator::alloc_slow_inline
  SAFE immix_allocator::<impl at src/util/alloc/immix_allocator.rs:169:1: 169:39>::alloc_slow_hot @ MIR line 120759 calls <immix_allocator::ImmixAllocator as allocator::Allocator>::alloc
    resolved callees: immix_allocator::<impl at src/util/alloc/immix_allocator.rs:48:1: 48:57>::alloc
  SAFE immix_allocator::<impl at src/util/alloc/immix_allocator.rs:169:1: 169:39>::alloc_slow_hot @ MIR line 120763 calls <immix_allocator::ImmixAllocator as allocator::Allocator>::alloc_slow_inline
    resolved callees: allocator::Allocator::alloc_slow_inline
  SAFE immix_allocator::<impl at src/util/alloc/immix_allocator.rs:169:1: 169:39>::overflow_alloc @ MIR line 120515 calls <immix_allocator::ImmixAllocator as allocator::Allocator>::alloc_slow_inline
    resolved callees: allocator::Allocator::alloc_slow_inline
  SAFE immix_allocator::<impl at src/util/alloc/immix_allocator.rs:48:1: 48:57>::alloc @ MIR line 119210 calls immix_allocator::ImmixAllocator::overflow_alloc
    resolved callees: immix_allocator::<impl at src/util/alloc/immix_allocator.rs:169:1: 169:39>::overflow_alloc
  SAFE immix_allocator::<impl at src/util/alloc/immix_allocator.rs:48:1: 48:57>::alloc @ MIR line 119214 calls immix_allocator::ImmixAllocator::alloc_slow_hot
    resolved callees: immix_allocator::<impl at src/util/alloc/immix_allocator.rs:169:1: 169:39>::alloc_slow_hot
  SAFE immix_allocator::<impl at src/util/alloc/immix_allocator.rs:48:1: 48:57>::alloc_slow_once @ MIR line 119540 calls immix_allocator::ImmixAllocator::acquire_clean_block
    resolved callees: immix_allocator::<impl at src/util/alloc/immix_allocator.rs:169:1: 169:39>::acquire_clean_block
  SAFE immix_allocator::<impl at src/util/alloc/immix_allocator.rs:48:1: 48:57>::alloc_slow_once_precise_stress @ MIR line 119852 calls immix_allocator::ImmixAllocator::acquire_clean_block
    resolved callees: immix_allocator::<impl at src/util/alloc/immix_allocator.rs:169:1: 169:39>::acquire_clean_block
  SAFE immix_allocator::<impl at src/util/alloc/immix_allocator.rs:48:1: 48:57>::alloc_slow_once_precise_stress @ MIR line 119965 calls immix_allocator::ImmixAllocator::acquire_clean_block
    resolved callees: immix_allocator::<impl at src/util/alloc/immix_allocator.rs:169:1: 169:39>::acquire_clean_block
  SAFE immix_allocator::<impl at src/util/alloc/immix_allocator.rs:48:1: 48:57>::alloc_slow_once_precise_stress @ MIR line 120013 calls <immix_allocator::ImmixAllocator as allocator::Allocator>::alloc
    resolved callees: immix_allocator::<impl at src/util/alloc/immix_allocator.rs:48:1: 48:57>::alloc
  SAFE immixspace::<impl at src/policy/immix/immixspace.rs:1083:1: 1083:63>::alloc_copy @ MIR line 26622 calls <immix_allocator::ImmixAllocator as allocator::Allocator>::alloc
    resolved callees: immix_allocator::<impl at src/util/alloc/immix_allocator.rs:48:1: 48:57>::alloc
  SAFE immixspace::<impl at src/policy/immix/immixspace.rs:1130:1: 1130:69>::alloc_copy @ MIR line 26764 calls <immix_allocator::ImmixAllocator as allocator::Allocator>::alloc
    resolved callees: immix_allocator::<impl at src/util/alloc/immix_allocator.rs:48:1: 48:57>::alloc
  SAFE immixspace::<impl at src/policy/immix/immixspace.rs:1130:1: 1130:69>::alloc_copy @ MIR line 26769 calls <immix_allocator::ImmixAllocator as allocator::Allocator>::alloc
    resolved callees: immix_allocator::<impl at src/util/alloc/immix_allocator.rs:48:1: 48:57>::alloc
  SAFE immixspace::<impl at src/policy/immix/immixspace.rs:282:1: 282:35>::get_clean_block @ MIR line 24201 calls <immixspace::ImmixSpace as space::Space>::acquire
    resolved callees: space::Space::acquire
  SAFE large_object_allocator::<impl at src/util/alloc/large_object_allocator.rs:23:1: 23:63>::alloc @ MIR line 118720 calls <large_object_allocator::LargeObjectAllocator as allocator::Allocator>::alloc_slow
    resolved callees: allocator::Allocator::alloc_slow
  SAFE large_object_allocator::<impl at src/util/alloc/large_object_allocator.rs:23:1: 23:63>::alloc_slow_once @ MIR line 118787 calls <large_object_allocator::LargeObjectAllocator as allocator::Allocator>::handle_obvious_oom_request
    resolved callees: allocator::Allocator::handle_obvious_oom_request
  SAFE large_object_allocator::<impl at src/util/alloc/large_object_allocator.rs:23:1: 23:63>::alloc_slow_once @ MIR line 118811 calls LargeObjectSpace::allocate_pages
    resolved callees: largeobjectspace::<impl at src/policy/largeobjectspace.rs:276:1: 276:41>::allocate_pages
  SAFE largeobjectspace::<impl at src/policy/largeobjectspace.rs:276:1: 276:41>::allocate_pages @ MIR line 30393 calls <LargeObjectSpace as space::Space>::acquire
    resolved callees: space::Space::acquire
  SAFE malloc_allocator::<impl at src/util/alloc/malloc_allocator.rs:23:1: 23:58>::alloc @ MIR line 118866 calls <malloc_allocator::MallocAllocator as allocator::Allocator>::alloc_slow
    resolved callees: allocator::Allocator::alloc_slow
  SAFE markcompact_allocator::<impl at src/util/alloc/markcompact_allocator.rs:32:1: 32:63>::alloc @ MIR line 126511 calls <bumpallocator::BumpAllocator as allocator::Allocator>::alloc
    resolved callees: bumpallocator::<impl at src/util/alloc/bumpallocator.rs:84:1: 84:56>::alloc
  SAFE markcompact_allocator::<impl at src/util/alloc/markcompact_allocator.rs:32:1: 32:63>::alloc_slow_once @ MIR line 126596 calls <bumpallocator::BumpAllocator as allocator::Allocator>::alloc_slow_once
    resolved callees: bumpallocator::<impl at src/util/alloc/bumpallocator.rs:84:1: 84:56>::alloc_slow_once
  SAFE markcompact_allocator::<impl at src/util/alloc/markcompact_allocator.rs:32:1: 32:63>::alloc_slow_once_precise_stress @ MIR line 126668 calls <bumpallocator::BumpAllocator as allocator::Allocator>::alloc_slow_once_precise_stress
    resolved callees: allocator::Allocator::alloc_slow_once_precise_stress, bumpallocator::<impl at src/util/alloc/bumpallocator.rs:84:1: 84:56>::alloc_slow_once_precise_stress
  SAFE memory_manager::alloc @ MIR line 49565 calls <mutator_context::Mutator as mutator_context::MutatorContext>::alloc
    resolved callees: memory_manager::alloc, mutator_context::<impl at src/plan/mutator_context.rs:180:1: 180:55>::alloc
  SAFE mutator_context::<impl at src/plan/mutator_context.rs:180:1: 180:55>::alloc @ MIR line 57062 calls <dyn allocator::Allocator as allocator::Allocator>::alloc
    resolved callees: bumpallocator::<impl at src/util/alloc/bumpallocator.rs:84:1: 84:56>::alloc, free_list_allocator::<impl at src/util/alloc/free_list_allocator.rs:35:1: 35:60>::alloc, immix_allocator::<impl at src/util/alloc/immix_allocator.rs:48:1: 48:57>::alloc, large_object_allocator::<impl at src/util/alloc/large_object_allocator.rs:23:1: 23:63>::alloc, malloc_allocator::<impl at src/util/alloc/malloc_allocator.rs:23:1: 23:58>::alloc, markcompact_allocator::<impl at src/util/alloc/markcompact_allocator.rs:32:1: 32:63>::alloc
  SAFE mutator_context::<impl at src/plan/mutator_context.rs:180:1: 180:55>::alloc_slow @ MIR line 57207 calls <dyn allocator::Allocator as allocator::Allocator>::alloc_slow
    resolved callees: allocator::Allocator::alloc_slow
  SAFE mutator_context::<impl at src/plan/mutator_context.rs:180:1: 180:55>::alloc_slow_with_options @ MIR line 57280 calls <dyn allocator::Allocator as allocator::Allocator>::alloc_slow_with_options
    resolved callees: allocator::Allocator::alloc_slow_with_options
  SAFE mutator_context::<impl at src/plan/mutator_context.rs:180:1: 180:55>::alloc_with_options @ MIR line 57135 calls <dyn allocator::Allocator as allocator::Allocator>::alloc_with_options
    resolved callees: allocator::Allocator::alloc_with_options
  SAFE native_ms::global::<impl at src/policy/marksweepspace/native_ms/global.rs:293:1: 293:39>::acquire_block @ MIR line 47023 calls <native_ms::global::MarkSweepSpace as space::Space>::acquire
    resolved callees: space::Space::acquire
  SAFE space::Space::acquire @ MIR line 3655 calls <Self as space::Space>::get_new_pages_and_initialize
    resolved callees: space::Space::get_new_pages_and_initialize
  UNSAFE space::Space::get_new_pages_and_initialize @ MIR line 4314 calls <{closure@src/policy/space.rs:143:20: 143:22} as std::ops::Fn>::call
    resolved callees: space::Space::get_new_pages_and_initialize::{closure#0}
    cleanup drops: bb83@4607: drop(_6) -> [return: bb82, unwind terminate(cleanup)]; [lock | std::sync::MutexGuard<'_, ()>]
  UNSAFE space::Space::get_new_pages_and_initialize @ MIR line 4341 calls <{closure@src/policy/space.rs:143:20: 143:22} as std::ops::Fn>::call
    resolved callees: space::Space::get_new_pages_and_initialize::{closure#0}
    cleanup drops: bb83@4607: drop(_6) -> [return: bb82, unwind terminate(cleanup)]; [lock | std::sync::MutexGuard<'_, ()>]
  SAFE space::Space::get_new_pages_and_initialize::{closure#0} @ MIR line 4924 calls <Linux as util::os::memory::OSMemory>::handle_mmap_error
    resolved callees: util::os::memory::OSMemory::handle_mmap_error
  UNSAFE util::os::memory::OSMemory::handle_mmap_error @ MIR line 186720 calls <{closure@src/util/os/memory.rs:89:32: 89:34} as std::ops::Fn>::call
    resolved callees: util::os::memory::OSMemory::handle_mmap_error::{closure#0}
    cleanup drops: bb32@186788: drop(_1) -> [return: bb33, unwind terminate(cleanup)]; [mmap_error | util::os::memory::MmapError]
  UNSAFE util::os::memory::OSMemory::handle_mmap_error @ MIR line 186739 calls <{closure@src/util/os/memory.rs:89:32: 89:34} as std::ops::Fn>::call
    resolved callees: util::os::memory::OSMemory::handle_mmap_error::{closure#0}
    cleanup drops: bb32@186788: drop(_1) -> [return: bb33, unwind terminate(cleanup)]; [mmap_error | util::os::memory::MmapError]
  UNSAFE util::os::memory::OSMemory::handle_mmap_error @ MIR line 186762 calls <{closure@src/util/os/memory.rs:89:32: 89:34} as std::ops::Fn>::call
    resolved callees: util::os::memory::OSMemory::handle_mmap_error::{closure#0}
    cleanup drops: bb32@186788: drop(_1) -> [return: bb33, unwind terminate(cleanup)]; [mmap_error | util::os::memory::MmapError]

Reachable in-crate functions: 49
  alloc_slow
  alloc_slow_with_options
  alloc_with_options
  allocator::Allocator::alloc_slow
  allocator::Allocator::alloc_slow_inline
  allocator::Allocator::alloc_slow_once_precise_stress
  allocator::Allocator::alloc_slow_once_traced
  allocator::Allocator::alloc_slow_with_options
  allocator::Allocator::alloc_with_options
  allocator::Allocator::handle_obvious_oom_request
  allocator::Allocator::out_of_memory
  bumpallocator::<impl at src/util/alloc/bumpallocator.rs:176:1: 176:38>::acquire_block
  bumpallocator::<impl at src/util/alloc/bumpallocator.rs:84:1: 84:56>::alloc
  bumpallocator::<impl at src/util/alloc/bumpallocator.rs:84:1: 84:56>::alloc_slow_once
  bumpallocator::<impl at src/util/alloc/bumpallocator.rs:84:1: 84:56>::alloc_slow_once_precise_stress
  copy::<impl at src/util/copy/mod.rs:65:1: 65:44>::alloc_copy
  copyspace::<impl at src/policy/copyspace.rs:327:1: 327:67>::alloc_copy
  free_list_allocator::<impl at src/util/alloc/free_list_allocator.rs:130:1: 130:42>::acquire_global_block
  free_list_allocator::<impl at src/util/alloc/free_list_allocator.rs:130:1: 130:42>::find_free_block_stress::{closure#1}
  free_list_allocator::<impl at src/util/alloc/free_list_allocator.rs:35:1: 35:60>::alloc
  free_list_allocator::<impl at src/util/alloc/free_list_allocator.rs:35:1: 35:60>::alloc_slow_once
  free_list_allocator::<impl at src/util/alloc/free_list_allocator.rs:35:1: 35:60>::alloc_slow_once_precise_stress
  immix_allocator::<impl at src/util/alloc/immix_allocator.rs:169:1: 169:39>::acquire_clean_block
  immix_allocator::<impl at src/util/alloc/immix_allocator.rs:169:1: 169:39>::alloc_slow_hot
  immix_allocator::<impl at src/util/alloc/immix_allocator.rs:169:1: 169:39>::overflow_alloc
  immix_allocator::<impl at src/util/alloc/immix_allocator.rs:48:1: 48:57>::alloc
  immix_allocator::<impl at src/util/alloc/immix_allocator.rs:48:1: 48:57>::alloc_slow_once
  immix_allocator::<impl at src/util/alloc/immix_allocator.rs:48:1: 48:57>::alloc_slow_once_precise_stress
  immixspace::<impl at src/policy/immix/immixspace.rs:1083:1: 1083:63>::alloc_copy
  immixspace::<impl at src/policy/immix/immixspace.rs:1130:1: 1130:69>::alloc_copy
  immixspace::<impl at src/policy/immix/immixspace.rs:282:1: 282:35>::get_clean_block
  large_object_allocator::<impl at src/util/alloc/large_object_allocator.rs:23:1: 23:63>::alloc
  large_object_allocator::<impl at src/util/alloc/large_object_allocator.rs:23:1: 23:63>::alloc_slow_once
  largeobjectspace::<impl at src/policy/largeobjectspace.rs:276:1: 276:41>::allocate_pages
  malloc_allocator::<impl at src/util/alloc/malloc_allocator.rs:23:1: 23:58>::alloc
  markcompact_allocator::<impl at src/util/alloc/markcompact_allocator.rs:32:1: 32:63>::alloc
  markcompact_allocator::<impl at src/util/alloc/markcompact_allocator.rs:32:1: 32:63>::alloc_slow_once
  markcompact_allocator::<impl at src/util/alloc/markcompact_allocator.rs:32:1: 32:63>::alloc_slow_once_precise_stress
  memory_manager::alloc
  mutator_context::<impl at src/plan/mutator_context.rs:180:1: 180:55>::alloc
  mutator_context::<impl at src/plan/mutator_context.rs:180:1: 180:55>::alloc_slow
  mutator_context::<impl at src/plan/mutator_context.rs:180:1: 180:55>::alloc_slow_with_options
  mutator_context::<impl at src/plan/mutator_context.rs:180:1: 180:55>::alloc_with_options
  native_ms::global::<impl at src/policy/marksweepspace/native_ms/global.rs:293:1: 293:39>::acquire_block
  space::Space::acquire
  space::Space::get_new_pages_and_initialize
  space::Space::get_new_pages_and_initialize::{closure#0}
  util::os::memory::OSMemory::handle_mmap_error
  util::os::memory::OSMemory::handle_mmap_error::{closure#0}

FAIL: found 0 unsafe direct out_of_memory callsite(s) and 5 unsafe caller edge(s).

[qinsoon]

Kunshan pointed me to this Rust RFC: https://rust-lang.github.io/rfcs/2945-c-unwind-abi.html.

To me, the relavant part is that the RFC defines Plain Old Frame (POF, https://rust-lang.github.io/rfcs/2945-c-unwind-abi.html#plain-old-frames) for Rust, and defines that 1. deallocating non POF with C functions is explicitly undefined behavior, and 2. deallocating POF is undefined behavior for now but will have a separate RFC to define how to safely deallocating non-POF.

POFs do not contain any pending destructors (live Drop objects) or catch_unwind calls.

[wks]

The Rust documentation mentioned the behavior of stack unwinding in several sections.

• https://doc.rust-lang.org/reference/items/functions.html#unwinding
• https://doc.rust-lang.org/reference/panic.html#unwinding-across-ffi-boundaries

And there is an RFC https://rust-lang.github.io/rfcs/2945-c-unwind-abi.html

The main idea is that the behavior of stack unwinding and the cleaning up of Drop values depends on both the ABI of each function ("Rust" or extern "C") and the mechanism of unwinding (Rust's panic!(), C++'s throw, or C's longjmp).

I did more experiment. Here is the modified project:

rustcppthrowtest-0.2.0.tar.gz

It added command line options to control

• The mechanism of unwinding (panic, sjlj, cpp)
• The ABI of the function holding the Drop resource (c, rust)
• Whether the function that calls the throwing function is inlined. This has some very subtle effect.

The result is:

unwinding mechanism	res hold func ABI	inline call to throwing func	dropped?	how is the program terminated?
panic!()	Rust	any	yes	exited normally
panic!()	C	any	yes	thread caused non-unwinding panic. aborting.
setjmp/longjmp	any	any	no	exited normally
C++ catch/throw	any	false	yes	thread caused non-unwinding panic. aborting.
C++ catch/throw	any	true	no	thread caused non-unwinding panic. aborting.

In summary,

• Rust panic!() always drops the resource, but the resource-holding function must have Rust ABI, or it won't unwind.
• C's setjmp/longjmp never drops the resource.
• C++'s catch/throw is more subtle. Whether it drops the resource depends on inlining decisions of the compiler, and it never successfully reaches the catcher.

The lesson is that unwinding across Rust functions is unreliable at least. The user needs to be aware of all those details to do unwinding, but the user should use returning because the behavior is deterministic, and it is the obvious solution.

Checking the IR-level control flow for Drop is like checking if integer overflow leads to crash. In both C and Rust, integer overflow results in undefined behavior. Despite that, developers who don't understand undefined behavior attempt to use it for "security checks". See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475

if (input + value < 0) { // If overflow happens, it will be undefined behavior.
    report_overflow(); // The compiler is allowed to assume this line is unreachable and optimize it away.
}

But the right way to do it is avoiding undefined behavior completely.