rustc 1.11.0 arm64 failed to compile debuginfo-gdb/type-names.rs #36348

infinity0 · 2016-09-08T11:39:47Z

Failure here, relevant snippet:

failures:

---- [debuginfo-gdb] debuginfo-gdb/type-names.rs stdout ----


executing aarch64-unknown-linux-gnu/stage2/bin/rustc /«BUILDDIR»/rustc-1.11.0+dfsg1/src/test/debuginfo/type-names.rs -L aarch64-unknown-linux-gnu/test/debuginfo-gdb/ --target=aarch64-unknown-linux-gnu -L aarch64-unknown-linux-gnu/test/debuginfo-gdb/type-names.stage2-aarch64-unknown-linux-gnu.debuginfo-gdb.libaux -C prefer-dynamic -o aarch64-unknown-linux-gnu/test/debuginfo-gdb/type-names.stage2-aarch64-unknown-linux-gnu -C link-args=-Wl,-z,relro --cfg rtopt -C rpath -L aarch64-unknown-linux-gnu/rt -g
------stdout------------------------------

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

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

error: compilation failed!
status: signal: 11
command: aarch64-unknown-linux-gnu/stage2/bin/rustc /«BUILDDIR»/rustc-1.11.0+dfsg1/src/test/debuginfo/type-names.rs -L aarch64-unknown-linux-gnu/test/debuginfo-gdb/ --target=aarch64-unknown-linux-gnu -L aarch64-unknown-linux-gnu/test/debuginfo-gdb/type-names.stage2-aarch64-unknown-linux-gnu.debuginfo-gdb.libaux -C prefer-dynamic -o aarch64-unknown-linux-gnu/test/debuginfo-gdb/type-names.stage2-aarch64-unknown-linux-gnu -C link-args=-Wl,-z,relro --cfg rtopt -C rpath -L aarch64-unknown-linux-gnu/rt -g
stdout:
------------------------------------------

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

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

thread '[debuginfo-gdb] debuginfo-gdb/type-names.rs' panicked at 'explicit panic', /«BUILDDIR»/rustc-1.11.0+dfsg1/src/tools/compiletest/src/runtest.rs:2243
stack backtrace:
   1:       0x7fb4edc84f - std::sys::backtrace::tracing::imp::write::h46e546df6e4e4fe6
   2:       0x7fb4ee9043 - std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::h077deeda8b799591
   3:       0x7fb4ee8acf - std::panicking::default_hook::heb8b6fd640571a4f
   4:       0x7fb4eb23d7 - std::panicking::rust_panic_with_hook::hd7b83626099d3416
   5:       0x555e330577 - std::panicking::begin_panic::hf17b963d1d3f11f5
   6:       0x555e3455cb - compiletest::runtest::ProcRes::fatal::h96be905edb55698f
   7:       0x555e35785f - compiletest::runtest::TestCx::fatal_proc_rec::h8398deadc2d3481b
   8:       0x555e35f287 - compiletest::runtest::TestCx::run_debuginfo_gdb_test_no_opt::h693619ce1093299a
   9:       0x555e34d0a3 - compiletest::runtest::TestCx::run_revision::haae9eca9e8cfdcc0
  10:       0x555e334b7b - _&lt;F as alloc..boxed..FnBox&lt;A&gt;&gt;::call_box::hb25f1d3f86806d7d
  11:       0x7fb52be4f3 - std::panicking::try::call::h62a4455a05e6ba27
  12:       0x7fb4ef3f8b - __rust_try
  13:       0x7fb4ef3f23 - __rust_maybe_catch_panic
  14:       0x7fb52be8f7 - _&lt;F as alloc..boxed..FnBox&lt;A&gt;&gt;::call_box::h665ae3a23f3a9576
  15:       0x7fb4ee71a3 - std::sys::thread::Thread::new::thread_start::hf2eed4b6f7149599
  16:       0x7fb4c18017 - &lt;unknown&gt;


failures:
    [debuginfo-gdb] debuginfo-gdb/type-names.rs

test result: FAILED. 97 passed; 1 failed; 5 ignored; 0 measured

thread 'main' panicked at 'Some tests failed', /«BUILDDIR»/rustc-1.11.0+dfsg1/src/tools/compiletest/src/main.rs:293
stack backtrace:
   1:       0x7fb4edc84f - std::sys::backtrace::tracing::imp::write::h46e546df6e4e4fe6
   2:       0x7fb4ee9043 - std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::h077deeda8b799591
   3:       0x7fb4ee8bd7 - std::panicking::default_hook::heb8b6fd640571a4f
   4:       0x7fb4eb23d7 - std::panicking::rust_panic_with_hook::hd7b83626099d3416
   5:       0x555e330577 - std::panicking::begin_panic::hf17b963d1d3f11f5
   6:       0x555e329c47 - compiletest::main::h9488a95819777ee7
   7:       0x7fb4ee83d7 - std::panicking::try::call::hca715a47aa047c49
   8:       0x7fb4ef3f8b - __rust_try
   9:       0x7fb4ef3f23 - __rust_maybe_catch_panic
  10:       0x7fb4ee7dbb - std::rt::lang_start::h162055cb2e4b9fe7
  11:       0x7fb4ca3363 - &lt;unknown&gt;
/«BUILDDIR»/rustc-1.11.0+dfsg1/mk/tests.mk:760: recipe for target 'tmp/check-stage2-T-aarch64-unknown-linux-gnu-H-aarch64-unknown-linux-gnu-debuginfo-gdb.ok' failed
make[2]: *** [tmp/check-stage2-T-aarch64-unknown-linux-gnu-H-aarch64-unknown-linux-gnu-debuginfo-gdb.ok] Error 101
make[2]: *** Waiting for unfinished jobs....

The text was updated successfully, but these errors were encountered:

michaelwoerister · 2016-09-08T13:30:59Z

Looks like a segmentation fault. Maybe a problem in LLVM? The Rust side doesn't do anything architecture specific, as far as I know.

infinity0 · 2016-09-08T13:48:46Z

We are using not-rust's-fork of LLVM for this, yes. I'll have to investigate further later.

TimNN · 2016-09-08T14:25:31Z

This may be #36023, which was indeed fixed by backporting an llvm patch in #36117.

michaelwoerister · 2016-09-08T16:51:16Z

@infinity0: If it's really the issue @TimNN mentions, is there something you can do about that?

infinity0 · 2016-09-08T18:52:18Z

Yes, I can have it backported to Debian's LLVM no problem. I just need some time to test and check that it does fix the issue.

infinity0 · 2016-09-09T15:40:46Z

OK, I'm fairly sure the patch @TimNN mentioned does not fix the issue, at least not by itself. (I don't have root on the arm64 machine I have access to, so I can't patch the system LLVM, but I set --llvm-root for the rustc build to the custom one I patched and built. So I should be doing things the right way.)

infinity0 · 2016-09-09T15:41:29Z

I have the build environment and all the build files intact however, so let me know if I can run extra things for a better diagnosis.

infinity0 · 2016-09-10T19:04:58Z

Here's a backtrace:

Thread 2 "rustc" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fb2bfeed0 (LWP 6685)]
getCopyFromParts(llvm::SelectionDAG&, llvm::SDLoc, llvm::SDValue const*, unsigned int, llvm::MVT, llvm::EVT, llvm::Value const*, llvm::ISD::NodeType) () at /home/infinity0/llvm-toolchain-3.8-3.8.1/include/llvm/CodeGen/SelectionDAGNodes.h:706
706         return ValueList[ResNo];
(gdb) bt
#0  getCopyFromParts(llvm::SelectionDAG&, llvm::SDLoc, llvm::SDValue const*, unsigned int, llvm::MVT, llvm::EVT, llvm::Value const*, llvm::ISD::NodeType) () at /home/infinity0/llvm-toolchain-3.8-3.8.1/include/llvm/CodeGen/SelectionDAGNodes.h:706
#1  0x0000007fb3d9aea8 in llvm::SelectionDAGISel::LowerArguments(llvm::Function const&) () at /home/infinity0/llvm-toolchain-3.8-3.8.1/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:7533
warning: Could not find DWO CU CMakeFiles/LLVMSelectionDAG.dir/SelectionDAGISel.cpp.dwo(0x63d611a14ea36bbf) referenced by CU at offset 0xb7b9 [in module /home/infinity0/vroot/usr/lib/debug/.build-id/38/1a430b7891664d86e253c9a285580437205637.debug]
#2  0x0000007fb3db1ba0 in llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) () at /home/infinity0/llvm-toolchain-3.8-3.8.1/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1221
#3  0x0000007fb3db293c in llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) () at /home/infinity0/llvm-toolchain-3.8-3.8.1/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:502
warning: Could not find DWO CU CMakeFiles/LLVMCore.dir/LegacyPassManager.cpp.dwo(0xe2d0d448fbcb5d61) referenced by CU at offset 0x9601 [in module /home/infinity0/vroot/usr/lib/debug/.build-id/38/1a430b7891664d86e253c9a285580437205637.debug]
#4  0x0000007fb3a60dc4 in llvm::FPPassManager::runOnFunction(llvm::Function&) () at /home/infinity0/llvm-toolchain-3.8-3.8.1/lib/IR/LegacyPassManager.cpp:1550
#5  0x0000007fb3a610fc in llvm::FPPassManager::runOnModule(llvm::Module&) () at /home/infinity0/llvm-toolchain-3.8-3.8.1/lib/IR/LegacyPassManager.cpp:1571
#6  0x0000007fb3a6142c in llvm::legacy::PassManagerImpl::run(llvm::Module&) () at /home/infinity0/llvm-toolchain-3.8-3.8.1/lib/IR/LegacyPassManager.cpp:1627
#7  0x0000007fb60ad954 in LLVMRustWriteOutputFile (Target=<optimized out>, PMR=<optimized out>, M=<optimized out>, path=<optimized out>, FileType=<optimized out>) at ./src/rustllvm/PassWrapper.cpp:310
#8  0x0000007fb7487954 in rustc_trans::back::write::write_output_file::h6987760832c57d2e () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/librustc_trans-39b92f95.so
#9  0x0000007fb74898ec in rustc_trans::back::write::optimize_and_codegen::_$u7b$$u7b$closure$u7d$$u7d$::h965e55032de68f69 () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/librustc_trans-39b92f95.so
#10 0x0000007fb74902a0 in rustc_trans::back::write::execute_work_item::h46f7bca878f71bc1 () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/librustc_trans-39b92f95.so
#11 0x0000007fb748a614 in rustc_trans::back::write::run_passes::h4610f818f672d1a8 () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/librustc_trans-39b92f95.so
#12 0x0000007fb7e81298 in rustc_driver::driver::phase_5_run_llvm_passes::h283134306ba7308a () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-39b92f95.so
#13 0x0000007fb7e3d1b8 in rustc_driver::driver::compile_input::hdfe4405d66704c31 () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-39b92f95.so
#14 0x0000007fb7e2c114 in rustc_driver::run_compiler::h581448fb74257353 () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-39b92f95.so
#15 0x0000007fb7e294f8 in std::panicking::try::call::hf081e8ea5e252d1a () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-39b92f95.so
#16 0x0000007fb7b54f8c in __rust_try () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/libstd-39b92f95.so
#17 0x0000007fb7b54f24 in __rust_maybe_catch_panic () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/libstd-39b92f95.so
#18 0x0000007fb7e29f60 in _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h2d5dcb354b3ff8db () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-39b92f95.so
#19 0x0000007fb7b481a4 in std::sys::thread::Thread::new::thread_start::hf2eed4b6f7149599 () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/libstd-39b92f95.so
#20 0x0000007fb585a018 in start_thread () from /lib/aarch64-linux-gnu/libpthread.so.0
#21 0x0000007fb79cdd18 in ?? () from /lib/aarch64-linux-gnu/libc.so.6

I am using Debian's LLVM 3.8.1-12 with this patch applied. I ran the following commands to get the above backtrace:

$ cat ./recomp-gdb.sh 
#!/bin/sh
exec gdb -d "../llvm-toolchain-3.8-3.8.1" -ex "set debug-file-directory $HOME/vroot/usr/lib/debug" -ex "run ./recomp.sh" sh

