Rust 117 🦀 Exception Safety in Unsafe Rust and Abort-On-Panic Strategies - KandZ

⏱️ Estimated read: 13 min | |

Unsafe Rust code inherits a contract that safe code does not: it must maintain memory safety even when a panic unwinds through it. This is called minimal exception safety, and violating it produces undefined behavior. The second half of the problem is strategic: sometimes the right response to a potential panic is not to unwind at all, but to abort the process immediately. Rust supports both strategies, and knowing when to choose each is the difference between code that fails safely and code that silently corrupts memory.

Key point: In unsafe Rust, exception safety is not optional. A panic can unwind through code that temporarily holds invalid invariants, and if that code does not guard against the unwind, the result is undefined behavior. Abort-on-panic is the escape hatch when unwinding is too dangerous to attempt.

Why exception safety and abort strategies exist

The transient invariant problem. Unsafe code often creates states that are temporarily invalid. Vec::set_len might set the length to a value that exceeds the number of initialized elements, and the code then initializes those elements in a loop. If the loop panics—because a Clone implementation panics, for example—the Vec is left with an invalid length and uninitialized memory. If the Vec is dropped in that state, it reads uninitialized memory, which is undefined behavior . This is not a theoretical concern; the standard library’s push_all implementation was once vulnerable to exactly this pattern.

The guard pattern. The standard solution is a guard type that cleans up the transient state in its own Drop implementation. The guard is created before the invalid state is entered, and its destructor restores a safe state if a panic occurs. The Hole type in BinaryHeap::sift_up is an example: it removes an element from the heap, creates a “hole” where the element was, and restores the element in its Drop implementation regardless of whether the sift-up loop completes or panics .

The unwinding cost problem. Unwinding is expensive. It walks the stack, runs destructors, and performs bookkeeping. For programs that need small binaries or predictable performance, aborting on panic is an alternative. In Cargo.toml, panic = 'abort' disables unwinding entirely. When a panic occurs, the process terminates immediately without running destructors . The operating system reclaims memory, but no user code runs after the abort.

The kernel precedent. The Rust-for-Linux project builds with abort-on-panic. As Linus Torvalds noted, “Note that Rust panics in the kernel do not unwind” . This simplifies reasoning about unsafe code because destructors do not run during a panic. The trade-off is that recovery from panics is impossible, but in a kernel context, a panic is already a fatal event.

The trade-off. Minimal exception safety requires guard types and careful ordering in unsafe code. Abort-on-panic eliminates the need for exception safety entirely, but sacrifices recovery. The choice depends on whether the code can tolerate unwinding and whether the binary size or performance justifies the loss of recoverability.

a. Minimal exception safety in unsafe code

The Rustonomicon defines two levels of exception safety. Minimal exception safety means that unsafe code does not violate memory safety when a panic unwinds through it. Maximal exception safety means that the program behaves correctly after a panic. Only minimal exception safety is required .

The rule is straightforward: do not leave a value in an invalid state across a call to code that might panic. If the invalid state is unavoidable—because you need to initialize elements in a loop—use a guard that restores the safe state in its Drop implementation.

// Unsafe code with exception safety
impl<T: Clone> Vec<T> {
    fn push_all(&mut self, to_push: &[T]) {
        self.reserve(to_push.len());
        // Do not set_len until all elements are initialized.
        for x in to_push {
            self.push(x.clone()); // clone may panic; push is exception-safe
        }
    }
}

The unsafe version of push_all from the Rustonomicon sets len before the loop, then writes elements directly. If clone panics, len is wrong and the Vec contains uninitialized memory. The fix is to either update len every iteration or set it only after the loop completes . The safe version above avoids the problem entirely by using push, which maintains the invariant that len always reflects initialized elements.

The guard pattern is necessary when the unsafe operation cannot be expressed with safe methods. The Hole type demonstrates this: it mutably borrows the data, takes an element, and restores it in Drop. Even if the comparison or swap panics, the Hole‘s destructor runs during unwinding and restores the element, leaving the data structure in a valid state .

b. Abort-on-panic as a configuration strategy

The panic = 'abort' setting in Cargo.toml changes the behavior of every panic in the binary. Instead of unwinding, the runtime calls abort(), which terminates the process immediately. Destructors do not run. Memory is reclaimed by the operating system .

[profile.release]
panic = "abort"

This setting is appropriate in several scenarios. Embedded systems and kernels often cannot support unwinding because of code size or the complexity of stack unwinding in kernel context. Programs that need small binaries benefit from removing the unwinding tables and panic runtime. And in safety-critical systems, a fail-fast strategy—abort immediately rather than continue with potentially corrupted state—is often the correct behavior .

The libabort crate provides an abort function that is guaranteed to terminate the process without unwinding. Its documentation notes that for unsafe code, “if unsafe invariants have been violated, it may be unsafe to execute any code whatever and the abort must be immediate” . This is the extreme case: when the code is so compromised that running a panic hook or destructor might cause harm, an immediate abort is the only safe option.

The trade-off is that panic = 'abort' disables catch_unwind. There is no way to recover from a panic. If the program is a long-running service, this means a panic is fatal. For services that need to stay alive, unwinding—and catching panics at a boundary—is necessary.

c. Library-level drop flags and the abort decision

The moveit crate provides a library-level DropFlag for tracking whether a pinned value has been destroyed. This is the same conditional destruction problem that the compiler solves with internal drop flags, but it appears at the library level when implementing DerefMove types that separate storage from contents .

A DropFlag is a counter, not a boolean, because a single storage allocation might hold multiple objects. When a MoveRef is forgotten (via mem::forget), the destructor for the storage does not know that the contents were never destroyed. The DropFlag detects this. If the flag is not cleared, the storage must either be leaked (for heap storage) or the process must abort (for stack storage).

The reason for the abort is subtle. If a panic were used to signal the failure, the panic could be caught, and the stack location could be reused. Reusing stack storage that still contains a valid object whose destructor has not run would cause a double-drop or use-after-free. A panic is insufficient; the process must terminate .

This is a concrete example of when abort is not just a configuration choice but a safety requirement. The DropFlag API does not make the decision for you—it provides the tools (dec_and_check_if_died returns true when the counter reaches zero)—but the caller must ensure that a detected failure leads to a leak or an abort, never a panic.

Complete Example Session

# ============================================
# PART 1: UNSAFE CODE WITH A PANIC BOMB
# ============================================

// This code is NOT exception-safe.
// If clone panics, len is too large.
fn push_all<T: Clone>(vec: &mut Vec<T>, to_push: &[T]) {
    vec.reserve(to_push.len());
    unsafe {
        vec.set_len(vec.len() + to_push.len());
        // If clone panics, vec has uninitialized elements.
        for (i, x) in to_push.iter().enumerate() {
            vec.as_mut_ptr().add(i).write(x.clone());
        }
    }
}

# ============================================
# PART 2: FIXING WITH GUARD PATTERN
# ============================================

// A guard that restores the length on unwind.
struct LenGuard<'a, T> {
    vec: &'a mut Vec<T>,
    original_len: usize,
}

impl<T> Drop for LenGuard<'_, T> {
    fn drop(&mut self) {
        unsafe { self.vec.set_len(self.original_len); }
    }
}

fn push_all_guarded<T: Clone>(vec: &mut Vec<T>, to_push: &[T]) {
    vec.reserve(to_push.len());
    let guard = LenGuard { vec, original_len: vec.len() };
    for x in to_push {
        guard.vec.push(x.clone());
    }
    std::mem::forget(guard); // success: do not truncate
}

# ============================================
# PART 3: ABORT-ON-PANIC CONFIGURATION
# ============================================

// Cargo.toml
[profile.release]
panic = "abort"

# ============================================
# PART 4: DETECTING PANICKING STATE
# ============================================

use std::thread;

impl Drop for Guard {
    fn drop(&mut self) {
        if thread::panicking() {
            // Clean up minimally; do not panic.
            self.restore_invariant();
        } else {
            // Normal destruction path.
        }
    }
}

# ============================================
# PART 5: LIBRARY-LEVEL DROP FLAG
# ============================================

use moveit::drop_flag::{DropFlag, DroppingFlag};

let mut flag = DropFlag::new();
// Storage tracked by flag...
// If flag is not cleared, abort (stack) or leak (heap).

# ============================================
# PART 6: IMMEDIATE ABORT
# ============================================

