From owner-freebsd-hackers  Fri Apr 26 09:03:43 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id JAA16070
          for hackers-outgoing; Fri, 26 Apr 1996 09:03:43 -0700 (PDT)
Received: from kithrup.com (kithrup.com [205.179.156.40])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA16063
          for <hackers@freebsd.org>; Fri, 26 Apr 1996 09:03:41 -0700 (PDT)
Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id JAA13098; Fri, 26 Apr 1996 09:03:40 -0700
Date: Fri, 26 Apr 1996 09:03:40 -0700
From: Sean Eric Fagan <sef@kithrup.com>
Message-Id: <199604261603.JAA13098@kithrup.com>
To: jkh@time.cdrom.com
Subject: Re: Something fishy with our PT_ATTACH code!
Cc: hackers@freebsd.org
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>Just got back from Kirk's usual Thursday-night OS class and while we
>were going through exit1(), I noticed something that looked a little
>odd in the ptrace "reattach" code.  In following it (and it later
>turned out to be correct), I happened to notice the following weird
>behavior with attach and detach:

Well, I didn't write the attach/detach code ;).

>This is probably a bit hard to read, so I'll give you
>a synopsis:  Start cat, attach cat from another tty with
>gdb, watch cat go to sleep, detach cat in gdb and watch
>cat erroneously suspend itself.

It doesn't seem that the detached process is suspending itself so much as it
is simply renotifying the parent that it is still stopped.  This could be
wrong behaviour, however.

To change that, in the PT_DETACH code, a

	psignal(p, SIGCONT);

would do the trick.  I think ;).

Sean.