[comp.unix.wizards] Debugging Child Processes.

pratap@hpcllcm.HP.COM (Pratap Subrahmanyam) (08/25/89)

I have been running into the following problem. I want to debug a child process
and all the debugger's that we have here cannot do that. Does anyone know where
such a debugger can be got ?


main()
{
...
if((pid = fork()) == 0) {

/* How can you step into this area ???? */

}
}

Any pointers will be appreciated.

-- pratap

kannan@babcock.cerc.wvu.wvnet.edu (R. Kannan) (08/25/89)

From article <6840004@hpcllcm.HP.COM>, by pratap@hpcllcm.HP.COM (Pratap Subrahmanyam):

> main()
> {
> ....
> if((pid = fork()) == 0) {
> 
> /* How can you step into this area ???? */
> 
> }
> }
> 
> Any pointers will be appreciated.
> 
> -- pratap

 Standard dbx(or any of its variations dbxtool etc)
there are commands like attach, debug etc.

What one woulf have to do is to get the pid of the child process and
then attach to it.
The great dbx will then step one through the child process.

We have found this otbe very useful.

If the child process quits too soon, then put a sleep in child and then
see what happens in it.

	Hope this helps.

--kannan

guy@auspex.auspex.com (Guy Harris) (08/27/89)

> Standard dbx(or any of its variations dbxtool etc)
>there are commands like attach, debug etc.

Wrongo.  SunOS "dbx" has "attach", but that's because SunOS "ptrace" has
PTRACE_ATTACH.  4.xBSD's "dbx" doesn't have "attach", because 4.xBSD's
"ptrace" doesn't have PTRACE_ATTACH.  Vendors other than Sun also offer
"dbx", and they may or may not have "attach".  I don't know which
version of "dbx" you mean by "standard 'dbx'", but not all versions have
"attach"....

deraadt@enme3.ucalgary.ca (Theo Deraadt) (08/27/89)

In article <6840004@hpcllcm.HP.COM> pratap@hpcllcm.HP.COM (Pratap Subrahmanyam) writes:
>I have been running into the following problem. I want to debug a child process
>and all the debugger's that we have here cannot do that. Does anyone know where
>such a debugger can be got ?
>
>main() {
>    ...
>    if((pid = fork()) == 0) {
>        /* How can you step into this area ???? */
>    }
>}

Under SunOS4.0 I can suggest one trick that I use when I have a lot of
weird things happening. It's only useful in a fork()ed child after you
do an exec().. I have not figured out a neat trick for doing things
there, although I guess I could start to look at ptrace()..

    char *args[10];

    switch( (child=fork()) {
    case -1:
	perror("fork");
	break;
    case 0:
	/* Sorry, I can't help you debug this part.... */
#if TRACE_DEBUG
	args[0] = "/bin/trace";
	args[1] = "-o";
	args[2] = "child.trace";
	args[3] = "child";
	args[4] = "child_argv[1]";
	args[5] = NULL;
#else
	args[0] = "child";
	args[1] = "child_argv[1]");
	args[2] = NULL;
#endif
	execv("/path/child", args);
	_exit(0);
	break;
    default:
	break;
    }

As the child runs (after the exec()), all the system calls it makes and
their parameters will be deposited in child.trace. Oh yeah, if you need
to get the value of a variable, do something stupid with it, like
	kill(-1, int);
	write(-1, string, strlen(string));
Then you can see what it is in the tracefile... Gad, I hope you have a Sun
on you.. this debugging has proved incredibly usefull in writing code that
played with weird stuff....
 <tdr.

Theo de Raadt                    (403) 289-5894     Calgary, Alberta, Canada

glen@astroatc.UUCP (Glen Ecklund) (08/29/89)

In article <6840004@hpcllcm.HP.COM> pratap@hpcllcm.HP.COM (Pratap Subrahmanyam) writes:
>if((pid = fork()) == 0) {
>
>/* How can you step into this area ???? */
>
>}

Simple.  Change the == to !=.
You may have problems, however, if pid is used before you are finished
debugging.  In typical cases, however, it will not be used except in the
parent, after the child is done.

This will allow you to debug the code up to an exec.  If you want to debug
code after an exec, someone else has already posted a solution for that.

If you are using dbx, it is safer to put a breakpoint inside the block,
where your comment is in the above case, and continue.  If you "step" or
"next", both processes will have breakpoints in them, and the one you are
not debugging may fail.

If not dbx, this advice may still be relevant, I don't know.

Glen