http://bugzilla.suse.com/show_bug.cgi?id=1068470 http://bugzilla.suse.com/show_bug.cgi?id=1068470#c45 Marcus Hüwe changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(sebastian.parscha | |uer@suse.com) --- Comment #45 from Marcus Hüwe --- (In reply to Sebastian Parschauer from comment #42)

headers["Connection"] = "close" try: h.request(req.get_method(), selector, req.data, headers) s = h.get_session() if s: self.saved_session = s r = h.getresponse()

Can you try the following? Revert all potential fixes (if applied) that are mentioned in the github issue and then remove or uncomment s = h.get_session() if s: self.saved_session = s and check if it still hangs? My guess is (_not_ verified yet): - h.get_session() performs a SSL_get_session() (not a SSL_get1_session()) - As you pointed out, we never "close" (== SSL_shutdown(...) == sending a close notify alert) the connection (== SSL struct) => the session is considered bad - When the execution returns from https_open, h is "destroyed" - Especially, h.sock is "destroyed", which SSL_free()s the SSL struct => the session is also SSL_SESSION_free()d (since it is bad) - If https_open is invoked again, we use the SSL_SESSION_free()d session Explicitly closing (SSL_shutdown()) is just fixing a symptom (the session is _not_ considered bad and remains in the session cache (and is not SSL_SESSION_free()d)). However, it is possible that the session is removed from the session cache and self.saved_session is dangling again... -- You are receiving this mail because: You are on the CC list for the bug.