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

petrochenkov · 2015-05-10T11:39:46Z

$ 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

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

petrochenkov · 2015-05-17T20:50:58Z

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 · 2015-07-28T23:02:28Z

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 · 2015-08-16T16:42:02Z

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

petrochenkov · 2015-08-23T08:44:22Z

@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 · 2015-09-17T09:48:29Z

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 · 2015-10-18T16:20:59Z

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 · 2015-10-20T12:41:22Z

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

tamird · 2015-11-08T15:29:37Z

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

tamird · 2015-11-08T15:33:50Z

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

frewsxcv · 2016-01-27T23:31:16Z

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 · 2016-03-23T10:20:40Z

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 · 2016-03-23T10:30:01Z

Nominating so that compiler team addresses how to prioritize this.

pnkfelix · 2016-03-23T10:30:10Z

triage: I-nominated T-compiler

pnkfelix · 2016-03-23T10:31:28Z

(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 · 2016-03-24T20:27:23Z

cc @michaelwoerister

nikomatsakis · 2016-03-24T20:27:27Z

triage: P-medium

michaelwoerister · 2016-03-25T02:52:18Z

It's on my radar.

cgswords · 2016-06-06T19:16:08Z

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 · 2016-07-10T17:36:54Z

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

jonas-schievink · 2016-07-10T20:36:53Z

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

MagaTailor · 2016-07-21T11:46:34Z

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

This reflects the fact that currently rust-lang/rust#25270 seems to be solved for nightly builds

whitequark · 2016-08-17T07:09:56Z

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 · 2016-08-17T07:29:38Z

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 · 2016-08-17T12:50:02Z

@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 · 2016-08-17T12:58:32Z

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 · 2016-08-17T13:03:00Z

@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 · 2016-08-17T13:06:22Z

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 · 2016-09-22T18:51:43Z

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 · 2017-01-15T04:59:40Z

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)

@alexcrichton

…richton Add regression test for debuginfo + LTO Fixes rust-lang#25270, which cannot be reproduced with the current nightly version of the compiler anymore (due to various fixes to debuginfo generation in the past). Should we run into the "possible ODR violation" again, the test added by this PR can be extend with the new case. r? @alexcrichton

steveklabnik added the O-windows Operating system: Windows label May 10, 2015

dotdash mentioned this issue Oct 18, 2015

Update LLVM fork to include a backported fix for broken debug locations #29144

Merged

dotdash mentioned this issue Oct 20, 2015

Buildbot Request: Add one --enable-debug --enable-optimize bot that at least bootstraps (no tests) #27010

Closed

dotdash changed the title ~~Test run-pass\sepcomp-lib-lto.rs fails on Windows~~ Test run-pass\sepcomp-lib-lto.rs fails with ODR in debug mode Oct 20, 2015

dotdash self-assigned this Oct 20, 2015

dotdash changed the title ~~Test run-pass\sepcomp-lib-lto.rs fails with ODR in debug mode~~ Test run-pass\sepcomp-lib-lto.rs fails with ODR violation in debug mode Oct 20, 2015

dotdash removed their assignment Oct 20, 2015

sanxiyn added A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) and removed O-windows Operating system: Windows labels Oct 20, 2015

sanxiyn mentioned this issue Oct 27, 2015

OSX make check failure #29389

Closed

nagisa mentioned this issue Nov 8, 2015

Compilation issues with debug and LTO enabled #29685

Closed

apasel422 mentioned this issue Nov 10, 2015

sepcomp-lib-lto.rs test failed on Rust 1.4.0 built with --enable-debug #29739

Closed

dotdash mentioned this issue Feb 9, 2016

LLVM assertion with tests on Windows #31501

Closed

rust-highfive added the I-nominated label Mar 23, 2016

pnkfelix added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Mar 23, 2016

rust-highfive added P-medium Medium priority and removed I-nominated labels Mar 24, 2016

jonas-schievink mentioned this issue Jul 4, 2016

rustc fails with "Assertion `Ty == resolve(Ty->getRef()) && "type was not uniqued, possible ODR violation." #34649

Closed

yuriks mentioned this issue Jul 22, 2016

Upgrade to newest Rust nightly tock/tock#75

Merged

yuriks added a commit to yuriks/tock that referenced this issue Jul 30, 2016

Disable debugging info to work around rust-lang/rust#25270

c85d8d4

apanda added a commit to NetSys/NetBricks that referenced this issue Aug 4, 2016

Changes to README.md and build.sh

cc59be9

This reflects the fact that currently rust-lang/rust#25270 seems to be solved for nightly builds

metajack mentioned this issue Aug 16, 2016

LLVM assertion failure when building Servo release version with debug symbols on #34434

Closed

michaelwoerister mentioned this issue Jan 18, 2017

Add regression test for debuginfo + LTO #39157

Merged

bors closed this as completed in #39157 Jan 21, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

petrochenkov commented May 10, 2015

petrochenkov commented May 17, 2015

petrochenkov commented Jul 28, 2015

dotdash commented Aug 16, 2015

petrochenkov commented Aug 23, 2015

vharavy commented Sep 17, 2015

dotdash commented Oct 18, 2015

dotdash commented Oct 20, 2015

tamird commented Nov 8, 2015

tamird commented Nov 8, 2015

frewsxcv commented Jan 27, 2016

agbaroni commented Mar 23, 2016

pnkfelix commented Mar 23, 2016

pnkfelix commented Mar 23, 2016

pnkfelix commented Mar 23, 2016

nikomatsakis commented Mar 24, 2016

nikomatsakis commented Mar 24, 2016

michaelwoerister commented Mar 25, 2016

cgswords commented Jun 6, 2016 •

edited

Loading

sfackler commented Jul 10, 2016

jonas-schievink commented Jul 10, 2016

MagaTailor commented Jul 21, 2016

whitequark commented Aug 17, 2016 •

edited

Loading

whitequark commented Aug 17, 2016

alevy commented Aug 17, 2016

whitequark commented Aug 17, 2016

alevy commented Aug 17, 2016 •

edited

Loading

whitequark commented Aug 17, 2016

pmarcelll commented Sep 22, 2016

pbadeer commented Jan 15, 2017 •

edited

Loading

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

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

Comments

petrochenkov commented May 10, 2015

petrochenkov commented May 17, 2015

petrochenkov commented Jul 28, 2015

dotdash commented Aug 16, 2015

petrochenkov commented Aug 23, 2015

vharavy commented Sep 17, 2015

dotdash commented Oct 18, 2015

dotdash commented Oct 20, 2015

tamird commented Nov 8, 2015

tamird commented Nov 8, 2015

frewsxcv commented Jan 27, 2016

agbaroni commented Mar 23, 2016

pnkfelix commented Mar 23, 2016

pnkfelix commented Mar 23, 2016

pnkfelix commented Mar 23, 2016

nikomatsakis commented Mar 24, 2016

nikomatsakis commented Mar 24, 2016

michaelwoerister commented Mar 25, 2016

cgswords commented Jun 6, 2016 • edited Loading

sfackler commented Jul 10, 2016

jonas-schievink commented Jul 10, 2016

MagaTailor commented Jul 21, 2016

whitequark commented Aug 17, 2016 • edited Loading

whitequark commented Aug 17, 2016

alevy commented Aug 17, 2016

whitequark commented Aug 17, 2016

alevy commented Aug 17, 2016 • edited Loading

whitequark commented Aug 17, 2016

pmarcelll commented Sep 22, 2016

pbadeer commented Jan 15, 2017 • edited Loading

cgswords commented Jun 6, 2016 •

edited

Loading

whitequark commented Aug 17, 2016 •

edited

Loading

alevy commented Aug 17, 2016 •

edited

Loading

pbadeer commented Jan 15, 2017 •

edited

Loading