$ cat ./recomp.sh 
#!/bin/sh
export RUSTC_BOOTSTRAP_KEY=39b92f95
export RUST_BACKTRACE=1
export LD_LIBRARY_PATH=/home/infinity0/vroot/usr/lib/llvm-3.8/lib
# the below is what the test claims to be running, c+p from its output:
exec aarch64-unknown-linux-gnu/stage2/bin/rustc \
/home/infinity0/rustc-1.11.0+dfsg1/src/test/debuginfo/type-names.rs \
-L aarch64-unknown-linux-gnu/test/debuginfo-gdb/ \
--target=aarch64-unknown-linux-gnu \
-L aarch64-unknown-linux-gnu/test/debuginfo-gdb/type-names.stage2-aarch64-unknown-linux-gnu.debuginfo-gdb.libaux \
-C prefer-dynamic \
-o aarch64-unknown-linux-gnu/test/debuginfo-gdb/type-names.stage2-aarch64-unknown-linux-gnu \
-C link-args=-Wl,-z,relro --cfg rtopt -C rpath -L aarch64-unknown-linux-gnu/rt -g

infinity0 · 2016-09-10T19:14:59Z

I can make the segfault go away (the test compiles) if I comment out the following two lines:

--- src/test/debuginfo/type-names.rs.orig       2016-09-10 19:14:05.466433219 +0000
+++ src/test/debuginfo/type-names.rs    2016-09-10 19:12:35.384131562 +0000
@@ -224,7 +224,7 @@
 fn rust_fn_with_return_value(_: f64) -> usize { 4 }
 extern "C" fn extern_c_fn_with_return_value() -> Struct1 { Struct1 }
 unsafe fn unsafe_fn_with_return_value(_: GenericStruct<u16, u8>) -> mod1::Struct2 { mod1::Struct2 }
-extern "stdcall" fn extern_stdcall_fn_with_return_value(_: Box<isize>) -> usize { 0 }
+//extern "stdcall" fn extern_stdcall_fn_with_return_value(_: Box<isize>) -> usize { 0 }

 fn generic_function<T>(x: T) -> T { x }

@@ -315,7 +315,7 @@
     let rust_fn_with_return_value = (rust_fn_with_return_value, 0_usize);
     let extern_c_fn_with_return_value = (extern_c_fn_with_return_value, 0_usize);
     let unsafe_fn_with_return_value = (unsafe_fn_with_return_value, 0_usize);
-    let extern_stdcall_fn_with_return_value = (extern_stdcall_fn_with_return_value, 0_usize);
+//    let extern_stdcall_fn_with_return_value = (extern_stdcall_fn_with_return_value, 0_usize);

     let generic_function_int = (generic_function::<isize>, 0_usize);
     let generic_function_struct3 = (generic_function::<mod1::mod2::Struct3>, 0_usize);

of course the test fails because it's missing the expected output, but perhaps this can help you diagnose the problem.

TimNN · 2016-09-10T19:55:18Z

Could this be related to #36142?

infinity0 · 2016-09-10T20:29:44Z

Possibly yes. If I read things right, "stdcall" is x86 specific so it shouldn't be present in a cross-platform test, or at least it should be enabled only for a particular platform. So the segfault is just a secondary here; though of course there could be a better error message instead of a segfault.

Looking through git grep, there are other tests that also have "stdcall" in them (e.g. run-pass/extern-methods.rs), and probably should be disabled or put behind an architecture-specific gate.

However after doing a bit more research I'm confused. On the successful Debian arm64 build of 1.10.0 we see:

test [debuginfo-gdb] debuginfo-gdb/type-names.rs ... ignored
[..]
test [run-pass] run-pass/extern-methods.rs ... ok

Neither of these tests changed between 1.10.0 and 1.11.0 so I'm wondering (a) why 1.11.0 doesn't ignore type-names like 1.10.0 does, and (b) how it managed to run extern-methods successfully...

infinity0 · 2016-09-11T08:52:18Z

On second thoughts, I don't think this is related to #36142. I can make the test pass by further commenting out the test case for extern_stdcall_fn_with_return_value, i.e.:

--- src/test/debuginfo/type-names.rs.orig       2016-09-10 19:14:05.466433219 +0000
+++ src/test/debuginfo/type-names.rs    2016-09-11 08:47:57.833460343 +0000
@@ -153,9 +153,6 @@
 // gdb-command:whatis unsafe_fn_with_return_value
 // gdb-check:type = struct (unsafe fn(type_names::GenericStruct<u16, u8>) -> type_names::mod1::Struct2, usize)

-// gdb-command:whatis extern_stdcall_fn_with_return_value
-// gdb-check:type = struct (extern "stdcall" fn(Box<isize>) -> usize, usize)
-
 // gdb-command:whatis generic_function_int
 // gdb-check:type = struct (fn(isize) -> isize, usize)

in additional to the other patch above. So arm64 can compile and test extern_stdcall_fn just fine, but fails with extern_stdcall_fn_with_return_value (which also has an extra argument).

infinity0 · 2016-09-11T09:14:10Z

Minimal test case, fails even on rustc 1.10 (with Debian's LLVM):

$ cat test.rs
extern "stdcall" fn extern_stdcall_fn_with_return_value(_: Box<isize>) -> usize { 0 }
fn main() {}

$ rustc test.rs 
test.rs:1:1: 1:86 warning: function is never used: `extern_stdcall_fn_with_return_value`, #[warn(dead_code)] on by default
test.rs:1 extern "stdcall" fn extern_stdcall_fn_with_return_value(_: Box<isize>) -> usize { 0 }
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Segmentation fault

However this does seem like a Debian-specific issue; I can't reproduce this with upstream 1.10 or 1.11.

infinity0 · 2016-09-12T09:59:07Z

Continued in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837533. I think in general rust should just remove these "stdcall" tests or move them into a separate test that is only run on the appropriate platforms.

infinity0 · 2016-09-12T15:39:10Z

Ok, it turns out I'm an idiot and actually already dealt with this in #34889. (Though the patch I wrote above allows more of the test to run, instead of ignoring it completely.) #24958 is another example of rust failing in a bad way when encountering inappropriate calling conventions. You can close this bug if you want, or leave it open if you want something specifically to track inappropriate uses of "stdcall" in what should be cross-platform tests.

michaelwoerister · 2016-09-12T16:19:10Z

Disabling the test on arm64 seems like an acceptable fix for me. Thanks for investigating this!

michaelwoerister added the A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) label Sep 8, 2016

michaelwoerister closed this as completed Sep 12, 2016

infinity0 mentioned this issue Sep 12, 2016

Add ppc64, ppc64le, s390 host release builds for linux #36006

Closed

3 tasks

TimNN mentioned this issue Sep 13, 2016

check target abi support #36421

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

rustc 1.11.0 arm64 failed to compile debuginfo-gdb/type-names.rs #36348

rustc 1.11.0 arm64 failed to compile debuginfo-gdb/type-names.rs #36348

infinity0 commented Sep 8, 2016

michaelwoerister commented Sep 8, 2016

infinity0 commented Sep 8, 2016

TimNN commented Sep 8, 2016

michaelwoerister commented Sep 8, 2016

infinity0 commented Sep 8, 2016

infinity0 commented Sep 9, 2016

infinity0 commented Sep 9, 2016

infinity0 commented Sep 10, 2016 •

edited

Loading

infinity0 commented Sep 10, 2016

TimNN commented Sep 10, 2016

infinity0 commented Sep 10, 2016 •

edited

Loading

infinity0 commented Sep 11, 2016

infinity0 commented Sep 11, 2016

infinity0 commented Sep 12, 2016

infinity0 commented Sep 12, 2016

michaelwoerister commented Sep 12, 2016

rustc 1.11.0 arm64 failed to compile debuginfo-gdb/type-names.rs #36348

rustc 1.11.0 arm64 failed to compile debuginfo-gdb/type-names.rs #36348

Comments

infinity0 commented Sep 8, 2016

michaelwoerister commented Sep 8, 2016

infinity0 commented Sep 8, 2016

TimNN commented Sep 8, 2016

michaelwoerister commented Sep 8, 2016

infinity0 commented Sep 8, 2016

infinity0 commented Sep 9, 2016

infinity0 commented Sep 9, 2016

infinity0 commented Sep 10, 2016 • edited Loading

infinity0 commented Sep 10, 2016

TimNN commented Sep 10, 2016

infinity0 commented Sep 10, 2016 • edited Loading

infinity0 commented Sep 11, 2016

infinity0 commented Sep 11, 2016

infinity0 commented Sep 12, 2016

infinity0 commented Sep 12, 2016

michaelwoerister commented Sep 12, 2016

infinity0 commented Sep 10, 2016 •

edited

Loading

infinity0 commented Sep 10, 2016 •

edited

Loading