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