// libabort::immediate_abort() never unwinds.
// Use when unsafe invariants are already violated.
// No destructors, no panic hook, no unwinding.

# ============================================
# PART 7: MUTEX POISONING
# ============================================

use std::sync::Mutex;

let mutex = Mutex::new(vec![1, 2, 3]);
// If a thread panics while holding the lock,
// the mutex is poisoned.
// Future locks return Err.
// This is maximal exception safety at work.

# ============================================
# PART 8: KERNEL-STYLE ABORT
# ============================================

// Linux kernel Rust builds with panic=abort.
// Destructors do not run on panic.
// Unsafe code does not need exception safety.
// Panics are fatal bugs.

# ============================================
# PART 9: THE COST OF UNWINDING
# ============================================

// Unwinding tables and destructors add binary size.
// panic=abort removes them.
// Binary size reduction can be significant.
// Performance is more predictable.

The nine parts above trace the landscape: the panic bomb in unsafe push_all, the guard pattern that fixes it, the Cargo.toml configuration for abort-on-panic, checking thread::panicking(), the moveit DropFlag, immediate abort via libabort, mutex poisoning as maximal exception safety, kernel-style abort, and the cost of unwinding.

Quick Reference

Exception Safety Levels

Level	Requirement	Applies To
Minimal	No memory unsafety on unwind	Unsafe code
Maximal	Correct behavior after unwind	Safe code

Panic Strategies

Strategy	Behavior	Configuration
Unwind	Runs destructors, allows `catch_unwind`	Default
Abort	Terminates immediately, no destructors	`panic = 'abort'`

Unsafe Exception Safety Tools

Tool	Purpose
Guard type	Restores invariant in `Drop` on unwind
`thread::panicking()`	Detect unwind context
`Hole` pattern	Temporarily removes element, restores in `Drop`
`DropFlag` (moveit)	Tracks destruction for pinned storage
`ManuallyDrop`	Inhibits automatic drop; requires manual tracking

Best Practices

✅ Do This:

// Guard that restores state on unwind
let guard = StateGuard::new(&mut data);
dangerous_operation()?;
mem::forget(guard); // success

✅ Guard restores invariant if panic occurs

[profile.release]
panic = "abort"

✅ Abort for kernels, embedded, fail-fast systems

if thread::panicking() {
    return; // clean up minimally
}

✅ Check panicking state before complex cleanup

// Use safe push instead of set_len+write
vec.push(x.clone());

✅ Safe methods maintain invariants automatically

❌ Don’t Do This:

unsafe { vec.set_len(len + n); }
for x in slice { vec.as_mut_ptr().add(i).write(x.clone()); }

❌ Panic in clone leaves uninitialized memory exposed

// Panic in Drop during unwind causes abort
impl Drop for Guard { fn drop(&mut self) { panic!(); } }

❌ Double panic is fatal

// Relying on catch_unwind in abort builds
catch_unwind(|| { panic!() });

❌ catch_unwind is unavailable with panic = 'abort'

Common Pitfalls

Pitfall	Why It Happens	Fix
Uninitialized memory exposed	`set_len` before loop, `clone` panics	Use guard or update `len` each iteration
Double panic abort	`Drop` panics during unwind	Check `thread::panicking()`
Cannot recover from panic	`panic = 'abort'` configured	Remove setting or catch at boundary
`catch_unwind` fails silently	Abort strategy active	Check profile configuration
Mutex poisoned after panic	Thread panicked while holding lock	Use `lock().unwrap()` or handle poison

Real-World Examples

1. Guard Restores Length

struct LenGuard<'a, T> { vec: &'a mut Vec<T>, len: usize }
impl Drop for LenGuard<'_, T> {
    fn drop(&mut self) { unsafe { self.vec.set_len(self.len); } }
}

2. Abort Profile

[profile.release]
panic = "abort"

3. Check Panicking

if std::thread::panicking() { return; }

4. Immediate Abort

libabort::immediate_abort();

5. Hole Pattern

let mut hole = Hole::new(&mut data, pos);
// hole restores element in Drop

6. Mutex Poison

let guard = mutex.lock().unwrap();
// poisoned mutex panics on unwrap

7. DropFlag Counter

flag.inc(); // track content
flag.dec_and_check_if_died(); // true if dead

8. Safe Push

