Process didn't exit successfully: ... (signal: 4) in tests #25089

zummenix · 2015-05-04T06:41:12Z

I receive Process didn't exit successfully: ... (signal: 4) doing cargo test. RUST_BACKTRACE=1 cargo test gives nothing. Output:

   Compiling play v0.0.1 (file:///Users/zummenix/projects/play)
     Running target/debug/play-bc5fff1cb75e27c9

running 1 test
Process didn't exit successfully: `/Users/zummenix/projects/play/target/debug/play-bc5fff1cb75e27c9` (signal: 4)

I tried this code:

#[cfg(not(test))]
fn main() {
}

#[test]
#[should_panic]
fn panic() {
    should_panic("string".to_string(), empty());
}

#[derive(Debug)]
struct Empty;

fn empty() -> Empty {
    Empty
}

fn should_panic<U, T>(_: U, _: T) where T: std::fmt::Debug {
    panic!("test panic");
}

I expected to see that test is passes.

Meta

rustc --version --verbose:

rustc 1.1.0-nightly (c42c1e7a6 2015-05-02) (built 2015-05-01)
binary: rustc
commit-hash: c42c1e7a678a27bb63c24fb1eca2866af4e3ab7a
commit-date: 2015-05-02
build-date: 2015-05-01
host: x86_64-apple-darwin
release: 1.1.0-nightly

The text was updated successfully, but these errors were encountered:

veddan · 2015-05-04T07:05:54Z

Try using lldb to get a stacktrace:

$ lldb -- target/debug/play-bc5fff1cb75e27c9 --test
$ run
...
$ bt

zummenix · 2015-05-04T07:30:01Z

(lldb) run
Process 30437 launched: '/Users/zummenix/projects/play/target/debug/play-bc5fff1cb75e27c9' (x86_64)

running 1 test
Process 30437 stopped
* thread #2: tid = 0x20a9f5, 0x0000000100063bf6 play-bc5fff1cb75e27c9`je_arena_dalloc_bin_locked [inlined] je_bitmap_unset(bit=0) + 71 at bitmap.h:215, name = 'panic', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x0000000100063bf6 play-bc5fff1cb75e27c9`je_arena_dalloc_bin_locked [inlined] je_bitmap_unset(bit=0) + 71 at bitmap.h:215
(lldb) bt
* thread #2: tid = 0x20a9f5, 0x0000000100063bf6 play-bc5fff1cb75e27c9`je_arena_dalloc_bin_locked [inlined] je_bitmap_unset(bit=0) + 71 at bitmap.h:215, name = 'panic', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x0000000100063bf6 play-bc5fff1cb75e27c9`je_arena_dalloc_bin_locked [inlined] je_bitmap_unset(bit=0) + 71 at bitmap.h:215
    frame #1: 0x0000000100063baf play-bc5fff1cb75e27c9`je_arena_dalloc_bin_locked [inlined] arena_run_reg_dalloc(ptr=<unavailable>, run=0x0000000101c021a8) + 95 at arena.c:217
    frame #2: 0x0000000100063b50 play-bc5fff1cb75e27c9`je_arena_dalloc_bin_locked(arena=0x0000000101042980, chunk=0x0000000101c00000, ptr=<unavailable>, bitselm=0x0000000000000000) + 208 at arena.c:1780
    frame #3: 0x0000000100074381 play-bc5fff1cb75e27c9`je_tcache_bin_flush_small(tbin=0x0000000101c1c028, binind=0, rem=0, tcache=0x0000000101c1c000) + 241 at tcache.c:120
    frame #4: 0x0000000100074f50 play-bc5fff1cb75e27c9`je_tcache_cleanup [inlined] tcache_destroy + 42 at tcache.c:328
    frame #5: 0x0000000100074f26 play-bc5fff1cb75e27c9`je_tcache_cleanup(tsd=0x0000000101433108) + 38 at tcache.c:385
    frame #6: 0x00000001000769ff play-bc5fff1cb75e27c9`je_tsd_cleanup(arg=0x0000000101433108) + 159 at tsd.c:81
    frame #7: 0x0000000100076e2a play-bc5fff1cb75e27c9`je_tsd_cleanup_wrapper(arg=0x0000000101433100) + 26 at tsd.h:486
    frame #8: 0x00007fff968bb72a libsystem_pthread.dylib`_pthread_tsd_cleanup + 86
    frame #9: 0x00007fff968bb451 libsystem_pthread.dylib`_pthread_exit + 117
    frame #10: 0x00007fff968ba273 libsystem_pthread.dylib`_pthread_body + 142
    frame #11: 0x00007fff968ba1e5 libsystem_pthread.dylib`_pthread_start + 176
    frame #12: 0x00007fff968b841d libsystem_pthread.dylib`thread_start + 13

alexcrichton · 2015-05-04T20:37:10Z

It looks like this is a bug in trans, the cleanup for the String argument in the example is given twice. For example this code has this IR:

#[test]
#[should_panic]
fn panic() {
    should_panic(Box::new(1), empty());
}

struct Empty;

fn empty() -> Empty { Empty }

#[inline(never)]
fn should_panic(_: Box<u32>, _: Empty) {
    panic!("test panic");
}

Optimized IR:

define internal void @_ZN5panic20hbd7799a4d53a7c18eaaE() unnamed_addr #0 {
entry-block:
  %0 = tail call i8* @je_mallocx(i64 4, i32 0)
  %1 = icmp eq i8* %0, null
  br i1 %1, label %then-block-132-.i.i, label %normal-return

then-block-132-.i.i:                              ; preds = %entry-block
  tail call void @_ZN3oom20h5ea7b8934ca1bc543ZaE()
  unreachable

normal-return:                                    ; preds = %entry-block
  %2 = bitcast i8* %0 to i32*
  store i32 1, i32* %2, align 4
  invoke fastcc void @_ZN12should_panic20hfe6f725236e48244xaaE(i32* noalias dereferenceable(4) %2)
          to label %normal-return1 unwind label %unwind_custom_

unwind_custom_:                                   ; preds = %normal-return
  %3 = landingpad { i8*, i32 } personality i32 (i32, i32, i64, %"1.std::rt::libunwind::_Unwind_Exception"*, %"1.std::rt::libunwind::_Unwind_Context"*)* @rust_eh_personality
          cleanup
  %4 = icmp eq i8* %0, inttoptr (i64 2097865012304223517 to i8*)
  br i1 %4, label %"_ZN14Box$LT$u32$GT$9drop.118117h48c45852b94c565eE.exit", label %cond.i

cond.i:                                           ; preds = %unwind_custom_
  tail call void @je_sdallocx(i8* %0, i64 4, i32 0)
  br label %"_ZN14Box$LT$u32$GT$9drop.118117h48c45852b94c565eE.exit"

"_ZN14Box$LT$u32$GT$9drop.118117h48c45852b94c565eE.exit": ; preds = %unwind_custom_, %cond.i
  resume { i8*, i32 } %3

normal-return1:                                   ; preds = %normal-return
  ret void
}

; Function Attrs: noinline noreturn uwtable
define internal fastcc void @_ZN12should_panic20hfe6f725236e48244xaaE(i32* noalias dereferenceable(4)) unnamed_addr #1 {
entry-block:
  %const = alloca %str_slice, align 8
  %1 = bitcast %str_slice* %const to i8*
  call void @llvm.memcpy.p0i8.p0i8.i64(i8* %1, i8* bitcast (%str_slice* @const1222 to i8*), i64 16, i32 8, i1 false)
  invoke fastcc void @_ZN2rt6unwind12begin_unwind20h8221535833087833418E(%str_slice* noalias nocapture dereferenceable(16) %const)
          to label %normal-return unwind label %unwind_custom_

normal-return:                                    ; preds = %entry-block
  call void @llvm.lifetime.end(i64 16, i8* %1)
  unreachable

unwind_custom_:                                   ; preds = %entry-block
  %2 = landingpad { i8*, i32 } personality i32 (i32, i32, i64, %"1.std::rt::libunwind::_Unwind_Exception"*, %"1.std::rt::libunwind::_Unwind_Context"*)* @rust_eh_personality
          cleanup
  %3 = icmp eq i32* %0, inttoptr (i64 2097865012304223517 to i32*)
  br i1 %3, label %"_ZN14Box$LT$u32$GT$9drop.118117h48c45852b94c565eE.exit", label %cond.i

cond.i:                                           ; preds = %unwind_custom_
  %4 = bitcast i32* %0 to i8*
  tail call void @je_sdallocx(i8* %4, i64 4, i32 0)
  br label %"_ZN14Box$LT$u32$GT$9drop.118117h48c45852b94c565eE.exit"

"_ZN14Box$LT$u32$GT$9drop.118117h48c45852b94c565eE.exit": ; preds = %unwind_custom_, %cond.i
  resume { i8*, i32 } %2
}

Note that both landing pads have calls to je_sdallocx so we're double-freeing.

cc @pnkfelix, @nrc

alexcrichton · 2015-06-03T01:39:29Z

triage: I-nominated

alexcrichton · 2015-06-03T01:46:53Z

Test case (for a unit test):

struct Foo(i32);

impl Drop for Foo {
    fn drop(&mut self) {
        static mut DROPPED: bool = false;
        unsafe {
            assert!(!DROPPED);
            DROPPED = true;
        }
    }
}

struct Empty;

fn empty() -> Empty { Empty }

fn should_panic(_: Foo, _: Empty) {
    panic!("test panic");
}

fn main() {
    should_panic(Foo(1), empty());
}

$ rustc foo.rs && ./foo
thread '<main>' panicked at 'test panic', foo.rs:18
thread '<main>' panicked at 'assertion failed: !DROPPED', foo.rs:7
stack backtrace:
   1:        0x10798ee45 - sys::backtrace::write::h6ede916059f8deceM9r
   2:        0x1079920c7 - panicking::on_panic::ha49f13d0ffb0f10e2uw
   3:        0x10798d448 - rt::unwind::begin_unwind_inner::hf0bdcaef6fa2453akdw
   4:        0x10798bade - rt::unwind::begin_unwind::h13318957588857980774
   5:        0x10798ba3e - Foo.Drop::drop::h2c1b207a3b565791kaa
   6:        0x10798bf32 - Foo::drop.886::haa7535a0227f2840
   7:        0x10798c02c - main::hdaf364a19f487aa9Dba
   8:        0x107992f58 - rust_try_inner
   9:        0x107992f45 - rust_try
  10:        0x107992750 - rt::lang_start::h5cc5e69c1f0d126e6pw
  11:        0x10798c08e - main
thread panicked while panicking. aborting.
zsh: illegal hardware instruction  ./foo

Using the wrong landing pad has obvious bad effects, like dropping a value twice. Testcase written by Alex Crichton. Fixes rust-lang#25089.

nikomatsakis · 2015-06-17T15:43:41Z

triage: P-medium

Using the wrong landing pad has obvious bad effects, like dropping a value twice. Testcase written by Alex Crichton. Fixes #25089.

Using the wrong landing pad has obvious bad effects, like dropping a value twice. Testcase written by Alex Crichton. Fixes rust-lang#25089.

sfackler added the I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics. label May 4, 2015

alexcrichton added the A-codegen Area: Code generation label May 4, 2015

rust-highfive added the I-nominated label Jun 3, 2015

alexcrichton mentioned this issue Jun 3, 2015

Safe code causes an "illegal hardware instruction" at runtime #25972

Closed

alexcrichton added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jun 3, 2015

eefriedman added a commit to eefriedman/rust that referenced this issue Jun 7, 2015

Clear cached landing pads before generating a call.

a1d2eb8

Using the wrong landing pad has obvious bad effects, like dropping a value twice. Testcase written by Alex Crichton. Fixes rust-lang#25089.

eefriedman mentioned this issue Jun 7, 2015

Clear cached landing pads before generating a call. #26062

Merged

alexcrichton mentioned this issue Jun 15, 2015

Segmentation fault on safe test panic #26298

Closed

rust-highfive added P-medium Medium priority and removed I-nominated labels Jun 17, 2015

nikomatsakis added the regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. label Jun 17, 2015

bors added a commit that referenced this issue Jun 17, 2015

Auto merge of #26062 - eefriedman:cleanup-cached, r=nikomatsakis

6065bed

Using the wrong landing pad has obvious bad effects, like dropping a value twice. Testcase written by Alex Crichton. Fixes #25089.

bors closed this as completed in #26062 Jun 17, 2015

brson pushed a commit to brson/rust that referenced this issue Jun 18, 2015

Clear cached landing pads before generating a call.

bd01426

Using the wrong landing pad has obvious bad effects, like dropping a value twice. Testcase written by Alex Crichton. Fixes rust-lang#25089.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Process didn't exit successfully: ... (signal: 4) in tests #25089

Process didn't exit successfully: ... (signal: 4) in tests #25089

zummenix commented May 4, 2015

veddan commented May 4, 2015

zummenix commented May 4, 2015

alexcrichton commented May 4, 2015

alexcrichton commented Jun 3, 2015

alexcrichton commented Jun 3, 2015

nikomatsakis commented Jun 17, 2015

Process didn't exit successfully: ... (signal: 4) in tests #25089

Process didn't exit successfully: ... (signal: 4) in tests #25089

Comments

zummenix commented May 4, 2015

Meta

veddan commented May 4, 2015

zummenix commented May 4, 2015

alexcrichton commented May 4, 2015

alexcrichton commented Jun 3, 2015

alexcrichton commented Jun 3, 2015

nikomatsakis commented Jun 17, 2015