1.15.1 armhf signal 7 in run-pass/packed-struct-vec.rs

[infinity0]

This happened on a Launchpad autobuilder but I also managed to reproduce it manually on Debian's asachi.debian.org.

Both systems are running armv7 (armhf) 32-bit userland with a arm64 64-bit kernel.

failures:

---- [run-pass] run-pass/packed-struct-vec.rs stdout ----
        

executing armv7-unknown-linux-gnueabihf/stage2/bin/rustc /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/test/run-pass/packed-struct-vec.rs -L armv7-unknown-linux-gnueabihf/test/run-pass/ --target=armv7-unknown-linux-gnueabihf --error-format json -L armv7-unknown-linux-gnueabih
f/test/run-pass/packed-struct-vec.stage2-armv7-unknown-linux-gnueabihf.run-pass.libaux -C prefer-dynamic -o armv7-unknown-linux-gnueabihf/test/run-pass/packed-struct-vec.stage2-armv7-unknown-linux-gnueabihf -C link-args=-Wl,-Bsymbolic-functions -C link-args=-Wl,-z,re
lro --cfg rtopt -C rpath -O -L armv7-unknown-linux-gnueabihf/rt
------stdout------------------------------

------stderr------------------------------

------------------------------------------
executing armv7-unknown-linux-gnueabihf/test/run-pass/packed-struct-vec.stage2-armv7-unknown-linux-gnueabihf 
------stdout------------------------------

------stderr------------------------------

------------------------------------------

error: test run failed!
status: signal: 7
command: armv7-unknown-linux-gnueabihf/test/run-pass/packed-struct-vec.stage2-armv7-unknown-linux-gnueabihf 
stdout:
------------------------------------------

------------------------------------------
stderr:
------------------------------------------

------------------------------------------

thread '[run-pass] run-pass/packed-struct-vec.rs' panicked at 'explicit panic', /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/tools/compiletest/src/runtest.rs:2416
stack backtrace:
   1: 0x407e3d1f - std::sys::imp::backtrace::tracing::imp::write::hd9cb4c1797101742
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:42
   2: 0x407ef7fb - std::panicking::default_hook::{{closure}}::h154dea97b11a961f
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libstd/panicking.rs:349
   3: 0x407ef20b - std::panicking::default_hook::h7b2373844128ce08
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libstd/panicking.rs:359
   4: 0x407efcf7 - std::panicking::rust_panic_with_hook::h8d52d23c1df454da
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libstd/panicking.rs:553
   5: 0xaacc8d37 - std::panicking::begin_panic::h2b5d2fe46dd8c732
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libstd/panicking.rs:515
   6: 0xaacf8fe7 - compiletest::runtest::ProcRes::fatal::h2aa53c9bf818cee9
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/tools/compiletest/src/runtest.rs:2416
   7: 0xaacf3a57 - compiletest::runtest::TestCx::fatal_proc_rec::h4a9e2fb6350dc15e
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/tools/compiletest/src/runtest.rs:1623
   8: 0xaace5997 - compiletest::runtest::TestCx::run_rpass_test::hf5fc17bd69f61f97
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/tools/compiletest/src/runtest.rs:224
   9: 0xaacc97f3 - <F as test::FnBox<T>>::call_box::hfd886996ef3768ba
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/tools/compiletest/src/runtest.rs:68
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/tools/compiletest/src/main.rs:478
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libtest/lib.rs:140
  10: 0x407f8f17 - __rust_maybe_catch_panic
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libpanic_unwind/lib.rs:98
  11: 0x4073048f - std::panicking::try::do_call::h8e5d0728aa750f11
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libstd/panicking.rs:434
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libstd/panic.rs:351
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libtest/lib.rs:1294
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libstd/panic.rs:295
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libstd/panicking.rs:458
  12: 0x407f8f17 - __rust_maybe_catch_panic
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libpanic_unwind/lib.rs:98
  13: 0x407372df - <F as alloc::boxed::FnBox<A>>::call_box::h882735c009d3deef
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libstd/panicking.rs:434
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libstd/panic.rs:351
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libstd/thread/mod.rs:301
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/liballoc/boxed.rs:605
  14: 0x407ee35b - std::sys::imp::thread::Thread::new::thread_start::hc88703e10b184eab
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/liballoc/boxed.rs:615
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libstd/sys_common/thread.rs:21
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libstd/sys/unix/thread.rs:84


failures:
    [run-pass] run-pass/packed-struct-vec.rs

test result: FAILED. 2586 passed; 1 failed; 7 ignored; 0 measured

thread 'main' panicked at 'Some tests failed', /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/tools/compiletest/src/main.rs:305
stack backtrace:
   1: 0x407e3d1f - std::sys::imp::backtrace::tracing::imp::write::hd9cb4c1797101742
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:42
   2: 0x407ef7fb - std::panicking::default_hook::{{closure}}::h154dea97b11a961f
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libstd/panicking.rs:349
   3: 0x407ef297 - std::panicking::default_hook::h7b2373844128ce08
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libstd/panicking.rs:365
   4: 0x407efcf7 - std::panicking::rust_panic_with_hook::h8d52d23c1df454da
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libstd/panicking.rs:553
   5: 0xaacc8d37 - std::panicking::begin_panic::h2b5d2fe46dd8c732
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libstd/panicking.rs:515
   6: 0xaacfae83 - compiletest::main::hb8255fc99c196c05
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/tools/compiletest/src/main.rs:305
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/tools/compiletest/src/main.rs:70
   7: 0x407f8f17 - __rust_maybe_catch_panic
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libpanic_unwind/lib.rs:98
   8: 0x407f0967 - std::rt::lang_start::h654cbbacaf320c39
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libstd/panicking.rs:434
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libstd/panic.rs:351
                at /<<BUILDDIR>>/rustc-1.15.1+dfsg0/src/libstd/rt.rs:57
   9: 0x408b066f - __libc_start_main
make[2]: *** [tmp/check-stage2-T-armv7-unknown-linux-gnueabihf-H-armv7-unknown-linux-gnueabihf-rpass.ok] Error 101
make[2]: Leaving directory `/<<BUILDDIR>>/rustc-1.15.1+dfsg0'

[TimNN]

I'm not sure what exactly causes a signal 7, or what it means, however it was recently discovered that this test contains UB (unaligned loads from pointers into a packed struct, and unaligned stores in certain situations). The UB should be fixed by #40385 and #40373, although I don't know if #40385 will apply cleanly if backported.

[jonas-schievink]

Signal 7 is SIGBUS, which can be caused by precisely these kinds of unaligned memory operations

[infinity0]

This is fixed in rustc 1.17.

[parched]

Although the unaligned accesses here were a bug in rust, we still allow LLVM to generate unaligned accesses for this target so this fault could still occur. Maybe the kernel is configured to trap unaligned accesses when it shouldn't be?

[infinity0]

Not sure how to check that myself, but the failure I reported in the original post, was from the same machine as the success that I just had with 1.17. (Though it's possible that the admins reconfigured the kernel in between these two runs.)

Are you suggesting that this bug should be re-opened?

[parched]

I don't think the kernel has changed and the bug fixed in 1.17 stopped the issue from being triggered. Just that, in theory, the issue could still happen if LLVM generated some unaligned accesses. We could ensure LLVM didn't to that by adding +strict-align but I think unaligned accesses should probably be enabled.