New submission from Amrith Kumar:
Environment:
- Linux (Ubuntu 14.04 LTS, x64) running Python 2.7.
- Code uses eventlet.green.subprocess
Code establishes subprocess as:
subprocess.Popen(command,
stdin=subprocess.PIPE,
stdout=subprocess.PIPE
Amrith Kumar added the comment:
I'll supply a patch for this proposed change.
--
___
Python tracker
<http://bugs.python.org/issue22114>
___
___
Python-bugs-l
Amrith Kumar added the comment:
I see three comments, one from r.david.murray, one from haypo and one from
pitrou. I'll try and address all three.
r.david.murray:
The code in question is in
https://github.com/openstack/oslo-incubator/blob/master/openstack/common/processutils.py#L177
Changes by Amrith Kumar :
--
title: You cannot call communicate() safely after receiving EAGAIN -> You
cannot call communicate() safely after receiving an exception (EINTR or EAGAIN)
___
Python tracker
<http://bugs.python.org/issu
Amrith Kumar added the comment:
haypo; no argument from me. I just updated the description to make it more
exact.
I may have received EINTR or EAGAIN.
In either event, I need to debug some more and try and do a clean repro and
then figure out a proper fix.
In the meanwhile, I proposed a fix
Amrith Kumar added the comment:
r.david.murray, I guess the issue we have is that something (hypothesis:
eventlet) is causing the blocking API to communicate() to throw an EAGAIN.
This (https://bugs.launchpad.net/nova/+bug/1271331) is the bug that was fixed a
while ago in OpenStack that
Amrith Kumar added the comment:
After some debugging and reading code in python's subprocess.py (v2.7), here's
what I'm seeing.
(a) the error has nothing to do with eventlet and monkey-patching.
(b) the code in _communicate_with_select() and potentially
_communicate_with
Amrith Kumar added the comment:
The issue turned out to be something funky in monkey patching.
os.read() shouldn't be getting called if the monkey patch was correct in the
first place.
--
resolution: -> not a bug
status: open -> closed
___
New submission from Amrith Kumar:
The urlparse library incorrectly accepts a URI which specifies an invalid host
identifier.
Example:
http://www.example.com:/abc
Looking at the URI specifications, this is an invalid URI.
By definition, you are supposed to specify a "hostport" and
Amrith Kumar added the comment:
As requested ...
>>> urlparse.urlparse('http://www.google.com:/abc')
ParseResult(scheme='http', netloc='www.google.com:', path='/abc', params='',
query='&#x
Amrith Kumar added the comment:
Eric, Martin,
I'm sure this is an interpretation (and I'll be fair and give you both) that a
URL of the form:
http://hostname.domain.tld:/path
should be held invalid. The rationale is per the section of the spec you quoted.
The other side of the a
11 matches
Mail list logo
