liujingchen
commented
4 years ago Hi, I just found that in our real code, it actually also exits with std::process::exit(0) when the segfault happens. Therefore, an unclean shutdown with std::process::exit(0) should be the cause this problem. But the reason why we have this unclean shutdown is because we are using an argument parser clap, which is a popular lib for command line applications. Clap will exit the process if you give arguments --version or --help.
Here is a code example to reproduce:
Cargo.toml:
[package]
name = "..."
version = "0.1.0"
authors = ["..."]
edition = "2018"
[dependencies]
sentry = "0.20.1"
clap = "2.33.3"
[[bin]]
name = "mytest"
path = "src/main.rs"src/main.rs:
fn main() {
let _guard = sentry::init("https://key@sentry.io/42");
let millis = std::time::Duration::from_millis(1);
std::thread::sleep(millis);
clap::App::new("mytest").version("1.0").get_matches();
}Build it with cargo build --release, and run:
$ bash -c "set -e; for n in {1..100};do ./target/release/mytest --version; done"
mytest 1.0
mytest 1.0
bash: line 1: 2603054 Segmentation fault (core dumped) ./target/release/mytest --versionclap has alternative methods to not exit the program when parsing the arguments, so we can work around the problem. But I think it is still better to fix the issue in sentry if possible, since a randomly happening segmentation fault is pretty bad anyway. Or at least should add some warning in sentry-rust's document to tell people avoid exiting the process before the _guard is clean dropped.
Swatinem
Sentry-rust occasionally causes Segmentation fault when our program exits. Here is a minimal code example to reproduce it.
To reproduce
Create a bin project with
cargo new.Cargo.toml:src/main.rs:Build the project with
cargo build --release(debug is also fine), and run the binary repeated:My environment is:
Some findings:
"https://key@sentry.io/42"tosentry::init(), otherwise sentry-rust is disabled, nothing will happen. But I haven't tried using a real Sentry sever yet. Probably one condition of triggering this is to have a fake server URL, or the server is down.std::process::exit(0)is needed in the example code to see the segfault. But in our real code from where we noticed this issue, the segfault can still happen without thestd::process::exit(0). Our real code is doing some real work before exit, so the time before exit is different from the example code. I guess thestd::process::exit(0)is not a cause of the segfault, but just a condition to increase of the chance of happening.std::process::exit(0)is needed to trigger the segfault, see comment below.