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.

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

Work around LLVM debuginfo problem in librustc_driver. #49904

Merged
merged 4 commits into from
Apr 17, 2018

Conversation

michaelwoerister
Copy link
Member

Works around a problem (#48910) with global variable debuginfo generation for rustc_driver::get_trans::LOAD by applying #[no_debug] to it (which just disables debuginfo generation for that variable). This way we can build the compiler with debuginfo again.

Since the problem is also present in beta, this workaround might have to be backported.

r? @alexcrichton

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 12, 2018
@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Contributor

bors commented Apr 12, 2018

📌 Commit f1610ae has been approved by alexcrichton

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 12, 2018
@alexcrichton alexcrichton added beta-nominated Nominated for backporting to the compiler in the beta channel. beta-accepted Accepted for backporting to the compiler in the beta channel. labels Apr 12, 2018
kennytm added a commit to kennytm/rust that referenced this pull request Apr 13, 2018
…lexcrichton

Work around LLVM debuginfo problem in librustc_driver.

Works around a problem (rust-lang#48910) with global variable debuginfo generation for `rustc_driver::get_trans::LOAD` by applying `#[no_debug]` to it (which just disables debuginfo generation for that variable). This way we can build the compiler with debuginfo again.

Since the problem is also present in beta, this workaround might have to be backported.

r? @alexcrichton
@kennytm
Copy link
Member

kennytm commented Apr 14, 2018

Yesterday the rollup 49939 failed on dist-arm-linux due to a strange error when cross-compiling liballoc (stage1, x86_64-unknown-linux-gnuarm-unknown-linux-gnueabi):

[00:22:41] error: failed to prepare thin LTO module: Invalid function metadata: outgoing forward refs (Producer: 'LLVM6.0.0' Reader: 'LLVM 6.0.0')

At that point, the PRs involved in the rollup are {"#49289", "#49396", "#49850", "#49866", "#49876", "#49884", "#49886", "#49904", "#49908", "#49915", "#49916", "#49922"}

Later I've reconstructed the rollup by removing all liballoc or metadata-related PRs, and the final list is {"#49465", "#49852", "#49864", "#49866", "#49871", "#49876", "#49886", "#49908", "#49913", "#49915", "#49916", "#49922", "#49951", "#49958"}

The difference, that may be the cause of that error, is:

- #49904 (Work around LLVM debuginfo problem in librustc_driver.)
- #49396 (Make OnDiskCache thread-safer)
- #49289 (Make --emit=metadata output metadata regardless of link)
- #49884 (core: Remove panics from some `Layout` methods)
- #49850 (core: Inline `From<AllocErr> for CollectionAllocErr`)

Here, 49396 and 49289 are already merged, which leaves only 49904, 49884 and 49850 as suspects. Out of which, I think this PR is the strongest candidate since it touches LLVM. @michaelwoerister could you verify if cross-compiling libstd to ARM works fine?

@bors
Copy link
Contributor

bors commented Apr 15, 2018

⌛ Testing commit f1610ae with merge 9e85294de5f524b40b7e56327dbbf765ca29cb24...

@bors
Copy link
Contributor

bors commented Apr 15, 2018

💔 Test failed - status-travis

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Apr 15, 2018
@rust-highfive
Copy link
Collaborator

Your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[00:23:36] error: failed to prepare thin LTO module: Invalid function metadata: outgoing forward refs (Producer: 'LLVM6.0.0' Reader: 'LLVM 6.0.0')
[00:23:36]
[00:23:36] error: aborting due to previous error
[00:23:36]
[00:23:36] [RUSTC-TIMING] alloc test:false 6.701
[00:23:36] error: Could not compile `alloc`.
[00:23:36]
[00:23:36] Caused by:
[00:23:36]   process didn't exit successfully: `/checkout/obj/build/bootstrap/debug/rustc --crate-name alloc liballoc/lib.rs --color always --error-format json --crate-type lib --emit=dep-info,link -C opt-level=2 -C metadata=f44c2b79c5c900d2 -C extra-filename=-f44c2b79c5c900d2 --out-dir /checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/aarch64-unknown-linux-gnu/release/deps --target aarch64-unknown-linux-gnu -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/aarch64-unknown-linux-gnu/release/deps -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/release/deps --extern compiler_builtins=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/aarch64-unknown-linux-gnu/release/deps/libcompiler_builtins-0131a1f921771d4b.rlib --extern core=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/aarch64-unknown-linux-gnu/release/deps/libcore-e89ee5bd779a4348.rlib -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/aarch64-unknown-linux-gnu/release/build/compiler_builtins-dd154bc0b1d5dfeb/out` (exit code: 101)
[00:23:36] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "aarch64-unknown-linux-gnu" "-j" "4" "--release" "--locked" "--color" "always" "--features" "panic-unwind jemalloc backtrace" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "--message-format" "json"
[00:23:36] expected success, got: exit code: 101
[00:23:36] thread 'main' panicked at 'cargo must succeed', bootstrap/compile.rs:1085:9
---
$ ls -lat $HOME/Library/Logs/DiagnosticReports/
ls: cannot access /home/travis/Library/Logs/DiagnosticReports/: No such file or directory
travis_time:end:242aa404:start=1523816141901628648,finish=1523816141909396600,duration=7767952
travis_fold:end:after_failure.2
travis_fold:start:after_failure.3
travis_time:start:06b16048
$ find $HOME/Library/Logs/DiagnosticReports -type f -name '*.crash' -not -name '*.stage2-*.crash' -not -name 'com.apple.CoreSimulator.CoreSimulatorService-*.crash' -exec printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" {} \; -exec head -750 {} \; -exec echo travis_fold":"end:crashlog \; || true
find: `/home/travis/Library/Logs/DiagnosticReports': No such file or directory
travis_time:end:06b16048:start=1523816141916492114,finish=1523816141924556659,duration=8064545
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0374002e
$ dmesg | grep -i kill
[   10.476510] init: failsafe main process (1094) killed by TERM signal

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

1 similar comment
@rust-highfive
Copy link
Collaborator

Your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[00:23:36] error: failed to prepare thin LTO module: Invalid function metadata: outgoing forward refs (Producer: 'LLVM6.0.0' Reader: 'LLVM 6.0.0')
[00:23:36]
[00:23:36] error: aborting due to previous error
[00:23:36]
[00:23:36] [RUSTC-TIMING] alloc test:false 6.701
[00:23:36] error: Could not compile `alloc`.
[00:23:36]
[00:23:36] Caused by:
[00:23:36]   process didn't exit successfully: `/checkout/obj/build/bootstrap/debug/rustc --crate-name alloc liballoc/lib.rs --color always --error-format json --crate-type lib --emit=dep-info,link -C opt-level=2 -C metadata=f44c2b79c5c900d2 -C extra-filename=-f44c2b79c5c900d2 --out-dir /checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/aarch64-unknown-linux-gnu/release/deps --target aarch64-unknown-linux-gnu -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/aarch64-unknown-linux-gnu/release/deps -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/release/deps --extern compiler_builtins=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/aarch64-unknown-linux-gnu/release/deps/libcompiler_builtins-0131a1f921771d4b.rlib --extern core=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/aarch64-unknown-linux-gnu/release/deps/libcore-e89ee5bd779a4348.rlib -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/aarch64-unknown-linux-gnu/release/build/compiler_builtins-dd154bc0b1d5dfeb/out` (exit code: 101)
[00:23:36] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "aarch64-unknown-linux-gnu" "-j" "4" "--release" "--locked" "--color" "always" "--features" "panic-unwind jemalloc backtrace" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "--message-format" "json"
[00:23:36] expected success, got: exit code: 101
[00:23:36] thread 'main' panicked at 'cargo must succeed', bootstrap/compile.rs:1085:9
---
$ ls -lat $HOME/Library/Logs/DiagnosticReports/
ls: cannot access /home/travis/Library/Logs/DiagnosticReports/: No such file or directory
travis_time:end:242aa404:start=1523816141901628648,finish=1523816141909396600,duration=7767952
travis_fold:end:after_failure.2
travis_fold:start:after_failure.3
travis_time:start:06b16048
$ find $HOME/Library/Logs/DiagnosticReports -type f -name '*.crash' -not -name '*.stage2-*.crash' -not -name 'com.apple.CoreSimulator.CoreSimulatorService-*.crash' -exec printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" {} \; -exec head -750 {} \; -exec echo travis_fold":"end:crashlog \; || true
find: `/home/travis/Library/Logs/DiagnosticReports': No such file or directory
travis_time:end:06b16048:start=1523816141916492114,finish=1523816141924556659,duration=8064545
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0374002e
$ dmesg | grep -i kill
[   10.476510] init: failsafe main process (1094) killed by TERM signal

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@michaelwoerister
Copy link
Member Author

I'll take a look. It might also be a different issue introduced by having a bootstrap compiler that now that uses LLVM 6.0?

@kennytm
Copy link
Member

kennytm commented Apr 16, 2018

The error happens when cross-compiling using the stage1 compiler, so I doubt this is caused by the bootstrap (stage0) compiler.

Though LLVM 6 can be the cause, since the smoke test CI uses LLVM 3.9. This problem might also be ARM-specific.

@alexcrichton
Copy link
Member

FWIW the most recent failure on CI was cross-compiling libstd in stage1 to aarch64-unknown-linux-gnu, which may point it more as a cross-compile thing rather than an ARM thing, but I'd also imagine that the ARM and aarch64 backends probably share a good deal of code.

@kennytm kennytm added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 16, 2018
@nnethercote
Copy link
Contributor

I'm still getting the clang abort when compiling with debuginfo on Linux64.

@michaelwoerister
Copy link
Member Author

I was able to reproduce the error and this version doesn't trigger it anymore.

@bors r=alexcrichton

@bors
Copy link
Contributor

bors commented Apr 17, 2018

📌 Commit 2814928 has been approved by alexcrichton

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 17, 2018
@bors
Copy link
Contributor

bors commented Apr 17, 2018

⌛ Testing commit 2814928 with merge 786e305...

bors added a commit that referenced this pull request Apr 17, 2018
Work around LLVM debuginfo problem in librustc_driver.

Works around a problem (#48910) with global variable debuginfo generation for `rustc_driver::get_trans::LOAD` by applying `#[no_debug]` to it (which just disables debuginfo generation for that variable). This way we can build the compiler with debuginfo again.

Since the problem is also present in beta, this workaround might have to be backported.

r? @alexcrichton
@bors
Copy link
Contributor

bors commented Apr 17, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 786e305 to master...

@bors bors merged commit 2814928 into rust-lang:master Apr 17, 2018
@alexcrichton alexcrichton removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Apr 19, 2018
kennytm added a commit to oli-obk/rust that referenced this pull request Apr 19, 2018
bors added a commit that referenced this pull request Apr 19, 2018
[beta] backport various PRs

original PRs:

* #49949 (not yet merged at the time of writing)
* #49947 (long running const eval error -> warning)
* #49833 (static recursion)
* #49876 (no clippy in stable rls)
* #49904 (Work around LLVM debuginfo problem in librustc_driver. )
@alexcrichton
Copy link
Member

@michaelwoerister I'm getting that same error on https://travis-ci.org/rust-lang-nursery/stdsimd/jobs/368892648, what'd you end up needing to do to fix it?

@michaelwoerister
Copy link
Member Author

In my case it was that we were not producing debuginfo for drop-glue and shims anymore. Then I changed the last commit (2814928) and the error went away.

@nnethercote
Copy link
Contributor

@michaelwoerister: I just updated and I'm still seeing this error :(

@michaelwoerister
Copy link
Member Author

@nnethercote The fix merged into the current beta branch. @rust-lang/release, is the bootstrapping compiler always an up-to-date beta?

@nnethercote
Copy link
Contributor

Aha! That would explain it. My stage0 compiler is "1.26.0-beta.1 (18aaa1d 2018-04-03)", which is too old to have this fix.

@alexcrichton
Copy link
Member

Ah yes the bootstrap compiler does not automatically update, but a PR is more than welcome to tweak src/stage0.txt!

@michaelwoerister
Copy link
Member Author

@alexcrichton, your wish is my command: #50222

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beta-accepted Accepted for backporting to the compiler in the beta channel. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants