popen2 on Windows does not check _fdopen return value

[frankty]

BPO	886488
Nosy	@terryjreedy, @tiran
Files	bug.zip: zip with test case and hacks

^{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 2013-03-25.20:51:34.818>
created_at = <Date 2004-01-28.20:28:33.000>
labels = ['interpreter-core', 'easy', 'OS-windows', 'type-crash']
title = 'popen2 on Windows does not check _fdopen return value'
updated_at = <Date 2013-03-25.20:51:34.816>
user = 'https://bugs.python.org/frankty'

bugs.python.org fields:

activity = <Date 2013-03-25.20:51:34.816>
actor = 'terry.reedy'
assignee = 'none'
closed = True
closed_date = <Date 2013-03-25.20:51:34.818>
closer = 'terry.reedy'
components = ['Interpreter Core', 'Windows']
creation = <Date 2004-01-28.20:28:33.000>
creator = 'frankty'
dependencies = []
files = ['1190']
hgrepos = []
issue_num = 886488
keywords = ['easy']
message_count = 7.0
messages = ['19840', '19841', '59205', '60178', '114313', '182508', '185232']
nosy_count = 6.0
nosy_names = ['terry.reedy', 'frankty', 'rupole', 'christian.heimes', 'BreamoreBoy', 'Ramchandra Apte']
pr_nums = []
priority = 'high'
resolution = 'wont fix'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue886488'
versions = ['Python 2.6', 'Python 2.7']

[frankty]

WinPython 2.3.3 crashes when using popen2 to spawn
*lots* of children > 100.

Running the test case on either W2k or Wxp causes
Python 2.3.3 to crash. Looking at the drwatson file,
it appears to be a race condition where the child is in
the process of crashing, while the popen2 code in
posixmodule.c is attempting to PyFile_SetBufSize() on
one of the pipes. Evil juju in ntdll.dll ..

I've no idea what system resource is being exhausted
(heap memory?) causing the crash.

If you look at the hacks in posixmodule.c, the Python
crash can be eliminated by simply commenting out the
calls to PyFile_SetBufSize. There is still the problem
of resource exhaustion. To gain more child processes I
included a hack such that with the setting of an
env-var (NOPYCMD) popen2 will NOT use cmd.exe /c to run
a child, but simply run the child command as passed
(yeah, I know that is has to be an absolute path or in
the CWD then ..).

I'm sure there is a better way to eliminate the cmd.exe
/c - like maybe a new method: popen2.popenXabspath ..

In any case, it appears we have an NT kernel bug
combined with an inefficient way of doing popen2 that
is making a mess. I started doing some exploration of
heap_chunk_size to attack to resource issue but haven't
gotten very far.

As for *why* I'm doing this, it's because we're using
Pyton as a system simulator tool to emulate a large
pile of PCs. The actual work *must* be done by
external .exe code that cannot be changed.

The attached zip contains a test case, the posixmodule
hack, drwatson file and a sample program written in
VisC++ which does basically the same as the Python test
case.

cheers,

• Frank

[rupole]

The code for the popen* functions doesn't check the return
value of _fdopen, which will return null when the limit of
open stdio streams is reached.
A similar issue exists in the win32pipe module, which uses
almost exactly the same code. See Pywin32 bug 1731778
( http://sourceforge.net/tracker/?func=detail&atid=551954&aid=1731778&group_id=78018 )
for more details.

[tiran]

Modules/posixmodule.c:_PyPopen() needs to check for NULL after the
_fdopen() calls.

[tiran]

An easy C task for the bug day.

[BreamoreBoy]

Can this be closed as popen2 is deprecated?

[RamchandraApte]

I think so.

[terryjreedy]

In particular, the popen2 entry says " "Deprecated since version 2.6: This module is obsolete. Use the subprocess module. Check especially the Replacing Older Functions with the subprocess Module section."

On core-mentorship list, Guido answered 'Sure'. [close it]

Let's hope that subprocess does better.