Date: Thu, 9 Sep 1999 13:48:44 -0700 (PDT) From: Kip Macy <kip@lyris.com> To: Zhihui Zhang <zzhang@cs.binghamton.edu> Cc: freebsd-hackers@freebsd.org Subject: Re: How to follow child process in gdb Message-ID: <Pine.SOL.4.05.9909091347490.11496-100000@luna> In-Reply-To: <Pine.GSO.3.96.990908200701.23944A-100000@sol.cs.binghamton.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
This appears to be an oversight on the developers of gdb's part, but direct from the info page: 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 *Note Attach::). From that point on you can debug the child process just like any other process which you attached to. On Wed, 8 Sep 1999, Zhihui Zhang wrote: > On Wed, 8 Sep 1999, Kip Macy wrote: > > > You need to detach from your current process and attach to the spawned > > process. It might make it easier to attach in a timely fashion if you put > > a 3 second sleep in right after the fork. This would all be easiest using > > something like DDD where DDD will tell you what other processes are > > running with the same name, and allow you to attach to them through the > > GUI. > > In dbx on a Sun workstation, all I need to do to follow a child process > after fork() is to use the following command in advance: > > (dbx)dbxenv follow_fork_mode child > > Your response suggests that I can not achieve the same result simply by > using (I am using gdb 4.18): > > (gdb)set follow-fork-mode child > > I have to use attach and dettach to do so. Does that mean I have to > display the pid of the new process in order to follow it. And I have to > modify the child process so that it can wait until I can attach to it. > That will not be as easy. > > -Zhihui > > > > > > > > > > On Wed, 8 Sep 1999, Zhihui Zhang wrote: > > > > > > > > I am using gdb 4.18 on FreeBSD-current. The program being debugged > > > consists of two small files: test1.c and test2.c. The main() in test1.c > > > has a call to fork() and for the child process case, it will call a > > > routine, say test(), in test2.c. > > > > > > I use "set follow-fork-mode child", "break fork", "step" command trying to > > > access the source in test2.c without success. The program is compiled > > > with "cc -g test1.c test2.c" and I run gdb with "gdb a.out". > > > > > > If there is no fork(), a call from test1.c to a routine in test2.c will > > > bring up the source of test2.c if I step that routine. Why it does not > > > work with fork()? Am I missing something? > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SOL.4.05.9909091347490.11496-100000>