[Python-bugs-list] [ python-Bugs-803610 ] os.close(3) raises OSError: [Errno 9] Bad file descriptor

[SourceForge.net]

Bugs item #803610, was opened at 2003-09-10 08:18
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=803610&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Syrah (syrah)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.close(3) raises OSError: [Errno 9] Bad file descriptor

Initial Comment:
os.close(3) raises OSError: Bad file descriptor on

FreeBSD 5.1, with both Python 2.2.2(_2) and 2.3(_1). 

Python 2.3 on Gentoo Linux 1.4 is not affected.



Interestingly, if you call os.fstat(3) first, a

subsequent call to os.close(3) succeeds.



And yes, you do need to set up fd #3.



Here is a demonstration (on FreeBSD):



[syrah at ripple filter]$ cat test.py

import os

os.close (3)



[syrah at ripple filter]$ python test.py 3> file

Traceback (most recent call last):

  File "test.py", line 2, in ?

    os.close (3)

OSError: [Errno 9] Bad file descriptor



[syrah at ripple filter]$ cat test2.py

import os

os.fstat (3)

os.close (3)



[syrah at ripple filter]$ python test2.py 3> file



[syrah at ripple filter]$   (success!)



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-09-10 22:19

Message:
Logged In: YES 
user_id=21627

os.close directly calls the operating system call close(2),

and reports an error if and only if the operating system

reports an error. So there is absolutely zero possibility

that the operatin system lets close(2) succeeed, yet python

returns OSError(9). As a consequence, if python raises

OSError(9), it was the operating system that has returned an

error before.



If you doubt this statement, please use ktrace/strace to

diagnose this further.



Also, if you *know* that a parent process has set up fd 3,

your test case is irrelevant. Your test case is only

meaningful in a context where a parent process has set up fd

3, however, you have not reported the code of that parent

process. Providing a minimal test case would be appreciated.

----------------------------------------------------------------------

Comment By: Syrah (syrah)
Date: 2003-09-10 19:33

Message:
Logged In: YES 
user_id=827529

I'm writing a mail filter for the courier mail server.



Before courier forks the filter, courier sets up fd 3 to

communicate with the filter.  When the filter has finished

initialization and is ready for work, the filter is supposed

to close fd 3.  Courier detects the closure of fd 3 and

knows that the filter is ready to work.



In general, before a call to fork/exec, the parent process

can set up any number of file descriptors for the child to

inherit.  If you are writing such a child in C, it is easy

to use these "extra" file descriptors.  It would nice to be

able to write in Python instead.



Saying that "3 *is* a bad file descriptor" assumes that

every program will be run from the command line, and the the

command line will only set up fd's 0, 1 and 2.  This is not

the case.  In fact it is very easy to set up other file

descriptors on the command line using bash.  See my example

above.



Another example of using more than 0, 1 and 2.  The openssl

program can use arbitrary file descriptors (referenced by

number on the command line) to recieve passwords.  This

allows you to cleanly pass in multiple passwords in a

reasonably secure manner.  (Arguably more secure than

writing the passwords to a file, and definitely more secure

that specifying them on the command line.)



The problem manifest on FreeBSD.  3 is not always a bad fd

on FreeBSD.  I've got a C program that has no problem

closing fd 3 (when fd 3 is properly set up).



Moreover, as I pointed out above, if I call os.fstat (3)

first, then I can os.close (3) without problem.  If 3 was a

bad fd, the call to os.fstat (3) should generate an error. 

It does not.



Please let me know if you have further questions.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-09-10 18:57

Message:
Logged In: YES 
user_id=21627

Why is this a bug? 3 *is* a bad file descriptor, on the

systems which report it to be a bad file descriptor.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=803610&group_id=5470