daveb@rtech.UUCP (Dave Brower) (11/20/85)
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}___/ |stephen@dcl-cs.UUCP (Stephen J. Muir) (11/23/85)
In article <755@rtech.UUCP> daveb@rtech.UUCP (Dave Brower) writes: >So, the question is, should fork propagate ptrace? I should say not. How often is the process you're debugging another debugger? Even if it was, it would get its child to do its own ptrace. Suppose you wish to debug a process that forks other processes. Now, the process being debugged will do a wait(2). If its child has stopped as a result of the ptrace, then the "wait" will return something unexpected and the process being debugged will get confused. Think about it. -- UUCP: ...!seismo!mcvax!ukc!dcl-cs!stephen DARPA: stephen%comp.lancs.ac.uk@ucl-cs | Post: University of Lancaster, JANET: stephen@uk.ac.lancs.comp | Department of Computing, Phone: +44 524 65201 Ext. 4599 | Bailrigg, Lancaster, UK. Project:Alvey ECLIPSE Distribution | LA1 4YR
rfm@x.UUCP (Bob Mabee) (11/23/85)
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
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (11/25/85)
My copy of the SVID does not say that the trace bit is inherited across a fork. The reported behavior is wrong, or at least a change in traditional UNIX ptrace semantics. Ptrace is all wrong anyhow and should be replaced with the 8th Edition UNIX mechanisms (/dev/proc etc.).
geoff@ISM780B.UUCP (11/27/85)
> My copy of the SVID does not say that the trace bit is > inherited across a fork. The reported behavior is > wrong, or at least a change in traditional UNIX ptrace > semantics. My SVID describes this in appendix 3.0 (K_EXT), under "Effect on BASE ..." I can't say I think it's a good idea, but that IS what the SVID says (sigh). > Ptrace is all wrong anyhow and should be replaced > with the 8th Edition UNIX mechanisms (/dev/proc etc.). Won't argue with that, 'tho I'm not familiar with it.
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (11/29/85)
> My SVID describes this in appendix 3.0 (K_EXT), under "Effect on BASE ..." > I can't say I think it's a good idea, but that IS what the SVID says (sigh). Gaak, you're right. The SVR2 fork(2) and exec(2) manual pages say the same thing. What a lossage.