Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

rustc assertion failed when building in release mode with -g #31702

Closed
arkpar opened this issue Feb 16, 2016 · 9 comments · Fixed by #31717 or #31771
Closed

rustc assertion failed when building in release mode with -g #31702

arkpar opened this issue Feb 16, 2016 · 9 comments · Fixed by #31717 or #31771
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-bug Category: This is a bug.

Comments

@arkpar
Copy link

arkpar commented Feb 16, 2016

rustc fails to build my crate in release mode with debugging symbols.
The crate is located here: https://github.com/ethcore/parity/tree/master/ethcore
It is hard to pinpoint the exact piece of code responsible since the error message gives no such indication.

Running cargo rustc --release -- -g fails with the following message:

Assertion failed: (std::all_of(Expr.begin(), Expr.end(), [](const DIExpression *E) { return E && E->isBitPiece(); }) && "conflicting locations for variable"), function addMMIEntry, file /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-mac/build/src/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.h, line 137.

Stack trace:

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x1413 of process 78186]
0x00007fff8e42b002 in __pthread_kill () from /usr/lib/system/libsystem_kernel.dylib
(gdb) bt
#0  0x00007fff8e42b002 in __pthread_kill () from /usr/lib/system/libsystem_kernel.dylib
#1  0x00007fff8b7255c5 in pthread_kill () from /usr/lib/system/libsystem_pthread.dylib
#2  0x00000001034e04d6 in abort () from /Users/a/.multirust/toolchains/nightly/lib/librustc_llvm-fd663c41.dylib
#3  0x00000001034e04b1 in __assert_rtn () from /Users/a/.multirust/toolchains/nightly/lib/librustc_llvm-fd663c41.dylib
#4  0x0000000102b76f49 in llvm::DbgVariable::addMMIEntry(llvm::DbgVariable const&) () from /Users/a/.multirust/toolchains/nightly/lib/librustc_llvm-fd663c41.dylib
#5  0x0000000102b76d38 in llvm::DwarfFile::addScopeVariable(llvm::LexicalScope*, llvm::DbgVariable*) () from /Users/a/.multirust/toolchains/nightly/lib/librustc_llvm-fd663c41.dylib
#6  0x0000000102b63d2c in llvm::DwarfDebug::collectVariableInfoFromMMITable(llvm::DenseSet<std::__1::pair<llvm::DILocalVariable const*, llvm::DILocation const*>, llvm::DenseMapInfo<std::__1::pair<llvm::DILocalVariable const*, llvm::DILocation const*> > >&) () from /Users/a/.multirust/toolchains/nightly/lib/librustc_llvm-fd663c41.dylib
#7  0x0000000102b64e75 in llvm::DwarfDebug::collectVariableInfo(llvm::DwarfCompileUnit&, llvm::DISubprogram const*, llvm::DenseSet<std::__1::pair<llvm::DILocalVariable const*, llvm::DILocation const*>, llvm::DenseMapInfo<std::__1::pair<llvm::DILocalVariable const*, llvm::DILocation const*> > >&) () from /Users/a/.multirust/toolchains/nightly/lib/librustc_llvm-fd663c41.dylib
#8  0x0000000102b669df in llvm::DwarfDebug::endFunction(llvm::MachineFunction const*) () from /Users/a/.multirust/toolchains/nightly/lib/librustc_llvm-fd663c41.dylib
#9  0x0000000102b3e7b6 in llvm::AsmPrinter::EmitFunctionBody() () from /Users/a/.multirust/toolchains/nightly/lib/librustc_llvm-fd663c41.dylib
#10 0x00000001027f342c in llvm::X86AsmPrinter::runOnMachineFunction(llvm::MachineFunction&) () from /Users/a/.multirust/toolchains/nightly/lib/librustc_llvm-fd663c41.dylib
#11 0x0000000102c799fd in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) () from /Users/a/.multirust/toolchains/nightly/lib/librustc_llvm-fd663c41.dylib
#12 0x000000010344190c in llvm::FPPassManager::runOnFunction(llvm::Function&) () from /Users/a/.multirust/toolchains/nightly/lib/librustc_llvm-fd663c41.dylib
#13 0x0000000103441b6b in llvm::FPPassManager::runOnModule(llvm::Module&) () from /Users/a/.multirust/toolchains/nightly/lib/librustc_llvm-fd663c41.dylib
#14 0x0000000103441fb6 in llvm::legacy::PassManagerImpl::run(llvm::Module&) () from /Users/a/.multirust/toolchains/nightly/lib/librustc_llvm-fd663c41.dylib
#15 0x00000001034425ad in llvm::legacy::PassManager::run(llvm::Module&) () from /Users/a/.multirust/toolchains/nightly/lib/librustc_llvm-fd663c41.dylib
#16 0x00000001021ae217 in LLVMRustWriteOutputFile () from /Users/a/.multirust/toolchains/nightly/lib/librustc_llvm-fd663c41.dylib
#17 0x000000010092fa38 in back::write::write_output_file::h8cdf1cd8684c16ddmTc () from /Users/a/.multirust/toolchains/nightly/lib/librustc_trans-fd663c41.dylib
#18 0x00000001009320f5 in back::write::optimize_and_codegen::_$u7b$$u7b$closure$u7d$$u7d$::closure.55532 () from /Users/a/.multirust/toolchains/nightly/lib/librustc_trans-fd663c41.dylib
#19 0x0000000100939e5a in back::write::execute_work_item::hdd6c4255c830b769GOd () from /Users/a/.multirust/toolchains/nightly/lib/librustc_trans-fd663c41.dylib
#20 0x0000000100933350 in back::write::run_passes::h13d1ef292e406e82wAd () from /Users/a/.multirust/toolchains/nightly/lib/librustc_trans-fd663c41.dylib
#21 0x0000000100058d7d in driver::phase_5_run_llvm_passes::h48d3ba608193e436p2a () from /Users/a/.multirust/toolchains/nightly/lib/librustc_driver-fd663c41.dylib
#22 0x00000001000197c4 in driver::compile_input::h54d49124c108da10Bca () from /Users/a/.multirust/toolchains/nightly/lib/librustc_driver-fd663c41.dylib
#23 0x0000000100009442 in run_compiler::h65293143fe622e848Gc () from /Users/a/.multirust/toolchains/nightly/lib/librustc_driver-fd663c41.dylib
#24 0x0000000100006886 in sys_common::unwind::try::try_fn::h7759751279928036373 () from /Users/a/.multirust/toolchains/nightly/lib/librustc_driver-fd663c41.dylib
#25 0x00000001044738cc in __rust_try () from /Users/a/.multirust/toolchains/nightly/lib/libstd-fd663c41.dylib
#26 0x000000010446bd54 in sys_common::unwind::inner_try::he3a51540743a3631D8s () from /Users/a/.multirust/toolchains/nightly/lib/libstd-fd663c41.dylib
#27 0x000000010000713a in boxed::F.FnBox$LT$A$GT$::call_box::h2643543928305581055 () from /Users/a/.multirust/toolchains/nightly/lib/librustc_driver-fd663c41.dylib
#28 0x000000010447d4f0 in sys::thread::Thread::new::thread_start::h26f0f802585e3c80ULx () from /Users/a/.multirust/toolchains/nightly/lib/libstd-fd663c41.dylib
#29 0x00007fff8b723c13 in _pthread_body () from /usr/lib/system/libsystem_pthread.dylib
#30 0x00007fff8b723b90 in _pthread_start () from /usr/lib/system/libsystem_pthread.dylib
#31 0x00007fff8b721375 in thread_start () from /usr/lib/system/libsystem_pthread.dylib
#32 0x0000000000000000 in ?? ()

$ rustc --version --verbose
rustc 1.8.0-nightly (fae516277 2016-02-13)
binary: rustc
commit-hash: fae516277b6da46b6c1cf568765c90fad2f9ae4b
commit-date: 2016-02-13
host: x86_64-apple-darwin
release: 1.8.0-nightly
@alexcrichton
Copy link
Member

This commit in the LLVM 3.8 release branch looks suspicious. Could you try updating your code to the most recent nightly so I can test against a rustc with that LLVM?

@arkpar
Copy link
Author

arkpar commented Feb 16, 2016

rustc 1.8.0-nightly (fae516277 2016-02-13) compiles it fine in debug mode or release without -g. That's the most recent nightly available with multirust.
Here is a similar issue btw: #29541

@alexcrichton
Copy link
Member

Ah right, yes! I'll try with the same nightly where the only change is an upgraded LLVM and see what I can come up with.

@alexcrichton alexcrichton mentioned this issue Feb 16, 2016
Merged
@alexcrichton
Copy link
Member

Ok, fixed in #31717

alexcrichton added a commit to alexcrichton/rust that referenced this issue Feb 16, 2016
@alexcrichton
rustc: Rebase LLVM on the 3.8 release branch
97f7898 
This commit rebases our LLVM submodule on the most recent tip of the
`release_38` branch of LLVM. There's been a few fixes and this notably fixes the
assertion error in rust-lang#31702.
bors added a commit that referenced this issue Feb 17, 2016
@bors
Auto merge of #31717 - alexcrichton:llvmup2, r=brson
82f30d2 
This commit rebases our LLVM submodule on the most recent tip of the
`release_38` branch of LLVM. There's been a few fixes and this notably fixes the
assertion error in #31702.

Closes #31702
@arkpar
Copy link
Author

arkpar commented Feb 17, 2016

Giant thank you @alexcrichton

alexcrichton added a commit to alexcrichton/rust that referenced this issue Feb 19, 2016
@alexcrichton
Ignore the test added in rust-lang#31717
d835f5b 
In rust-lang#31717 we rebased our LLVM fork over the 3.8 release branch, and it was
thought that this fixed rust-lang#31702. The testing, however, must have been erroneous,
as it unfortunately didn't fix the issue! Our MUSL nightly builders are failing
from the same assertion reported in the issue, so we at least know the test case
is a reproduction!

I believe the failure is only happening on the MUSL nightly builders because
none of the auto builders have LLVM assertions enabled, and the Linux nightly
builder *does* have assertions enabled for the binaries we generate but the
distcheck run doesn't test a compiler with LLVM assertions enabled.
@alexcrichton alexcrichton mentioned this issue Feb 19, 2016
Merged
@alexcrichton
Copy link
Member

Alas it looks like I was a little too eager to close this issue, sorry about that! Looks like the LLVM update didn't actually fix anything.

@alexcrichton alexcrichton reopened this Feb 19, 2016
bors added a commit that referenced this issue Feb 20, 2016
@bors
Auto merge of #31771 - alexcrichton:oops-that-didnt-fix-anything, r=b…
a212264 
…rson

In #31717 we rebased our LLVM fork over the 3.8 release branch, and it was
thought that this fixed #31702. The testing, however, must have been erroneous,
as it unfortunately didn't fix the issue! Our MUSL nightly builders are failing
from the same assertion reported in the issue, so we at least know the test case
is a reproduction!

I believe the failure is only happening on the MUSL nightly builders because
none of the auto builders have LLVM assertions enabled, and the Linux nightly
builder *does* have assertions enabled for the binaries we generate but the
distcheck run doesn't test a compiler with LLVM assertions enabled.
@alexcrichton alexcrichton reopened this Feb 20, 2016
@sanxiyn sanxiyn added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Mar 18, 2016
@sanxiyn
Copy link
Member

sanxiyn commented Jan 10, 2017

If you unignore issue-31702.rs test, you now get hr_lifetime_in_assoc_type error, see #33685. It seems probable to me (but not confirmed) this issue is related to the error and is now fixed by rejecting the code.

@Mark-Simulacrum Mark-Simulacrum added the C-bug Category: This is a bug. label Jul 24, 2017
@Mark-Simulacrum
Copy link
Member

@alexcrichton Do you think that @sanxiyn's comment above correctly diagnoses this? If so, we should close this (and maybe removed the test?).

@alexcrichton
Copy link
Member

Sure!

@oli-obk oli-obk mentioned this issue Sep 6, 2017
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-bug Category: This is a bug.
Projects
None yet
Milestone
No milestone
4 participants
@sanxiyn @alexcrichton @Mark-Simulacrum @arkpar