rustc -vV segmentation fault

[bbigras]

I don't know if it's related to #52772. In my case rustc --version doesn't segfault, only rustc -vV does.

I'm running it on NixOS with nix-shell.

$ rustup show
Default host: x86_64-unknown-linux-gnu

nightly-x86_64-unknown-linux-gnu (default)
(error reading rustc version)

$ rustc --version
rustc 1.33.0-nightly (c2d381d39 2019-01-10)

shell.nix

let
  moz_overlay = import (builtins.fetchTarball https://github.com/mozilla/nixpkgs-mozilla/archive/master.tar.gz);
  nixpkgs = import <nixpkgs> { overlays = [ moz_overlay ]; };
in
  with nixpkgs;
  stdenv.mkDerivation {
    name = "moz_overlay_shell";
    buildInputs = [
      (nixpkgs.rustChannelOf { date = "2019-01-11"; channel = "nightly"; }).rust
      ];
  }

$ gdb -quiet --args rustc -vV
Reading symbols from rustc...done.
(gdb) run
Starting program: /nix/store/jknmv24nl8zz0cacn14y317kms1521ra-rust-1.33.0-nightly-2019-01-10-c2d381d39/bin/rustc -vV
warning: File "/nix/store/95i38z61425xrci8h178blwff88p0a4h-gcc-7.3.0-lib/lib/libstdc++.so.6.0.24-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
        add-auto-load-safe-path /nix/store/95i38z61425xrci8h178blwff88p0a4h-gcc-7.3.0-lib/lib/libstdc++.so.6.0.24-gdb.py
line to your configuration file "/home/bbigras2/.gdbinit".
To completely disable this security protection add
        set auto-load safe-path /
line to your configuration file "/home/bbigras2/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
        info "(gdb)Auto-loading safe path"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/7gx4kiv5m0i7d7qkixq2cwzbr10lvxwc-glibc-2.27/lib/libthread_db.so.1".
[New Thread 0x7fffef5ff700 (LWP 11468)]
rustc 1.33.0-nightly (c2d381d39 2019-01-10)
binary: rustc
commit-hash: c2d381d39d282c0586d50ea7d7a431ffd5ddb3fb
commit-date: 2019-01-10
host: x86_64-unknown-linux-gnu
release: 1.33.0-nightly

Thread 2 "rustc" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffef5ff700 (LWP 11468)]
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff70f7079 in __pthread_once_slow () from /nix/store/7gx4kiv5m0i7d7qkixq2cwzbr10lvxwc-glibc-2.27/lib/libpthread.so.0
#2  0x00007fffe9e43413 in llvm::cl::OptionCategory::registerCategory() ()
   from /nix/store/jknmv24nl8zz0cacn14y317kms1521ra-rust-1.33.0-nightly-2019-01-10-c2d381d39/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/../lib/libLLVM-8svn.so
#3  0x00007fffe9e55553 in _GLOBAL__sub_I_CommandLine.cpp ()
   from /nix/store/jknmv24nl8zz0cacn14y317kms1521ra-rust-1.33.0-nightly-2019-01-10-c2d381d39/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/../lib/libLLVM-8svn.so
#4  0x00007ffff7de702a in call_init.part () from /nix/store/7gx4kiv5m0i7d7qkixq2cwzbr10lvxwc-glibc-2.27/lib/ld-linux-x86-64.so.2
#5  0x00007ffff7de713b in _dl_init () from /nix/store/7gx4kiv5m0i7d7qkixq2cwzbr10lvxwc-glibc-2.27/lib/ld-linux-x86-64.so.2
#6  0x00007ffff7deb0f4 in dl_open_worker () from /nix/store/7gx4kiv5m0i7d7qkixq2cwzbr10lvxwc-glibc-2.27/lib/ld-linux-x86-64.so.2
#7  0x00007ffff6a529cc in _dl_catch_exception () from /nix/store/7gx4kiv5m0i7d7qkixq2cwzbr10lvxwc-glibc-2.27/lib/libc.so.6
#8  0x00007ffff7deaa77 in _dl_open () from /nix/store/7gx4kiv5m0i7d7qkixq2cwzbr10lvxwc-glibc-2.27/lib/ld-linux-x86-64.so.2
#9  0x00007ffff6ee4fc6 in dlopen_doit () from /nix/store/7gx4kiv5m0i7d7qkixq2cwzbr10lvxwc-glibc-2.27/lib/libdl.so.2
#10 0x00007ffff6a529cc in _dl_catch_exception () from /nix/store/7gx4kiv5m0i7d7qkixq2cwzbr10lvxwc-glibc-2.27/lib/libc.so.6
#11 0x00007ffff6a52a4f in _dl_catch_error () from /nix/store/7gx4kiv5m0i7d7qkixq2cwzbr10lvxwc-glibc-2.27/lib/libc.so.6
#12 0x00007ffff6ee5619 in _dlerror_run () from /nix/store/7gx4kiv5m0i7d7qkixq2cwzbr10lvxwc-glibc-2.27/lib/libdl.so.2
#13 0x00007ffff6ee5056 in dlopen@@GLIBC_2.2.5 () from /nix/store/7gx4kiv5m0i7d7qkixq2cwzbr10lvxwc-glibc-2.27/lib/libdl.so.2
#14 0x00007ffff45febb4 in rustc_metadata::dynamic_lib::dl::open ()
   from /nix/store/jknmv24nl8zz0cacn14y317kms1521ra-rust-1.33.0-nightly-2019-01-10-c2d381d39/bin/../lib/../lib/librustc_metadata-8089fdf4fd6a5a3b.so
#15 0x00007ffff46458c8 in rustc_metadata::dynamic_lib::DynamicLibrary::open ()
   from /nix/store/jknmv24nl8zz0cacn14y317kms1521ra-rust-1.33.0-nightly-2019-01-10-c2d381d39/bin/../lib/../lib/librustc_metadata-8089fdf4fd6a5a3b.so
#16 0x00007ffff7661cae in rustc_driver::load_backend_from_dylib ()
   from /nix/store/jknmv24nl8zz0cacn14y317kms1521ra-rust-1.33.0-nightly-2019-01-10-c2d381d39/bin/../lib/librustc_driver-701dfbab6509fb05.so
#17 0x00007ffff7662d4c in rustc_driver::get_codegen_sysroot ()
   from /nix/store/jknmv24nl8zz0cacn14y317kms1521ra-rust-1.33.0-nightly-2019-01-10-c2d381d39/bin/../lib/librustc_driver-701dfbab6509fb05.so
#18 0x00007ffff766b096 in rustc_driver::version ()
   from /nix/store/jknmv24nl8zz0cacn14y317kms1521ra-rust-1.33.0-nightly-2019-01-10-c2d381d39/bin/../lib/librustc_driver-701dfbab6509fb05.so
#19 0x00007ffff766e39b in rustc_driver::handle_options ()
   from /nix/store/jknmv24nl8zz0cacn14y317kms1521ra-rust-1.33.0-nightly-2019-01-10-c2d381d39/bin/../lib/librustc_driver-701dfbab6509fb05.so
#20 0x00007ffff7663780 in rustc_driver::run_compiler ()
   from /nix/store/jknmv24nl8zz0cacn14y317kms1521ra-rust-1.33.0-nightly-2019-01-10-c2d381d39/bin/../lib/librustc_driver-701dfbab6509fb05.so
#21 0x00007ffff766f9eb in <scoped_tls::ScopedKey<T>>::set ()
   from /nix/store/jknmv24nl8zz0cacn14y317kms1521ra-rust-1.33.0-nightly-2019-01-10-c2d381d39/bin/../lib/librustc_driver-701dfbab6509fb05.so
#22 0x00007ffff7742be3 in std::sys_common::backtrace::__rust_begin_short_backtrace ()
   from /nix/store/jknmv24nl8zz0cacn14y317kms1521ra-rust-1.33.0-nightly-2019-01-10-c2d381d39/bin/../lib/librustc_driver-701dfbab6509fb05.so
#23 0x00007ffff737d56a in __rust_maybe_catch_panic () at src/libpanic_unwind/lib.rs:92
#24 0x00007ffff774e261 in <F as alloc::boxed::FnBox<A>>::call_box ()
   from /nix/store/jknmv24nl8zz0cacn14y317kms1521ra-rust-1.33.0-nightly-2019-01-10-c2d381d39/bin/../lib/librustc_driver-701dfbab6509fb05.so
#25 0x00007ffff737c32e in _$LT$alloc..boxed..Box$LT$$LP$dyn$u20$alloc..boxed..FnBox$LT$A$C$$u20$Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$RP$$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::hb8a717666535f7b2 () at /rustc/c2d381d39d282c0586d50ea7d7a431ffd5ddb3fb/src/liballoc/boxed.rs:744
#26 std::sys_common::thread::start_thread () at src/libstd/sys_common/thread.rs:14
#27 std::sys::unix::thread::Thread::new::thread_start () at src/libstd/sys/unix/thread.rs:81
#28 0x00007ffff70ef5a7 in start_thread () from /nix/store/7gx4kiv5m0i7d7qkixq2cwzbr10lvxwc-glibc-2.27/lib/libpthread.so.0
#29 0x00007ffff6a1a22f in clone () from /nix/store/7gx4kiv5m0i7d7qkixq2cwzbr10lvxwc-glibc-2.27/lib/libc.so.6
(gdb)

[bbigras]

It seems it began with rustc 1.33.0-nightly (d22fa2d87 2019-01-08). I hope it's not a problem on my side.

$ rustc -vV
rustc 1.33.0-nightly (8e2063d02 2019-01-07)
binary: rustc
commit-hash: 8e2063d02062ee9f088274690a97826333847e17
commit-date: 2019-01-07
host: x86_64-unknown-linux-gnu
release: 1.33.0-nightly
LLVM version: 8.0

$ rustc -vV
rustc 1.33.0-nightly (d22fa2d87 2019-01-08)
binary: rustc
commit-hash: d22fa2d87d03d19fdb1359faab9ec5e74eff26b3
commit-date: 2019-01-08
host: x86_64-unknown-linux-gnu
release: 1.33.0-nightly
Segmentation fault

[bbigras]

This segfault breaks flycheck btw. At least I can use 2019-01-07 for now.

[nagisa]

I can reproduce.

[nagisa]

It could be an issue somewhere in the system exacerbated by dynamic loading.

Namely what happens is that __pthread_once_slow calls this C++ proxy, which then goes to fetch data from a thread-local variable. Although it succeeds in fetching the memory area of the thread-local storage, the actual slot is not initialized (is zeroed). The code then immediately calls the slot and jumps into 0x0.

It is most likely some sort of an issue in how LLVM uses synchronisation, but like I said before the root cause may be dynamic loading.

This is the list of commits in the regression range. cc @alexcrichton that -static-libstdc++ commit seems very suspect.

[alexcrichton]

One problem that this may be encountering is that we may be linking libstdc++ twice, once into libLLVM.so and once into librustc_codegen_llvm.so (the codegen backend). The latter may be getting included with our src/rustllvm/*.cpp. I can't really confirm that, though, it's just a suspicion.

Is there a way to reproduce this? Or is it possible to narrow down to what's causing it?

[bbigras]

Is there a way to reproduce this?

Here's a way to reproduce it with Nix but I have no idea how to have the Mozilla overlay use Rust from a local git checkout. I was able to reproduce it with Nix on Ubuntu.

• Install nix (see https://nixos.org/nix/ or run curl https://nixos.org/nix/install | sh)
• relog or run the command to have the environment variables set
• create the shell.nix file
• run nix-shell
• run rustc -vV

shell.nix

let
  moz_overlay = import (builtins.fetchTarball https://github.com/mozilla/nixpkgs-mozilla/archive/master.tar.gz);
  nixpkgs = import <nixpkgs> { overlays = [ moz_overlay ]; };
in
  with nixpkgs;
  stdenv.mkDerivation {
    name = "moz_overlay_shell";
    buildInputs = [
      (nixpkgs.rustChannelOf { date = "2019-01-11"; channel = "nightly"; }).rust
      ];
  }

[alexcrichton]

Hm ok is there a way to reproduce this without nix? Or perhaps can you try to narrow it down to see what's causing it?

[pnkfelix]

triage: Tempted to assign to @nagisa . Also tempted to tag as P-medium, unless we get indication that this could be expected to affect platforms other than Nix

[nagisa]

This does not reproduce on a rustc built locally, although as always, my configuration may not match what dist builders have exactly...

[Ralith]

Affecting me as well; I haven't been able to use a nightly since the seventh, which is aggravating when futures-preview requires a newer nightly and cargo ignores specific prerelease version requirements...

[Ralith]

Reviewing d585553 cited above, it looks like the intention is that libstdc++ is no longer statically linked? That's definitely not what's happening here:

$ ldd `which rustc`
	linux-vdso.so.1 (0x00007fffbb1fb000)
	/nix/store/95i38z61425xrci8h178blwff88p0a4h-gcc-7.3.0-lib/lib/libstdc++.so.6 (0x00007f3371b3b000)
	...

$ readelf -d `which rustc`
Dynamic section at offset 0x460268 contains 35 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [/nix/store/95i38z61425xrci8h178blwff88p0a4h-gcc-7.3.0-lib/lib/libstdc++.so.6]
...

[maackle]

We're seeing the same problem, on both 2019-01-17 and 2019-01-21. Again, only with nix.

[nagisa]

This is a bug in the rustc overlay. Specifically this line is the cause of all the issues observed here. Removing that line makes stuff work as expected.

Closing. Filled a bug with the overlay instead mozilla/nixpkgs-mozilla#152.