Changes by Serhiy Storchaka storch...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21619
___
___
Martin Panter added the comment:
Sure, new version is fine by me
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21619
___
___
Python-bugs-list
Serhiy Storchaka added the comment:
I think we should add __enter__ for consistency.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21619
___
Changes by Serhiy Storchaka storch...@gmail.com:
Added file: http://bugs.python.org/file38386/overflow-pipe-test-2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21619
___
Roundup Robot added the comment:
New changeset 4ea40dc3d26d by Serhiy Storchaka in branch '3.4':
Issue #21619: Cleaned up test_broken_pipe_cleanup.
https://hg.python.org/cpython/rev/4ea40dc3d26d
New changeset 41ce95a5b2d8 by Serhiy Storchaka in branch 'default':
Issue #21619: Cleaned up
STINNER Victor added the comment:
overflow-pipe-test.patch looks good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21619
___
___
Martin Panter added the comment:
Thanks for getting the test working. Just to tidy things up here I would like
to get rid of my stdout signalling in the test, which is no longer needed and
could be misleading. See overflow-pipe-test.patch.
--
status: closed - open
Added file:
Serhiy Storchaka added the comment:
Looks as tests are fixed. Thank you Victor.
--
resolution: - fixed
stage: needs patch - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21619
Roundup Robot added the comment:
New changeset 77a978716517 by Victor Stinner in branch '3.4':
Issue #21619: Try to fix test_broken_pipe_cleanup()
https://hg.python.org/cpython/rev/77a978716517
--
___
Python tracker rep...@bugs.python.org
Changes by Serhiy Storchaka storch...@gmail.com:
--
stage: - needs patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21619
___
___
Martin Panter added the comment:
Aha! So perhaps Windows can accept a small amount of data into its pipe buffer
even if we know the pipe has been broken. That kind of makes sense. Test case
could be modified to:
proc = subprocess.Popen([...], bufsize=support.PIPE_MAX_SIZE,
STINNER Victor added the comment:
I opened the issue #23570: Change with subprocess.Popen(): (context manager)
to ignore broken pipe error.
FAIL: test_broken_pipe_cleanup (test.test_subprocess.ContextManagerTests)
Serhiy: see existing test_communicate_epipe() and
Serhiy Storchaka added the comment:
Could you provide a patch Martin?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21619
___
___
STINNER Victor added the comment:
I would be safer to use a bufsize a little bit larger :-)
proc = subprocess.Popen([...], bufsize=support.PIPE_MAX_SIZE * 2,
stdin=subprocess.PIPE, stdout=subprocess.PIPE)
...
proc.stdin.write(b'x' * support.PIPE_MAX_SIZE)
--
Akira Li added the comment:
On Windows behavior
http://stackoverflow.com/questions/23688492/oserror-errno-22-invalid-argument-in-subprocess
--
nosy: +akira
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21619
Martin Panter added the comment:
Thanks for that link; the answer by Eryksun
https://stackoverflow.com/questions/23688492/oserror-errno-22-invalid-argument-in-subprocess#28020096
is particularly enlightening. Apparently EINVAL actually represents an
underlying broken pipe condition in
STINNER Victor added the comment:
A few months ago, I modified Popen.communicate() to handle EINVAL on
Windows.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21619
___
Serhiy Storchaka added the comment:
The test still sporadically fails on Windows:
http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/9323/steps/test/logs/stdio
==
FAIL: test_broken_pipe_cleanup
Serhiy Storchaka added the comment:
Why not ignoring BrokenPipeError like communicate()?
Why communicate() ignores BrokenPipeError?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21619
Serhiy Storchaka added the comment:
It was added in issue10963. I don't know if this way is applicable to this
issue.
--
nosy: +dmalcolm, pitrou, rosslagerwall
resolution: fixed -
stage: resolved -
___
Python tracker rep...@bugs.python.org
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21619
___
STINNER Victor added the comment:
Le dimanche 1 mars 2015, Serhiy Storchaka rep...@bugs.python.org a écrit :
Why communicate() ignores BrokenPipeError?
It's more convinient. There is nothing useful you can do on pipe error in
communicate().
For __exit__, what do you want to on broken pipe
Serhiy Storchaka added the comment:
When you write to the file you don't want the error was silently ignored.
with open(filename, 'w') as f:
f.write(content)
And also I don't want the error was silently ignored when write to the
subprocess.
with subprocess.Popen(cmd,
Martin Panter added the comment:
It seems two different issues have popped up:
## 1. Windows behaviour ##
Windows apparently doesn’t handle broken pipes consistently, sometimes raising
an EINVAL error, and sometimes not raising any error. I don’t know if this is a
problem with Python, or a
Roundup Robot added the comment:
New changeset b5e9ddbdd4a7 by Serhiy Storchaka in branch '3.4':
Issue #21619: Popen objects no longer leave a zombie after exit in the with
https://hg.python.org/cpython/rev/b5e9ddbdd4a7
New changeset cdac249808a8 by Serhiy Storchaka in branch 'default':
Issue
Serhiy Storchaka added the comment:
Thank you for your contribution Martin.
--
resolution: - fixed
stage: patch review - resolved
type: - resource usage
versions: +Python 3.5
___
Python tracker rep...@bugs.python.org
STINNER Victor added the comment:
Why not ignoring BrokenPipeError like communicate()?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21619
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21619
___
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
assignee: - serhiy.storchaka
nosy: +serhiy.storchaka
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21619
___
Roundup Robot added the comment:
New changeset 1b4d916329e7 by Serhiy Storchaka in branch '3.4':
Fixed a test for issue #21619 on Windows.
https://hg.python.org/cpython/rev/1b4d916329e7
New changeset eae459e35cb9 by Serhiy Storchaka in branch 'default':
Fixed a test for issue #21619 on Windows.
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21619
___
___
Python-bugs-list
Martin Panter added the comment:
Here is a patch to fix this by calling wait() even if stdin.close() fails,
including a test case. With my patch, the subprocess context manager __exit__()
will still raise a BrokenPipeError, but no zombie will be left.
--
keywords: +patch
Added file:
New submission from Martin Panter:
The documentation for the “subprocess” module says that a “with” statement will
“wait for” the process, implying that it does not leave a zombie. However this
is not the case if there is buffered input data:
$ python3 -Wall -bt -q
import subprocess
with
33 matches
Mail list logo
