Skip to content

Crash compiling my unsafe (crappy) code #8286

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

Closed
panzi opened this issue Aug 4, 2013 · 12 comments
Closed

Crash compiling my unsafe (crappy) code #8286

panzi opened this issue Aug 4, 2013 · 12 comments

Comments

@panzi
Copy link

panzi commented Aug 4, 2013

I tried to make myself familiar with rust and tried to compile this code with rust 0.7. rustc crashed and gave me this trace.

@jdm
Copy link
Contributor

jdm commented Aug 4, 2013

Could you run rustc under gdb and gist the backtrace from rust_task_fail?

@panzi
Copy link
Author

panzi commented Aug 4, 2013

I installed rustc via: ./configure --prefix=$HOME/software/rust && make -j 2 && make install This seems to strip the debug infos. How do I install the debug infos and/or refere gdb to them?

@jdm
Copy link
Contributor

jdm commented Aug 4, 2013

We don't give good debug output yet, but the backtrace will show us mangled functions names which are useful.

@jdm
Copy link
Contributor

jdm commented Aug 4, 2013

Also, seeing if you can reproduce with HEAD would be useful.

@panzi
Copy link
Author

panzi commented Aug 4, 2013

Well, when I run gdb --args rustc main.rs I seem not to be able to get a backtrace:

GNU gdb (GDB) Fedora (7.3.50.20110722-16.fc16)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/panzi/software/rust/bin/rustc...(no debugging symbols found)...done.
(gdb) run
Starting program: /home/panzi/software/rust/bin/rustc main.rs
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff605b700 (LWP 17992)]
[New Thread 0x7ffff6042700 (LWP 17993)]
[New Thread 0x7ffff4053700 (LWP 17994)]
rust: task failed at 'option::get none', /home/panzi/software/rust-0.7/src/libstd/option.rs:331
error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug
note: try running with RUST_LOG=rustc=1,::rt::backtrace to get further details and report the results to github.com/mozilla/rust/issues
rust: task failed at 'explicit failure', /home/panzi/software/rust-0.7/src/librustc/rustc.rs:354
rust: domain main @0x606d90 root task failed
[Thread 0x7ffff605b700 (LWP 17992) exited]
[Thread 0x7ffff4053700 (LWP 17994) exited]
[Thread 0x7ffff6042700 (LWP 17993) exited]
[Inferior 1 (process 17989) exited with code 0145]
(gdb) backtrace
No stack.
(gdb) quit

The program quits. It crashes on a rust level, not a C/C++ level. fail! is called in Option.get which exits the program (no SIGSEGV or anything like this). It's just further proof that this method is a bad idea. But that was already in the output I posted as a gist.

Is there a way to get a stacktrace from a fail!?

@panzi
Copy link
Author

panzi commented Aug 4, 2013

Ok I sat a breakpoint at _ZN9rust_task13begin_failureEPKcS1_m and then got this backtrace at that point.

@panzi
Copy link
Author

panzi commented Aug 4, 2013

Yeah, middle::trans::common::find_vtable in HEAD looks different: https://github.com/mozilla/rust/blob/master/src/librustc/middle/trans/common.rs#L1091
I guess I compile from git then.

@jdm
Copy link
Contributor

jdm commented Aug 5, 2013

I did mention to get a backtrace from rust_task_fail :) Yours works too, though.

@panzi
Copy link
Author

panzi commented Aug 5, 2013

Ok, with git HEAD I had to change my code a bit, but I still get a crash. It's basically the same crash. The only difference is that now then None case is handled and a better fail! message is provided: vtables missing where they are needed

@jdm
Copy link
Contributor

jdm commented Aug 5, 2013

I suspect it might be triggered by one of the destructors. Try commenting them out and see if it's still reproducible?

@panzi
Copy link
Author

panzi commented Aug 5, 2013

Indeed. Commenting out the Weakref destructor makes it compile!

@huonw
Copy link
Member

huonw commented Aug 5, 2013

That error message is the same as #8059, which is closed as a dupe of #4252; closing this one as a dup too.

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