Skip to content

Backtrace info missing when file descriptors exhausted #686

Open

Description

@glyn

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.

Activity

  1. glyn commented on Jan 1, 2025

    @glyn
    Author

    Just noticed this isn't the std backtrace. Apologies. Closing, but feel free to exceed the std behaviour if you like.

  2. glyn commented on Jan 1, 2025

    @glyn
    Author

    I am informed this library provides the standard library backtrace support after all. Re-opening.

    The README threw me: "This library aims to enhance the support of the standard library by [...]"

  3. reopened this on Jan 1, 2025
  4. workingjubilee commented on Jan 1, 2025

    @workingjubilee
    Member

    Ideally, full backtrace information should be generated.

    I'm going to guess that probably won't happen in that event. :^)

    Though it might. I'll look into if the ioctl interface or some other syscall-based thing can be exposed to get the information we need consistently.

    Alternatively, it would be helpful to include some clue in the backtrace as to why the information is missing.

    But we can definitely do that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions