Panics in destructors can cause the tail expression of a block to be leaked

STR

struct NoisyDrop;
impl Drop for NoisyDrop {
    fn drop(&mut self) {
        println!("dropping a NoisyDrop");
    }
}

impl NoisyDrop {
    fn new() -> Self {
        println!("creating a NoisyDrop");
        NoisyDrop
    }
}

struct PanickyDrop;
impl Drop for PanickyDrop {
    fn drop(&mut self) {
        panic!()
    }
}

fn foo() -> NoisyDrop {
    let p = PanickyDrop;
    NoisyDrop::new()
}

fn main() {
    foo();
}

Expected Result

"creating a NoisyDrop" and "dropping a NoisyDrop" should appear the same number of times

Actual Result

creating a NoisyDrop
thread 'main' panicked at 'explicit panic', src/main.rs:18:8
note: Run with `RUST_BACKTRACE=1` for a backtrace.

The destructor is ignored.

Heh, this even happens on Rust 1.0

@jonas-schievink

@jonas-schievink

Rust 1.0 is far worse than this - it leaks everything when a destructor panics.

@arielb1

@arielb1, could you explain why this is tagged as a soundness bug? The language makes no guarantee that destructors will ever be invoked.

ping @rust-lang/compiler this should be triagged, even if it is not a soundness bug, unwinding working properly is something that a lot of code relies on.

So, to be clear, it's not that we leak all destructors when panic in drop occurs. For example, this function drops both p and n as expected:

fn foo() {
    let n = NoisyDrop::new();
    let p = PanickyDrop;
}

The specific scenario here is that:

we are in the middle of returning the NoisyDrop to our caller (so our caller "owns it")
but we panic before our return completes (so they don't realize they own it)

I don't think it's quite right to say that "we make no guarantee that destructors will ever be invoked". We don't guarantee that all destructors are always invoked, but we do guarantee some things: for example, that if you have a local variable whose scope includes a call, it will be dropped when the call panics (here, n would be dropped):

let n = ...;
foo();

So the question is what we should guarantee in this particular scenario. Perhaps the answer is that we should just be very clear to document the current behavior, given how long it has existed.

Auto merge of rust-lang#125923 - matthewjasper:no-return-leak, r=<try>

Possibly related to #156713.

A leak can also happen with a closure that panics upon drop, even without any relevant blocks.

struct LoudDrop;
impl Drop for LoudDrop {
    fn drop(&mut self) {
        println!("dropped");
    }
}
fn new() -> LoudDrop {
    println!("created");
    LoudDrop
}

struct PanicOnDrop;
impl Drop for PanicOnDrop {
    fn drop(&mut self) {
        panic!()
    }
}

fn foo(f: impl FnOnce(LoudDrop) -> LoudDrop) {
    f(new());
}

fn main() {
    let x = PanicOnDrop;
    foo(move |y| (&x, y).1);
}

The above code prints "created" but not "drop".

fix(rust-js): what a filter or a take_while discards is dropped past …

fix(rust-js): a collect std makes in place is its fold, so a filter's…

fix(rust-js): a collect in place asks no room: std's compiled collect…

Navigation Menu

Repository navigation

Panics in destructors can cause the tail expression of a block to be leaked #47949

STR

Expected Result

Actual Result

63 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Panics in destructors can cause the tail expression of a block to be leaked #47949

Description

STR

Expected Result

Actual Result

Activity

jonas-schievink commented on Feb 1, 2018

arielb1 commented on Feb 2, 2018

solb commented on Mar 8, 2018

gnzlbg commented on May 7, 2019

nikomatsakis commented on May 7, 2019

63 remaining items

theemathas commented on May 23, 2026

theemathas commented on May 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions