ltrace crashes when trying to resolve memory mapped shared libraries of an inferior under /proc/self/fd/*

Hello! Similar to a bug I found on GDB, If any of you will try to dlopen a memory mapped file in the following way:dlopen("/proc/self/fd/4"....) The operation will trigger ltrace's hook on dlopen and will try to load the file "/proc/self/fd/4". Obviously ltrace's process has different FD's on /proc/self, and will read from an arbitrary opened file which will cause ltrace to crash. Here is a rust snippet that will crash ltrace once being debugged:

use std::{os::unix::prelude::{AsFd, AsRawFd}, io::Write};

use memfd;
use dlopen_derive::{self, WrapperApi};
#[macro_use]
use dlopen::wrapper::{Container,WrapperApi};

#[derive(WrapperApi)]
struct Api<'a> {
    example_rust_fun: fn(arg: i32) -> u32,
    example_c_fun: unsafe extern "C" fn(),
    example_reference: &'a mut i32,
}
fn main() {
    let opts = memfd::MemfdOptions::default().allow_sealing(true);
    let mfd = opts.create("hellooo").unwrap();
    let buff = std::fs::read("/usr/lib64/ld-linux-x86-64.so.2").unwrap();
    mfd.as_file().write(buff.as_slice()).unwrap();
    let fd = mfd.as_file().as_fd().as_raw_fd();
    let fm = format!("/proc/self/fd/{}", fd);
    println!("{}", fm);
    let mut cont: Container<Api> =
        unsafe { Container::load(fm) }.expect("Could not open library or load symbols");

}

I can easily submit a patch later this week.

Edited by Asaf Fisher