File descriptor 5 is held open

[Lloyd Parkes]

Configuration Information [Automatically generated, do not change]:
Machine: alpha
OS: OSF1
Compiler: cc -migrate
Compilation CFLAGS: -DHAVE_SETLINEBUF -DHAVE_VFPRINTF -DHAVE_UNISTD_H -DHAVE_STDLIB_H -DHAVE_LIMITS_H -DHAVE_GETGROUPS -DHAVE_RESOURCE -DHAVE_SYS_PARAM -DVOID_SIGHANDLER -DNLS -D_BSD -DHAVE_WAIT_H -DHAVE_GETWD -DHAVE_DUP2 -DHAVE_STRERROR -DHAVE_DIRENT_H -DHAVE_STRING_H -DHAVE_VARARGS_H -DHAVE_STRCHR -Dalpha -DOSF1 -DSHELL -DHAVE_ALLOCA_H -O4
uname output: OSF1 pukatea.its.vuw.ac.nz V3.2 148 alpha

Bash Version: 1.14
Patch Level: 5

Description:
When bash execs another program, the new program inherits an
open file descriptor. File descriptor #5 to be precise. This file
descriptor is open for reading and under various circumstances the new
program will block waiting for input on that descriptor. I have seen
this before on other platforms, but now is is becoming a pain in the
neck, rather than just a bash foible.

Repeat-By:
Take a minimal program e.g.

main ()
{
sleep (3000);
}

Compile it and run it under gdb. I use GDB 4.14
(alpha-dec-osf3.0). Before the sleep terminates, interrupt the
program. The gdb prompt will appear. Type the quit command. Gdb will
ask you if you are sure because the program is still running. Type 'y'
and then press enter. Gdb now hangs. You can interrupt gdb and it will
terminate.

You can now use ps to look for the process that was being
debugged. You should find that it is blocked waiting for tty
input. e.g.

PID TTY S TIME COMMAND
19779 ttyp3 T 0:00.11 /u/its/lloyd/tmp/a.out

I have seen similar behaviour from rsh when used the the X11R5/R6
program xon. I have seen this sort of behaviour on NetBSD/i386,
NetBSD/sparc, SunOS 4, and Irix (these are all from memory though).

[Chet Ramey]

> Description:
> When bash execs another program, the new program inherits an
> open file descriptor. File descriptor #5 to be precise. This file
> descriptor is open for reading and under various circumstances the new
> program will block waiting for input on that descriptor. I have seen
> this before on other platforms, but now is is becoming a pain in the
> neck, rather than just a bash foible.

This sounds like the old BSD rshd bug. A description from several years
ago is appended.

You can use a program that prints out information about open file descriptors
using fstat, run that from bash so it inherits the open fd, and try to
track down what kind of fd is is from that (socket, file, etc.). It's
possible that it's a file descriptor left open by the YP library functions.

Message describing the bug:

This is a bug alright, but it's a bug with rshd that's not fixed until
4.3-reno.

rshd sets up a pipe (int pv[2]; if you have the source to the tahoe rshd)
to the process it executes and uses it to manage error and control output
from over the net. In the child process, it does a dup2(pv[1], 2), but
never calls close(pv[1]). Adding that code to the 4.3-tahoe rshd makes it
(and the Xemacs script) work right.

I don't know how to solve this cleanly in bash. Doing a blanket close of
all open file descriptors < 2, < 20 is a no-no, especially when we're not
interactive. csh `works' because it does the blanket close on startup, but
csh can get away with doing that because it doesn't let you manipulate
arbitrary file descriptors.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, Case Western Reserve University Internet: ch...@po.CWRU.Edu

[Lloyd Parkes]

Hi Chet,
another bash user and I hacked on the problem yesterday, and this is what we
found out.

The problem is the same one as the old rshd bug, but it isn't in rshd. I have
suffered under the rshd bug which make me think this problem was more wide
spread than it really is. I did test this under a number of environments, so I
was fairly sure the descriptor wasn't being inherited by bash.

It turns out the gdb seems to be doing the same sort of thing that rshd used
to do. Because the behaviour of the two problems is identical I thought they
were the same problem. I don't quite know why this problem doesn't manifest
itself when gdb is is run from (a clean) tcsh, but I think it has to do with
the SHELL environment variable.

I intend to rebuild the latest bash and gdb for the machine in question, and
then see what happens.

Cheers,
Lloyd

[Lloyd Parkes]

I have upgraded all my alphas to the latest rev. of gdb and bash. While the
software fault still exists, there is no longer a software failure. i.e.
various programs still forget to close fds, but I don't get any hanging
processes anymore.

There is no problem with bash. While csh, tcsh and possbly gdb and sh seem to
be untidy with their file descriptors, the hacking that Andrew has done shows
that bash itself is quite well behaved. I suppose I ought to have a look at
gdb now...

Cheers,
Lloyd

[mishura...@gmail.com]

On Saturday, January 6, 1996 at 2:00:00 PM UTC+6, Lloyd Parkes wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: alpha
> OS: OSF1
> Compiler: cc -migrate
> Compilation CFLAGS: -DHAVE_SETLINEBUF -DHAVE_VFPRINTF -DHAVE_UNISTD_H -DHAVE_STDLIB_H -DHAVE_LIMITS_H -DHAVE_GETGROUPS -DHAVE_RESOURCE -DHAVE_SYS_PARAM -DVOID_SIGHANDLER -DNLS -D_BSD -DHAVE_WAIT_H -DHAVE_GETWD -DHAVE_DUP2 -DHAVE_STRERROR -DHAVE_DIRENT_H -DHAVE_STRING_H -DHAVE_VARARGS_H -DHAVE_STRCHR -Dalpha -DOSF1 -DSHELL -DHAVE_ALLOCA_H -O4
> uname output: OSF1 pukatea.its.vuw.ac.nz V3.2 148 alpha
>
> Bash Version: 1.14
> Patch Level: 5
>

> Description:
> When bash execs another program, the new program inherits an
> open file descriptor. File descriptor #5 to be precise. This file
> descriptor is open for reading and under various circumstances the new
> program will block waiting for input on that descriptor. I have seen
> this before on other platforms, but now is is becoming a pain in the
> neck, rather than just a bash foible.
>