Groups Created When a Program Calls fork()/exec()
TotalView can automatically attach to child processes created when a process being debugged calls fork() or vfork(). Here’s a typical flow:
1. TotalView is started on a program named "a.out". TotalView names the process "a.out" and automatically places it in Control Group 1 and Share Group 2.
2. During execution, process "a.out" makes a fork() system call to create a child process. If TotalView is configured to automatically attach to child processes, it names the process "a.out.1". The child process remains in Control Group 1 because of the parent/child relationship, and it also remains in Share Group 2 because it is executing the program named "a.out".
3. During execution, process "a.out.1" (the child process) makes an execve() system call on a program named "b.out". TotalView renames the child process to "a.out<b.out>.1". The child process remains in Control Group 1, but is placed in Share Group 3 because it is now executing a program named "b.out".
4. All the threads in processes "a.out" and "a.out<b.out>.1" are placed in Worker Group 4, because neither program creates manager threads, and both processes are members of the same Control Group.
Setting breakpoints when acquiring processes using fork or exec
Use TotalView TV::exec_handling and -exec_handling options to control whether new processes are stopped or allowed to continue running
choose to either attach or detach from the new child process.