Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site x.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!cybvax0!frog!x!rfm
From: rfm@x.UUCP (Bob Mabee)
Newsgroups: net.unix-wizards
Subject: Re: ptrace child after fork?
Message-ID: <853@x.UUCP>
Date: Fri, 22-Nov-85 21:15:26 EST
Article-I.D.: x.853
Posted: Fri Nov 22 21:15:26 1985
Date-Received: Sun, 24-Nov-85 07:20:13 EST
References: <755@rtech.UUCP>
Reply-To: rfm@x.UUCP (PUT YOUR NAME HERE)
Distribution: net
Organization: Charles River Data Systems, Framingham MA
Lines: 23
Summary: 

In article <755@rtech.UUCP> daveb@rtech.UUCP (Dave Brower) writes:
>One of the SV machines I am now working with has implemented what they
>have been told is the "correct" behavior of fork() as per the SVID. When
>the fork creates the child, the ptrace status of the parent is passed on
>to the child.  This completely breaks the only debugger (sdb) on
>multiple-process programs, as the child just sits there, ptraced.

This is desirable behavior as it allows you to debug any of the processes
spawned by the one you start with.  UNOS has this feature/bug too.
With CRDS's debugger I use a shell escape to start up another debugger,
telling it to work on the particular child process (can sdb do that?).
We also have a command which makes a suspended process run again
("resume PID &" if you don't want the shell to wait for it).
I need another terminal or a windowing package to debug both processes at
once.

You should not let the parent fork with any breakpoints in place as they
will get duplicated in the child, but the debugger won't know to remove them.
You should put a breakpoint on fork and exec* and single-step through the
system call.
-- 
				Bob Mabee @ Charles River Data Systems
				decvax!frog!rfm