New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EBADF error on x86 Tiger 3.x buildbot #74411
Comments
test_http_body_pipe() of test_urllib2 uses a subprocess, no idea if it's related: cmd = [sys.executable, "-c", r"pass"]
for headers in {}, {"Content-Length": 30}:
with subprocess.Popen(cmd, stdout=subprocess.PIPE) as proc:
req = Request("http://example.com/", proc.stdout, headers)
... See also my issue bpo-29915 "Drop Mac OS X Tiger support in Python 3.7?" :-) http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/597/steps/test/logs/stdio ./python.exe -E -c 'import sys ; from sysconfig import get_platform ; print("%s-%d.%d" % (get_platform(), *sys.version_info[:2]))' >platform Current thread 0xa000d000 (most recent call first): Current thread 0xa000d000 (most recent call first): |
@david Bolen: Would you mind to take a look? I don't have access to your x86 Tiger 3.x buildbot. |
Hmm, I wonder if this is another race condition similar to bpo-8458? I think that was thought to be related to the subprocess exiting quickly, in which case the question might be why that might happen more so than the actual descriptor error. BTW, Victor, in case it would help, your account (vstinner, ssh key haypo@marge) still exists on this buildbot from past testing in 2011. The only thing I'd need to re-enable is the port forwarding on my firewall. |
In running the test under a local build, the issue is very repeatable, but I believe it's actually due to slow process startup rather than a quick exit. That is, adding a brief sleep after process creation and just before the Request() call seems to fix the problem. I'm guessing the buildbot is sluggish enough that it just takes a bit longer for the process to start and be ready to be used. Whether or not that's purely a machine or test problem, or whether it means that perhaps subprocess.Popen() is returning sooner than it should with a process that isn't ready yet is unclear. (Or even if subprocess can tell) With the machine fairly idle, it looks like the minimum workable delay is about 200ms - probably something a bit longer would be safer under load, if looking for a quick workaround. |
initstdio() is supposed to handle EBADF: see issue bpo-24891. |
Ok, the race condition causing EBADF is now handled correctly in 3.5, 3.6 and master (3.7). |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: