segfault with -C lto with rustc 1.43.0, 1.44.0 on s390x

[mwhudson]

I'm updating rustc and cargo on Ubuntu. The build of cargo 0.44.1 on s390x with rustc 1.43.0 fails:

https://launchpad.net/~mwhudson/+archive/ubuntu/rust-stuff/+build/19366472

One of the failing tests runs this command:

rustc --crate-name test src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C opt-level=3 -C lto -C metadata=7394e033338f9890 -C extra-filename=-7394e033338f9890 --out-dir /build/cargo-IGXegx/cargo-0.44.1/target/s390x-unknown-linux-gnu/cit/t263/foo/target/release/deps -L dependency=/build/cargo-IGXegx/cargo-0.44.1/target/s390x-unknown-linux-gnu/cit/t263/foo/target/release/deps

I expected to see this happen: not a segfault

Instead, this happened: "Segmentation fault (core dumped)"

The backtrace from gdb is this:

(gdb) bt
#0  memcpy () at ../sysdeps/s390/memcpy-z900.S:191
#1  0x000003fff599b0d4 in core::intrinsics::copy_nonoverlapping (src=0x1 <error: Cannot access memory at address 0x1>, dst=<optimized out>, count=16)
    at /usr/src/rustc-1.43.0/src/libcore/intrinsics.rs:1999
#2  core::slice::<impl [T]>::copy_from_slice (self=..., src=...) at /usr/src/rustc-1.43.0/src/libcore/slice/mod.rs:2280
#3  <alloc::vec::Vec<T> as alloc::vec::SpecExtend<&T,core::slice::Iter<T>>>::spec_extend (self=0x3fff06b31f8, iterator=...) at /usr/src/rustc-1.43.0/src/liballoc/vec.rs:2124
#4  <alloc::vec::Vec<T> as core::iter::traits::collect::Extend<&T>>::extend (self=0x3fff06b31f8, iter=...) at /usr/src/rustc-1.43.0/src/liballoc/vec.rs:2265
#5  <&str as std::ffi::c_str::CString::new::SpecIntoVec>::into_vec (self=...) at src/libstd/ffi/c_str.rs:346
#6  0x000003fff67be9de in std::ffi::c_str::CString::new (t=...) at /usr/src/rustc-1.43.0/src/libstd/ffi/c_str.rs:351
#7  rustc_codegen_llvm::back::lto::fat_lto (cgcx=0x3fff06b3910, diag_handler=0x3fff06b3310, symbol_white_list=..., modules=..., cached_modules=..., serialized_modules=...)
    at src/librustc_codegen_llvm/back/lto.rs:270
#8  rustc_codegen_llvm::back::lto::run_fat (cgcx=0x3fff06b3910, modules=..., cached_modules=...) at src/librustc_codegen_llvm/back/lto.rs:147
#9  0x000003fff6639dac in <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::write::WriteBackendMethods>::run_fat_lto (cgcx=0x3fff06b3910, modules=..., cached_modules=...)
    at src/librustc_codegen_llvm/lib.rs:141
#10 rustc_codegen_ssa::back::write::generate_lto_work (cgcx=0x3fff06b3910, needs_fat_lto=..., needs_thin_lto=..., import_only_modules=...)
    at /usr/src/rustc-1.43.0/src/librustc_codegen_ssa/back/write.rs:284
#11 0x000003fff67a5f1c in rustc_codegen_ssa::back::write::start_executing_work::{{closure}} () at /usr/src/rustc-1.43.0/src/librustc_codegen_ssa/back/write.rs:1304
#12 std::sys_common::backtrace::__rust_begin_short_backtrace (f=...) at /usr/src/rustc-1.43.0/src/libstd/sys_common/backtrace.rs:130
#13 0x000003fff67009f8 in std::thread::Builder::spawn_unchecked::{{closure}}::{{closure}} () at /usr/src/rustc-1.43.0/src/libstd/thread/mod.rs:475
#14 <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once (self=..., _args=<optimized out>) at /usr/src/rustc-1.43.0/src/libstd/panic.rs:318
#15 std::panicking::try::do_call (data=0x3fff06b4648 "") at /usr/src/rustc-1.43.0/src/libstd/panicking.rs:303
#16 0x000003fff59a1938 in __rust_try () from /lib/s390x-linux-gnu/libstd-388f52bec4c8e58e.so
#17 0x000003fff59a1822 in __rust_maybe_catch_panic (f=<optimized out>, data=<optimized out>, data_ptr=0x3fff06b4638, vtable_ptr=0x3fff06b4640) at src/libpanic_unwind/lib.rs:86
#18 0x000003fff6621e4a in std::panicking::try (f=...) at /usr/src/rustc-1.43.0/src/libstd/panicking.rs:281
#19 std::panic::catch_unwind (f=...) at /usr/src/rustc-1.43.0/src/libstd/panic.rs:394
#20 std::thread::Builder::spawn_unchecked::{{closure}} () at /usr/src/rustc-1.43.0/src/libstd/thread/mod.rs:474
#21 core::ops::function::FnOnce::call_once{{vtable-shim}} () at /usr/src/rustc-1.43.0/src/libcore/ops/function.rs:232
#22 0x000003fff5956028 in <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once (self=..., args=<optimized out>) at /usr/src/rustc-1.43.0/src/liballoc/boxed.rs:1017
#23 0x000003fff596d428 in <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once (self=0x3ffec6f6ec0, args=<optimized out>) at /usr/src/rustc-1.43.0/src/liballoc/boxed.rs:1017
#24 std::sys_common::thread::start_thread (main=<optimized out>) at src/libstd/sys_common/thread.rs:13
#25 std::sys::unix::thread::Thread::new::thread_start (main=0x3ffec6f6ec0) at src/libstd/sys/unix/thread.rs:80
#26 0x000003fff55099f6 in start_thread (arg=0x3fff06b5900) at pthread_create.c:477
#27 0x000003fff58067e6 in thread_start () at ../sysdeps/unix/sysv/linux/s390/s390-64/clone.S:65

