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

[rzambre]

Platform: Mac OSX 10.11
Servo issue: servo/servo#11828

After commenting out lines 30 and 31 in the Cargo.toml under components/servo, ./mach build -r compiles all the way until layout_thread but returns this LLVM assertion failure:

Assertion failed: (std::all_of(Expr.begin(), Expr.end(), { 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.

This is most likely an existing rustc bug that got exposed after some recent commits (not precisely sure which one but possibly servo/servo#11804) in Servo. The release version with debug symbols on was compiling successfully a couple of days ago.

[rzambre]

Sadly, the error still occurs with the newer rustc version (2016-06-24)

cc @larsbergstrom

[larsbergstrom]

@aturon Is there any work going on with making debug info work better for release builds? We've had to leave it disabled in Servo due to per-platform breakage for a long time (March of 2015 - servo/servo@fda3791). Thanks!

[alexcrichton]

cc @rust-lang/compiler as well, thoughts on debug info in release builds? (@larsbergstrom's previous comment)

[larsbergstrom]

The big thing that this makes challenging is doing any sort of profiling. Since it's only meaningful on release builds, we need to turn it on. I often get lucky on linux or android, but macOS and Windows seem less reliable.

[michaelwoerister]

-Cdebuginfo=1 should provide enough debuginfo for profiling while sidestepping some of the error cases that might cause LLVM to fail. Have you given that a try?

[rzambre]

@michaelwoerister how do I use the -Cdebuginfo=1 flag? I tried ./mach build -r -Cdebuginfo=1 for Servo but I get an unknown flag complaint.

[eddyb]

@rzambre You'd have to find the code that adds to RUSTFLAGS in python/servo and add the flag there.

[glennw]

I tried this and get "error: -g and -C debuginfo both provided" reported from several of our (and upstream) crates. I'm not sure what's causing that yet.

[sanxiyn]

@glennw That error is #7493, which is truly ancient.

[metajack]

I think release+debuginfo should be a tested Rust compiler code path. Do we need to file a separate bug from this to propose that Rust CI start doing this?

[eddyb]

@metajack We have debug-opt but it doesn't run tests.

[metajack]

@eddyb Then it sounds like my proposal is to enable tests on the existing debug-opt. I assume they are disabled because these code paths don't currently pass?

[eddyb]

I don't know the exact details. cc @rust-lang/tools

[sanxiyn]

#27010 has discussion why debug-opt does not run tests.

[larsbergstrom]

We would probably also like to test at least compiling on ARM32 or ARM64 (hopefully both), as those ICE even more often, or at least have over the last couple of years.

[metajack]

@sanxiyn So it's just #25270 that prevents enabling tests on debug-opt builders?

[sanxiyn]

I just ran make check for debug-opt build, and it passed! So it seems to work on x86_64-unknown-linux-gnu.

[alexcrichton]

To clarify what we build today:

• We have builders for an optimized + debug assertions + debuginfo compiler. This does not run tests, it takes too long.
• We have a builder for an optimized compiler and non-optimized tests. Debug info is disabled
• We have a builder for an optimized compiler and optimized tests. Debug info is disabled.

I believe we have no builders that build tests with debug info.

[metajack]

@alexcrichton is it debuginfo or the debug asserts that cause the slowdown when running tests?

[alexcrichton]

I don't personally know, but enabling them both causes the compiler to take just about as long to build as a no-debug-assertions and no-debug-info compiler takes to build and run tests.

[brson]

Seems like turning off the asserts would help then at least. If we had a (new) release + no-asserts + debuginfo builder we could probably get some amount of testing done in time.

[glennw]

This assertion failure is no longer occurring, when building Servo with the compile flags in the original bug report.

[larsbergstrom]

Do you think that we should try turning on debuginfo for Servo by default? I'd LOVE to have it there all the time, but I'm also afraid that it'll cause us to open random high-pri bugs against rustc for random platforms if e.g., there's an ICE in arm32 debuginfo.

[sanxiyn]

I think Rust people would like to learn about debug-opt problems, but realistically can't guarantee that they will be fixed promptly.

Is @rust-lang/compiler team willing to investigate debug-opt problems as high priority as they are found? I think we must do this at some point, but am unsure whether we should right now.

[arielb1]

Unfortunately, only @michaelwoerister has any idea how debuginfo works.

[michaelwoerister]

Unfortunately, only @michaelwoerister has any idea how debuginfo works.

That's a bit of an overstatement. There are others too and it's not more complicated than other parts of the compiler.

Is @rust-lang/compiler team willing to investigate debug-opt problems as high priority as they are found? I think we must do this at some point, but am unsure whether we should right now.

It's really a question of resources and prioritization (as you say). Debuginfo in optimized builds has historically been a rather brittle affair where things could break at every minor LLVM update, especially with LTO enabled, and investigating and fixing these issues can be rather time-consuming.

I think Rust people would like to learn about debug-opt problems, but realistically can't guarantee that they will be fixed promptly.

That's pretty accurate, at least from my point of view.

[larsbergstrom]

Hrm, then it sounds like a good plan of action here is:

• Enable debug info for all platforms
• If there's a break, open a high-pri bug and land the rust up by disabling the flag on the minimum set of platforms possible

[Mark-Simulacrum]

@larsbergstrom Could you give an update here? I don't see anything related to debuginfo in the Cargo.toml; and from my own experience release + debuginfo seems to work locally.. though I cannot be certain.

[larsbergstrom]

You can close this now, from my perspective. Release+debuginfo still breaks occasionally, but there are enough high-profile consumers at this point that the bugs are pretty quickly identified and fixed.