Segfault on NetBSD when run from $PATH

[dcuddeback]

When running rustup without an explicit path, I get a segmentation fault:

$ rustup --version
Segmentation fault (core dumped)
$ which rustup
/home/david/.cargo/bin/rustup
$ echo $PATH
/home/david/.cargo/bin:/usr/bin:/bin:/usr/pkg/bin:/usr/local/bin

It works when run with an explicit path:

$ ~/.cargo/bin/rustup --version
rustup 0.1.8 (3cb86ed 2016-04-28)

The same is true for the tools installed by rustup:

$ ~/.cargo/bin/rustc --version
rustc 1.10.0-nightly (8da2bcac5 2016-04-28)
$ rustc --version
Segmentation fault (core dumped)
$ which rustc
/home/david/.cargo/bin/rustc

This is on a fresh install of NetBSD 7.0 on a virtual machine:

$ uname -a
NetBSD netbsd-7-dev 7.0 NetBSD 7.0 (GENERIC.201509250726Z) amd64

The backtrace ends at a NULL pointer:

$ gdb -q ~/.cargo/bin/rustup rustup.core -ex bt
Reading symbols from /home/david/.cargo/bin/rustup...done.
[New process 1]
Core was generated by `rustup'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f7ffffde370 in ?? ()
#0  0x00007f7ffffde370 in ?? ()
#1  0x000000000062856a in ?? ()
#2  0x0000000000a09a90 in ?? ()
#3  0x00007f7ffffde404 in ?? ()
#4  0x0000000000000000 in ?? ()

I installed from the rustup-init binary in the README, because NetBSD doesn't seem to be supported by curl https://sh.rustup.rs -sSf | sh:

wget --no-check-certificate https://static.rust-lang.org/rustup/dist/x86_64-unknown-netbsd/rustup-init
chmod +x rustup-init
./rustup-init --default-toolchain=nightly -y

[dcuddeback]

Here's a Vagrantfile for a quick reproduction:

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "kja/netbsd-7-amd64"
  config.vm.hostname = "rustup-issue-388"

  config.vm.synced_folder ".", "/vagrant", disabled: true

  config.vm.provider "virtualbox" do |vb|
    vb.gui = false
    vb.name = "rustup-issue-388"
    vb.cpus = 1
    vb.memory = 4*1024
  end

  config.vm.provision :shell, privileged: false, inline: <<-SHELL
    wget --no-check-certificate https://static.rust-lang.org/rustup/dist/x86_64-unknown-netbsd/rustup-init
    chmod +x rustup-init
    ./rustup-init -y --default-toolchain=nightly
  SHELL
end

Assuming you have Vagrant and VirtualBox installed, save this as Vagrantfile, then run vagrant up and vagrant ssh to connect to the machine. Running rustup will result in a segfault.

[brson]

Sorry I haven't looked into this. I'm not a NetBSD user so it's just a low priority for me. Help wanted.

[erde74]

Hello, i use NetBSD i could try to help you. I could do some tests.

[brson]

@erde74 Thank you! Have you reproduced this?

One thing you might try to do is build it locally in debug mode and see if you can figure out with a debugger where the crash is happening.

[erde74]

do you mean rustup.rs or rustc and cargo? i tried to build rustup.rs and it works like expected. i need to mention if i modify my path from export PATH="$PATH:$HOME/.cargo/bin" to export PATH="$HOME/.multirust/toolchains/stable-x86_64-unknown-netbsd/bin:$PATH" and now it works.

[erde74]

Hello,
I did some tests, when i download rustup-init and run it. I can reproduce the problem.
When i checkout the sources from git and use the local compiled version, i get

Shared object "libcurl.so.4" not found

after

export LD_LIBRARY_PATH=/usr/pkg/lib'

it seems to work like it should.

[brson]

@erde74 Thank you for the investigation! Perhaps there's a problem with our build environment. It looks like we're using Ubuntu's NetBSD toolchain on @alexcrichton's docker image. Not sure what Ubuntu that's based off of.

We could possibly try to reproduce it there, possibly adjust the build settings on the bots for either rustc or gcc to add debug info, reduce optimizations see if we can stir up more information.

[brson]

Since rustup seems to work when run directly on NetBSD, and the rustc LLVM backend is the same regardless of host platform, I might guess that the crash is in OpenBSD, the only C program that's part of the build, that uses the Ubuntu NetBSD cross compiler.

[brson]

In #635 @Boddlnagg discovered that our builds are using an ancient toolchain. Upgrading that may fix this problem.

[brson]

Toolchain upgrade: #651

[erde74]

i got this now, while running rustup

if i do "/home/stefan/.cargo/bin/rustup" it works

#0 0x00007f7fff935370 in ?? ()
#1 0x00000000634dff6a in backtrace_pcinfo ()
#2 0x00000000634dde6e in backtrace::symbolize::libbacktrace::resolve::hb54fdb6f97e8b2a6 ()
#3 0x00000000634de283 in backtrace::capture::Backtrace::new::_$u7b$$u7b$closure$u7d$$u7d$::h8c8e495362f5824e ()
#4 0x00000000634dd7ed in backtrace::backtrace::libunwind::trace::trace_fn::h3a2f321306e332c8 ()
#5 0x00007e8a1c8049e5 in _Unwind_Backtrace () from /usr/lib/libgcc_s.so.1
#6 0x00000000634de20e in backtrace::backtrace::trace::h0b153d57556bb63f ()
#7 0x00000000634de190 in backtrace::capture::Backtrace::new::h3a3d5e9defd7d407 ()
#8 0x000000006324952e in _$LT$errors..Error$u20$as$u20$std..convert..From$LT$errors..ErrorKind$GT$$GT$::from::h7af083c6413a7d7e ()
#9 0x0000000063256957 in rustup_utils::utils::cargo_home::hae3b436b1540b91c ()
#10 0x00000000630a33db in rustup_init::run_multirust::h172cfe3ff9832782 ()
#11 0x00000000630a2d92 in rustup_init::main::h81d74e5ca7cf36c2 ()
#12 0x000000006350bbde in std::sys_common::unwind::try::try_fn::h76efc8ed010787e5 ()
#13 0x00000000635030bc in __rust_try ()
#14 0x0000000063503036 in std::sys_common::unwind::inner_try::h012db03be6c2ef95 ()
#15 0x000000006350b5e7 in std::rt::lang_start::h73c48c6a9af036ed ()
#16 0x00000000630a2ca5 in ___start ()
#17 0x00007f7f5b60570b in _rtld () from /usr/libexec/ld.elf_so
#18 0x00007f7fff93cb96 in ?? ()
#19 0x00007f7fff93cba2 in ?? ()
#20 0x00007f7fff93cbbc in ?? ()
#21 0x00007f7fff93cbc6 in ?? ()
#22 0x00007f7fff93cbd5 in ?? ()
#23 0x00007f7fff93cbe3 in ?? ()
#24 0x00007f7fff93cc04 in ?? ()
#25 0x00007f7fff93cc11 in ?? ()
#26 0x00007f7fff93cc23 in ?? ()
#27 0x00007f7fff93cc30 in ?? ()
#28 0x00007f7fff93cc49 in ?? ()
#29 0x0000000000000000 in ?? ()

[iquiw]

I have seen the same problem, but it seems to be solved on the current master (fcc0396).

[Diggsey]

Thanks @iquiw, closing this for now.
@erde74 if this is still happening, please re-open!