Inconsistent subprocess.Popen.communicate()
behavior between Windows and Posix on non-byte memoryview input
#134453
Labels
3.13
bugs and security fixes
stdlib
Python modules in the Lib dir
topic-subprocess
Subprocess issues.
type-bug
An unexpected behavior, bug, or error
Uh oh!
There was an error while loading. Please reload this page.
Bug report
Bug description:
This is not a bug per se as it diverges from the documentation, but Posix version of
subprocess.Popen.communicate()
behaves less ideally when a large "memoryview"-able object with non-byte item is passed as theinput
argument. For example, suppose I have a simple pass-through process which takes a long input arrayx
of length greater than 512 and return it as is:This example fails the assertion only in Posix because the returned array
y
shorter thanx
.This appears to stem from
sp.Popen.communicate()
The indexed
chunk
ofinput_view
sends more bytes ifself._input
is not a bytes-like whilelen(self._input)
counts the number of items. As suchself._input_offset
>len(self._input)
after the first few writes due to the mismatch in their units.I think the if statement checks the bytes read against
input_view.nbytes
instead oflen(self._input)
.This use case is not officially supported as the input is expected to be bytes-like and not any arbitrary memoryview object, but it works under Windows, and this Posix codepath behavior is rather nasty as it works (as wrongly expected) for a short input (as is often the case for testing).
I believe an arbitrary memoryview object as a subprocess input works otherwise (based on my extensive uses passing audio and video data to and from FFmpeg) so perhaps I should label this issue as a feature request.
P.S., A fix for the example is to use
ret = sp,run('pass_thru', input=x.view('b'))
.CPython versions tested on:
3.13
Operating systems tested on:
No response
Linked PRs
The text was updated successfully, but these errors were encountered: