From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040204 Description of problem: Simple threaded python script breaks when httplib.HTTPSConnection is used. httplib.HTTPConnection works fine in the same scenario. It is unclear if this is a httplib issue or a openssl bindings issue. Version-Release number of selected component (if applicable): python-2.2.3-5 How reproducible: Always Steps to Reproduce: 1. Start netcat "nc -l -p 8080". 2. Run python-https.py on same host. Actual Results: When httplib.HTTPConnection is called, "I'm still here" prints on the screen every 2 seconds. When httplib.HTTPSConnection is called, "I'm still here" prints once and then the script bombs (and the output on the netcat window is screwed up). Expected Results: When httplib.HTTPSConnection is called, "I'm still here" should print every 2 seconds just like when using httplib.HTTPConnection. Additional info: python 2.3 on Fedora Core 2 does NOT have this issue. Whatever changed in python 2.3 (or openssl) on FC2 should be back-ported to RHEL 3 to fix this issue.
Created attachment 102260 [details] httplib.HTTPConnection script This script works in conjunction with "nc -l -p 8080" using the HTTP protocol.
Created attachment 102261 [details] httplib.HTTPSConnection script This script fails in conjunction with "nc -l -p 8080". The only difference between this script and python-http.py is the httplib.HTTPConnection was changed to httplib.HTTPSConnection.
tao
I'd be interested to see if this happens with rhnlib as well. python's stock ssl implementation is pretty useless, that's why RHN uses pyOpenSSL (binding directly to openssl). I'll modify the test case for that.
I've been looking at this ticket this afternoon, and I've noticed that the "I'm still here thread" appears to block on a futex after the network thread opens it's ssl connection. In the non-ssl case, the "ISH" thread does not block on the futex. The network thread appears to be doing the same number/order of futex wakes. I'm looking for the source (and backtrace) of the futex calls..
Created attachment 104770 [details] backport ssl thread support from python 2.3.3
The above patch corrects the hang reported in this ticket. Needs review by someone who understands phython's threading/locking mechanisims.
The patch looks harmless. Thanks for submitting it, I'll build a new python package.
Can you please release this RPM as an errata for RHEL 3? If possible, releasing it before Update 4 would be ideal; otherwise, please include it in Update 4. Thank you.
Did this make the U4 beta?
No, looks like I missed the deadline. I'll build the packages nevertheless and put them on people.redhat.com in the meantime.
Packages are now available at: ftp://people.redhat.com/misa/python-fixes/mt-ssl/ The packages are signed with my GPG key, available at: http://people.redhat.com/misa/misa.gpg
It was my understanding from IBM Level 3 support that this package would be in U4. Is there any chance this package can be added to the U4 beta in RHN so people can test it until U4 is GA?
Brian, We are currently working with Release Engineering and QA on a plan to put this package in U4. As far as I know U4 beta is frozen, but we will see what we can do to make them widely available. In the meantime, if you can try to run the packages posted on comment #15 in one of your environments that are exhibiting the problem, that would give me a higher level of confidence that the problem is indeed fixed.
Mihai, The problem is fixed with your RPM. That's why I'm hoping it shows up in U4 :) Thanks! /Brian/
Brian, it's great to hear that! Major problems raised by QA excluded, it should make it in U4.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2004-616.html
*** Bug 121428 has been marked as a duplicate of this bug. ***