Closed oblitum closed 8 years ago
This looks like an error that indicates that the runtime isn't set up yet, would it be possible to reduce the code down to a smaller example?
@alexcrichton at this moment, not from my side, since I don't have knownledge on both codebases. Any help @phildawes?
Hi Oblitum. I haven't seen this, but then I only have ubuntu linux to test on. Does the same thing happen with a recent nightly?
@phildawes I have just pulled rust and built it and tried again, same error..
still happening in 3be6a2f with phildawes/racer@ecde206.
@phildawes @alexcrichton I just started looking at Rust, so I have no idea if this ought to work or not. I was able to create a minimal reproducer for this issue on OS X though:
extern crate syntax;
use syntax::parse::{new_parse_sess};
use std::task;
fn main() {
task::try(proc() {
new_parse_sess();
});
}
Output:
[5152 john]% rustc main.rs
main.rs:7:5: 9:8 warning: unused result which must be used, #[warn(unused_must_use)] on by default
main.rs:7 task::try(proc() {
main.rs:8 new_parse_sess();
main.rs:9 });
[5153 john]% ./main
There are not many persons who know what wonders are opened to them in the
stories and visions of their youth; for when as children we listen and dream,
we think but half-formed thoughts, and when as men we try to remember, we are
dulled and prosaic with the poison of life. But some of us awake in the night
with strange phantasms of enchanted hills and gardens, of fountains that sing
in the sun, of golden cliffs overhanging murmuring seas, of plains that stretch
down to sleeping cities of bronze and stone, and of shadowy companies of heroes
that ride caparisoned white horses along the edges of thick forests; and then
we know that we have looked back through the ivory gates into that world of
wonder which was ours before we were wise and unhappy.
fatal runtime error: assertion failed: !ptr.is_null()
zsh: illegal hardware instruction ./main```
Should've specified that is with rust revision b7aa03a
Even more minimal test case. It looks like "extern crate rustc" is causing the problem - removing that line fixes the failure.
extern crate rustc;
fn main() {
let x = std::task::try(proc() {
println!("hello!");
});
let y = match x {
Ok(..) => "Ok!",
Err(..) => "Err!",
};
println!("{}", y);
}
I'm unable to reproduce the assertion failure on the test case you gave, did you just compile and run it?
Yep:
[5114 john ~]% rustc tmp.rs
[5115 john ~]% ./tmp
There are not many persons who know what wonders are opened to them in the
stories and visions of their youth; for when as children we listen and dream,
we think but half-formed thoughts, and when as men we try to remember, we are
dulled and prosaic with the poison of life. But some of us awake in the night
with strange phantasms of enchanted hills and gardens, of fountains that sing
in the sun, of golden cliffs overhanging murmuring seas, of plains that stretch
down to sleeping cities of bronze and stone, and of shadowy companies of heroes
that ride caparisoned white horses along the edges of thick forests; and then
we know that we have looked back through the ivory gates into that world of
wonder which was ours before we were wise and unhappy.
fatal runtime error: assertion failed: !ptr.is_null()
hello!
zsh: illegal hardware instruction ./tmp
Here's the backtrace:
Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand.
0x000000010334f6d2 in util::abort::h9182c37c9de2edd0ICa ()
(gdb) bt
#0 0x000000010334f6d2 in util::abort::h9182c37c9de2edd0ICa ()
#1 0x000000010334fc00 in fmt::secret_show::h3110566893878729201 ()
#2 0x000000010001c0ff in local_ptr::compiled::take::h10142886416038288936 ()
#3 0x000000010001bf8e in local::Task.Local$LT$local_ptr..Borrowed$LT$Task$GT$$GT$::take::he4688e74cf2e22f9Sfb ()
#4 0x000000010001becc in comm::oneshot::Packet$LT$T$GT$::recv::h3883734107073250834 ()
#5 0x000000010001b702 in comm::Receiver$LT$T$GT$::recv_opt::h3285373062164709319 ()
#6 0x000000010001b508 in comm::Receiver$LT$T$GT$::recv::h15528954908478842927 ()
#7 0x000000010001b279 in task::TaskBuilder$LT$S$GT$::try_future::closure.3207 ()
#8 0x0000000100002040 in sync::future::Future$LT$A$GT$::get_ref::h11522134085165834637 ()
#9 0x0000000100001d97 in sync::future::Future$LT$A$GT$::unwrap::h8665793292685818696 ()
#10 0x0000000100001cd6 in task::TaskBuilder$LT$S$GT$::try::h9076772579531168055 ()
#11 0x0000000100001b65 in task::try::h15377513306858637937 ()
#12 0x0000000100001938 in main::h86eac4ec1db0033dfaa ()
#13 0x000000010007dcba in start::closure.8650 ()
#14 0x00000001038490cc in rust_try_inner ()
#15 0x00000001037e14cc in task::Task::run::h184281d54b13b946MVc ()
#16 0x000000010007db0e in start::h5719ba99613907a78je ()
#17 0x000000010007d959 in lang_start::hf6b85c6c32cdb3b4rje ()
#18 0x0000000100001abf in main ()
A bit more info. It looks like the rt::init symbol does not exist in the version that includes "extern crate rustc":
# tmp.crash is the above example including "extern crate rustc"
[5196 john ~]% nm tmp.crash| grep 'rt.*init'
# tmp.nocrash is the example without "extern crate libc"
[5197 john ~]% nm tmp.nocrash| grep 'rt.*init'
0000000100054690 T __ZN2io25IoFactory.rtio..IoFactory10timer_init20hc9a34fb8d223cf2672dE
0000000100061460 T __ZN2rt4init20h9bb1881593d90783tirE
I was able to get this bug to go away by rebuilding rustc manually with --enable-rpath.
Previously, I had built rustc via homebrew's --HEAD option. @oblitum is that how you built rustc as well? The only config options I see in the homebrew file are --disable-rpath and --enable-clang. Could one of those be causing this?
@jgallagher probably. I'm using rust just like you said: homebrew --HEAD.
@oblitum With much help from @alexcrichton and a lot of detective work, this is what's going on:
There are three possible fixes:
export DYLD_LIBRARY_PATH=/usr/local/lib/rustlib/x86_64-apple-darwin/lib
.@jgallagher thanks for the detailed report!
Triage: ahhhh the old runtime failure error message. These were the days :smile:
Given this ticket hasn't seen an update in over two years, and involves a bunch of stuff that doesn't exist anymore, I'm going to give it a close.
@steveklabnik just cc'ed it on #14662, just in case.
I'm at 66a0b52 and I'm trying phildawes/racer@07b2346 on OS X, but the only thing I'm getting is: