Segfault in rustc -v on Linux when libunwind is present during compilation

[mlen]

I found a segfault in rustc that happens only when libunwind.so is present in the system during the build. Even though it should use libgcc_s.so, libunwind implementation is used instead.

The problem disappears when I uninstall libunwind and then rebuild Rust -- it correctly uses libgcc_s.so. While this could be a possible workaround other packages I use need this library installed.

Expected:

$ rustc -v
error: no input filename given

$

Actual:

$ rustc -v
error: no input filename given

Segmentation fault
$ dmesg | tail -1
[130216.618605] rustc[2142]: segfault at 0 ip 00007fc3e16174ee sp 00007ffdb724fc20 error 4 in libstd-1a86a61763c2b34b.so[7fc3e1542000+176000]
$

Steps to reproduce

• Install libunwind-dev or equivalent (library + development files)
• Build Rust
• Run rustc -v

Meta

rustc --version --verbose:

rustc 1.28.0-dev
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.28.0-dev
LLVM version: 6.0

I collected the backtraces below with gdb and rr

Backtrace (last call to _Unwind_Resume before crash):

#0  0x00007f8d4dc19bf0 in __libunwind_Unwind_Resume () from /usr/lib64/libunwind.so.8
#1  0x00007f8d53ee87ad in <rustc_driver::RustcDefaultCalls as rustc_driver::CompilerCalls<'a>>::no_input () from /usr/lib64/librustc_driver-f1b059b9d0550531.so
#2  0x00007f8d53ee3ca2 in rustc_driver::run_compiler_with_pool () from /usr/lib64/librustc_driver-f1b059b9d0550531.so
#3  0x00007f8d53e4902c in <scoped_tls::ScopedKey<T>>::set () from /usr/lib64/librustc_driver-f1b059b9d0550531.so
#4  0x00007f8d53e1ddbe in syntax::with_globals () from /usr/lib64/librustc_driver-f1b059b9d0550531.so
#5  0x00007f8d53dfe783 in <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once () from /usr/lib64/librustc_driver-f1b059b9d0550531.so
#6  0x00007f8d53ab21da in __rust_maybe_catch_panic () from /usr/lib64/libstd-1a86a61763c2b34b.so
#7  0x00007f8d53ee1871 in rustc_driver::run () from /usr/lib64/librustc_driver-f1b059b9d0550531.so
#8  0x00007f8d53ef162b in rustc_driver::main () from /usr/lib64/librustc_driver-f1b059b9d0550531.so
#9  0x000055e87feadac3 in std::rt::lang_start::{{closure}} ()
#10 0x00007f8d53a77413 in std::panicking::try::do_call () from /usr/lib64/libstd-1a86a61763c2b34b.so
#11 0x00007f8d53ab21da in __rust_maybe_catch_panic () from /usr/lib64/libstd-1a86a61763c2b34b.so
#12 0x00007f8d53a6c166 in std::rt::lang_start_internal () from /usr/lib64/libstd-1a86a61763c2b34b.so
#13 0x000055e87feadb24 in main ()

Backtrace (after resume):

#0  0x00007f8d53eda2b0 in core::ptr::drop_in_place () from /usr/lib64/librustc_driver-f1b059b9d0550531.so
#1  0x00007f8d53ee4e0a in rustc_driver::run_compiler_with_pool () from /usr/lib64/librustc_driver-f1b059b9d0550531.so
#2  0x00007ffd2d23f170 in ?? ()
#3  0x0000000000000000 in ?? ()

Backtrace (at the time of crash):

#0  je_rtree_get (dependent=true, key=0, rtree=<optimized out>)
    at /var/tmp/portage/dev-lang/rust-1.28.0-r2/work/rustc-1.28.0-src/src/liballoc_jemalloc/../jemalloc/include/jemalloc/internal/rtree.h:325
#1  je_chunk_lookup (dependent=true, ptr=0x0)
    at /var/tmp/portage/dev-lang/rust-1.28.0-r2/work/rustc-1.28.0-src/src/liballoc_jemalloc/../jemalloc/include/jemalloc/internal/chunk.h:89
#2  huge_node_get (ptr=0x0)
    at /var/tmp/portage/dev-lang/rust-1.28.0-r2/work/rustc-1.28.0-src/src/liballoc_jemalloc/../jemalloc/src/huge.c:11
#3  je_huge_dalloc (tsdn=0x7ffff7fdf530, ptr=0x0)
    at /var/tmp/portage/dev-lang/rust-1.28.0-r2/work/rustc-1.28.0-src/src/liballoc_jemalloc/../jemalloc/src/huge.c:424
#4  0x00007ffff7ac7e0a in rustc_driver::run_compiler_with_pool () from /usr/lib64/librustc_driver-f1b059b9d0550531.so
#5  0x00007fffffffb6a0 in ?? ()
#6  0x0000000000000000 in ?? ()

[djc]

It looks like the build process is automagically linking in libunwind if installed, which doesn't seem intentional on the part of the build script. Is there some way to prevent this?

@alexcrichton, looks like you've reviewed code in that area, any ideas?

[alexcrichton]

Unfortunately I'm not sure where this is getting pulled in, from what it looks like scanning libstd on Linux we shouldn't ever explicitly link to libunwind to pull it in.

[Enselic]

Triage: Can this still be reproduced in modern systems? I couldn't when I tried. I notice you are using rustc provided by your distro (/usr/lib64/libstd-1a86a61763c2b34b.so). Why should we not assume the distro accidentally built rustc the wrong way? I'm tempted to close this as "not a rust project bug" but maybe you can show that it is in fact a rustc bug?