Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
zummenix opened this issue May 4, 2015 · 6 comments

Comments

@zummenix
Copy link

commented May 4, 2015

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
@veddan

This comment has been minimized.

Copy link
Contributor

commented May 4, 2015

Try using lldb to get a stacktrace:

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

This comment has been minimized.

Copy link
Author

commented May 4, 2015

(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

@sfackler sfackler added the I-crash label May 4, 2015

@alexcrichton

This comment has been minimized.

Copy link
Member

commented May 4, 2015

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

This comment has been minimized.

Copy link
Member

commented Jun 3, 2015

triage: I-nominated

@alexcrichton

This comment has been minimized.

Copy link
Member

commented Jun 3, 2015

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
eefriedman added a commit to eefriedman/rust that referenced this issue Jun 7, 2015
Clear cached landing pads before performing a call.
Using the wrong landing pad has obvious bad effects, like dropping a value
twice.

Testcase written by Alex Crichton.

Fixes rust-lang#25089.
eefriedman added a commit to eefriedman/rust that referenced this issue Jun 7, 2015
Clear cached landing pads before performing a call.
Using the wrong landing pad has obvious bad effects, like dropping a value
twice.

Testcase written by Alex Crichton.

Fixes rust-lang#25089.
eefriedman added a commit to eefriedman/rust that referenced this issue Jun 7, 2015
Clear cached landing pads before generating a call.
Using the wrong landing pad has obvious bad effects, like dropping a value
twice.

Testcase written by Alex Crichton.

Fixes rust-lang#25089.
eefriedman added a commit to eefriedman/rust that referenced this issue Jun 7, 2015
Clear cached landing pads before generating a call.
Using the wrong landing pad has obvious bad effects, like dropping a value
twice.

Testcase written by Alex Crichton.

Fixes rust-lang#25089.
@nikomatsakis

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2015

triage: P-medium

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

bors added a commit that referenced this issue Jun 17, 2015
Auto merge of #26062 - eefriedman:cleanup-cached, r=nikomatsakis
Using the wrong landing pad has obvious bad effects, like dropping a value
twice.

Testcase written by Alex Crichton.

Fixes #25089.

@bors bors closed this in #26062 Jun 17, 2015

brson added a commit to brson/rust that referenced this issue Jun 18, 2015
Clear cached landing pads before generating a call.
Using the wrong landing pad has obvious bad effects, like dropping a value
twice.

Testcase written by Alex Crichton.

Fixes rust-lang#25089.
thepowersgang added a commit to thepowersgang/rust that referenced this issue Jul 25, 2015
Clear cached landing pads before generating a call.
Using the wrong landing pad has obvious bad effects, like dropping a value
twice.

Testcase written by Alex Crichton.

Fixes rust-lang#25089.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.