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

ICE #15469

Closed
o11c opened this issue Jul 6, 2014 · 4 comments
Closed

ICE #15469

o11c opened this issue Jul 6, 2014 · 4 comments
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️

Comments

@o11c
Copy link

o11c commented Jul 6, 2014

What I'm trying to do is turn a Box into a *mut c_void. I've hit this with several variants of the following code:

        unsafe
        {
            let fun = Some(pen_lively_callback);
            let data = box LivelyPenData{pen: self.pen, cb: cb};
            let mut id: c_int = 0;
            {
                let raw_data_ptr: *const *const LivelyPenData = std::mem::transmute(&data);
                let raw_data = *raw_data_ptr;
                let raw_data: *mut c_void = std::mem::transmute(raw_data);
                id = c::tickit_pen_bind_event(self.pen, ev, fun, raw_data);
            };
            LivelyPenEvent{id: id, data: data}
        }
error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
task 'rustc' failed at 'index out of bounds: the len is 0 but the index is 0', /build/buildd/rust-nightly-201407010407~90ab2f8~trusty/src/librustc/lib.rs:1

stack backtrace:
   1:     0x7f40f48f9f10 - rt::backtrace::imp::write::h20ea790cd11512b89Hp::v0.11.0.pre
   2:     0x7f40f4900a40 - <unknown>
   3:     0x7f40f50c5330 - unwind::begin_unwind_inner::h6989cca23ac32950cZd::v0.11.0.pre
   4:     0x7f40f50c4de0 - unwind::begin_unwind_fmt::hed325abc04af5cbbFWd::v0.11.0.pre
   5:     0x7f40f50c4da0 - rust_begin_unwind
   6:     0x7f40f5107180 - failure::begin_unwind::h04dff981da03c579xiw::v0.11.0.pre
   7:     0x7f40f5108ea0 - failure::fail_bounds_check::h48f92529758f7c44Jgw::v0.11.0.pre
   8:     0x7f40f57f32d0 - middle::subst::SubstFolder<'a>.TypeFolder::fold_region::ha4c49cfb8c9c0c98wFU::v0.11.0.pre
   9:     0x7f40f57f3250 - <unknown>
  10:     0x7f40f57f2670 - <unknown>
  11:     0x7f40f57f24c0 - <unknown>
  12:     0x7f40f579b8c0 - middle::subst::SubstFolder<'a>.TypeFolder::fold_ty::h4677d2be2ed197995FU::v0.11.0.pre
  13:     0x7f40f579b8c0 - middle::subst::SubstFolder<'a>.TypeFolder::fold_ty::h4677d2be2ed197995FU::v0.11.0.pre
  14:     0x7f40f579b7d0 - <unknown>
  15:     0x7f40f5920d40 - middle::ty::lookup_field_type::hcf295e3c01ace151ugS::v0.11.0.pre
  16:     0x7f40f57da3e0 - middle::ty::struct_fields::h750a5e3c9ba03de9LoS::v0.11.0.pre
  17:     0x7f40f594d5e0 - <unknown>
  18:     0x7f40f58e7d70 - middle::ty::type_contents::h04f981e1d4907a10rvP::v0.11.0.pre
  19:     0x7f40f5caad40 - <unknown>
  20:     0x7f40f5cadba0 - middle::kind::check_crate::h9276be46bc90db1fS0P::v0.11.0.pre
  21:     0x7f40f6093050 - driver::driver::phase_3_run_analysis_passes::h7a1b0f2c50043fdfTdq::v0.11.0.pre
  22:     0x7f40f608e600 - driver::driver::compile_input::h8cab87c201bb9a18R0p::v0.11.0.pre
  23:     0x7f40f615b410 - <unknown>
  24:     0x7f40f615b320 - <unknown>
  25:     0x7f40f6170430 - <unknown>
  26:     0x7f40f6170050 - <unknown>
  27:     0x7f40f821cc90 - <unknown>
  28:     0x7f40f511d4d0 - rust_try
  29:     0x7f40f50c1940 - unwind::try::h31ede991d064db63BNd::v0.11.0.pre
  30:     0x7f40f50c1620 - task::Task::run::h4e89f6317d5d7de3XYc::v0.11.0.pre
  31:     0x7f40f821ca50 - <unknown>
  32:     0x7f40f50c41e0 - <unknown>
  33:     0x7f40f4368000 - start_thread
  34:     0x7f40f4d86039 - __clone
  35:                0x0 - <unknown>
@huonw huonw added the I-ICE label Jul 6, 2014
@huonw
Copy link
Member

huonw commented Jul 6, 2014

Could you post a reproducing example? (Even if it's not minimal, although that would be nice. :) )

Just substituting best-guess definitions in naively doesn't reproduce the ICE:

extern crate libc;

use libc::{c_void, c_int};

struct LivelyPenData { pen: uint, cb: extern "C" fn() }
struct LivelyPenEvent { id: c_int, data: Box<LivelyPenData> }

extern "C" fn pen_lively_callback() {}
extern "C" fn cb() {}

mod c {
    extern {
        pub fn tickit_pen_bind_event(x: uint, ev: (), fun: Option<extern "C" fn()>, ptr: *mut ::libc::c_void) -> ::libc::c_int;
    }
}

fn main() {
    let ev = ();

        unsafe
        {
            let fun = Some(pen_lively_callback);
            let data = box LivelyPenData{pen: 0, cb: cb};
            let mut id: c_int = 0;
            {
                let raw_data_ptr: *const *const LivelyPenData = std::mem::transmute(&data);
                let raw_data = *raw_data_ptr;
                let raw_data: *mut c_void = std::mem::transmute(raw_data);
                id = c::tickit_pen_bind_event(0, ev, fun, raw_data);
            };
            LivelyPenEvent{id: id, data: data}
        };

}

That compiles (on the playpen) with a pile of warnings and a linkage error, but no ICE.

@o11c
Copy link
Author

o11c commented Jul 6, 2014

Looks like the external C functions needing the data pointer was a red herring.

#![crate_type = "dylib"]

struct Boxee<'a> {
    cb: ||: 'a,
}

pub struct Boxer<'a> {
    data: Box<Boxee<'a>>,
}

impl<'a> Drop for Boxer<'a> {
    fn drop(&mut self) {
        println!("dropping boxer");
    }
}

pub fn build_it<'a>(cb: ||: 'a) -> Boxer<'a> {
    let data = box Boxee{cb: cb};
    Boxer{data: data}
}

The ICE appeared once I added the Drop impl, but the fact that I'm taking a lifetime'd closure is also relevant. If I change the closure to 'static, I get an error (regardless of whether I leave the unused 'a lifetime on everything else):

ice.rs:11:15: 11:20 error: cannot implement a destructor on a structure that does not satisfy Send
ice.rs:11 impl Drop for Boxer {
                        ^~~~~
ice.rs:11:15: 11:20 note: use "#[unsafe_destructor]" on the implementation to force the compiler to allow this
ice.rs:11 impl Drop for Boxer {
                        ^~~~~
error: aborting due to previous error

If I replace the closure with an extern fn(), then I get the ICE if the unused lifetime is left in, and I get no error if the unused lifetime is removed.

If I impl Drop for Boxee instead of Boxer, there is no change.

@o11c
Copy link
Author

o11c commented Jul 6, 2014

If I follow the error's suggestion and use #[unsafe_destructor], then both my minimal testcase and my real code compile just fine.

@luqmana
Copy link
Member

luqmana commented Jul 6, 2014

Dupe of #14889.

@luqmana luqmana closed this as completed Jul 6, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Projects
None yet
Development

No branches or pull requests

3 participants