Test run-pass\sepcomp-lib-lto.rs fails with ODR violation in debug mode

[petrochenkov]

$ make check-notidy TESTNAME='sepcomp-lib-lto'
cfg: version 1.1.0-dev (3906edf41 2015-05-09) (built 2015-05-10)
cfg: build triple x86_64-pc-windows-gnu
cfg: host triples x86_64-pc-windows-gnu
cfg: target triples x86_64-pc-windows-gnu
cfg: enabling debug assertions (CFG_ENABLE_DEBUG_ASSERTIONS)
cfg: enabling debuginfo (CFG_ENABLE_DEBUGINFO)
cfg: host for x86_64-pc-windows-gnu is x86_64
cfg: os for x86_64-pc-windows-gnu is pc-windows-gnu
cfg: good valgrind for x86_64-pc-windows-gnu is
cfg: using CC=gcc (CFG_CC)
cfg: disabling valgrind run-pass tests
cfg: no xelatex found, disabling LaTeX docs
cfg: no pandoc found, omitting PDF and EPUB docs
cfg: including test rules
cfg: javac not available, skipping lexer test...
run rpass [x86_64-pc-windows-gnu]: x86_64-pc-windows-gnu/stage2/bin/compiletest.exe

running 1 test
test [run-pass] run-pass/sepcomp-lib-lto.rs ... FAILED

failures:

---- [run-pass] run-pass/sepcomp-lib-lto.rs stdout ----

error: compilation failed!
status: exit code: 3
command: PATH="x86_64-pc-windows-gnu/stage2/bin;C:\msys64\home\rust\x86_64-pc-windows-gnu\stage2\bin;C:\msys64\mingw64\bin;C:\msys64\usr\local\bin;C:\msys64\usr\bin;C:\msys64\usr\bin" x86_64-pc-windows-gnu/stage2/bin/rustc.exe C:/msys64/home/rust/src/test/run-pass/sepcomp-lib-lto.rs -L x86_64-pc-windows-gnu/test/run-pass/ --target=x86_64-pc-windows-gnu -L x86_64-pc-windows-gnu/test/run-pass\sepcomp-lib-lto.stage2-x86_64-pc-windows-gnu.run-pass.libaux -o x86_64-pc-windows-gnu/test/run-pass\sepcomp-lib-lto.stage2-x86_64-pc-windows-gnu.exe --cfg rtopt --cfg debug -O -L x86_64-pc-windows-gnu/rt -C lto
stdout:
------------------------------------------

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

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Assertion failed!

Program: C:\msys64\home\rust\x86_64-pc-windows-gnu\stage2\bin\rustc.exe
File: C:/msys64/home/rust/src/llvm/lib/CodeGen/LexicalScopes.cpp, Line 179

Expression: DISubprogram(Scope).describes(MF->getFunction())

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

thread '[run-pass] run-pass/sepcomp-lib-lto.rs' panicked at 'explicit panic', C:/msys64/home/rust/src/compiletest\runtest.rs:1525



failures:
    [run-pass] run-pass/sepcomp-lib-lto.rs

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

I'm using msys2 x64 on Windows 7 and a fresh clone of Rust.

cc #23566

[petrochenkov]

I've reproduced this issue on one more machine with Windows 8.1. I don't know why build bots don't catch it.

[petrochenkov]

Probably a duplicate of #26447
It appears only with --enable-debug and the new error message is very similar to #26447:

Assertion failed!

Program: C:\msys64\home\we\rust\x86_64-pc-windows-gnu\stage2\bin\rustc.exe
File: C:/msys64/home/we/rust/src/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp, Line 713

Expression: Ty == resolve(Ty->getRef()) && "type was not uniqued, possible ODR violation."

[dotdash]

Should actually be a dupe of #23566 which is closed by now. Can you check if this is fixed as well? Thanks!

[petrochenkov]

@dotdash
Can't check now, the build with --enable-debug segfaults even before proceeding to tests.

$ make VERBOSE=1
cfg: version 1.4.0-dev (5e5b99f47 2015-08-22)
cfg: build triple x86_64-pc-windows-gnu
cfg: host triples x86_64-pc-windows-gnu
cfg: target triples x86_64-pc-windows-gnu
cfg: enabling debug assertions (CFG_ENABLE_DEBUG_ASSERTIONS)
cfg: enabling debuginfo (CFG_ENABLE_DEBUGINFO)
cfg: host for x86_64-pc-windows-gnu is x86_64
cfg: os for x86_64-pc-windows-gnu is pc-windows-gnu
cfg: good valgrind for x86_64-pc-windows-gnu is
cfg: using CC=gcc (CFG_CC)
cfg: disabling valgrind run-pass tests
MATCHES=""; if [ -n "$MATCHES" ] ; then echo "warning: removing previous" \'std-*.dll\' "libraries:" $MATCHES; rm $MATCHES ; fi
MATCHES=""; if [ -n "$MATCHES" ] ; then echo "warning: removing previous" \'libstd-*.rlib\' "libraries:" $MATCHES; rm $MATCHES ; fi
CFG_LLVM_LINKAGE_FILE=/home/rust/x86_64-pc-windows-gnu/rt/llvmdeps.rs PATH=/home/rust/x86_64-pc-windows-gnu/stage1/bin:$PATH   x86_64-pc-windows-gnu/stage1/bin/rustc.exe --cfg stage1  -O --cfg rtopt -C debug-assertions=on -g -C prefer-dynamic --target=x86_64-pc-windows-gnu  -D warnings -L "x86_64-pc-windows-gnu/rt" -L "C:\msys64\home\rust\x86_64-pc-windows-gnu\llvm\Release+Asserts/lib"    --out-dir x86_64-pc-windows-gnu/stage1/bin/rustlib/x86_64-pc-windows-gnu/lib -C extra-filename=-a5fc0d6c src/libstd/lib.rs
/home/rust/mk/target.mk:163: ошибка выполнения рецепта для цели «x86_64-pc-windows-gnu/stage1/bin/rustlib/x86_64-pc-windows-gnu/lib/stamp.std»
make: *** [x86_64-pc-windows-gnu/stage1/bin/rustlib/x86_64-pc-windows-gnu/lib/stamp.std] Segmentation fault

[VHaravy]

This test still fails as of commit f18c2aa (at least when using MSVC):

---- [run-pass] run-pass/sepcomp-lib-lto.rs stdout ----

error: compilation failed!
status: exit code: -1073740791
command: PATH="x86_64-pc-windows-msvc/stage2/bin;D:\Sources\Rust\x86_64-pc-windows-msvc\stage2\bin;C:\MSYS2\mingw64\bin;C:\MSYS2\usr\local\bin;C:\MSYS2\usr\bin;C:\MSYS2\usr\bin;C:\Program Files\Python 3;C:\Program Files\Python 3\Scripts;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit;C:\Program Files\SlikSvn\bin;C:\Program Files\System Tools;C:\Program Files (x86)\System Tools;C:\Program Files\Vim\vim74;C:\Program Files\Rust\bin;C:\Program Files\Microsoft\Web Platform Installer;C:\Program Files\MiKTeX\miktex\bin\x64;C:\Program Files (x86)\Pandoc;C:\Program Files\LLVM\bin;C:\Program Files\KDiff3;C:\Program Files\Git\cmd;C:\Users\Vitali\AppData\Local\atom\bin;C:\MSYS2\usr\bin\site_perl;C:\MSYS2\usr\bin\vendor_perl;C:\MSYS2\usr\bin\core_perl" x86_64-pc-windows-msvc/stage2/bin/rustc.exe D:/Sources/Rust/src/test/run-pass/sepcomp-lib-lto.rs -L x86_64-pc-windows-msvc/test/run-pass/ --target=x86_64-pc-windows-msvc -L x86_64-pc-windows-msvc/test/run-pass\sepcomp-lib-lto.stage2-x86_64-pc-windows-msvc.run-pass.libaux -o x86_64-pc-windows-msvc/test/run-pass\sepcomp-lib-lto.stage2-x86_64-pc-windows-msvc.exe -O -L x86_64-pc-windows-msvc/rt -C lto
stdout:
------------------------------------------

------------------------------------------
stderr:
------------------------------------------
Assertion failed: Ty == resolve(Ty->getRef()) && "type was not uniqued, possible ODR violation.", file D:\Sources\Rust\src\llvm\lib\CodeGen\AsmPrinter\DwarfUnit.cpp, line 713

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

thread '[run-pass] run-pass/sepcomp-lib-lto.rs' panicked at 'explicit panic', D:/Sources/Rust/src/compiletest\runtest.rs:1501

[dotdash]

The problem here seems to be that the namespaces recorded in the typenames and debuginfo don't always use the original create name, but "sometimes"(?) use the alias from extern crate foo as bar.

That way we get a duplicate definition for a Vec<u8> type. One declared in namespace collections::vec and one in core_collections::vec.

[dotdash]

Updated the title to reflect that this isn't specific to Windows.

[tamird]

This also affects run-pass-fulldeps/lto-syntax-extension.rs

[tamird]

Somewhat unexpectedly, this also affects run-make/codegen-options-parsing because this assertion fires when -C lto is finally passed correctly.

[frewsxcv]

Somewhat unexpectedly, this also affects run-make/codegen-options-parsing because this assertion fires when -C lto is finally passed correctly.

Just ran into this, so I can confirm this is still an issue

[agbaroni]

The problem is present also on OS X with recent update 10.11.4 and XCode 7.3. I have test the master branch version 1.9.0-dev (7545d7e7f 2016-03-23).

My configuration was:

./configure --enable-debug --disable-docs --disable-optimize-tests --enable-ccache --disable-optimize

My test command was:

make check-stage1 TESTNAME='sepcomp-lib-lto' RUST_BACKTRACE=1

The backtrace is the following:

   1:        0x100781b8d - sys::backtrace::tracing::imp::write::h451035250644f72ciTu
   2:        0x1007b54b5 - panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::closure.45160
   3:        0x1007b4a59 - panicking::default_hook::hd45755f627c9bf85ocA
   4:        0x10077b865 - panicking::on_panic::h9489142bd84cbbfbKgA
   5:        0x1007022c0 - sys_common::unwind::begin_unwind_inner::h3e31d5ad2821e976rTt
   6:        0x1002f2317 - sys_common::unwind::begin_unwind::h6426500494896913122
   7:        0x10032fabb - runtest::fatal_proc_rec::h2765868c2b6c7fcfJ4c
   8:        0x100334a71 - runtest::run_rpass_test_revision::h1bde4bdf1fb4d51cUbb
   9:        0x100334b55 - fn(&common..Config, &header..TestProps, &test..TestPaths, core..option..Option<&str>) $u7b$runtest..run_rpass_test_revision$u7d$::fn_pointer_shim.15926::h3e3c80ba5416a450
  10:        0x100334418 - runtest::for_each_revision::h3601343610551425150
  11:        0x100324e04 - runtest::run_rpass_test::h10cce149c4fcacd9ybb
  12:        0x100308300 - runtest::run::h5e44a1045dbf1f017Wa
  13:        0x100307aa0 - make_test_closure::_$u7b$$u7b$closure$u7d$$u7d$::closure.14368
  14:        0x100308547 - boxed::F.FnBox<A>::call_box::h13902352304284010375
  15:        0x10048675b - boxed::Box<FnBox<A, Output $u3d$$u20$R$GT$$u2b$$u20$Send$u20$$u2b$$u20$$u27$a$GT$.FnOnce$LT$A$GT$::call_once::h8809736880423065284
  16:        0x1004858ac - run_test::run_test_inner::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::closure.14314
  17:        0x1004851c2 - std::thread::Builder::spawn::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::closure.14304
  18:        0x100485159 - sys_common::unwind::try::try_fn::h7929338595508807158
  19:        0x10077ab77 - __rust_try
  20:        0x10077a882 - sys_common::unwind::inner_try::_$u7b$$u7b$closure$u7d$$u7d$::closure.43862
  21:        0x10077a783 - thread::local::LocalKey<T>::with::h17390026479279564951
  22:        0x10077a69c - sys_common::unwind::inner_try::hb2b5674d7a23de2etQt
  23:        0x1004850cb - sys_common::unwind::try::h17492865234244695728
  24:        0x100484f06 - std::thread::Builder::spawn::_$u7b$$u7b$closure$u7d$$u7d$::closure.14302
  25:        0x100485a94 - boxed::F.FnBox<A>::call_box::h10400995320128026508
  26:        0x10076b04b - boxed::Box<FnBox<A, Output $u3d$$u20$R$GT$$u2b$$u20$$u27$a$GT$.FnOnce$LT$A$GT$::call_once::h762367925961598935
  27:        0x100777e2e - sys_common::thread::start_thread::hfb6d93eeb3a097eaACt
  28:        0x1007b2374 - sys::thread::Thread::new::thread_start::hef26ac5ff6dd1c47Oqz
  29:     0x7fff8b84199c - _pthread_body
  30:     0x7fff8b841919 - _pthread_start

[pnkfelix]

Nominating so that compiler team addresses how to prioritize this.

[pnkfelix]

triage: I-nominated T-compiler

[pnkfelix]

(in particular, the fact that this is now visible on Windows and on later versions of Mac OS X is a sign that this problem is going to become a more significant problem for us than it has been in the past...)

[nikomatsakis]

cc @michaelwoerister

[nikomatsakis]

triage: P-medium

[michaelwoerister]

It's on my radar.

[cgswords]

I've managed to replicate this bug in an Ubuntu virtual machine with llvm 3.8 from a fresh pull request. I built as per ituxbag above using 1.11.0-nightly (7746a334d 2016-05-28) and received the same error.

[sfackler]

I'm seeing this on Arch Linux now as well.

[jonas-schievink]

Additionally, run-pass/panic-runtime/lto-abort.rs and run-pass/panic-runtime/lto-unwind.rs fail the same way

[MagaTailor]

Just hit this issue trying to compile cargo with lto and -g. BTW, I never enabled assertions during LLVM build - did the default change?

[whitequark]

Still fails today--it would be really nice to see this fixed. I'd like use LTO for my embedded platform to get smaller binaries. (I already use --gc-sections, but LTO would be even better.)

[whitequark]

On top of that, it looks like that, even if I set debug = false in profile overrides, I still get this failure because libcore and friends are built with -g.

[alevy]

@whitequark FWIW it is possible to get this running with LTO -- we use LTO for Tock. You just need to, as you mentioned, ensure libcore (and friends) are compiled without debug symbols for now. One simple way to do that for libcore is to depend on the rust-libcore crate which, behind the scenes, compiles libcore with whatever target and compiler arguments Cargo would otherwise use.

[whitequark]

That crate seems quite outdated, but also not really enough. Currently I build the following for my target:

• libcore
• liblibc_mini (a tiny implementation of OS-independent libc that I hacked up to make liballoc build)
• liballoc
• librustc_unicode
• libcollections
• libpanic_abort
• libpanic_unwind (yes, I use unwinding; in fact that predates my use of Rust)

It would be great if there was some elegant way to build all that with Cargo, but for now I don't see it... putting stuff on crates.io is onerous and especially so when tracking nightlies is desired, adding Rust as a submodule brings in a massive dependency into your project, and I've had issues with that before simply because the networks over here aren't very good and some build tools (cough_conda_cough) aren't very smart.

[alevy]

@whitequark Take a look at the implementation of the rust-libcore crate. It's really just a build.rs that pulls in the version of libcore based on your rustc --version (which is why it hasn't needed to be updated for a while) and then compiles it. You can do the same (perhaps by just modifying a local copy of the rust-libcore crate) for all of those since they are just in the Rust tarball.

Note: obviously none of this solves the underlying bug, but just something to hold us non-compiler-folks while the professionals figure this out

[whitequark]

That would work well if I didn't also have to use a fork of Rust (the upstream doesn't define the ABI or have the LLVM target initialization for my architecture). But thanks for telling anyway, I might be able to use this in some other form.

The complete lack of caching and reliance on POSIX sh is still an issue...

[pmarcelll]

I tried to reproduce it with the commands described in #25270 (comment) on nightly, but I couldn't. Can someone else also try it?

[pbadeer]

New to Rust, but this was halting my first ever compile of Redox. I read this: rust-lang/cargo#1691 and changed codegen-units='nproc' on line 24 of redox/mk/config.mk to codegen-units=1 just so I could try out the OS. It shutup the error and let me compile, maybe this will help someone else who's stuck trying to run Redox.

I have a Mac running OSX 10.12.2 and Xcode 8.2.1 with Rust Nightly rustc 1.16.0-nightly (1a2ed98d3 2017-01-13)