src=0x1 in #1 0x000003fff599b0d4 in core::intrinsics::copy_nonoverlapping (src=0x1 <error: Cannot access memory at address 0x1>, dst=<optimized out>, count=16) sure looks bad.

I don't have a lot of time to dig into this now, will be able to get back to it and run more tests Tuesday NZ time if there's anything I can run that would be useful.

[mwhudson]

One (rather obvious from the traceback) thing: removing "-C lto" from the invocation makes it pass.

The same code passes tests on all other ubuntu architectures, amd64, i386, arm64, ppc64el (not riscv64 because our rustc 1.43.0 didn't build there)

[mwhudson]

This happens with any use of -C lto, and happens with stable (rustc 1.43.1 (8d69840ab 2020-05-04)) and beta (rustc 1.44.0-beta.4 (02c25b359 2020-05-23)) installed via rustup but not 1.42.0 (rustc 1.42.0 (b8cedc004 2020-03-09)) or nightly (rustc 1.45.0-nightly (5fd2f06e9 2020-05-31)).

ubuntu@juju-b11c42-ubuntu-23:~$ rustup default stable
info: using existing install for 'stable-s390x-unknown-linux-gnu'
info: default toolchain set to 'stable-s390x-unknown-linux-gnu'

  stable-s390x-unknown-linux-gnu unchanged - rustc 1.43.1 (8d69840ab 2020-05-04)

ubuntu@juju-b11c42-ubuntu-23:~$ cat hello.rs
fn main() {
    println!("Hello World!");
}
ubuntu@juju-b11c42-ubuntu-23:~$ rustc -C lto hello.rs 
Segmentation fault (core dumped)

[msirringhaus]

I can confirm this issue. Same happens on SUSE.

The log says:

[1054066.219979] User process fault: interruption code 003b ilc:3 in libc-2.26.so[3ffa6c80000+1a0000]
[1054066.219990] Failing address: 0000000000000000 TEID: 0000000000000800
[1054066.219991] Fault in primary space mode while using user ASCE.
[1054066.219993] AS:0000000018b541c7 R3:0000000000000024 
[1054066.219998] CPU: 0 PID: 49385 Comm: rustc Tainted: G                   4.12.14-195-default #1 SLE15-SP1
[1054066.219998] Hardware name: IBM 2827 H43 400 (z/VM 6.1.0)
[1054066.220000] task: 0000000015ee2000 task.stack: 00000000341a4000
[1054066.220001] User PSW : 0705000180000000 000003ffa6d20876
[1054066.220003]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3
[1054066.220004] User GPRS: 0000000000000008 000003ff980028f0 000003ff980028f0 0000000000000001
[1054066.220005]            0000000000000012 0000000000000000 0000000000000013 000003ffa0814370
[1054066.220006]            0000000000000001 000003ffa080c700 0000000000000014 0000000000000001
[1054066.220007]            000003ff9deb52b8 0000000000000013 000003ffa6edfeb8 000003ff9deb4f10
[1054066.220016] User Code: 000003ffa6d20868: eb540008000c      srlg    %r5,%r4,8
                            000003ffa6d2086e: b9020055          ltgr    %r5,%r5
                           #000003ffa6d20872: a7740006          brc     7,3ffa6d2087e
                           >000003ffa6d20876: c6400000001c      exrl    %r4,3ffa6d208ae
                            000003ffa6d2087c: 07fe              bcr     15,%r14
                            000003ffa6d2087e: c25c00040000      cgfi    %r5,262144
                            000003ffa6d20884: a7240076          brc     2,3ffa6d20970
                            000003ffa6d20888: e31033000036      pfd     1,768(%r3)
[1054066.220029] Last Breaking-Event-Address:
[1054066.220039]  [<00000000007ac0f0>] system_call+0x128/0x2c8

[tmiasko]

The same issue as #73324?

[msirringhaus]

Looks like it. Thanks for the pointer. I'm trying out the patch from there.

[msirringhaus]

I can verify that the patch (applied to the bundled LLVM) solves the issue for me.

[mwhudson]

Me too, thanks for the link!