Hello folks,
Once again, the list has come through. You'll recall, I was having problems
with the Perl5.0 POSIX verfication tests, and had concluded that the
pipe(2) system call was leaking fds somehow.
Well, I was wrong, it's the shells that are leaking the FDs. You normally
expect that when you are sitting at a shell prompt, you have only fd 0, 1 and
2 open, but this may not be the case if the shell did not close all open
FDs at startup.
ft@maxwell.ccs.att.com (Frederick True) was the first to peg it. Here's his
response:
======
Ted, I have recently seen this problem break some of our internal software's
regression tests as they relate to expected file descriptors. We've found
that the Bourne and Korn shells under Solaris 2.3 do not force the closing
of file descriptors >2 when the start up (as csh and other shells apparently
do), and as a consequence, stray file descriptors opened by such things as
xterms and rlogins persist in a shell environment, and thus in any programs
you run under that environment.
Try something simple like:
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
main()
{
int i;
struct stat st;
for(i = 0; i < 20; ++i)
if(fstat(i,&st) >= 0)
printf("%d is opened\n",i);
}
Theoretically, you should only see descriptors 0,1,2 open (for stdin,
stdout, stderr). Run it under different shells (ksh, sh, csh) and via an
rlogin session versus on a console or directly attached terminal. I think
you'll find the results change a bit.
Not really a bug, but not what you'd think either.
========
Thanks also to:
"Tom Mornini" <tmornini@infomania.com>
pod@morgan.com (Paul O'Donnell)
and a couple of others that I somehow managed to loose track of..
Also, advance apologies for a note that will be appearing soon that was
meant to be a direct reply to someone, but on which I forgot to remove
the list CC
Ted Nolan
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:15 CDT