Segfault update thread-local panic count on macOS in empty unit test #50867
Labels
A-runtime
Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows
C-bug
Category: This is a bug.
O-macos
Operating system: macOS
regression-from-stable-to-nightly
Performance or correctness regression from stable to nightly.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
jdm
added
the
regression-from-stable-to-nightly
|
This was referenced May 18, 2018
|
There are no nightlies between 4-30 and 5-03, unfortunately. Based on the commit log from github, I believe 221b7ca...58eeeb4 is the range of commits that could be responsible. |
|
I can't reproduce the error with Edit: No repro with the mentioned nightly either. |
|
It reproduces consistently on three particular macOS build machines that Servo uses. I can't actually reproduce it locally. I am attempting to bisect rustc on an affected machine to figure out the cause. |
|
@jdm What are the macOS and Xcode versions of those build machines? Maybe it's caused by Xcode 7 again. |
|
|
(Darwin 14.5.0 = OS X Yosemite 10.10.5) |
cuviper
added
A-runtime
|
|
FWIW this historically has looked to be an issue with OSX's linker. Newer versions of Xcode appear to have a fixed linker as this bug doesn't manifest when Rust programs are linked with newer versions of Xcode |
|
While the underlying bug might be in the linker, programs that used to compile correctly with an older rustc version don’t anymore. https://forge.rust-lang.org/platform-support.html lists "OSX (10.7+, Lion+)" as tier 1, but XCode 8 is only available on 10.11.5+. Are we dropping support for older versions? |
|
@SimonSapin oh I'm not saying we shouldn't fix this, it's moreso that at this point in time no one knows how to fix this other than (a) using an updated Xcode or (b) compiling with |
This sounds very very good to know, thanks! It’s much easier than upgrading the OS on Servo’s CI. I’ll try it today. |
|
As to knowing how to fix it, bisecting to a single PR would be a start. Is there an easier way to use CI builds than forging S3 URLs and extracting a couple tarballs manually? |
|
@SimonSapin Both |
|
|
|
Awesome thanks for the bisection @SimonSapin! Also cc @Zoxc for that commit. For the build error you had above, was that a clean build? I think you'll have to recompile some of the C objects. For the bisection result my guess would be that it's a legitimate optimization being performed which the linker or something along the way doesn't handle. I'm not sure what though? I would personally be ok backing out the opt-level=3 change as well. |
|
The |
I think this would probably work around the bug, but adding a test so that it doesn’t regress again is tricky since the Travis-CI config uses newer XCode than versions that are affected according to #50867 (comment). |
SimonSapin
added a commit
to SimonSapin/rust
that referenced
this issue
May 29, 2018
This reverts commit aad9840. Level 3 (possibly indirectly, the underlying bug might be in XCode’s linker) causes unit tests to sefault when compiled with some versions of XCode: rust-lang#50867 It also appears to cause some segfaults on Windows: rust-lang#50329 (comment) … and regressions in some rustc performance benchmarks: rust-lang#50329 (comment)
SimonSapin
added a commit
to SimonSapin/rust
that referenced
this issue
May 29, 2018
|
Note: On LLVM 6, Maybe we could isolate to one of these passes but we need to find a faster reproducer besides recompiling the whole compiler to stage1. |
bors
added a commit
that referenced
this issue
May 29, 2018
Revert "Set opt-level to 3" This reverts commit aad9840. Level 3 (possibly indirectly, the underlying bug might be in XCode’s linker) causes unit tests to sefault when compiled with some versions of XCode: #50867 It also appears to cause some segfaults on Windows: #50329 (comment), and regressions in some rustc performance benchmarks: #50329 (comment)
|
Reverting in #51165 has worked around the issue for now. Should we keep this open for finding a more targeted work-around? |
|
Can you reproduce on today's nightly on older OSX machines when compiling with LTO? If so I think that's definitely a reason to keep this issue |
|
Adding this: [profile.test]
opt-level = 3
lto = truedoes cause segfaults to come back: But I’m not seeing anything in the rustc command for LTO… |
|
It's weird but you'll want to configure the bench profile |
|
Alright, this time I get |
|
bah! In that case seems safe to close as we can't reproduce easily then |
|
I encountered a similar situation on macOS with the XCode 9.3 and project: compile with |
Mark-Simulacrum
added a commit
to Mark-Simulacrum/rust
that referenced
this issue
Jun 30, 2018
…xcrichton Do not allow LLVM to increase a TLS's alignment on macOS. This addresses the various TLS segfault on macOS 10.10. Fix rust-lang#51794. Fix rust-lang#51758. Fix rust-lang#50867. Fix rust-lang#48866. Fix rust-lang#46355. Fix rust-lang#44056.
bors
added a commit
that referenced
this issue
Jul 11, 2018
Set opt-level = 3 the third time. This PR reverts #51165 (set -O2 to fix #50867), which reverted #50329 (set -O3), which was second attempt of #48204 (set -O3, closed due to Windows segfault that is fixed now), which reverted #42123 (set -O2 to fix spurious Windows segfaults), which reverted #41967 (set -O3). Last time we've found that setting -O3 regressed the wall time of NLL (#50329 (comment)), so we may need another perf run to confirm. I'd like to check this *after* the LLVM 7 upgrade #51966 has been merged, so marking this as <kbd>S-blocked</kbd> for now.
bors
added a commit
that referenced
this issue
Jul 14, 2018
Set opt-level = 3 the third time. This PR reverts #51165 (set -O2 for fixing #50867), which reverted #50329 (set -O3), which was second attempt of #48204 (set -O3, closed due to Windows segfault that is fixed now), which reverted #42123 (set -O2 to fix spurious Windows segfaults), which reverted #41967 (set -O3). Since we have found the root cause of #50867, this optimization could be tried again. Last time we've found that setting -O3 regressed the wall time of NLL (#50329 (comment)), so we may need another perf run to confirm. I'd like to check this *after* the LLVM 7 upgrade #51966 has been merged, so marking this as <kbd>S-blocked</kbd> for now.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
text_util.rs:
The text was updated successfully, but these errors were encountered: