Debugging Forks

使用gdb来调试fork产生的多进程程序,来源:https://sourceware.org/gdb/current/onlinedocs/gdb/Forks.html#Forks

On most systems, gdb has no special support for debugging programs which create additional processes using the fork function. When a program forks, gdb will continue to debug the parent process and the child process will run unimpeded. If you have set a breakpoint in any code which the child then executes, the child will get a SIGTRAP signal which (unless it catches the signal) will cause it to terminate.

However, if you want to debug the child process there is a workaround which isn't too painful. Put a call to sleep in the code which the child process executes after the fork. It may be useful to sleep only if a certain environment variable is set, or a certain file exists, so that the delay need not occur when you don't want to run gdb on the child. While the child is sleeping, use the ps program to get its process ID. Then tell gdb (a new invocation of gdb if you are also debugging the parent process) to attach to the child process (see Attach). From that point on you can debug the child process just like any other process which you attached to.

On some systems, gdb provides support for debugging programs that create additional processes using the fork or vfork functions. Currently, the only platforms with this feature are HP-UX (11.x and later only?) and gnu/Linux (kernel version 2.5.60 and later).

By default, when a program forks, gdb will continue to debug the parent process and the child process will run unimpeded.

If you want to follow the child process instead of the parent process, use the command set follow-fork-mode.

set follow-fork-mode  mode
Set the debugger response to a program call of  fork or  vfork. A call to  fork or  vfork creates a new process. The  mode argument can be:
parent
The original process is debugged after a fork. The child process runs unimpeded. This is the default. 
child
The new process is debugged after a fork. The parent process runs unimpeded.


show follow-fork-mode
Display the current debugger response to a  fork or  vfork call.

On Linux, if you want to debug both the parent and child processes, use the command set detach-on-fork.

set detach-on-fork  mode
Tells gdb whether to detach one of the processes after a fork, or retain debugger control over them both.
on
The child process (or parent process, depending on the value of  follow-fork-mode) will be detached and allowed to run independently. This is the default. 
off
Both processes will be held under the control of  gdb. One process (child or parent, depending on the value of  follow-fork-mode) is debugged as usual, while the other is held suspended.


show detach-on-fork
Show whether detach-on-fork mode is on/off.

If you choose to set ‘detach-on-fork’ mode off, then gdb will retain control of all forked processes (including nested forks). You can list the forked processes under the control of gdb by using the info inferiors command, and switch from one fork to another by using the inferior command (see Debugging Multiple Inferiors and Programs).

To quit debugging one of the forked processes, you can either detach from it by using the detach inferiors command (allowing it to run independently), or kill it using thekill inferiors command. See Debugging Multiple Inferiors and Programs.

If you ask to debug a child process and a vfork is followed by an execgdb executes the new target up to the first breakpoint in the new target. If you have a breakpoint set onmain in your original program, the breakpoint will also be set on the child process's main.

On some systems, when a child process is spawned by vfork, you cannot debug the child or parent until an exec call completes.

If you issue a run command to gdb after an exec call executes, the new target restarts. To restart the parent process, use the file command with the parent executable name as its argument. By default, after an exec call executes, gdb discards the symbols of the previous executable image. You can change this behaviour with the set follow-exec-mode command.

set follow-exec-mode  mode
Set debugger response to a program call of  exec. An  exec call replaces the program image of a process.

follow-exec-mode can be:

new
gdb creates a new inferior and rebinds the process to this new inferior. The program the process was running before the  exec call can be restarted afterwards by restarting the original inferior.

For example:

               (gdb) info inferiors
               (gdb) info inferior
                 Id   Description   Executable
               * 1    <null>        prog1
               (gdb) run
               process 12020 is executing new program: prog2
               Program exited normally.
               (gdb) info inferiors
                 Id   Description   Executable
               * 2    <null>        prog2
                 1    <null>        prog1

same
gdb keeps the process bound to the same inferior. The new executable image replaces the previous executable loaded in the inferior. Restarting the inferior after the exec call, with e.g., the  run command, restarts the executable the process was running after the  exec call. This is the default mode.

For example:

               (gdb) info inferiors
                 Id   Description   Executable
               * 1    <null>        prog1
               (gdb) run
               process 12020 is executing new program: prog2
               Program exited normally.
               (gdb) info inferiors
                 Id   Description   Executable
               * 1    <null>        prog2

You can use the catch command to make gdb stop whenever a forkvfork, or exec call is made.

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值