Unix Programming - Use of the /proc psuedo-file system

Author

Use of the /proc psuedo-file system

Ed Apap

2004-11-18, 5:52 pm

Hi folks.

I'm relatively new to the world of UNIX programming, and I need to
develop a "monitor" that will be able to examine the state of the data
within a running application. Writing to the process is not required.

I initially was using the ptrace() system call, but had limited
success, and found it to be quite expensive from a processing time
point of view. The man pages also suggested that the /proc
psuedo-file system provided a better interface, so I've been trying
that too.

So, my question is - has anyone out there had any success specifically
using the /proc/<pid>/mem psuedo-file? On the Linux system I have, I
get an "invalid process id" type of error when I try to lseek() to the
required memory location.

Any help would be appreciated

Pascal Bourguignon

2004-11-18, 5:52 pm

eapap@hotmail.com (Ed Apap) writes:

> Hi folks.
>
> I'm relatively new to the world of UNIX programming, and I need to
> develop a "monitor" that will be able to examine the state of the data
> within a running application. Writing to the process is not required.
>
> I initially was using the ptrace() system call, but had limited
> success, and found it to be quite expensive from a processing time
> point of view. The man pages also suggested that the /proc
> psuedo-file system provided a better interface, so I've been trying
> that too.
>
> So, my question is - has anyone out there had any success specifically
> using the /proc/<pid>/mem psuedo-file? On the Linux system I have, I
> get an "invalid process id" type of error when I try to lseek() to the
> required memory location.
>
> Any help would be appreciated

1- This is linux specific, not unix.

2- Perhaps you should first read /proc/$pid/maps to know where to seek to?

3- It's probably better to use mmap than lseek/read.

4- You may find valuable information in the sources of gdb, which is
able to do exactly what you want. Perhaps even you don't need to
program the feature yourself: you could just write a gdb script.

--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.

Michael Kerrisk

2004-11-19, 2:48 am

On 18 Nov 2004 14:41:33 -0800, eapap@hotmail.com (Ed Apap) wrote:

>Hi folks.
>
>I'm relatively new to the world of UNIX programming, and I need to
>develop a "monitor" that will be able to examine the state of the data
>within a running application. Writing to the process is not required.
>
>I initially was using the ptrace() system call, but had limited
>success, and found it to be quite expensive from a processing time
>point of view. The man pages also suggested that the /proc
>psuedo-file system provided a better interface, so I've been trying
>that too.
>
>So, my question is - has anyone out there had any success specifically
>using the /proc/<pid>/mem psuedo-file?

Yes.

>On the Linux system I have, I
>get an "invalid process id" type of error

What is this error? It doesn't correspond to any errno-type value.

>when I try to lseek() to the
>required memory location.
>
>Any help would be appreciated

All I can add is that open()/lseek()/read() of /proc/PID/mem workdks
for me. Do you have a simple program that demonstrates the problem?

Cheers,

Michael

Ed Apap

2004-11-19, 5:51 pm

Michael Kerrisk <michael.kerrisk.at.gmx.net@nospam.com> wrote in message news:<k24rp0pmahtnr8pqn51e23cea9mhn2p258@4ax.com>...
> On 18 Nov 2004 14:41:33 -0800, eapap@hotmail.com (Ed Apap) wrote:
>
>
> Yes.
>
>
> What is this error? It doesn't correspond to any errno-type value.
>
>
> All I can add is that open()/lseek()/read() of /proc/PID/mem workdks
> for me. Do you have a simple program that demonstrates the problem?
>
> Cheers,
>
> Michael

Michael - my apologies! I was not very accurate in my posting.

In fact, the lseek() does work properly. I get the error on the
read() operation. Specifically, I get errno=3 which equates to ESRCH
"No such process". I have seen mention of this on the Internet
"somewhere" but can't remember where :/

The program at this point is a very simple prototype. I pass the pid
of the process, and the address to examine from the command line.

Here is the meat of the code, warts and all:

sprintf( path, "/proc/%u/mem", pid );

fd = open( path, O_RDONLY | O_SYNC );
printf( " OPEN %s returned fd:%u \n", path, fd );

result = lseek( fd, dAddr, SEEK_SET);
printf( " LSEEK %lu (0x%lx) returned %ld\n", dAddr, dAddr, result );
if (-1==result)
{
errText = strerror(errno);
printf( "LSEEK ERROR: %d %s\n", errno, errText );
}
result = 0;
errno = 0;
rVal = read( fd, &result, 4 );
printf( "Read %d bytes, peeked character (read) = \"%c\", (%d),
(HEX:%x)\n",
rVal,
(int)result,
(int)result,
(int)result );
if (-1==rVal)
{
errText = strerror(errno);
printf( "READ ERROR: %d %s\n", errno, errText );
}

close( fd );

Ed Apap

2004-11-19, 5:51 pm

Pascal Bourguignon <spam@mouse-potato.com> wrote in message news:<87zn1ek831.fsf@thalassa.informatimago.com>...
> eapap@hotmail.com (Ed Apap) writes:
>
>
> 1- This is linux specific, not unix.
>
> 2- Perhaps you should first read /proc/$pid/maps to know where to seek to?
>
> 3- It's probably better to use mmap than lseek/read.
>
> 4- You may find valuable information in the sources of gdb, which is
> able to do exactly what you want. Perhaps even you don't need to
> program the feature yourself: you could just write a gdb script.

Pascal - thanks for your ideas. Since the program is just a prototype
at this point, I do look at /proc/$pid/maps using the "cat" utility.
I'll look into mmap.

Unfortuantely, using gdb in any way will not likely work. The system
runs in a 3 processor configuration, and uses a 2 out of 3 voting
scheme. If I use gdb, it will like put in watchpoints that will stop
the process - this will likely cause it to miss its "voting window"
and cause the process to halt.

Barry Margolin

2004-11-19, 8:47 pm

In article <d226dda.0411191343.525d9359@posting.google.com>,
eapap@hotmail.com (Ed Apap) wrote:

> In fact, the lseek() does work properly. I get the error on the
> read() operation. Specifically, I get errno=3 which equates to ESRCH
> "No such process". I have seen mention of this on the Internet
> "somewhere" but can't remember where :/
....
> rVal = read( fd, &result, 4 );
> printf( "Read %d bytes, peeked character (read) = \"%c\", (%d),
> (HEX:%x)\n",
> rVal,
> (int)result,
> (int)result,
> (int)result );
> if (-1==rVal)
> {
> errText = strerror(errno);
> printf( "READ ERROR: %d %s\n", errno, errText );
> }
>
> close( fd );

You called printf(), and it very likely changed errno.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Jonathan Adams

2004-11-22, 2:47 am

In article <87zn1ek831.fsf@thalassa.informatimago.com>,
Pascal Bourguignon <spam@mouse-potato.com> wrote:

> eapap@hotmail.com (Ed Apap) writes:
>

>
> 1- This is linux specific, not unix.
>
> 2- Perhaps you should first read /proc/$pid/maps to know where to seek to?
>
> 3- It's probably better to use mmap than lseek/read.

At least on Solaris (using /proc/<pid>/as, the local equivalent), mmap(2)
doesn't work. And, at least on Linux 2.4.22, it doesn't work, either.
Semantically, it's difficult to see what it should do -- what happens
if you MAP_FIXED a portion of your address space on top of itself?

The ESRCH you are running into is (at least on Linux 2.4.22) because
/proc/<pid>/mem is only accessible to the process itself and a
ptrace(2)-using owner of the process. In the latter case, the process
being examined must also be stopped.

Interestingly, Solaris's /proc/*/as does not have this restriction.

Cheers,
- jonathan

Ed Apap

2004-11-24, 6:28 pm

Barry Margolin <barmar@alum.mit.edu> wrote in message news:<barmar-B9481B.21001019112004@comcast.dca.giganews.com>...
> In article <d226dda.0411191343.525d9359@posting.google.com>,
> eapap@hotmail.com (Ed Apap) wrote:
>
> ...
>
> You called printf(), and it very likely changed errno.

Thanks Barry - I moved the printf() to the "else" branch of the
(-1==rVal) check without any change in results - probably because the
printf() executed successfully it did not change errno.

Ed Apap

2004-11-24, 6:28 pm

Jonathan Adams <jwadams@gmail.com> wrote in message news:<jwadams-5041A8.22574921112004@news1nwk.sfbay.sun.com>...

> The ESRCH you are running into is (at least on Linux 2.4.22) because
> /proc/<pid>/mem is only accessible to the process itself and a
> ptrace(2)-using owner of the process. In the latter case, the process
> being examined must also be stopped.

This is quite interesting. I am now looking into a way to "fool" the
process into thinking that my program is its parent. This is what the
ptrace() system call seems to do. The trick is to find out how it's
done