[FreeBSD] ptrace( ) - Device busy - High Level Programming

Driver · #1 (**permalink**) 01-30-2003

Hello,
I'm trying to obtain process memory contents using ptrace( ) on FreeBSD 4.7. I know this is neither portable nor clean, yet I'd really like to get it to work... I read the manual help page and did a google search, but couldn't find anything helpful.
First, the code I'm using to read an integer:

Code:

#include <sys/types.h>
#include <sys/ptrace.h>
#include <sys/wait.h>
#include <unistd.h>
#include <signal.h>
#include <errno.h>
#include <stdio.h>

#define ERR( msg, pid ) do { \
                          fprintf( stderr, "%s: %s (errno = %d)\n", \
                            msg, strerror( errno ), errno ); \
                          waitpid( pid, NULL, 0 ); \
                          return 1; \
                        } while( 0 );

int main( ) {
  pid_t child;
  int   i;
  child = fork( );
  if( child == -1 ) {
    perror( "fork" );
    return 1;
  } else if( child == 0 ) {
    execl( "./foobar", NULL );
    perror( "execl" );
    return 1;
  }
  printf( "Attaching to %d\n", child );
  rc = ptrace( PT_ATTACH, child, ( void* )0, 0 );
  if( rc == -1 ) {
    ERR( "ptrace", child );
  }
  printf( "Stopping...\n" );
  if( kill( child, SIGSTOP ) != 0 ) {
    ERR( "kill", child );
  }
  printf( "Attempting to read...\n" );
  rc = ptrace( PT_READ_I, child, ( void* )0, 0 );
  if( rc == -1 ) {
    ERR( "ptrace", child );
  }
  printf( "0x0: %d\n", rc );
  return 0;
}

And the source for the exec'd ``foobar'':

Code:

#include <unistd.h>

int main( ) {
  pause( );
  return 0;
}

The output I get when I execute the program is this:

Code:

Attaching to 5994
Stopping...
Attempting to read...
ptrace: Device busy (errno = 16)

I have tried several variations using PT_READ_I and PT_READ_D (although my manual help page states these are identical on FreeBSD), using several addresses - I always get this error.
Can anyone see what I'm doing wrong here?
Thanks in advance.

Perderabo · #2 (**permalink**) 01-30-2003

I can't actually try this, but that kill() immediately followed by a ptrace() really bothers me.

You seem to be thinking that the kill() system call will not return to the caller until after the signaled process has completed whatever action will result from the signal. Or something like that.

In any event, my guess is that you need to signal the child and then wait until it stops. Look at paragraph 1 of the ptrace man page: "the tracing process is expected to notice this via wait(2) or the delivery of a SIGCHLD signal..." Where are you doing that? Some time is required to actually stop a process, even one that is sleeping.

And look at the "ERRORS" section of the man page...only 3 possibilities. And only:
"A request (other than PT_ATTACH) specified a process that wasn't stopped"
really could apply here.

Hmmmm. Good thing you didn't unbuffer stdout. If you had, that printf might have slowed down the tracer enough that it might sometimes work and sometimes fail.

Driver · #3 (**permalink**) 01-30-2003

Thanks for your reply!
I actually tried it using sleep( ) before, but that didn't have any effect. Using wait( ), as you suggested, did the trick. Now I have a new problem: If I pass low addresses as third parameter, I always get ``Bad address'' errors. While trying to find the root of this problem, I happened to pass the uninitialised variable ``i'' as address (I used it as loop counter before and when I commented that out, the value became, of course, undefined :-) )...
It worked! Strangely, the value of ``i'' was 671482112.
Quotation from the man page:

Quote:

The addr argument specifies the address (in the traced process' virtual address space) at which the read is to be done. This address does not have to meet any alignment constraints.

I don't believe that my tiny ``foobar'' program uses > 640mb of memory. Even if this was an absolute address (contradicting the man page), I don't have that much. While I'm typing this, I have the program trying all ``addresses'' from 0 to 1000000000 - It's at 115xxxxxx now and no ``address'' was valid. What the heck is going here?

Code:

Code:

...
int i;
...
printf( "Attempting to read...\n" );
wait( NULL );
rc = ptrace( PT_READ_D, child, ( void* )i, 0 );
if( rc == -1 && errno ) {
  ERR( "ptrace", child );
}
printf( "%p: %d\n", ( void* )i, rc );

Output:

Code:

Attaching to 6487
Stopping..
Attempting to read...
0x28060100: -716130182

Perderabo · #4 (**permalink**) 01-30-2003

It's awfully hard to help much on this since I don't have access to your system and this stuff varies a lot among kernels. But I'll try...

First, let's say that your pagesize is 4096 and your program needs 50 pages. So it is 50 * 4096 = 204800 bytes long. That does not mean that the first address is zero and the last is 204800. You can't make something like that work with any cpu. Typically the pages are arranged into segments and the segments are contiguous. But the segments will be scattered throughout the virtual address space. Think about malloc() and the underlying brk()/sbrk() calls. They need to be able to make the data segment grow. The stack must be able to change size dynamically. Maybe your program will map in a shared library...now everything has to grow. Also remember that it is illegal to deference a null pointer. Put something at zero and rerefencing a null pointer becomes legal. And taking the address of whatever you put there would give you NULL. The c standard prohibits that taking the address of an object would result in a NULL. And memory is organized into pages. If you can't use the first byte, you can't you the first page.

So you need to know what address you need. It can be anywhere. You might try putting "int xyzzy=777" before the main in your little to-be-traced program. Then run the nm program on it. Since xyzzy is external in scope it should probably be in the symbol table. Get the address for it and plug that into your tracer program. Then see if you can get the value 777. I tend to think that will work.

By the way, I have never used ptrace() on any system, so I am not exactly a ptrace() expert. I am not going to be able to help write a debugger or anything.

Driver · #5 (**permalink**) 01-31-2003

Ok, using addresses from nm works.

I chose a ``null pointer'' fist because I thought the supplied parameter would be used as offset to the beginning of the first page (where the text segment starts, at ``NULL''). Apparently it isn't. Oh well, I guess it's time to read some source code (probably gdb).
Thanks again for your help!

Perderabo · #6 (**permalink**) 01-31-2003

After sleeping on this, I think that I know how to to take this to the next level. The tracing program should be able to use nlist() on the executable of the child. This would enable it to programmaticly obtain the address of externals.

More UNIX and Linux Forum Topics You Might Find Helpful
Thread	Thread Starter	Forum	Replies	Last Post
Tracing self process using ptrace()	vpraveen84	High Level Programming	1	06-02-2008 01:14 PM
Cannot umount - device busy	keelba	HP-UX	2	04-11-2008 12:16 PM
rmdev - device is busy	Livio	AIX	2	05-17-2006 12:58 AM
umount, device busy, but..	sTorm	UNIX for Dummies Questions & Answers	10	08-20-2002 03:49 AM
freeBSD device driver (use struct uio)	Alex_T	High Level Programming	0	07-31-2002 06:12 AM

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode