From owner-freebsd-hackers Thu Sep 9 13:49:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from luna.lyris.net (luna.shelby.com [207.90.155.6]) by hub.freebsd.org (Postfix) with ESMTP id ED59D1514D for ; Thu, 9 Sep 1999 13:49:36 -0700 (PDT) (envelope-from kip@lyris.com) Received: from luna.shelby.com by luna.lyris.net (8.9.1b+Sun/SMI-SVR4) id NAA11631; Thu, 9 Sep 1999 13:48:44 -0700 (PDT) Received: from (luna.shelby.com [207.90.155.6]) by luna.shelby.com with SMTP (MailShield v1.50); Thu, 09 Sep 1999 13:48:44 -0700 Date: Thu, 9 Sep 1999 13:48:44 -0700 (PDT) From: Kip Macy X-Sender: kip@luna To: Zhihui Zhang Cc: freebsd-hackers@freebsd.org Subject: Re: How to follow child process in gdb In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: luna X-SMTP-MAIL-FROM: kip@lyris.com X-SMTP-RCPT-TO: zzhang@cs.binghamton.edu,freebsd-hackers@freebsd.org X-SMTP-PEER-INFO: luna.shelby.com [207.90.155.6] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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