# procstat not working



## ProphetOfDoom (Dec 29, 2018)

Hi,
I need to get the base addresses of all shared objects loaded by a particular process. The output of the command `procstat -v pid` is incomplete; the PATH field is blank for most memory regions (well, all except the name of the main program and the dynamic loader). I know my library is loaded because I’m printing out text in its constructor. But procstat doesn’t show its name.
Can anyone help? I don’t mind whether it’s C code or a shell command.
Thanks.


----------



## ShelLuser (Dec 29, 2018)

According to procstat(1) some information is only shown if you're either the owner of the process or root. As such: did you also try to run that command as root to see if it generated more useful output?


----------



## T-Daemon (Dec 29, 2018)

AlexanderProphet said:


> The output of the command  procstat -v pid is incomplete; the PATH field is blank for most memory regions (well, all except the name of the main program and the dynamic loader).


Does the above description not match the annotation in the bug section of procstat(1)?

```
BUGS
     The display of open file or memory    mapping    pathnames is implemented using
     the kernel's name cache.  If a file system    does not use the name cache,
     or    the path to a file is not in the cache,    a path will not    be displayed.
```


----------



## Bobi B. (Dec 29, 2018)

There are at least two cases I've met, where path name will be unavailable:

shared library have been unlink(2)ed from the filesystem (some JIT VMs do that, particularly Java runtime, the last time I've checked),
the process were started some time ago and due to one reason, or another, a component from shared library's path is no longer in the name cache.
To work-around this you can get mapped file's i-node and run a find(1) for it. Won't work for unlinked files. You should also be aware, that i-nodes can be duplicated across filesystems.


----------



## yuripv (Dec 29, 2018)

What is the actual procstat output?


----------



## ProphetOfDoom (Dec 29, 2018)

Hi there,
ShelLuser,`sudo` has no effect on the output.
T-Daemon I thought it might be this, but I didn't really understand the bugs section of the man page.
Bobi B thank you I shall investigate that option.
yuri, here is the command output:

```
PID              START                END PRT  RES PRES REF SHD FLAG TP PATH
13846           0x400000           0x401000 r-x    1    3   1   0 CN-- vn /usr/home/alexander/exp_valve/hamster_fish
13846           0x600000           0x601000 rw-    1    1   1   0 ---- df
13846        0x800600000        0x800620000 r-x   29   29  66   0 CN-- vn /libexec/ld-elf.so.1
13846        0x80081f000        0x800821000 rw-    1    1   1   0 ---- df
13846     0x7fffdffff000     0x7ffffffdf000 ---    0    0   0   0 ---- --
13846     0x7ffffffdf000     0x7ffffffff000 rw-    1    1   1   0 ---D df
13846     0x7ffffffff000     0x800000000000 r-x    1    1  69   0 ---- ph
```
There should be (as in Linux's procfs) a mention of a shared object which I know to be loaded.
Does anyone have a cleaner way to find an object's base address? I know how to do it _from within the object itself - _with the `dladdr` function - but I want to do this from within a parent process.


----------



## ProphetOfDoom (Dec 29, 2018)

Sorry, I was so p****d off about procstat I completely forgot to thank you guys for your time. Thank-you, it's appreciated!


----------



## Bobi B. (Dec 29, 2018)

In procstat(1), when `TP` is not `vn`, this memory range is not mmapped to a vnode.


----------



## ProphetOfDoom (Dec 29, 2018)

So what's going on? Are the `df` entries not shared objects at all? Really confused now.


----------



## Bobi B. (Dec 29, 2018)

Consult procstat(1) man page: `man procstat`:

```
The following VM object types may be displayed:

     --  none
     dd  dead
     df  default
     dv  device
     md  device with managed pages (GEM/TTM)
     ph  physical
     sg  scatter/gather
     sw  swap
     vn  vnode
```

... I'm not sure what `default` means, but it is not a memory-mapped file.

PS: FreeBSD man pages are pretty solid.


----------



## ProphetOfDoom (Dec 29, 2018)

There must be a simple way for a debugger to determine where the child process’ libs are loaded. Otherwise how would debuggers insert breakpoints?


----------

