Issue 1489: test_socket_ssl hanhs on Windows (deadlock) (original) (raw)

Created on 2007-11-22 21:23 by paul.moore, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
test_socket_ssl.diff paul.moore,2007-11-22 21:23
unnamed janssen,2008-04-22 21:47
unnamed janssen,2008-04-22 21:48
Messages (7)
msg57768 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2007-11-22 21:23
When running the test suite on Windows, test_socket_ssl hangs. After a bit of investigation, it appears that the test is hanging at line 184 (if self.s.stdout.readline() != "ERROR\n":) in OpenSSLServer._external. The problem is that the test assumes it can read a line of stdout from the openssl.exe process. However, the openssl.exe on my PC (from the GnuWin32 project) appears to buffer its output, so the Python process deadlocks waiting for a response. An easy (if clumsy) fix is to simply skip the check on the output of the server. I have attached a patch which does this for win32 only (on the assumption that other platforms don't have this issue). I guess that other openssl builds don't have the same problem - however, I can't see an easy way of testing for this.
msg65163 - (view) Author: Trent Nelson (trent) * (Python committer) Date: 2008-04-08 14:00
Re-assigned this to myself (hope you don't mind janssen ;-) as I'm actively looking into it. We build openssl.exe as part of our Windows build so we should make an effort to use this where possible. Note that there is definitely a problem with 'openssl s_server' on Windows, I'm not sure if it's to do with buffering though as I can step through the same actions the test is performing in the console and I get 'ERROR\n' immediately back from the server. This sort of falls into my existing work with issue 2550 (and patches) to improve network- oriented tests such that they can be ran in parallel. Note that patch trunk.2550-2.patch attached to goes as far as converting openssl to use the -accept [port] option such that we don't bind on 4443 by default (thus impeding other test_ssl_socket tests that may be running). Also, openssl.exe in the s_server mode is using SO_REUSEADDR when it should be using SO_EXCLUSIVEADDRUSE. That's not our problem per se, but given that we maintain our own openssl-0.9.8g sources, I'm considering fixing it if it improves the reliability of the test. (I'll feed back any changes to the OpenSSL project, of course.)
msg65170 - (view) Author: Bill Janssen (janssen) * (Python committer) Date: 2008-04-08 15:38
Fine with me. I don't have a checkout of the code handy, but I believe this is obsolete test code. All the SSL tests are, or should be, in test_ssl, for 2.6 and 3.x. The right fix is to remove it.
msg65680 - (view) Author: Trent Nelson (trent) * (Python committer) Date: 2008-04-22 19:15
Hey, if we can get rid of it, that's great. You sound 95% certain in your last post that completely removing test_socket_ssl on trunk and py3k is the Right Thing -- any chance of getting you to 100% so I can go ahead and delete it and close this ticket?
msg65685 - (view) Author: Bill Janssen (janssen) * (Python committer) Date: 2008-04-22 21:47
On Tue, Apr 22, 2008 at 12:15 PM, Trent Nelson <report@bugs.python.org> wrote: > > Trent Nelson <tnelson@onresolve.com> added the comment: > > Hey, if we can get rid of it, that's great. You sound 95% certain in > your last post that completely removing test_socket_ssl on trunk and > py3k is the Right Thing -- any chance of getting you to 100% so I can > go ahead and delete it and close this ticket? > > __________________________________ > Tracker <report@bugs.python.org> > <http://bugs.python.org/issue1489> > __________________________________ >
msg65686 - (view) Author: Bill Janssen (janssen) * (Python committer) Date: 2008-04-22 21:48
Sorry, didn't mean to be indeterminate. Sure, nuke it. The tests are now all in test_ssl.py. Bill On Tue, Apr 22, 2008 at 2:47 PM, Bill Janssen <bill.janssen@gmail.com> wrote: > > > On Tue, Apr 22, 2008 at 12:15 PM, Trent Nelson <report@bugs.python.org> > wrote: > > > > > Trent Nelson <tnelson@onresolve.com> added the comment: > > > > Hey, if we can get rid of it, that's great. You sound 95% certain in > > your last post that completely removing test_socket_ssl on trunk and > > py3k is the Right Thing -- any chance of getting you to 100% so I can > > go ahead and delete it and close this ticket? > > > > __________________________________ > > Tracker <report@bugs.python.org> > > <http://bugs.python.org/issue1489> > > __________________________________ > > > >
msg68381 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-06-18 23:08
Kind of fixed: test_socket_ssl was removed in both trunk and py3k branches. "tests are now in test_ssl.py"
History
Date User Action Args
2022-04-11 14:56:28 admin set github: 45830
2008-06-18 23:08:08 amaury.forgeotdarc set status: open -> closednosy: + amaury.forgeotdarcresolution: fixedmessages: +
2008-04-22 21:48:41 janssen set files: + unnamedmessages: +
2008-04-22 21:47:58 janssen set files: + unnamedmessages: + title: test_socket_ssl hangs on Windows (deadlock) -> test_socket_ssl hanhs on Windows (deadlock)
2008-04-22 19:34:48 draghuram set title: test_socket_ssl hanhs on Windows (deadlock) -> test_socket_ssl hangs on Windows (deadlock)
2008-04-22 19:15:28 trent set messages: +
2008-04-08 15:38:30 janssen set messages: +
2008-04-08 14:00:53 trent set assignee: janssen -> trentmessages: + nosy: + trent
2008-01-05 11:32:42 vila set nosy: + vila
2007-11-23 03:13:44 gvanrossum set assignee: janssennosy: + janssen
2007-11-22 21:23:11 paul.moore create