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

LLVM assert (possibly class-related) #2718

Closed
eholk opened this issue Jun 25, 2012 · 6 comments
Closed

LLVM assert (possibly class-related) #2718

eholk opened this issue Jun 25, 2012 · 6 comments

Comments

@eholk
Copy link
Contributor

eholk commented Jun 25, 2012

I'm trying to use classes in some code where I would normally use a resource, since resources are going away. I get the following LLVM assertion and backtrace.

Assertion failed: (Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"), function getTypeSizeInBits, file /Users/eholk/Documents/projects/mozilla/rust/src/llvm/lib/Target/TargetData.cpp, line 466.

Program received signal SIGABRT, Aborted.
[Switching to process 40424 thread 0x1e03]
0x00007fff8fda7ce2 in __pthread_kill ()
(gdb) bt
#0  0x00007fff8fda7ce2 in __pthread_kill ()
#1  0x00007fff962897d2 in pthread_kill ()
#2  0x0000000101f3eca6 in abort ()
#3  0x0000000101f3ecf8 in __assert_rtn ()
#4  0x0000000101d777d0 in llvm::TargetData::getTypeSizeInBits ()
#5  0x000000010128307a in LLVMSizeOfTypeInBits__c_stack_shim ()
#6  0x000000010163becc in __morestack () at rust_task.cpp:1327
#7  0x000000010162b7ce in rust_task::call_on_c_stack (this=0x10281e000, args=0x105026750, fn_ptr=0x105026750) at rust_task.h:392
#8  0x000000010162c357 in rust_task::record_stack_limit () at /Users/eholk/Documents/projects/mozilla/rust/src/rt/rust_task.h:58
#9  0x000000010162c357 in upcall_call_shim_on_c_stack (args=0x105026750, fn_ptr=0x101283040) at rust_upcall.cpp:64
#10 0x0000000100f1c556 in middle::trans::shape::static_size_of_enum::anon ()
#11 0x0000000100e3bc67 in middle::trans::shape::static_size_of_enum::_17b77bb34c1ffe7e::_02 ()
#12 0x0000000100e34b9e in middle::trans::type_of::type_of::_f3f689176c62646a::_02 ()
#13 0x0000000100e3528e in middle::trans::type_of::type_of::_f3f689176c62646a::_02 ()
#14 0x0000000100f1c52b in middle::trans::shape::static_size_of_enum::anon ()
#15 0x0000000100e3bc67 in middle::trans::shape::static_size_of_enum::_17b77bb34c1ffe7e::_02 ()
#16 0x0000000100e34b9e in middle::trans::type_of::type_of::_f3f689176c62646a::_02 ()
#17 0x0000000100e34f8e in middle::trans::type_of::type_of::_f3f689176c62646a::_02 ()
#18 0x0000000100e34e39 in middle::trans::type_of::type_of::_f3f689176c62646a::_02 ()
#19 0x0000000100e3528e in middle::trans::type_of::type_of::_f3f689176c62646a::_02 ()
#20 0x0000000101286d59 in __morestack ()
Previous frame inner to this frame (gdb could not unwind past this frame)

Here is a sampling of the code, some of which might be related.

    class send_packet<T: send> {
        let mut p: option<*packet<T>>;
        new(p: *packet<T>) { self.p = some(p); }
        drop {
            if self.p != none {
                let mut p = none;
                p <-> self.p;
                sender_terminate(option::unwrap(p))
            }
        }
        fn unwrap() -> *packet<T> {
            let mut p = none;
            p <-> self.p;
            option::unwrap(p)
        }
    }

    enum state {
        empty,
        full,
        blocked,
        terminated
    }

    type packet<T: send> = {
        mut state: state,
        mut blocked_task: option<task::task>,
        mut payload: option<T>
    };
@catamorphism
Copy link
Contributor

I think I've fixed this, but I'll try again once I'm finished building the snapshot I'm building.

@ghost ghost assigned catamorphism Jun 25, 2012
@catamorphism
Copy link
Contributor

Appears to be fixed (at least, this code compiles), but I'm still waiting for the snapshot to be able to check in the fix.

@eholk
Copy link
Contributor Author

eholk commented Jun 25, 2012

Great! Thanks for getting on this so quickly.

@eholk eholk reopened this Jun 26, 2012
@eholk
Copy link
Contributor Author

eholk commented Jun 26, 2012

I guess I didn't include enough of a test case... here's the full code: https://gist.github.com/2992324

I'm still seeing this issue.

@am0d
Copy link
Contributor

am0d commented Oct 13, 2012

This is still an issue with rust 0.4 - fcf8d0d
Here is a gist showing a minimal program to crash the compiler: https://gist.github.com/3885764

@catamorphism
Copy link
Contributor

@am0d - This is a different bug, so I'll file a new issue for it. However, in the meantime, if you change your struct definition to:

struct Tree {
    mut leftTree: Option<@Tree>,
    mut rightTree: Option<@Tree>,
    key: int
}

and change the rest of the code accordingly, this code will compile.

RalfJung pushed a commit to RalfJung/rust that referenced this issue Dec 24, 2022
add graceful shim for the custom `O_TMPFILE` file opening flag plus test case

I'm trying if I can get the [`tempfile`](https://crates.io/crates/tempfile) crate to work nicely with miri. Right now miri errors out due to an unsupported flag `O_TMPFILE` (= `0x410000`) passed to [`OpenOptions::custom_flags`](https://github.com/Stebalien/tempfile/blob/92ae3e9d6e82bdcfcf114be459d234d3602be2d4/src/file/imp/unix.rs#L71-L86). Interestingly, `tempfile` has a fallback in case the underlying file system does not support the `O_TMPFILE` flag, in which case `open`/`open64` is expected to return the error code `EOPNOTSUPP` (= `95`). This PR adds support for this scenario and also includes a test case (relevant [zulip](https://rust-lang.zulipchat.com/#narrow/stream/269128-miri/topic/miri.20and.20the.20.60tempfile.60.20crate) discussion).
Aaron1011 pushed a commit to Aaron1011/rust that referenced this issue Jan 6, 2023
add graceful shim for the custom `O_TMPFILE` file opening flag plus test case

I'm trying if I can get the [`tempfile`](https://crates.io/crates/tempfile) crate to work nicely with miri. Right now miri errors out due to an unsupported flag `O_TMPFILE` (= `0x410000`) passed to [`OpenOptions::custom_flags`](https://github.com/Stebalien/tempfile/blob/92ae3e9d6e82bdcfcf114be459d234d3602be2d4/src/file/imp/unix.rs#L71-L86). Interestingly, `tempfile` has a fallback in case the underlying file system does not support the `O_TMPFILE` flag, in which case `open`/`open64` is expected to return the error code `EOPNOTSUPP` (= `95`). This PR adds support for this scenario and also includes a test case (relevant [zulip](https://rust-lang.zulipchat.com/#narrow/stream/269128-miri/topic/miri.20and.20the.20.60tempfile.60.20crate) discussion).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants