From owner-freebsd-stable  Wed Apr  8 04:06:24 1998
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id EAA11555
          for freebsd-stable-outgoing; Wed, 8 Apr 1998 04:06:24 -0700 (PDT)
          (envelope-from owner-freebsd-stable@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA11529;
          Wed, 8 Apr 1998 04:06:02 -0700 (PDT)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id VAA18316;
	Wed, 8 Apr 1998 21:01:27 +1000
Date: Wed, 8 Apr 1998 21:01:27 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199804081101.VAA18316@godzilla.zeta.org.au>
To: eirvine@tpgi.com.au, freebsd-stable@FreeBSD.ORG
Subject: Re: A new Bug with FreeBSD?
Cc: ache@FreeBSD.ORG
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk

>I'm running FreeBSD 2.2 Stable and am wondering
>if this is a bug I should report. Perhaps someone
>would like to try and duplicate it?
>
>You will need "elm" and the editor "ee" on
>your system, as well as a telnet client on a
>PC or a Mac.

A standard FreeBSD setup on one system suffices, at least in -current.

>Telnet to FBSD as an ordinary user.

Or telnet to localhost.

>Set up "ee" as your default editor in .profile

Or set it on the command line.

>enter elm, and start to edit a new mail message.
>Your screen editor should be "ee".

Or use /usr/bin/mail...

>Do not leave the editor in the normal way.
>Instead, just rudely quit the telnet session.
>(eg: File->Quit).
>
>Go to the console and run "top".
>
>top should show the "ee" process still active,
>using up 95% of CPU time. Now go to your
>ethernet hub. It should show a whole heap
>of activity - much more than normal.

This is a special case of an old problem.  Here it is caused by
a bug in libncurses:

---
static inline int fifo_push()
{
int n;
unsigned char ch;

	if (tail == -1) return ERR;
again:
	n = read(fileno(SP->_ifp), &ch, 1);
	if (n == -1 && errno == EINTR)
		goto again;
	T(("read %d characters", n));
	SP->_fifo[tail] = ch;
	if (head == -1) head = tail;
	t_inc();
	T(("pushed %d at %d", ch, tail));
	fifo_dump();
	return ch;
}
---

This is inlined in wgetch().  It returns a garbage value for both types
of EOF (n == 0, and n == -1 && errno != EINTR).

>I presume this shouldn't happen on a Unix system -
>all processes should be children of the logged in
>user, and thus should get KILL'ed when the user
>exits, no matter how they exit.

Not in POSIX.1-1990.  Killing is associated with exit() of controlling
processes (telnet in this case).  SIGHUP is sent to each process in the
_foreground_ process group of the controlling terminal of the controlling
process, and if exit of the controlling process causes a process group
to become orphaned and any member in the newly orphaned process group is
stopped, than a SIGHUP followed by a SIGCONT is sent to every process in
the newly orphaned process group here.  I'm not sure of the details here,
but this normally results in propagation of SIGHUP being limited to one
or two levels of the process tree - shells propagate it, but mail programs
don't.  Death of the controlling terminal results in reads on the c.t.
returning -1/EIO (the more usual 0 is not returned due to a kernel bug),
and interactive processes should exit when they read -1 or 0 on stdin
or /dev/tty.  libncurses has perfectly broken handling of both types of
EOF, so programs that use it usually spin when the controlling terminal
goes away.

Bruce

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message