From owner-freebsd-hackers Thu Jun 27 13:20:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA21569 for hackers-outgoing; Thu, 27 Jun 1996 13:20:57 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA21553 for ; Thu, 27 Jun 1996 13:20:52 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA05687; Thu, 27 Jun 1996 13:17:27 -0700 From: Terry Lambert Message-Id: <199606272017.NAA05687@phaeton.artisoft.com> Subject: Re: longstanding, woeful inadeqacy To: fhackers@jraynard.demon.co.uk (James Raynard) Date: Thu, 27 Jun 1996 13:17:27 -0700 (MST) Cc: alk@think.com, jkh@time.cdrom.com, hackers@freebsd.org In-Reply-To: <199606270949.JAA00671@jraynard.demon.co.uk> from "James Raynard" at Jun 27, 96 09:49:26 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > : Fork is an easier case since you don't need to swap the debugger's > > : executable out - just attach to the new process. > > > > Easier in what sense? It is essentially impossible to debug anything > > that forks, since by the time you can attach to it, it has gone > > veering wildly out of control. > > Not if you put a sleep loop in it:- > > int PauseMode = 1; > > if (fork()) /* parent */ > .... > else { /* child */ > while (PauseMode) > sleep(5); > ... > } > > and then set PauseMode to 0 when you attach. Or use vfork and implicitly follow the fork (vfork won't resume the parent process until the child exits or exec's... this would be more useful if one could tell which one had occurred without depending on the inherently unreliable SIGCHLD). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.