Quick close of all the open files.

Quick close of all the open files.

[vamsi krishna]

Hello,

I found that the following code is closing all the open files by the
program, do you think its a bug in kernel code?

------------
fp = tmpfile();
fp->_chain = stderr;
fpclose(fp);
fp = NULL;
------------

o Is there any other elegant way to close all the open files (rather
than reading from /proc/<pid>/fd and calling close on each of the fd?)

Looking forward to hear from you.

Thank you,
Vamsi.

Re: Quick close of all the open files.

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

On Wed, 07 Jun 2006 03:15:43 +0530, vamsi krishna said:
> Hello,
> 
> I found that the following code is closing all the open files by the
> program, do you think its a bug in kernel code?
> 
> ------------
> fp = tmpfile();
> fp->_chain = stderr;
> fpclose(fp);
> fp = NULL;

strace that, and see how many times close() gets called.  If it gets
called once, it's a kernel bug.  If it gets called once for each open
file, it's a userspace bug.

For bonus points, how did you verify that all the open files were closed?

(Hint - what does that fp->_chain = stderr *really* do? ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Quick close of all the open files.

[vamsi krishna]

> For bonus points, how did you verify that all the open files were closed?
>
I checked as follows I did printf("lowest fd = %d",fileno(tmpfile()));
it prints 3

> (Hint - what does that fp->_chain = stderr *really* do? ;)
>
>
>

Re: Quick close of all the open files.

[Måns Rullgård]

Valdis.Kletnieks@vt.edu writes:

> On Wed, 07 Jun 2006 03:15:43 +0530, vamsi krishna said:
>> Hello,
>> 
>> I found that the following code is closing all the open files by the
>> program, do you think its a bug in kernel code?
>> 
>> ------------
>> fp = tmpfile();
>> fp->_chain = stderr;
>> fpclose(fp);
>> fp = NULL;
>
> strace that, and see how many times close() gets called.  If it gets
> called once, it's a kernel bug.  If it gets called once for each open
> file, it's a userspace bug.

Actually, it's not a bug at all.

> For bonus points, how did you verify that all the open files were closed?
>
> (Hint - what does that fp->_chain = stderr *really* do? ;)

As it touches the innards of the FILE type, it invokes undefined
behavior.  Nothing that follows can be considered a bug.

-- 
Måns Rullgård
mru@inprovide.com

Re: Quick close of all the open files.

[Måns Rullgård]

"vamsi krishna" <vamsi.krishnak@gmail.com> writes:

>> For bonus points, how did you verify that all the open files were closed?
>>
> I checked as follows I did printf("lowest fd = %d",fileno(tmpfile()));
> it prints 3

That is proof that at least stdout is still open, or you would not see
the output.

-- 
Måns Rullgård
mru@inprovide.com

Re: Quick close of all the open files.

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]

On Wed, 07 Jun 2006 03:32:58 +0530, vamsi krishna said:
> > For bonus points, how did you verify that all the open files were closed?
> >
> I checked as follows I did printf("lowest fd = %d",fileno(tmpfile()));
> it prints 3

Which proves that file descriptor 3 was closed, so tmpfile() was able to
open it.  This certainly implies that fd 0, 1, 2 (connected to stdin,
stdout, and stderr streams of stdio) are still open, contrary to your
statement that *all* of them are closed.

If file descriptor 3 is closed, but 4 is open, what does tmpfile()
do? Hint - tmpfile() ends up invoking open(), and the manpage for that says:

       Given a pathname for a file, open() returns a file descriptor, a small,
       non-negative integer for  use  in  subsequent  system  calls  (read(2),
       write(2), lseek(2), fcntl(2), etc.).  The file descriptor returned by a
       successful call will be the lowest-numbered file  descriptor  not  cur-
       rently open for the process.

So.. explain why you think that "all files were closed"?  We know that 0..2
were open, and we know nothing about 4..1023.

This doesn't look like a kernel bug, you may want to continue the discussion
on one of the various "beginning Linux C programming" lists.

On Tue, 06 Jun 2006 23:03:38 BST, =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= said:
> > (Hint - what does that fp->_chain = stderr *really* do? ;)
> 
> As it touches the innards of the FILE type, it invokes undefined
> behavior.  Nothing that follows can be considered a bug.

Invoking undefined behavior is often considered a bug itself.  And it's
certainly happening in userspace.. so there's a userspace bug. ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Quick close of all the open files.

[vamsi krishna]

> > >
> > I checked as follows I did printf("lowest fd = %d",fileno(tmpfile()));
> > it prints 3
>
> Which proves that file descriptor 3 was closed, so tmpfile() was able to
> open it.  This certainly implies that fd 0, 1, 2 (connected to stdin,
> stdout, and stderr streams of stdio) are still open, contrary to your
> statement that *all* of them are closed.

I know 0,1,2 are open (I opened it) no need to tell it specifically,
HOW DO YOU THINK I CAN PRINT SOME THING WITHOUT OPENING THIS
FILES(stdout,stderr)?


>
> If file descriptor 3 is closed, but 4 is open, what does tmpfile()
> do? Hint - tmpfile() ends up invoking open(), and the manpage for that says:
>
>        Given a pathname for a file, open() returns a file descriptor, a small,
>        non-negative integer for  use  in  subsequent  system  calls  (read(2),
>        write(2), lseek(2), fcntl(2), etc.).  The file descriptor returned by a
>        successful call will be the lowest-numbered file  descriptor  not  cur-
>        rently open for the process.
>
> So.. explain why you think that "all files were closed"?  We know that 0..2
> were open, and we know nothing about 4..1023.
>
> This doesn't look like a kernel bug, you may want to continue the discussion
> on one of the various "beginning Linux C programming" lists.
>
> On Tue, 06 Jun 2006 23:03:38 BST, =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= said:
> > > (Hint - what does that fp->_chain = stderr *really* do? ;)
> >
> > As it touches the innards of the FILE type, it invokes undefined
> > behavior.  Nothing that follows can be considered a bug.
>
> Invoking undefined behavior is often considered a bug itself.  And it's
> certainly happening in userspace.. so there's a userspace bug. ;)
>
>
>

Re: Quick close of all the open files.

[Måns Rullgård]

Valdis.Kletnieks@vt.edu writes:

> On Tue, 06 Jun 2006 23:03:38 BST, =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= said:
>> > (Hint - what does that fp->_chain = stderr *really* do? ;)
>> 
>> As it touches the innards of the FILE type, it invokes undefined
>> behavior.  Nothing that follows can be considered a bug.
>
> Invoking undefined behavior is often considered a bug itself.  And it's
> certainly happening in userspace.. so there's a userspace bug. ;)

The bug is in the program that invoked the undefined behavior, not in
the library (libc) in which this behavior was invoked.

-- 
Måns Rullgård
mru@inprovide.com

Re: Quick close of all the open files.

[Måns Rullgård]

"vamsi krishna" <vamsi.krishnak@gmail.com> writes:

>> > >
>> > I checked as follows I did printf("lowest fd = %d",fileno(tmpfile()));
>> > it prints 3
>>
>> Which proves that file descriptor 3 was closed, so tmpfile() was able to
>> open it.  This certainly implies that fd 0, 1, 2 (connected to stdin,
>> stdout, and stderr streams of stdio) are still open, contrary to your
>> statement that *all* of them are closed.
>
> I know 0,1,2 are open (I opened it) no need to tell it specifically,
> HOW DO YOU THINK I CAN PRINT SOME THING WITHOUT OPENING THIS
> FILES(stdout,stderr)?

That still says nothing about file descriptors 4 and up.

-- 
Måns Rullgård
mru@inprovide.com

Re: Quick close of all the open files.

[Bernd Petrovitsch]

On Wed, 2006-06-07 at 06:52 +0530, vamsi krishna wrote:
[...]
> > > I checked as follows I did printf("lowest fd = %d",fileno(tmpfile()));
> > > it prints 3
>
> > Which proves that file descriptor 3 was closed, so tmpfile() was able to
> > open it.  This certainly implies that fd 0, 1, 2 (connected to stdin,
> > stdout, and stderr streams of stdio) are still open, contrary to your
> > statement that *all* of them are closed.

And it specifically says absolutely nothing about the file descriptors 4
and larger since open(2) always uses the lowest unused file descriptor.

> I know 0,1,2 are open (I opened it) no need to tell it specifically,
> HOW DO YOU THINK I CAN PRINT SOME THING WITHOUT OPENING THIS
> FILES(stdout,stderr)?

No reason to shout: The trivial solution is to syslog(3) the output like
all of the daemons out there do since ages.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: Quick close of all the open files.

[linux-os (Dick Johnson)]

On Tue, 6 Jun 2006, vamsi krishna wrote:

> Hello,
>
> I found that the following code is closing all the open files by the
> program, do you think its a bug in kernel code?
>
> ------------
> fp = tmpfile();
> fp->_chain = stderr;
> fpclose(fp);
> fp = NULL;
> ------------
>
> o Is there any other elegant way to close all the open files (rather
> than reading from /proc/<pid>/fd and calling close on each of the fd?)
>
> Looking forward to hear from you.
>
> Thank you,
> Vamsi.
> -

tmpfile() returns a pointer to the FILE type. FILE is an opaque
type, meaning you have no business accessing any of its contents.
In fact, there are no user accessible headers from which you
could properly determine the contents of this type. Your program
should not even know that it is a structure. In fact, it could
be a pointer to a linked list.

Anything you think you are seeing, any behavior you think exists,
is invalidated once you access any members of this structure.

If you want to close all open buffered files (streams), you use
fcloseall().

Also, the FILE type and any buffering is performed by the 'C'
runtime library. The kernel only does open/read/write/close,
the underlying primitives. If you find anything wrong with
FILE operations, you should contact the people who provided
your 'C' runtime library, not the Linux kernel group.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.88 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.