Illegal instruction - when i run main.rs


#1

this is my first time run rust in centos 6.6 ,and started to learn rust ,i install rust 1.1.0 from first page of rust web
1-wget link
2- ./install.sh
3-fallow getting started
4-vim main.rs

fn main() {
    println!("Hello, world!");
}

5-rustc main.rs
6-./main
getting blow error

thread ‘’ panicked at ‘cannot access a TLS value during or after it is destroyed’, …/src/libcore/option.rs:330
fatal runtime error: Could not unwind stack, error = 5
Illegal instruction

my first time in rust from pythom what can i do?


#2

there are a bunch of errors this might be: https://github.com/rust-lang/rust/search?q=illegal+instruction+5&type=Issues&utf8=✓


#3

I’m having exactly the same problem.
Centos 6.6 32bit.
Downloaded and installed the Rust stable 1.1, cargo new hello --bin, then cargo run gives exactly the above error.
Had a look at the “bunch of errors” and found nothing that seemed relevant.
Then installed the beta version using this on August 1 2015: curl -sSf https://static.rust-lang.org/rustup.sh | sh -s -- --channel=beta
Did a cargo new hello --bin followed by cargo run and got the same error.

Someone suggested compiling with rustc -g main.rs which I did, and then ran with gdb ./main.

Anyway, muddled my way through to a backtrace which was pretty meaningless to me, but it’s all shown below.

[kevin@localhost src]$ gdb ./main
<snip>
warning: Missing auto-load scripts referenced in section .debug_gdb_scripts
of file /home/kevin/rust/hello/src/main
Use `info auto-load python [REGEXP]' to list them.
(gdb) rbreak expect
(gdb) run
Starting program: /home/kevin/rust/hello/src/main 
[Thread debugging using libthread_db enabled]
thread '<unnamed>' panicked at 'cannot access a TLS value during or after it is destroyed', ../src/libcore/option.rs:330
fatal runtime error: Could not unwind stack, error = 5

Program received signal SIGILL, Illegal instruction.
0x0011ba94 in rt::unwind::imp::panic::hfaa8870ac7a1d724NCw ()
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.149.el6_6.9.i686 libgcc-4.4.7-11.el6.i686

(gdb) backtrace
 #0  0x0011ba94 in rt::unwind::imp::panic::hfaa8870ac7a1d724NCw ()
 #1  0x0011bb85 in rust_panic ()
 #2  0x0011589b in rt::unwind::begin_unwind_inner::h6634105f10f7b227hOw ()
 #3  0x00115a65 in rt::unwind::begin_unwind_fmt::he4c5632cdef37027nNw ()
 #4  0x0011bbfb in rust_begin_unwind ()
 #5  0x0014767a in panicking::panic_fmt::h01da0ff0da77895eH8B ()
 #6  0x001186c6 in sys_common::thread_info::set::h49402b4b7d231ea8fwr ()
 #7  0x0011dc95 in rt::lang_start::h360ebe0394cbf4d5A3w ()
 #8  0x00114376 in main ()
(gdb)

#4

Apparently code blocks are one-liners if they aro not preceded with a blank line (read in another post).

Could you please fix your comment, so I can help you?


#5

Thanks, I’ve added some white space as you suggested and it now looks better.
If you’re not able to reproduce this problem then I can give you probably arrange access to the CentOS machine on which it occurs if that will help.
Or I’m happy to do some diagnostic stuff myself, but you’d need to give me some pointers on how to go about doing such things.


#6

Have you tried to compare the LLVM IR (I am afraid I don’t know how to get that) with the play.rust-lang.org one?

I guess if it is the same we can say it is a problem with either the libraries (or linking in general) or compilation into assembly (that is done by LLVM I think).

If not and there is someone who can actually read that stuff you might be able to figure out if it means the same, or if the problem lies there. If it does, then the aforementioned guy who can read it, might be able to tell you what the problem is.


#7

Crossreference: https://github.com/rust-lang/rust/issues/27543

It is believed the reported issue is the same as one reported here.


#8

I have reported what I believe to be the same issue here

I think you will need to get a newer version of GCC. The Centos 6.6 VM I have contains 4.4, and I tested a fedora 14 machine with 4.5, both of which seem to not work.


#9

Well, the issue has been closed as “basically a linker bug we can’t do much about”.

I updated binutils on my CentOS 6.6 machine which made the problem go away.

These are the steps I did:
wget http://ftp.gnu.org/gnu/binutils/binutils-2.25.tar.gz
tar xvfz binutils-2.25.tar.gz
cd binutils-2.25
./configure
make
make install

This last step (make install) I did as root (or you can sudo).