backtrace from gdb

(gdb) where
#0  0x000002aa0c3616c4 in core::ptr::drop_in_place () at /builddir/build/BUILD/rustc-1.46.0-src/src/libcore/ptr/mod.rs:184
#1  core::ptr::drop_in_place () at /builddir/build/BUILD/rustc-1.46.0-src/src/libcore/ptr/mod.rs:184
#2  core::ptr::drop_in_place () at /builddir/build/BUILD/rustc-1.46.0-src/src/libcore/ptr/mod.rs:184
#3  core::ptr::drop_in_place () at /builddir/build/BUILD/rustc-1.46.0-src/src/libcore/ptr/mod.rs:184
#4  core::ptr::drop_in_place () at /builddir/build/BUILD/rustc-1.46.0-src/src/libcore/ptr/mod.rs:184
#5  <libcoreinst::source::FileLocation as libcoreinst::source::ImageLocation>::sources (self=0x3ffcc3fc4f8) at src/source.rs:135
#6  libcoreinst::download::tests::test_write_image_limit () at src/download.rs:489
#7  0x000002aa0c36ccb2 in std::panicking::try::do_call ()
#8  0x000002aa0c3a224c in __rust_try ()
#9  0x000002aa0c39ecbe in test::run_test::run_test_inner::{{closure}} ()
#10 0x000002aa0c39e4b6 in test::run_test::run_test_inner ()
#11 0x000002aa0c39ce6e in test::run_test ()
#12 0x000002aa0c39559c in test::run_tests ()
#13 0x000002aa0c37ef4e in test::console::run_tests_console ()
#14 0x000002aa0c392a54 in test::test_main ()
#15 0x000002aa0c3943d4 in test::test_main_static ()
#16 0x000002aa0c310a72 in std::rt::lang_start::{{closure}} () at /builddir/build/BUILD/rustc-1.46.0-src/src/libstd/rt.rs:67
#17 0x000002aa0c664446 in std::panicking::try::do_call ()
#18 0x000002aa0c66daa4 in __rust_try ()
#19 0x000002aa0c665156 in std::rt::lang_start_internal ()
#20 0x000002aa0c310a58 in std::rt::lang_start (main=<optimized out>, argc=<optimized out>, argv=<optimized out>) at /builddir/build/BUILD/rustc-1.46.0-src/src/libstd/rt.rs:67
#21 0x000003ff9b8abbda in __libc_start_main () from /lib64/libc.so.6
#22 0x000002aa0c30cdf4 in _start ()

build in koji is https://koji.fedoraproject.org/koji/taskinfo?taskID=52413150

I have made a build of rust 1.46 with llvm-10 (https://koji.fedoraproject.org/koji/taskinfo?taskID=52444549) and the test crashes there as well. So this could be really a rust issue, not a LLVM one.

[sharkcz@devel10 rust-coreos-installer]$ /home/sharkcz/rust-coreos-installer/coreos-installer-0.7.0/target/release/deps/libcoreinst-135b46c0efd4c9e3

running 16 tests
test blockdev::tests::disk_sector_size_reader ... ok
test blockdev::tests::lsblk_split ... ok
test blockdev::tests::test_saved_partitions ... ok
test cmdline::tests::test_parse_partition_filters ... ok
test download::tests::test_image_copy_default_first_mb ... ok
test download::tests::test_write_image_limit ... Segmentation fault (core dumped)


For the record - my builds were done with a single CPU system, the output is different on a multi-CPU system

It looks like upstream coreos-installer has been dancing around s390x issues:

https://github.com/coreos/coreos-installer/pull/360
https://github.com/coreos/coreos-installer/issues/372
https://github.com/coreos/coreos-installer/pull/373

I don't know if those changes have anything to do with the test in question here.

All three of those issues came down to an LTO bug in Rust 1.43 and 1.44: https://github.com/coreos/coreos-installer/issues/372#issuecomment-686424629.  We didn't see it in FCOS, which was already on 1.45.  We ended up making net no code changes for it (there's a PR plus a revert) and just disabled LTO in the RHCOS package.

The issue reported here is not known to be related.  I could try disabling LTO in the package.

Looks like it also fails with LTO disabled: https://koji.fedoraproject.org/koji/taskinfo?taskID=52479791

Ah, right, I think that s390x LTO issue was bug 1837660. That was a build failure, but I guess it could break in other ways. Current LLVM shouldn't be affected by that particular issue.

I can reproduce this, but only in optimized builds with "-Ccodegen-units=1", which rust-packaging %cargo_prep sets in ".cargo/config". So if you need an immediate workaround, you could edit that file to increase or remove that argument. I believe the default is 16 in release builds.

I'll try to bisect the rust change, but the build is really slow in the beaker machine I got...

Josh, thanks for the workaround.  Applied in rust-coreos-installer-0.7.0-2.fc34.

I've confirmed that the upstream LLVM patch fixes the problem here.
https://reviews.llvm.org/D89034

This should be fixed in rawhide now -- do the coreos folks need this backported to stable branches too?

It'd be useful, but not required.  Per comment 9 we have a workaround in the coreos-installer package.

Thanks for all your work to track this down!

This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.