[MacOS] nightly causes runtime segfault when crate binary is compiled with --release #50586
Comments
kennytm
added
O-macos
|
PRs in the range 3926453...55c984e: |
|
@kennytm Does the |
|
@jjpe It is "stable-to-stable" since the regression happened at 1.26, the coming stable version. |
|
Hmm, I have a "nagging feeling" this may fall under the heading of "LLVM codegen regression" (#50422). Without access to some way to reproduce, it's going to be hard to track down. Here are some ideas you might try though:
|
|
triage: P-high However, this is not assigned to anyone yet, as I don't know that we have any immediate steps forward available to us. |
|
One thing this may be which I've seen a lot of lately is a misaligned memory access due to misaligned TLS slots. To diagnose that though we'd need to take a look a gdb backtrace as well as the faulting instruction |
|
TLS... that reminds me of #48866. Any chance you're using Xcode 7? |
|
I think I may got more info on this one since I may ran into it as well. I'm on OSX 10.11.6 The code works fine on 1.25 but immediately segfaults on 1.26. Its also using the A couple of more data points
I'll see if I can come up with an isolated test. |
|
Actually that was easier than expected, it boils down to this to segfault: extern crate thread_local;
use thread_local::ThreadLocal;
fn main() {
let tls: ThreadLocal<u32> = ThreadLocal::new();
assert_eq!(tls.get(), None);
}Let me know if there is more I can do to help debug this. |
|
I tried turning on As for where the issue occurs, the code sample I mentioned on rust-lang.org is this: pub fn read_regex(&mut self, regex: &Regex) -> LexResult<Token> {
self.ensure_has_input()?;
let (m_start, m_end) = match regex.find(self.remaining_source_code()) {
Some(regex_match) if regex_match.start() == 0 =>
(regex_match.start(), regex_match.end()),
_ => return Err(LexErr::ExpectedRegexMatch {
position: self.position()
}),
};
let start = self.position() + m_start;
let end = self.position() + m_end;
self.position = end;
Ok(Token::new(start..end))
}The segfault location here is in the |
|
@jjpe I'm curious - can you run the binary with valgrind so we see where it ends up in the stack when segfaulting? Checking to see if the thread locals are also the culprit. |
|
I redacted some details due to the fact that this is proprietary software, but I think the parts relevant to this thread (no pun intended) are still in there. Specifically, looks like you're correct about thread locals being issue: |
|
From what we know about this bug the issue here is that there's a bug in older linkers on OSX which seems to be fixed on more recent versions. AFAIK we don't know what the bug is, only that newer versions of the linker, when used, do not produce binaries that fault whereas older binaries do. One alternative is to compile Rust code with |
|
@alexcrichton do you have an idea why it still works with 1.25 then? Is it because of the LLVM upgrade which triggered this linker bug? |
|
@daschl LLVM upgrades bring a huge amount of changes, so my guess is that something entirely unrelated is triggering a preexisting bug. I'd doubt that an LLVM change which caused this to worsen would be the actual cause of the underlying issue. |
|
Well, at least for now enabling LTO is the "workaround of least resistance" because I don't need to care about env vars, and it doesn't seem to bring any performance regressions in my case either. So until I get a chance to upgrade the OS I'll just use that. I'm not sure what this means for the bug, though. |
|
visiting for triage. assigning self to evaluate current status and what our options are. |
|
If it is TLS it might be fixed by #51828. Someone needs to confirm. |
|
I just built my crate with using I cannot reproduce the issue anymore. |
|
Thank you @jjpe for confirming that this is fixed! (The Cargo version that you get together with Nightly is based on the |
On OS X 10.10, when I compile a crate I wrote for work and run the crate binary using
cargo run --release, the generated binary will segfault when I try certain actions. Oddly enough, debug builds do not seem to exhibit the segfaulting behavior at all.This bug is tricky to describe, as I have no clue what causes the generated binary to segfault.
Just to rule out the factor: the crate I'm building has no
unsafecode.However, I do know that compiling using up to and including
rustc 1.26.0-nightly (392645394 2018-03-15), the generated crate binary runs fine.Starting with
rustc 1.26.0-nightly (55c984ee5 2018-03-16)something has changed in behavior to cause this segfault on OS X.For context and some additional information, please see the discussion on users.rust-lang.org.
The text was updated successfully, but these errors were encountered: