backtrace-rs
backtrace-rs copied to clipboard
Backtrace info missing when file descriptors exhausted
When a program uses all available file descriptors and then panics, the backtrace contains no symbolic information, line numbers, and such like.
Example output
Consuming all available file descriptors with RUST_BACKTRACE=full
thread 'main' panicked at src/main.rs:19:13:
ran out of file descriptors
stack backtrace:
0: 0x61c61a98b56a - <unknown>
1: 0x61c61a9a7f33 - <unknown>
2: 0x61c61a988fd3 - <unknown>
3: 0x61c61a98b3b2 - <unknown>
4: 0x61c61a98c35c - <unknown>
5: 0x61c61a98c1a2 - <unknown>
6: 0x61c61a98c937 - <unknown>
7: 0x61c61a98c796 - <unknown>
8: 0x61c61a98ba49 - <unknown>
9: 0x61c61a98c45c - <unknown>
10: 0x61c61a959420 - <unknown>
11: 0x61c61a95b2d9 - <unknown>
12: 0x61c61a959ecb - <unknown>
13: 0x61c61a95ab2e - <unknown>
14: 0x61c61a95b961 - <unknown>
15: 0x61c61a98636e - <unknown>
16: 0x61c61a95b93a - <unknown>
17: 0x61c61a95b33e - <unknown>
18: 0x76526c753e08 - <unknown>
19: 0x76526c753ecc - <unknown>
20: 0x61c61a959c95 - <unknown>
21: 0x0 - <unknown>
Desired behaviour
Ideally, full backtrace information should be generated.
Alternatively, it would be helpful to include some clue in the backtrace as to why the information is missing.
Reproducing the issue
The following program reproduces the behaviour:
use libc;
use tempdir::TempDir;
use std::{ffi::CString, io::Write};
use std::{env, fs::File};
fn main() {
env::set_var("RUST_BACKTRACE", "full");
println!("Consuming all available file descriptors with RUST_BACKTRACE=full");
let tmp_dir = TempDir::new("example").unwrap();
let path : String = tmp_dir.path().join("test").to_owned().into_os_string().into_string().unwrap();
let mut file = File::create_new(&path).unwrap();
file.write_all(b"contents").unwrap();
let mut fds = vec!();
loop {
let file_path = CString::new(path.clone()).unwrap();
let fd = unsafe { libc::open(file_path.as_ptr(), libc::O_RDONLY) };
if fd == -1 {
panic!("ran out of file descriptors");
}
fds.push(fd);
}
}
Reproduce the issue by cloning this repository and issuing cargo run from inside the cloned directory.
Environment
The issue occurred in the following environments.
Linux
- Rust 1.83.0
- Arch linux 6.12.4
- x86_64
macOS
- Rust 1.83.0
- macOS Sonoma 14.7.2
- Apple M1
Background
The issue was encountered while debugging a failing test. See this zuplip conversation for more details.