My problem was (and still is...) that I could not redirect the gdb
to the child process--though it's specificaly designed for that.
Maybe someone still can help about that.
The ddd front end even has a menu for this.
Eventually I did something very similar to what Daniel Feiglin
suggested,
but ch
What about something idiotic like this:
junk = fork();
if (junk < 0) {
// error
}
else if (junk > 0) {
// parent comes here
printf("Child pid = %d\n, junk);
}
else { // junk = 0; chil comes here
sleep(5); // sleep 5 seconds here
...
}
You could stick a g
another idea .. trap or signal for awakening the child after its birth.
after forking - sleep until you send external intervention, in order to
begin execution and examination ... etc.
-=O0~~O0=-
"Beware the Jabberwock, my son!
The jaws that bite, the claws that catc
another problem with attaching to a child process can be:
until the process is born it has no PID ..
and to predict a PID may not be possible.
-=O0~~O0=-
"Beware the Jabberwock, my son!
The jaws that bite, the claws that catch!
Beware the Jubjub bird, and shun
The
>
> ddd is a graphic front end for gdb (and dbx and other debuggers).
> However, I haven't been able to redirect it to the child process,
> after a fork call. I need to redirect the debugger before the
> childs birth-- see the reason below .
> I've write "set follow fork-mode child" on the gdb pa
ddd is a graphic front end for gdb (and dbx and other debuggers).
However, I haven't been able to redirect it to the child process,
after a fork call. I need to redirect the debugger before the
childs birth-- see the reason below .
I've write "set follow fork-mode child" on the gdb panel of ddd,
