Repository navigation
SIGTRAP in drop glue when slice literal initialization panics #30018
Description
struct Foo;
impl Drop for Foo {
fn drop(&mut self) {}
}
fn foo() -> Foo {
panic!();
}
fn main() {
let _ = &[foo()];
}Backtrace:
* thread #1: tid = 0x9916e, 0x0000000100000deb test`Foo::drop.2547::ha10a92966c711a1c + 43, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)
* frame #0: 0x0000000100000deb test`Foo::drop.2547::ha10a92966c711a1c + 43
frame #1: 0x0000000100000da1 test`_$u5b$Foo$u3b$$u20$1$u5d$::drop.2545::h30bf5c7af770ce1a + 49
frame #2: 0x0000000100000d6c test`main::h49ea8f6746b41e81Raa + 92
frame #3: 0x0000000100006493 test`sys_common::unwind::try::try_fn::h8880715059644542985 + 35
frame #4: 0x00000001000040a9 test`__rust_try + 9
frame #5: 0x000000010000631c test`rt::lang_start::hf0f318bf9acb9103hUw + 540
frame #6: 0x0000000100000e7a test`main + 42
frame #7: 0x00007fff8e9185ad libdyld.dylib`start + 1
Activity
sfackler commentedon Nov 24, 2015
Popped up in broken tests in one of my crates: kornelski/rust-security-framework@8ab48c2
alexcrichton commentedon Nov 25, 2015
triage: I-nominated
probably good to have crashes like this categorized at least
sfackler commentedon Nov 25, 2015
It does appear to have been present since 1.0 at least, BTW.
sfackler commentedon Nov 25, 2015
@alexcrichton added back I-nominated, assuming that the removal was unintentional.
nikomatsakis commentedon Dec 3, 2015
@pnkfelix notes that this is likely a debug flag, and probably only occurs if debug assertions are enabled.
nikomatsakis commentedon Dec 3, 2015
triage: P-medium
sfackler commentedon Dec 3, 2015
Yeah, when compiling with optimizations, it won't hit this signal but continues on and behavior depends on the specific case. The minimized example exits without issue, but the test case I had in my crate segfaults.
pnkfelix commentedon Jan 11, 2016
I think I know why this happens; it is probably related to how somewhat sloppy handling of the drop flags on scratch/temporary values in other contexts (see e.g. #30530).