Bug 1797127

Summary: Rust 1.41 fails to build on Fedora 30 i686
Product: [Fedora] Fedora Reporter: Josh Stone <jistone>
Component: llvmAssignee: Tom Stellard <tstellar>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 30CC: dmalcolm, igor.raits, jakub, jistone, rust-sig, scottt.tw, sean, sguelton, siddharth.kde, TicoTimo, tstellar
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Unspecified   
Whiteboard:
Fixed In Version: llvm-8.0.0-7.fc30 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-02-27 22:05:42 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
llvm-ir for a 64-bit atomic_load_unordered none

Description Josh Stone 2020-02-01 00:21:28 UTC
Description of problem:
In rust-1.41.0-1.fc30: https://koji.fedoraproject.org/koji/taskinfo?taskID=41303328

The i686 build triggered a segmentation fault while compiling compiler_builtins in stage0 (using the prior version of the toolchain). All other arches completed the build without trouble.

Version-Release number of selected component (if applicable):
rust-1.40.0-1.fc30.i686
llvm-8.0.0-6.fc30.i686

How reproducible:
100%

Steps to Reproduce:
1. Try to build rust-1.41.0-1.fc30

Actual results:

Building stage0 std artifacts (i686-unknown-linux-gnu -> i686-unknown-linux-gnu)
   Compiling compiler_builtins v0.1.22
   Compiling core v0.0.0 (/builddir/build/BUILD/rustc-1.41.0-src/src/libcore)
   Compiling cc v1.0.47
   Compiling libc v0.2.64
   Compiling autocfg v0.1.6
   Compiling std v0.0.0 (/builddir/build/BUILD/rustc-1.41.0-src/src/libstd)
   Compiling hashbrown v0.6.2
   Compiling unwind v0.0.0 (/builddir/build/BUILD/rustc-1.41.0-src/src/libunwind)
   Compiling backtrace-sys v0.1.32
   Compiling rustc-std-workspace-core v1.99.0 (/builddir/build/BUILD/rustc-1.41.0-src/src/tools/rustc-std-workspace-core)
   Compiling cfg-if v0.1.8
   Compiling alloc v0.0.0 (/builddir/build/BUILD/rustc-1.41.0-src/src/liballoc)
   Compiling rustc-demangle v0.1.16
   Compiling panic_abort v0.0.0 (/builddir/build/BUILD/rustc-1.41.0-src/src/libpanic_abort)
error: could not compile `compiler_builtins`.

Caused by:
  process didn't exit successfully: `/builddir/build/BUILD/rustc-1.41.0-src/build/bootstrap/debug/rustc --crate-name compiler_builtins /builddir/build/BUILD/rustc-1.41.0-src/vendor/compiler_builtins/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C codegen-units=1 -C debuginfo=2 -C debug-assertions=off -C overflow-checks=on --cfg 'feature="compiler-builtins"' --cfg 'feature="core"' --cfg 'feature="default"' --cfg 'feature="rustc-dep-of-std"' -C metadata=302301c59b8bd4fb -C extra-filename=-302301c59b8bd4fb --out-dir /builddir/build/BUILD/rustc-1.41.0-src/build/i686-unknown-linux-gnu/stage0-std/i686-unknown-linux-gnu/debug/deps --target i686-unknown-linux-gnu -L dependency=/builddir/build/BUILD/rustc-1.41.0-src/build/i686-unknown-linux-gnu/stage0-std/i686-unknown-linux-gnu/debug/deps -L dependency=/builddir/build/BUILD/rustc-1.41.0-src/build/i686-unknown-linux-gnu/stage0-std/debug/deps --extern core=/builddir/build/BUILD/rustc-1.41.0-src/build/i686-unknown-linux-gnu/stage0-std/i686-unknown-linux-gnu/debug/deps/librustc_std_workspace_core-148617687675f4a5.rmeta --cap-lints allow -Clink-arg=-Wl,-z,relro,-z,now --cfg=bootstrap -Zexternal-macro-backtrace -Wrust_2018_idioms -Wunused_lifetimes -Dwarnings -Cprefer-dynamic -Zbinary-dep-depinfo --cfg 'feature="unstable"'` (signal: 11, SIGSEGV: invalid memory reference)
warning: build failed, waiting for other jobs to finish...
error: build failed


Expected results:
A normal build.

Additional info:
Preliminary debugging shows the SIGSEGV is raised within LLVM, but the backtrace looks corrupt.

Thread 5 "rustc" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xe97ffb40 (LWP 1549)]
expandAtomicCmpXchg () at ../lib/CodeGen/AtomicExpandPass.cpp:1246
1246        Builder.SetInsertPoint(ExitBB, ++ExitBB->begin());
(gdb) bt
#0  expandAtomicCmpXchg () at ../lib/CodeGen/AtomicExpandPass.cpp:1246
#1  0xf06a802b in ?? () from /lib/libLLVM-8.so
#2  0x535f6c61 in ?? ()
#3  0x74666968 in ?? ()
#4  0x43006465 in ?? ()
#5  0x6156706d in ?? ()

