How can i fix /proc/self/fd/3: undefined symbol: frida_agent_main?

[Sonys9]

Code:

use hook_inject::{Process, Library, inject_process, InjectedProcess};

pub async fn inject(process_id: i32, file_path: String) -> Result<InjectedProcess, String> {
let process = match Process::from_pid(process_id) {
Ok(process) => process,
Err(e) => return Err(format!("Incorrect process id: {}, got error: {}", process_id, e))
};
let library = match Library::from_path(&file_path) {
Ok(library) => library,
Err(e) => return Err(format!("Incorrect library path: {}, got error: {}", file_path, e))
};
let injected_library = match inject_process(process, library) {
Ok(injected_library) => injected_library,
Err(e) => return Err(format!("Can't inject library, got error: {}. The library may inject, but you will unable to uninject it.", e))
};
return Ok(injected_library);
}

Im getting error at inject_process it says /proc/self/fd/3: undefined symbol: frida_agent_main

OS: Linux fedora 6.17.8-200.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov 14 04:52:44 UTC 2025 x86_64 GNU/Linux

But it inject the library with no problems so idk what happens
Anyway the library is still cool

[Sonys9]

Also, for some apps (for me its cs 1.6 where im trying to do some mod) it gives me an error in the same place with text "The connection is closed" maybe the game has some type of anticheat?

[Sonys9]

aand.. also injecting is not as fine as gdb method does
.so lib code:

//use log::info;
use crate::offsets::OFFSETS;
use retour::static_detour;
mod offsets;
mod utils;

static PROCESS_NAME: &'static str = "vuln_app";
static_detour! {
    static OnPvCall: fn(u32);
}

#[ctor::ctor]
fn init() {
    env_logger::init();
    let process_pid = utils::sync_get_process_pid(PROCESS_NAME);
    println!("Found process PID: {}", &process_pid.trim()); 
    let (app_addr_from, app_addr_to) = utils::sync_get_module_address(&process_pid.trim(), PROCESS_NAME, "r-xp").unwrap();
    println!("Found app address: 0x{:x}-0x{:x}", &app_addr_from, &app_addr_to);
    let pv_fn_addr = app_addr_from + OFFSETS[0];
    println!("Found function address: 0x{:x}", &pv_fn_addr);
    let pv_fn: fn(u32) = unsafe { std::mem::transmute(pv_fn_addr) };
    //pv_fn(1000);
    unsafe { 
        OnPvCall.initialize(pv_fn, on_pv_call).unwrap();
        OnPvCall.enable().unwrap();
    };
}

fn on_pv_call(value: u32) {
    println!("Got new function call!");
    println!("Value is {}", value);
}

after the hook my app crashes, but when i inject with gdb everything is fine. I can give all app's and lib's code if you need

[veecore]

I'm really sorry — I'm just seeing this issue now. I hadn't gotten a notification from GitHub. If it's not too late, I'll take a closer look at it right away.

[veecore]

Quick update on this:

1. The '/proc/self/fd/3: undefined symbol: frida_agent_main' error can be worked around by defining an extern "C" function named frida_agent_main in your dynamic library.

I chose frida_agent_main as the default symbol because the underlying Frida Vala code expects a string rather than a nullable string. Passing NULL through the C bindings causes a crash, so I defaulted the symbol name to reduce friction for Rust users.

This never surfaced in my own testing because I always provided an explicit entrypoint instead of relying on the ctor path. Since you'd prefer using a ctor over the entrypoint convenience API, I'd recommend defining the following function for now:

#[unsafe(no_mangle)]
pub unsafe extern "C" fn frida_agent_main(
    _data: *const c_char,
    _stay_resident: *mut i32,
    _state: *mut core::ffi::c_void,
) {}

I'm also considering opening a PR against Frida Core to make both the entrypoint and data arguments optional.

2. Regarding the crash: I was able to reproduce it by printing to the terminal right inside the entrypoint. Printing from inside the hooked symbol shouldn't cause a crash, so something is clearly off there.

I haven't pushed this crate quite that far before, so I never ran into this issue during development. Thanks for reporting it. I'm currently investigating and working on a fix.

UPDATE: I realized I had actually run into something similar before in https://github.com/veecore/retarget/blob/main/examples/screenshot_agent/src/lib.rs. At the time I worked around it by logging to a file instead of writing directly to the terminal from inside the injected library. Looking back, that's probably not a coincidence.