Title: Subprocesses called with stdout/stderr=subprocess.PIPE block on Windows
Type: Severity: normal
Components: Core Versions: 25rc4
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: pjenvey Nosy List: otmarhumbel, pjenvey
Priority: normal Keywords: test failure causes

Created on 2009-05-20.09:29:36 by otmarhumbel, last changed 2009-05-22.02:43:37 by pjenvey.

msg4701 (view) Author: Oti Humbel (otmarhumbel) Date: 2009-05-20.09:29:35
The following could be reproduced both on Windows XP and Windows Vista,
using Jython 2.5rc2:

Jython 2.5rc2 (Release_2_5rc2:6341, May 11 2009, 17:07:28)
[Java HotSpot(TM) Client VM (Sun Microsystems Inc.)] on java1.6.0_13
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> import sys
>>> cmd_line = [ sys.executable, '-m', 'runpy', 'fnordl9203828xyz' ]
Traceback (most recent call last):
ImportError: No module named fnordl9203828xyz
>>>, stdout=subprocess.PIPE,
  #running for ever
msg4705 (view) Author: Philip Jenvey (pjenvey) Date: 2009-05-22.02:43:35
Turns out this is just an abuse of The code is 
originally from test_cmd_line, doh

call just wait()s, it doesn't consume the PIPEs we specify. With nothing 
consuming those pipes, the child can deadlock after writing enough 
output to fill the pipe's buffer

The -m runpy fnordXXX was the only trigger because it wrote enough 
output (a traceback) to fill the buffer, and it only happened on Windows 
because Windows has a pretty small pipe buf

The author of subprocess confirms that this is indeed a bad idea here:

fixed in r6363
Date User Action Args
2009-05-22 02:43:37pjenveysetstatus: open -> closed
keywords: + test failure causes
resolution: fixed
messages: + msg4705
2009-05-21 05:20:44pjenveysetassignee: pjenvey
nosy: + pjenvey
2009-05-20 09:29:36otmarhumbelcreate