benfred / remoteprocess

Cross platform process information in Rust

remoteprocess

This crate provides a cross platform way of querying information about other processes running on the system. This let's you build profiling and debugging tools.

Features:

• Suspending the execution of the process
• Getting the process executable name and current working directory
• Get the command line of the process
• Listing all the threads in the process
• Get all the child processes of the process
• Figure out if a thread is active or not
• Read memory from the other processes (using read_proceses_memory crate)

By enabling the unwind feature you can also:

• Get a stack trace for a thread in the target process
• Resolve symbols for an address in the other process

This crate provides implementations for Linux, OSX, FreeBSD and Windows

Usage

To show a stack trace from each thread in a program

fn get_backtrace(pid: remoteprocess::Pid) -> Result<(), remoteprocess::Error> {
    // Create a new handle to the process
    let process = remoteprocess::Process::new(pid)?;

    // lock the process to get a consistent snapshot. Unwinding will fail otherwise
    let _lock = process.lock()?;

    // Create a stack unwind object, and use it to get the stack for each thread
    let unwinder = process.unwinder()?;
    for thread in process.threads()?.iter() {
        println!("Thread {}", thread);

        // Iterate over the callstack for the current thread
        for ip in unwinder.cursor(thread)? {
            let ip = ip?;

            // Lookup the current stack frame containing a filename/function/linenumber etc
            // for the current address
            unwinder.symbolicate(ip, &mut |sf| {
                println!("{}", sf);
            })?;
        }
    }
    Ok(())
}

A complete program with this code can be found in the examples folder.

Limitations

Currently we only have implementations for getting stack traces on some platforms:

	Linux	Windows	OSX	FreeBSD
i686
x86-64	yes	yes
ARM	yes
Aarch64

Credits

This crate heavily relies on the gimli project. Gimli is an amazing tool for parsing DWARF debugging information, and we are using it here for looking up filename and line numbers given an instruction pointer.

remoteprocess's Issues

Please add a license file to this crate

This crate is listed as MIT in metadata, but there's no license file in the repository. Please add one and include it in the crate as well.

Don't try to determine where musl is determined based on the target vendor being alpine or not

This is wrong when trying to use a rustup installed rustc on alpine or when globally installing musl on a non-alpine system. I would suggest always assuming that musl is globally installed and if this isn't the case ask the user to manually pass in the required -Clink-args required to make the linker find musl. This is necessary anyway for other crates like libc to work and it will allow it to work with the musl copy shipped with rustc itself when statically linking. For determining if static or dynamic linking should be used, checking the presence of the crt-static target feature works much better as this is what actually determines if libc will be statically linked or not.

linux/windows: Process.lock() behavior diverges when using ManuallyDrop

This may not be a bug and just need documented:

On Windows using ManuallyDrop with the result of Process.lock will leave the process suspended forever.
On Linux the process will resume after the rust process exits.

This is due to SuspendThread and ptrace attach having different behavior. With ptrace, the process is always resumed once the debugging process exits.

One possible workaround is to directly send SIGSTOP. Whether this library should do this is unclear.

If there was a separate API Process.suspend and Process.resume which deliberately allowed leaving the process suspended then sending SIGSTOP on Linux would be better.

Error: reference to packed field is unaligned

Could not build remoteprocess 0.4.11 with rustc 1.69.0. There are several E0793 errors.

error[E0793]: reference to packed field is unaligned
   --> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/remoteprocess-0.4.11/src/freebsd/kinfo_proc.rs:303:40
    |                                                                                                                                                                                                 
303 |         unsafe { ::std::mem::transmute(self._bitfield_1.get(0usize, 16u8) as u64) }
    |                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: fields of packed structs are not properly aligned, and creating a misaligned reference is undefined behavior (even if that reference is never dereferenced)
    = help: copy the field contents to a local variable, or replace the reference with a raw pointer and use `read_unaligned`/`write_unaligned` (loads and stores via `*p` must be properly aligned even when using raw pointers)

Race condition when locking Linux processes

We've had a couple of reports that locking processes on busy production servers can fail, returning an ESRCH error (no such process). My best guess is that it's related to threads exiting between the calls to self.threads() and thread.lock here, resulting in a lock error. The locking code is tolerant of new threads spinning up during the loop but immediately returns an error if a thread fails to lock.

Would it be acceptable for remoteprocess to log (e.g. debug/warn) failed locks but not return an error? Or to count the number of failed thread locks and only return an error if all of them fail? I'd be happy to make a PR if we can agree on a path.

Downstream issue with repro steps: rbspy/rbspy#334

Failed to get backtrace NixError(EPERM)

cargo run --example trace --features unwind

When I run this command, I got this error. Anyone can help?

    Finished dev [unoptimized + debuginfo] target(s) in 4.02s
    Running `target/debug/examples/trace`
children []
Thread 4116226 - running
Failed to get backtrace NixError(EPERM)

My system:

➜  remoteprocess git:(master) uname -a
Linux n37-132-231 5.4.56.bsk.10-amd64 #5.4.56.bsk.10 SMP Debian 5.4.56.bsk.10 Fri Sep 24 12:17:03 UTC  x86_64 GNU/Linux

Dynamically link libunwind on musl

Instead of forcing static link, could it be linked dynamically on systems that provide libunwind?