{"id":255692,"date":"2016-12-21T12:11:20","date_gmt":"2016-12-21T04:11:20","guid":{"rendered":"http:\/\/blog.zhenglei.net\/?p=255692"},"modified":"2016-12-21T12:12:23","modified_gmt":"2016-12-21T04:12:23","slug":"debug-forks-with-gdb","status":"publish","type":"post","link":"https:\/\/blog.zhenglei.net\/?p=255692","title":{"rendered":"Debug Fork with gdb"},"content":{"rendered":"

Two\u00a0 Methods<\/strong><\/span>:<\/p>\n

    \n
  1. Add sleep in the entry of main loop<\/li>\n
  2. With GDB command:<\/li>\n<\/ol>\n

    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 set follow-fork-mode <\/em><\/code>mode<\/var> (parent\/child)<\/em>
    \nset detach-on-fork <\/code><\/em>mode (on\/off)<\/em>
    \n<\/var><\/p>\n

     <\/p>\n

    https:\/\/sourceware.org\/gdb\/onlinedocs\/gdb\/Forks.html<\/a><\/p>\n

    <\/p>\n

    4.11 Debugging Forks<\/h3>\n

    <\/a><\/a><\/a>On most systems, gdb<\/span> has no special support for debugging programs which create additional processes using the fork<\/code> function. When a program forks, gdb<\/span> 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<\/code> signal which (unless it catches the signal) will cause it to terminate.<\/p>\n

    However, if you want to debug the child process there is a workaround which isn’t too painful. Put a call to sleep<\/code> 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<\/span> on the child. While the child is sleeping, use the ps<\/code> program to get its process ID. Then tell gdb<\/span> (a new invocation of gdb<\/span> if you are also debugging the parent process) to attach to the child process (see Attach<\/a>). From that point on you can debug the child process just like any other process which you attached to.<\/p>\n

    On some systems, gdb<\/span> provides support for debugging programs that create additional processes using the fork<\/code> or vfork<\/code> functions. On gnu<\/span>\/Linux platforms, this feature is supported with kernel version 2.5.46 and later.<\/p>\n

    The fork debugging commands are supported in native mode and when connected to gdbserver<\/code> in either target remote<\/code> mode or target extended-remote<\/code> mode.<\/p>\n

    By default, when a program forks, gdb<\/span> will continue to debug the parent process and the child process will run unimpeded.<\/p>\n

    If you want to follow the child process instead of the parent process, use the command set\u00a0follow-fork-mode<\/code>. <\/a><\/p>\n

    \n
    set follow-fork-mode <\/code>mode<\/var><\/dt>\n
    Set the debugger response to a program call of fork<\/code> or vfork<\/code>. A call to fork<\/code> or vfork<\/code> creates a new process. The mode<\/var> argument can be:<\/p>\n
    \n
    parent<\/code><\/dt>\n
    The original process is debugged after a fork. The child process runs unimpeded. This is the default.<\/dd>\n
    child<\/code><\/dt>\n
    The new process is debugged after a fork. The parent process runs unimpeded.<\/dd>\n<\/dl>\n

    <\/a><\/p>\n<\/dd>\n

    show follow-fork-mode<\/code><\/dt>\n
    Display the current debugger response to a fork<\/code> or vfork<\/code> call.<\/dd>\n<\/dl>\n

    <\/a>On Linux, if you want to debug both the parent and child processes, use the command set\u00a0detach-on-fork<\/code>. <\/a><\/p>\n

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

    <\/a><\/p>\n<\/dd>\n

    show detach-on-fork<\/code><\/dt>\n
    Show whether detach-on-fork mode is on\/off.<\/dd>\n<\/dl>\n

    If you choose to set \u2018detach-on-fork<\/span><\/samp>\u2019 mode off, then gdb<\/span> will retain control of all forked processes (including nested forks). You can list the forked processes under the control of gdb<\/span> by using the info\u00a0inferiors<\/code> command, and switch from one fork to another by using the inferior<\/code> command (see Debugging Multiple Inferiors and Programs<\/a>).<\/p>\n

    To quit debugging one of the forked processes, you can either detach from it by using the detach\u00a0inferiors<\/code> command (allowing it to run independently), or kill it using the kill\u00a0inferiors<\/code> command. See Debugging Multiple Inferiors and Programs<\/a>.<\/p>\n

    If you ask to debug a child process and a vfork<\/code> is followed by an exec<\/code>, gdb<\/span> executes the new target up to the first breakpoint in the new target. If you have a breakpoint set on main<\/code> in your original program, the breakpoint will also be set on the child process’s main<\/code>.<\/p>\n

    On some systems, when a child process is spawned by vfork<\/code>, you cannot debug the child or parent until an exec<\/code> call completes.<\/p>\n

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

    \n
    set follow-exec-mode <\/code>mode<\/var><\/dt>\n
    Set debugger response to a program call of exec<\/code>. An exec<\/code> call replaces the program image of a process.follow-exec-mode<\/code> can be:<\/p>\n
    \n
    new<\/code><\/dt>\n
    gdb<\/span> creates a new inferior and rebinds the process to this new inferior. The program the process was running before the exec<\/code> call can be restarted afterwards by restarting the original inferior.For example:<\/p>\n
                   (gdb) info inferiors\r\n               (gdb) info inferior\r\n                 Id   Description   Executable\r\n               * 1    <null>        prog1\r\n               (gdb) run\r\n               process 12020 is executing new program: prog2\r\n               Program exited normally.\r\n               (gdb) info inferiors\r\n                 Id   Description   Executable\r\n                 1    <null>        prog1\r\n               * 2    <null>        prog2\r\n<\/pre>\n<\/dd>\n
    same<\/code><\/dt>\n
    gdb<\/span> 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<\/code> call, with e.g., the run<\/code> command, restarts the executable the process was running after the exec<\/code> call. This is the default mode.For example:<\/p>\n
                   (gdb) info inferiors\r\n                 Id   Description   Executable\r\n               * 1    <null>        prog1\r\n               (gdb) run\r\n               process 12020 is executing new program: prog2\r\n               Program exited normally.\r\n               (gdb) info inferiors\r\n                 Id   Description   Executable\r\n               * 1    <null>        prog2\r\n<\/pre>\n<\/dd>\n<\/dl>\n<\/dd>\n<\/dl>\n
    follow-exec-mode<\/code> is supported in native mode and target extended-remote<\/code> mode.<\/p>\n
    You can use the catch<\/code> command to make gdb<\/span> stop whenever a fork<\/code>, vfork<\/code>, or exec<\/code> call is made. See Setting Catchpoints<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
    Two\u00a0 Methods: Add sleep in the entry of  … \u7ee7\u7eed\u9605\u8bfb →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[342,343,341],"class_list":["post-255692","post","type-post","status-publish","format-standard","hentry","category-linux","tag-debug","tag-fork","tag-gdb"],"_links":{"self":[{"href":"https:\/\/blog.zhenglei.net\/index.php?rest_route=\/wp\/v2\/posts\/255692","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.zhenglei.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.zhenglei.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.zhenglei.net\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.zhenglei.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=255692"}],"version-history":[{"count":3,"href":"https:\/\/blog.zhenglei.net\/index.php?rest_route=\/wp\/v2\/posts\/255692\/revisions"}],"predecessor-version":[{"id":255695,"href":"https:\/\/blog.zhenglei.net\/index.php?rest_route=\/wp\/v2\/posts\/255692\/revisions\/255695"}],"wp:attachment":[{"href":"https:\/\/blog.zhenglei.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=255692"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.zhenglei.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=255692"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.zhenglei.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=255692"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}