Repository navigation
Segfault in safe code that spawns a thread with an infinite loop when optimized #39753
Description
Summary
Complete original report
Originally reported on Stack Overflow.
use std::thread;
fn main() {
thread::spawn(|| {
let a = 2;
loop {
a*a;
}
}).join();
}$ rustc -O inf.rs
warning: unused result which must be used, #[warn(unused_must_use)] on by default
--> inf.rs:4:5
|
4 | thread::spawn(|| {
| _____^ starting here...
5 | | let a = 2;
6 | | loop {
7 | | a*a;
8 | | }
9 | | }).join();
| |______________^ ...ending here
$ ./inf
Segmentation fault: 11
$ rustc --version --verbose
rustc 1.15.1 (021bd294c 2017-02-08)
binary: rustc
commit-hash: 021bd294c039bd54aa5c4aa85bcdffb0d24bc892
commit-date: 2017-02-08
host: x86_64-apple-darwin
release: 1.15.1
LLVM version: 3.9
Adding an unwrap() does not change the behavior.
Activity
shepmaster commentedon Feb 12, 2017
The original poster there also had this backtrace:
shepmaster commentedon Feb 12, 2017
LLDB (without debugging symbols) says:
shepmaster commentedon Feb 12, 2017
Setting a breakpoint on
unwrap_failedgets this better backtrace:hanna-kruppe commentedon Feb 12, 2017
Might be #39432? There's no nightly with #39721 in it yet, making it hard to try if that fixed it.
shepmaster commentedon Feb 12, 2017
@rkruppe certainly seems related, but there's no
!here AFAICS. If the same, could mean the other issue has a larger scope than it appears.shepmaster commentedon Feb 12, 2017
However, I've got a fresh build going, so I can check in a little bit.
shepmaster commentedon Feb 12, 2017
I updated to ba7cf7c which contains ca92c51, but the issue still appears
shepmaster commentedon Feb 12, 2017
Some disassembly:
The
EXC_BAD_ACCESS/EXC_I386_GPFLToccurs on the 4th instruction there.The registers:
shepmaster commentedon Feb 12, 2017
Valgrind output (code compiled with Rust 1.15.1):
shepmaster commentedon Feb 12, 2017
Oh, right,
loop {}is diverging. However, I still get the segfault on macOS with the commit that is marked as fixing it. I'm (slowly) building master in a Linux VM to get up-to-date Valgrind output.liuxy600 commentedon Feb 12, 2017
A shorter version also crashes:
But, it works well if I add
println!("123")in the loop:shepmaster commentedon Feb 12, 2017
In Linux, against ba7cf7c, the code no longer segfaults, but it does panic:
And Valgrind is still unhappy about it:
sfackler commentedon Feb 12, 2017
Dup of #28728
shepmaster commentedon Feb 12, 2017
Agreed. The LLVM IR has the same telltale sign: