Re: [ python-Bugs-1048808 ] test_subprocess 2.4b1 fails on FreeBSD 5.2
Comments? Is it safe or not to assume that by the time the Python has started, only fds 0,1,2 are open? /Peter
I think this is the core of the problem. The test_close_fds test works like this:
All file descriptors in the forked child (except 0,1,2) are closed. Then the Python binary is executed via execvp(). A small test program is passed to the Python binary via the -c command line option. If the OS and subprocess module works correctly, we can be sure of that by the time of the execve() system call, only file descriptors (0,1,2) are open (well, the errpipe as well, but let's leave that out for now). But, by the time the Python binary starts executing the small program, all sorts of things may have happened. I'm not really sure we can trust Python not to open files during startup. For example, if we have a PYTHONSTARTUP file, that open file will have a file descriptor, perhaps 3.
On one hand, this bug could indicate a bug in the Python interpreter itself: perhaps a file descriptor leak. On the other hand, this test might be a bit too unsafe.
So probably, this test should be removed.
Hi, I would say it is not safe: f=file("hello") from os import fork, execl if fork()!=0: execl("python", "python" ) This leaves fd=3 open on linux On Wed, Oct 20, 2004 at 03:10:28PM +0200, Peter Astrand wrote:
Comments? Is it safe or not to assume that by the time the Python has started, only fds 0,1,2 are open?
/Peter
I think this is the core of the problem. The test_close_fds test works like this:
All file descriptors in the forked child (except 0,1,2) are closed. Then the Python binary is executed via execvp(). A small test program is passed to the Python binary via the -c command line option. If the OS and subprocess module works correctly, we can be sure of that by the time of the execve() system call, only file descriptors (0,1,2) are open (well, the errpipe as well, but let's leave that out for now). But, by the time the Python binary starts executing the small program, all sorts of things may have happened. I'm not really sure we can trust Python not to open files during startup. For example, if we have a PYTHONSTARTUP file, that open file will have a file descriptor, perhaps 3.
On one hand, this bug could indicate a bug in the Python interpreter itself: perhaps a file descriptor leak. On the other hand, this test might be a bit too unsafe.
So probably, this test should be removed.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ludal%40logilab.fr
-- Ludovic Aubry LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org
On Wed, 20 Oct 2004, Ludovic Aubry wrote:
I would say it is not safe:
f=file("hello") from os import fork, execl
if fork()!=0: execl("python", "python" )
This leaves fd=3 open on linux
Yes, but with the subprocess module and close_fds=True, subprocess explicitly closes all fds except 0,1,2, between fork and exec. I'm talking about the problem with the Python interpreter opening *new* files during startup. /Peter Åstrand <astrand@lysator.liu.se>
On Wed, Oct 20, 2004 at 05:07:59PM +0200, Ludovic Aubry wrote:
Hi,
I would say it is not safe:
.. or in this example: $ python -c 'import os; os.write(4, "the text\n")' 4>the_file $ cat the_file the text If Python changed to break this behavior, it would be a tragedy. Jeff
I'm missing some context here, but the opening of STARTUP and other examples is irrelevant, as long as that code properly closes its fds. Of course, you can't trust shells not to have other fds open for internal purposes; that's a feature of fd inheritance. On Wed, 20 Oct 2004 15:10:28 +0200 (MEST), Peter Astrand <astrand@lysator.liu.se> wrote:
Comments? Is it safe or not to assume that by the time the Python has started, only fds 0,1,2 are open?
/Peter
I think this is the core of the problem. The test_close_fds test works like this:
All file descriptors in the forked child (except 0,1,2) are closed. Then the Python binary is executed via execvp(). A small test program is passed to the Python binary via the -c command line option. If the OS and subprocess module works correctly, we can be sure of that by the time of the execve() system call, only file descriptors (0,1,2) are open (well, the errpipe as well, but let's leave that out for now). But, by the time the Python binary starts executing the small program, all sorts of things may have happened. I'm not really sure we can trust Python not to open files during startup. For example, if we have a PYTHONSTARTUP file, that open file will have a file descriptor, perhaps 3.
On one hand, this bug could indicate a bug in the Python interpreter itself: perhaps a file descriptor leak. On the other hand, this test might be a bit too unsafe.
So probably, this test should be removed.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (4)
-
Guido van Rossum -
Jeff Epler -
Ludovic Aubry -
Peter Astrand