I will try to get the llvm-ir to reproduce this on its own.

Comment 1 Josh Stone 2020-02-01 01:36:39 UTC
Created attachment 1656893 [details]
llvm-ir for a 64-bit atomic_load_unordered

#![no_std]
#![crate_type = "lib"]
#![feature(core_intrinsics)]

#[no_mangle]
pub unsafe fn unordered_load(src: *const u64) {
    core::intrinsics::atomic_load_unordered(src);
}

Comment 2 Josh Stone 2020-02-01 01:42:48 UTC
The attachment is the full llvm-ir for the given Rust code, basically just a 64-bit unordered load alone:

  %1 = load atomic i64, i64* %src unordered, align 8

Compiled with llc in llvm-8.0.0-6.fc30.i686:

Stack dump:
0.      Program arguments: llc load.ll
1.      Running pass 'Function Pass Manager' on module 'load.ll'.
2.      Running pass 'Expand Atomic instructions' on function '@unordered_load'
#0 0xfffffffff3b29227 llvm::sys::PrintStackTrace(llvm::raw_ostream&) ../lib/Support/Unix/Signals.inc:499:3
#1 0xfffffffff3b29301 ../lib/Support/Unix/Signals.inc:559:1
#2 0xfffffffff3b27011 llvm::sys::RunSignalHandlers() ../lib/Support/Signals.cpp:69:20
#3 0xfffffffff3b27195 ../lib/Support/Unix/Signals.inc:348:31
#4 0xfffffffff7f9db70 (linux-gate.so.1+0xb70)
#5 0xfffffffff393b6d0 ../include/llvm/IR/TrackingMDRef.h:34:48
#6 0xfffffffff393b6d0 ../include/llvm/IR/TrackingMDRef.h:115:62
#7 0xfffffffff393b6d0 ../include/llvm/IR/DebugLoc.h:34:9
#8 0xfffffffff393b6d0 ../include/llvm/IR/IRBuilder.h:147:30
#9 0xfffffffff393b6d0 expandAtomicCmpXchg ../lib/CodeGen/AtomicExpandPass.cpp:1246:27
#10 0xfffffffff633c02b (/lib/libLLVM-8.so+0x2fcb02b)
Segmentation fault (core dumped)

I can also confirm this with llvm8.0-8.0.0-11.fc31.x86_64:

$ llc-8.0 load.ll
Stack dump:
0.      Program arguments: llc-8.0 load.ll
1.      Running pass 'Function Pass Manager' on module 'load.ll'.
2.      Running pass 'Expand Atomic instructions' on function '@unordered_load'
#0 0x00007f92dc934d0e llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/lib64/llvm8.0/lib/libLLVM-8.so+0xabed0e)
#1 0x00007f92dc932d84 llvm::sys::RunSignalHandlers() (/usr/lib64/llvm8.0/lib/libLLVM-8.so+0xabcd84)
#2 0x00007f92dc932f05 (/usr/lib64/llvm8.0/lib/libLLVM-8.so+0xabcf05)
#3 0x00007f92dbaef6b0 __restore_rt (/lib64/libc.so.6+0x3c6b0)
#4 0x00007f92dc755172 (/usr/lib64/llvm8.0/lib/libLLVM-8.so+0x8df172)
#5 0x00007ffdcbec1278
Segmentation fault (core dumped)

It also crashes with llc-7.0, but llc from llvm-9.0.0-1.fc31.x86_64 is okay.

Comment 3 Josh Stone 2020-02-01 04:35:54 UTC
I bisected to this: https://github.com/llvm/llvm-project/commit/2153c4b8281c1e5f25887ef9183947198c50a9d2

    [AtomicExpand] Fix a crash bug when lowering unordered loads to cmpxchg

    Add tests for wider atomic loads and stores.  In the process, fix a crasher where we appearently handled unorder stores, but not loads, when lowering to cmpxchg idioms.

    llvm-svn: 356482

I'd say that fits!

Comment 5 Fedora Update System 2020-02-04 01:22:05 UTC
FEDORA-2020-5739bd54c3 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-5739bd54c3

Comment 6 Fedora Update System 2020-02-05 00:52:34 UTC
llvm-8.0.0-7.fc30, rust-1.41.0-1.fc30, rust-packaging-10-2.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-5739bd54c3

Comment 7 Fedora Update System 2020-02-20 04:45:44 UTC
llvm-8.0.0-7.fc30, rust-1.41.0-1.fc30, rust-packaging-10-2.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

Comment 8 Josh Stone 2020-02-27 22:05:42 UTC
The update reached stable a week ago.