fatal runtime error: assertion failed: !ptr.is_null()

[oblitum]

I'm at 66a0b52 and I'm trying phildawes/racer@07b2346 on OS X, but the only thing I'm getting is:

➤ /opt/src/racer/bin/racer complete std::io::

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()
Illegal instruction: 4
➤ /opt/src/racer/bin/racer complete 10 26 sample.rs
PREFIX 25,26,c

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()
Illegal instruction: 4

[alexcrichton]

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?

[oblitum]

@alexcrichton at this moment, not from my side, since I don't have knownledge on both codebases. Any help @phildawes?

[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?

[oblitum]

@phildawes I have just pulled rust and built it and tried again, same error..

[oblitum]

still happening in 3be6a2f with phildawes/racer@ecde206.

[jgallagher]

@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```

[jgallagher]

Should've specified that is with rust revision b7aa03a

[jgallagher]

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);
}

[alexcrichton]

I'm unable to reproduce the assertion failure on the test case you gave, did you just compile and run it?

[jgallagher]

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 ()

[jgallagher]

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

[jgallagher]

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?

[oblitum]

@jgallagher probably. I'm using rust just like you said: homebrew --HEAD.

[jgallagher]

@oblitum With much help from @alexcrichton and a lot of detective work, this is what's going on:

• Rust currently installs two copies of some of the libraries it uses ("stage1" and "stage2" artifacts) - they should be identical in any meaningful way (e.g., they export all the same symbols). You can see this as /usr/local/lib/.dylib (stage1) and /usr/local/lib/rustlib/x86_64-apple-darwin/lib/.dylib (stage2).
• The stage1 libraries are only supposed to be installed because rustc itself depends on them.
• The stage2 libraries that have dependencies (e.g., librustc, which is used by Racer) are supposed to be linked against other stage2 libraries.
• When Homebrew does the final installation of rust, it uses install_name_tool to change all the dylib dependencies from relative paths (which make no sense and are just whatever the filesystem happened to look like when rust was built) to absolute paths to /usr/local/Cellar and related locations.
• Because rust installs two copies of some libraries, homebrew is finding the wrong ones, and making some stage2 libraries dependent on stage1 libraries.
• When we try to build Racer or other programs that dynamically link against stage2 libraries, the binary is linked against stage2 but the stage2 libs are themselves linking against stage1 due to the Homebrew rewrite thing. This means there are two instances of the rust runtime, resulting in the assertions we're seeing.

There are three possible fixes:

• Wait for #14662 to be closed. When the stage1 libs are no longer distributed, Homebrew won't find them and will correctly rewrite the library dependency paths. (This is the real long term fix I think.)
• Set DYLD_LIBRARY_PATH like so: export DYLD_LIBRARY_PATH=/usr/local/lib/rustlib/x86_64-apple-darwin/lib.
• Install Rust using some mechanism other than Homebrew. (This may still require setting DYLD_LIBRARY_PATH, depending on how and where you install it.)

[oblitum]

@jgallagher thanks for the detailed report!

[steveklabnik]

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.

[oblitum]

@steveklabnik just cc'ed it on #14662, just in case.