Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rtech.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!nsc!amdahl!rtech!daveb
From: daveb@rtech.UUCP (Dave Brower)
Newsgroups: net.unix-wizards
Subject: ptrace child after fork?
Message-ID: <755@rtech.UUCP>
Date: Tue, 19-Nov-85 23:55:33 EST
Article-I.D.: rtech.755
Posted: Tue Nov 19 23:55:33 1985
Date-Received: Thu, 21-Nov-85 04:00:26 EST
Distribution: net
Organization: Relational Technology, Alameda CA
Lines: 23

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.

Interestingly, the SV.2 Vax code does NOT do this; nor does the SV.2
available on the 3b's -- sdb works fine.

Because of the 'official' interpretion, alledgedly supported by the AT&T
certification/verification test, the manufacturer is reluctant to remove
this wart.  ("It's not a bug, it's specified that way").

So, the question is, should fork propagate ptrace?  Is this something
that is being 'fixed' in the SV.3 ID?  And why doesn't Mr Reagun DO
something about it?

Thanks.
-dB
-- 
{amdahl|dual|sun|zehntel}\		|
{ucbvax|decvax}!mtxinu---->!rtech!daveb | "Something can always go wrong"
ihnp4!{phoenix|amdahl}___/		|