[issue21069] test_fileno of test_urllibnet intermittently fails

2016-04-09 Thread Martin Panter
Changes by Martin Panter : -- resolution: -> fixed stage: commit review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue21069] test_fileno of test_urllibnet intermittently fails

2016-04-09 Thread Roundup Robot
Roundup Robot added the comment: New changeset 00240ddce1d0 by Martin Panter in branch '3.5': Issue #21069: Move test_fileno() from test_urllibnet and rewrite it https://hg.python.org/cpython/rev/00240ddce1d0 New changeset 4c19396bd4a0 by Martin Panter in branch 'default': Issue #21069: Merge te

[issue21069] test_fileno of test_urllibnet intermittently fails

2016-04-09 Thread Berker Peksag
Berker Peksag added the comment: I saw test_fileno failure again on the Gentoo buildbot: http://buildbot.python.org/all/builders/x86%20Gentoo%20Installed%20with%20X%203.x/builds/459/steps/test/logs/stdio rewrite-fileno.patch looks good to me. -- nosy: +berker.peksag stage: patch review

[issue21069] test_fileno of test_urllibnet intermittently fails

2016-04-03 Thread Martin Panter
Martin Panter added the comment: Yes using select() would be another way to fix the immediate problem of read() returning None. In the long term I was hoping to use something like my patch to avoid the problems with reading the HTTP response (already discussed in this report) at the same time.

[issue21069] test_fileno of test_urllibnet intermittently fails

2016-04-03 Thread STINNER Victor
STINNER Victor added the comment: I added a timeout because test_urllibnet fails with a timeout after 15 minutes on the ARM buildbot and other tests of the same file also use a timeout. I tried but failed to reproduce the timeout. I ran the test after my change and it passes so I considered th

[issue21069] test_fileno of test_urllibnet intermittently fails

2016-04-01 Thread Martin Panter
Martin Panter added the comment: Here is a patch implementing my ideas. Let me know what you think of the ideas and/or the patch :) If people think this change is too much for 3.5, I could try making a more minimal patch that calls something like socket.getpeername() rather than read(). That

[issue21069] test_fileno of test_urllibnet intermittently fails

2016-04-01 Thread Mark Lawrence
Changes by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue21069] test_fileno of test_urllibnet intermittently fails

2016-04-01 Thread Martin Panter
Martin Panter added the comment: Mark: My understanding is on Windows, winsock file descriptors and C library file descriptors are different beasts; see . Perhaps the test should call socket functions like socket.recv() on the

[issue21069] test_fileno of test_urllibnet intermittently fails when using www.example.com

2015-05-04 Thread Mark Lawrence
Mark Lawrence added the comment: I tried reproducing this on Windows 8.1 with the code snippet from msg216429 but got Traceback (most recent call last): File "C:\Users\Mark\Documents\MyPython\mytest.py", line 9, in with os.fdopen(fd, 'rb') as f: File "c:\python34\lib\os.py", line 980,

[issue21069] test_fileno of test_urllibnet intermittently fails when using www.example.com

2014-04-15 Thread Ned Deily
Ned Deily added the comment: Senthil, thanks for looking into this. Since it is turning out to be more of a urllib design issue, I'm going to deassign myself from it. -- assignee: ned.deily -> ___ Python tracker

[issue21069] test_fileno of test_urllibnet intermittently fails when using www.example.com

2014-04-15 Thread Senthil Kumaran
Senthil Kumaran added the comment: Ned Deily had done the correct analysis in the msg214947 and has this question - > I don't know whether the file descriptor read is expected to be meaningful > for urllib2/urllib.request. I can see that this test case was for the old behavior where we creat

[issue21069] test_fileno of test_urllibnet intermittently fails when using www.example.com

2014-04-15 Thread Senthil Kumaran
Senthil Kumaran added the comment: This is turning out be trickier than I ever thought. fileno() returning b'' is just random error. The underlying issue is, *directly* reading from the fp of the socket() is returning a incomplete output at all times. The correct way to read the output is by u

[issue21069] test_fileno of test_urllibnet intermittently fails when using www.example.com

2014-04-15 Thread Senthil Kumaran
Senthil Kumaran added the comment: This is the best way I found to reproduce the failure. I changed the resource to www.example.com and then ran this. $ ./python.exe -m test -m "*fileno*" -u all -v -F test_urllibnet -- ___ Python tracker

[issue21069] test_fileno of test_urllibnet intermittently fails when using www.example.com

2014-04-15 Thread Senthil Kumaran
Senthil Kumaran added the comment: I am getting to this late. >> I don't know whether the file descriptor read is expected to be meaningful >> for urllib2/urllib.request. >> Senthil, what do you think? It should be meaningful no matter what the length is. I am looking further into this now.

[issue21069] test_fileno of test_urllibnet intermittently fails when using www.example.com

2014-03-27 Thread Arfrever Frehtes Taifersar Arahesis
Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue21069] test_fileno of test_urllibnet intermittently fails when using www.example.com

2014-03-27 Thread Ned Deily
Ned Deily added the comment: After looking at why the 2.7 version of the test does not fail, the problem became apparent. In 2.7, test_errno tests urlopen() of the original deprecated urllib module. In 3.x, the test was ported over but now uses urlopen() of urllib.request which is based on u

[issue21069] test_fileno of test_urllibnet intermittently fails when using www.example.com

2014-03-27 Thread Ned Deily
Ned Deily added the comment: After pushing the changes for Issue20939, many of the buildbots started experiencing the test_fileno failure using www.example.com. The interesting thing is that not all of them do, including my primary development system (OS X 10.9) which is why I didn't see a pr