Description of problem: rust-toolset-1.29-rust-1.27.1-1.el7 gets stuck on rpmbuild's %check in rhel-alt-7.5 aarch64. This was not reproducible in other architectures. # rpmbuild --rebuild ./rust-toolset-1.29-rust-1.27.1-1.el7.src.rpm (...) test [run-pass] run-pass/xcrate_generic_fn_nested_return.rs ... ok test [run-pass] run-pass/yield2.rs ... ok test [run-pass] run-pass/yield.rs ... ok test [run-pass] run-pass/zero-size-type-destructors.rs ... ok test [run-pass] run-pass/yield1.rs ... ok test [run-pass] run-pass/zero-sized-tuple-struct.rs ... ok test [run-pass] run-pass/zero-sized-binary-heap-push.rs ... ok test [run-pass] run-pass/zero-sized-linkedlist-push.rs ... ok test [run-pass] run-pass/zero_sized_subslice_match.rs ... ok test [run-pass] run-pass/zero-sized-vec-push.rs ... ok test [run-pass] run-pass/zero-sized-vec-deque-push.rs ... ok test [run-pass] run-pass/zero-sized-btreemap-insert.rs ... ok (it hangs with no more messages) ps output from a rust testrun when hung: # ps fax (...) 1115 ? Ssl 0:02 /usr/sbin/rsyslogd -n 1117 ? Ss 0:00 /usr/bin/rhsmcertd 1898 ? Ss 0:00 /usr/libexec/postfix/master -w 1940 ? S 0:00 \_ qmgr -l -t unix -u 5627 ? S 0:00 \_ pickup -l -t unix -u 4248 ? Ss 0:00 /usr/sbin/crond -n 4251 ? Ss 0:02 /usr/bin/python /usr/bin/beah-srv --log-stderr 12829 ? S 0:17 \_ /usr/bin/python /usr/bin/beah-rhts-task 12862 ? S 0:00 \_ scl enable rust-toolset-1.29 /var/lib/beah/tortilla/wrappers.d/runtest 12903 ? S 0:00 \_ /bin/bash /var/tmp/sclIxBj22 12910 ? S 0:00 \_ /bin/sh -x /var/lib/beah/tortilla/wrappers.d/runtest 12914 ? S 3:18 \_ /bin/bash /usr/bin/rhts-test-runner.sh 12942 ? S 0:00 \_ make run 12946 ? S 0:01 | \_ /bin/bash ./runtest.sh 14386 ? S 0:02 | \_ rpmbuild --rebuild ./rust-toolset-1.29-rust-1.27.1-1.el7.src.rpm 3429 ? S 0:00 | | \_ /bin/sh -e /var/tmp/rpm-tmp.r6JZnC 3449 ? S 0:00 | | \_ python2 ./x.py test --no-fail-fast 3462 ? S 0:00 | | \_ /root/rpmbuild/BUILD/rustc-1.27.1-src/build/bootstrap/debug/bootstrap test --no-fail-fast 16434 ? Sl 0:15 | | \_ /root/rpmbuild/BUILD/rustc-1.27.1-src/build/aarch64-unknown-linux-gnu/stage0-tools-bin/compiletest --compile-lib-path /root/rpmbuild/BUILD/rustc-1.27.1-src/build/aarch64-unknown-linux-gnu/stage2/lib --run-lib-path /root/rpmbuild/BUILD/rustc-1.27.1-src/build/aarch64-unknown-linux-gnu/stage2/lib/rustlib/aarch64-unknown-linux-gnu/lib --rustc-path /root/rpmbuild/BUILD/rustc-1.27.1-src/build/aarch64-unknown-linux-gnu/stage2/bin/rustc --src-base /root/rpmbuild/BUILD/rustc-1.27.1-src/src/test/run-pass --build-base /root/rpmbuild/BUILD/rustc-1.27.1-src/build/aarch64-unknown-linux-gnu/test/run-pass --stage-id stage2-aarch64-unknown-linux-gnu --mode run-pass --target aarch64-unknown-linux-gnu --host aarch64-unknown-linux-gnu --llvm-filecheck /opt/rh/llvm-toolset-6.0/root/usr/bin/FileCheck --host-rustcflags -Crpath -O -Zunstable-options --target-rustcflags -Crpath -O -Zunstable-options -Lnative=/root/rpmbuild/BUILD/rustc-1.27.1-src/build/aarch64-unknown-linux-gnu/native/rust-test-helpers --docck-python /usr/bin/python2 --lldb-python /usr/bin/python2 --gdb /usr/bin/gdb --lldb-version lldb version 6.0.1 --lldb-python-dir /opt/rh/llvm-toolset-6.0/root/usr/lib64/python2.7/site-packages --llvm-version 6.0.1 --system-llvm --cc --cxx --cflags --llvm-components --llvm-cxxflags --adb-path adb --adb-test-dir /data/tmp/work --android-cross-path 1211 ? S 0:00 | | \_ /root/rpmbuild/BUILD/rustc-1.27.1-src/build/aarch64-unknown-linux-gnu/test/run-pass/panic-runtime/lto-abort.stage2-aarch64-unknown-linux-gnu 1214 ? R 880:35 | | \_ /root/rpmbuild/BUILD/rustc-1.27.1-src/build/aarch64-unknown-linux-gnu/test/run-pass/panic-runtime/lto-abort.stage2-aarch64-unknown-linux-gnu foo 14387 ? S 0:00 | \_ tee /home/rpmbuildqrNPq/rebuild.log 15357 ? S 0:00 \_ sleep 1 (...) Version-Release number of selected component (if applicable): rust-toolset-1.29-rust-1.27.1-1.el7.src.rpm
I attached gdb to that nested lto-abort, pid 1214 above, and the process appears to be stuck in its backtrace machinery. The normal rpm build does not set RUST_BACKTRACE=1, so this test would normally just abort without printing any backtrace. Still, having that set shouldn't really be a problem...
(In reply to Josh Stone from comment #1) > I attached gdb to that nested lto-abort, pid 1214 above, and the process > appears to be stuck in its backtrace machinery. The normal rpm build does > not set RUST_BACKTRACE=1, so this test would normally just abort without > printing any backtrace. Still, having that set shouldn't really be a > problem... Thanks Josh for looking into that and providing the workaround. The rpmbuild test finished successfully using RUST_BACKTRACE=0: https://beaker.engineering.redhat.com/recipes/5462943#task76640543
This feels similar to an issue I'm investigating on s390x: https://github.com/rust-lang/rust/issues/53372#issuecomment-413616844 In this aarch64 case, the unwinder is stuck on std::panicking::begin_panic(). Unlike the other bug, even GDB doesn't seem to recover from this one, just backtracing that frame over and over. With -Cpanic=abort, this test will be built without landing pads, and recently without even frame pointers at all. That's surely detrimental to unwinding. I do have a patch that at least limits how far Rust will try to unwind for a backtrace, so we won't get into an infinite loop. https://github.com/rust-lang/rust/pull/53436
Looks better with 1.28.0-3
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:3584