vec.push(x.clone()); // exception-safe

9. Forget Guard on Success

mem::forget(guard); // prevent cleanup

10. Kernel Abort

// Kernel builds: panic=abort
// No unwind, no destructors

Visual

Exception Safety in Unsafe Code

┌──────────────────────────────────────────────┐
│  Unsafe operation begins                     │
│  set_len(large)  ← transient invalid state   │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Loop: clone() may panic                     │
└──────────┬───────────────────────┬───────────┘
           │ NO PANIC              │ PANIC
           ▼                       ▼
┌──────────────────────┐  ┌──────────────────────┐
│  All elements        │  │  Unwind begins       │
│  initialized         │  │                      │
│  set_len(actual)     │  │  If no guard:        │
│  Success             │  │  Vec has bad len → UB│
└──────────────────────┘  │                      │
                          │  If guard:           │
                          │  Drop restores len   │
                          │  Safe state          │
                          └──────────────────────┘

The guard converts a panic path that would produce undefined behavior into a path that restores safety.

Panic Strategy Choice

┌──────────────────────────────────────────────┐
│  Can the program recover from panic?         │
└──────────┬───────────────────────┬───────────┘
           │ YES                   │ NO
           ▼                       ▼
┌──────────────────────┐  ┌──────────────────────┐
│  Use unwinding       │  │  Consider abort      │
│  Default behavior    │  │  panic = 'abort'     │
│                      │  │                      │
│  Required for:       │  │  Benefits:           │
│  - catch_unwind      │  │  - Smaller binary    │
│  - Mutex poisoning   │  │  - No unwind tables  │
│  - Long-running      │  │  - Fail-fast         │
│    services          │  │  - No exception      │
│                      │  │    safety needed     │
└──────────────────────┘  └──────────────────────┘

The choice is architectural. Unwinding supports recovery; aborting simplifies unsafe code and reduces binary size.

DropFlag Decision

┌──────────────────────────────────────────────┐
│  MoveRef forgotten?                          │
└──────────┬───────────────────────┬───────────┘
           │ YES                   │ NO
           ▼                       ▼
┌──────────────────────┐  ┌──────────────────────┐
│  Storage destructor  │  │  Normal destruction  │
│  checks DropFlag     │  │  Flag cleared        │
│                      │  │  No issue            │
│  Flag dead?          │  └──────────────────────┘
│  ├─ YES: leak heap   │
│  │       abort stack │
│  └─ NO:  ??          │
└──────────────────────┘

The DropFlag exists because a panic is insufficient—catching it would allow stack reuse, which is undefined behavior.

Summary

Item	Value
Minimal exception safety	No memory unsafety on unwind (unsafe code)
Maximal exception safety	Correct behavior after unwind (safe code)
Guard pattern	`Drop` restores invariant on unwind
Abort configuration	`panic = 'abort'` in `Cargo.toml`
Abort consequence	No destructors, no `catch_unwind`
Kernel choice	Abort; no unwinding in kernel
`DropFlag` failure	Leak (heap) or abort (stack)
Mutex poisoning	Maximal exception safety for shared state

Key takeaways:

Unsafe code must be minimally exception-safe. A panic can unwind through code that holds transient invalid state; if the code does not guard against it, memory safety is violated .
Guards restore invariants. A type with a Drop implementation that cleans up transient state converts a potentially unsound unwind path into a safe one.
Abort-on-panic eliminates the need for exception safety. When panic = 'abort' is set, destructors do not run, and unsafe code does not need to account for unwinding .
Abort is not universally better. It removes recovery. Long-running services and code that uses catch_unwind require unwinding.
The kernel uses abort for simplicity. Rust panics in the Linux kernel do not unwind, which simplifies reasoning about unsafe code .
Library-level drop flags require abort, not panic. The moveit DropFlag cannot use a panic to signal failure because a caught panic could allow stack reuse, which would be undefined behavior .

Remember: Exception safety in unsafe Rust is about one thing: ensuring that a panic does not expose uninitialized memory, double-drops, or other invariant violations. The guard pattern is the standard tool. Abort-on-panic is the strategic alternative—it removes the unwinding path entirely, simplifying unsafe code at the cost of recoverability. Choose the strategy that matches the system’s requirements, but never assume that a panic through unsafe code is harmless.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!