Repository navigation
subprocess leaves open fds on construction error #49429
Description
| BPO | 5179 |
|---|---|
| Nosy | @birkenfeld, @pitrou |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2009-03-03.22:56:40.218>
created_at = <Date 2009-02-07.20:04:37.082>
labels = ['library']
title = 'subprocess leaves open fds on construction error'
updated_at = <Date 2009-03-03.22:56:40.199>
user = 'https://github.com/birkenfeld'bugs.python.org fields:
activity = <Date 2009-03-03.22:56:40.199>
actor = 'ocean-city'
assignee = 'none'
closed = True
closed_date = <Date 2009-03-03.22:56:40.218>
closer = 'ocean-city'
components = ['Library (Lib)']
creation = <Date 2009-02-07.20:04:37.082>
creator = 'georg.brandl'
dependencies = []
files = ['12972', '13236']
hgrepos = []
issue_num = 5179
keywords = ['patch']
message_count = 12.0
messages = ['81347', '81348', '81387', '82001', '82028', '82082', '82083', '82084', '82092', '83097', '83099', '83108']
nosy_count = 3.0
nosy_names = ['georg.brandl', 'pitrou', 'ocean-city']
pr_nums = []
priority = 'high'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue5179'
versions = ['Python 2.6', 'Python 3.0', 'Python 3.1', 'Python 2.7']
Activity
birkenfeld commentedon Feb 7, 2009
The test case below will (on Linux here) eventually quit with "OSError:
[Errno 24] Too many open files". I assume that some additional cleaning
up is in order.
-------------------------------------------------------------------
birkenfeld commentedon Feb 7, 2009
Proposed patch attached.
pitrou commentedon Feb 8, 2009
Perhaps you could add a test?
birkenfeld commentedon Feb 14, 2009
I would, but how this fails is likely to be highly platform-specific.
Can you try it on Windows and tell me what the resulting exception is?
pitrou commentedon Feb 14, 2009
Well, I'm not under Windows. I'll try to launch a VM if nobody beats me
to it...
birkenfeld commentedon Feb 14, 2009
On second thought, if the patch is applied, there *shouldn't* be an
exception. And simply running the loop for a fixed number of
repetitions isn't a good test either, since different platforms may have
a different maximum for open file descriptors.
Hmm, is there a way to get the current number of open file descriptors?
pitrou commentedon Feb 14, 2009
Under Unix, you can use resource.getrlimit():
(1024, 1024)
But 1024 is a very common value, so you could simply loop 1024 times if
it's not too slow.
Besides, you definitely don't want to loop 2**31 times if 2**31 happens
to be the current limit.
pitrou commentedon Feb 14, 2009
Wow, the Roundup email gateway borks code snippets:
birkenfeld commentedon Feb 14, 2009
OK, Windows has 2048. Added test and fixed in r69620.
ocean-city commentedon Mar 3, 2009
This issue is not fixed on windows yet. (test_leaking_fds_on_error fails)
I think attached patch will fix this.
======================================================================
ERROR: test_writes_before_communicate (main.ProcessTestCase)
----------------------------------------------------------------------
birkenfeld commentedon Mar 3, 2009
Since I can't test on Windows, I'll leave that in your hands :)
ocean-city commentedon Mar 3, 2009
Thanks, fixed in r70137(trunk), r70142(py3k), r70146(release30-maint),
r70147(release26-maint)