Ronald Oussoren added the comment:
The workaround should not be implemented in os.read because it is a very thin
wrapper around the system call and should stay that way.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15896
Vitaly added the comment:
The workaround should not be implemented in os.read because it is a very thin
wrapper around the system call and should stay that way.
Although this issue was initially filed as Sporadic EINVAL in nonblocking pipe
os.read when forked child fails on Mac OS, the
Ronald Oussoren added the comment:
How can you work around it in os.read, without knowing anything about what the
file descriptor represents? Just triggering on getting on EINVAL error when
calling read might trigger other problems and might even be a valid result for
some file descriptors
Vitaly added the comment:
And what kind of workaround do you propose?
[os.read(fd, buffersize)]
I am thinking about these options:
Option 1:
Fix breakages as they are discovered at higher level (above os.read) as needed
in places where usage semantics are known, and address the issue via
Ned Deily added the comment:
Out of curiosity, has anyone checked whether this is also an issue with any of
the supported BSD's? There have been other issues which were detected first on
OS X but turned out to be more general BSD vs Linux differences, rather than OS
X bugs.
--
Charles-François Natali added the comment:
Option 1:
Fix breakages as they are discovered at higher level (above os.read) as
needed in places where usage semantics are known, and address the issue via
errata documentation (i.e., On Mac OS X, don't make individual pipe read
requests that
Vitaly added the comment:
It's not Python's job to workaround stupid platform bugs...
So I'd suggest closing this, and urge people to complain to the OS-X folks
After digesting the postings, I've come around to this point of view as well,
so closing as rejected. And, as mentioned earlier, I
Changes by Vitaly vitaly.krugl.nume...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15896
___
___
Vitaly added the comment:
In the work-around, we need to watch out for what 'man 2 read' on Mac OS refers
to as normal file:
==
Upon successful completion, read(), readv(), and pread() return the number of
bytes actually read and placed in the buffer. *The system guarantees to
read the
Changes by Ralf Schmitt python-b...@systemexit.de:
--
nosy: +schmir
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15896
___
___
Python-bugs-list
Charles-François Natali added the comment:
What's wrong with working around this bug by reading a smaller amount?
How much data is there supposed to be?
Nothing, except that there are probably other places in the stdlib
where we can get bitten by this bug. Note that this should eventually
be
Vitaly added the comment:
Nothing, except that there are probably other places in the stdlib
where we can get bitten by this bug. Note that this should eventually
be done for another reason, see http://bugs.python.org/issue15918
For greatest benefit, I think that the work-around should be
Vitaly added the comment:
I wrote a C-language program to reproduce this issue on Mac OS without Python.
It reproduces the issue in both increasing and decreasing order of initial read
sizes, and it reliably reproduces it for each KB from 128KB to 1024KB ; the
Python version reproduced the
Vitaly added the comment:
The C-language program for reproducing the same issue is attached as
test_fork_pipe_error.cpp
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15896
___
Vitaly added the comment:
I used g++ to compile test_fork_pipe_error.cpp on both Mac OS and on Linux.
EINVAL showed up only on Mac OS.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15896
Charles-François Natali added the comment:
The reason I said above that those might be red-herring discoveries is this:
if I insert a short time.sleep(0.001) delay before the outer pipe-read loop,
the EINVAL errors don't get triggered either.
That's interesting.
So it really seems that
Changes by Charles-François Natali neolo...@free.fr:
--
type: crash - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15896
___
___
Vitaly added the comment:
By the way, the existing code in subprocess.Popen (at least on 2.6.7) reads the
pipe incorrectly: It doesn't loop to read all the data until EOF -- it only
loops over EINTR until it gets a single successful os.read() call. However,
since this is a pipe read (not a
Vitaly added the comment:
I filed this issue with apple: Problem ID: 12274650:
https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa/64/wo/VE1RGG9qEL5OS9KdzFSDHw/19.66
--
___
Python tracker rep...@bugs.python.org
Vitaly added the comment:
Apple bug report URL correction:
https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa/64/wo/VE1RGG9qEL5OS9KdzFSDHw/17.66
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15896
Vitaly added the comment:
Sorry, I don't know why the URL comes out all messed up. I can't seem to find
the correct syntax for this.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15896
Charles-François Natali added the comment:
By the way, the existing code in subprocess.Popen (at least on 2.6.7) reads
the pipe incorrectly: It doesn't loop to read all the data until EOF -- it
only loops over EINTR until it gets a single successful os.read() call.
However, since this is
Vitaly added the comment:
Filed http://bugs.python.org/issue15918 for the incorrect pipe read logic in
subprocess.Popen.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15896
___
Ronald Oussoren added the comment:
What's wrong with working around this bug by reading a smaller amount? How much
data is there supposed to be?
BTW. URLs for reports in Apple's tracker are fairly useless as bugreports are
private (only you and Apple's engineers can see the report). The bug
Vitaly added the comment:
What's wrong with working around this bug by reading a smaller amount? How
much data is there supposed to be?
This makes sense for working around the issue. Even in the blocking-read case,
such as in subprocess.Popen, attempting to read a 1MB chunk of data in a
Changes by Vitaly vitaly.krugl.nume...@gmail.com:
--
versions: +Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15896
___
___
Changes by Denis Bilenko denis.bile...@gmail.com:
--
nosy: +Denis.Bilenko
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15896
___
___
Charles-François Natali added the comment:
Looks like - another - OS-X bug.
What happens if you reduce the size argument when reading from the error pipe?
Try setting it to a value like 512 (minimum guaranteed PIPE_BUF):
newData = os.read(errpipe_read, min(512, rSize))
You could also try to
Vitaly added the comment:
Per Charles-François Natali (neologix), I tried the following:
1. Reduce the initial read size argument (rSize in my code snippet) from
1048576 (1MB, the same amount as used by subprocess.Popen._executeChild) to
100: the problem appears to go away (could be just
Charles-François Natali added the comment:
1. Reduce the initial read size argument (rSize in my code snippet) from
1048576 (1MB, the same amount as used by subprocess.Popen._executeChild) to
100: the problem appears to go away (could be just red herring, though);
this actually makes
Changes by Vitaly vitaly.krugl.nume...@gmail.com:
Added file: http://bugs.python.org/file27170/test_fork_pipe_error.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15896
___
Vitaly added the comment:
os.read() must also be allocating the read buffer in addition to calling the
system read() function. I just uploaded a new test script
test_fork_pipe_error.py that iterates in increasing or decreasing order over
initial pipe read sizes and accumulates failed size
New submission from Vitaly:
Python 2.6.7 on Mac OS 10.7.4 running on MacBookPro laptop.
run attachment as: python test_pipe_error.py
The test() function makes multiple calls to _execute_child() in a loop. Every
other call to _execute_child() fails with:
=
os.read(3, 1048576) self pid:
33 matches
Mail list logo
