This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: socket close() hangs client if used without prior shutdown()
Type: Stage:
Components: Extension Modules Versions: Python 2.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: irmen, loewis, nnorwitz, splitscreen
Priority: high Keywords:

Created on 2006-06-27 09:54 by irmen, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
py25bug.py irmen, 2006-06-27 09:54 socket server to test with
socket.diff nnorwitz, 2006-07-01 08:22 v1
Messages (8)
msg28937 - (view) Author: Irmen de Jong (irmen) (Python triager) Date: 2006-06-27 09:54
In Python 2.5b1, when closing a client socket using
socket.close(), the connecting client hangs. I.e. the
socket is not properly taken down. If you add an
explicit call to socket.shutdown(), prior to the
close(), it works again.

But I think this shutdown() should not be mandatory? At
least, it wasn't in older Python versions.

Sample code attached. Run the script and connect to
socket 9000. If you remove the call to shutdown, your
client connection will hang (use telnet or netcat).
msg28938 - (view) Author: Irmen de Jong (irmen) (Python triager) Date: 2006-06-27 09:55
Logged In: YES 
user_id=129426

Oops forgot to mention: Tested with Python2.5b1 (official
binary releases) on Windows XP and on Mac OS tiger.
msg28939 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2006-06-30 06:07
Logged In: YES 
user_id=33168

Shutdown should not be mandatory.

I can reproduce the same behaviour under linux.  This is new
breakage in 2.5 and needs to be fixed.
msg28940 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-06-30 16:34
Logged In: YES 
user_id=21627

The problem is that _socketobject.close fails to set
recv_into and recvfrom_into to _dummy.

The real problem seems to me that close relies on 
refcounting to close the underlying socket object. I think 
it should first call self._sock.close() before releasing
it.

Also, a test case should be added that the socket object
really does go away after close, e.g. in the form

 native_socket = s._sock
 s.close()
 assert sys.getrefcount(native_socket) == 2
msg28941 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2006-07-01 08:22
Logged In: YES 
user_id=33168

The attached patch fixes the problem for me.  It includes a
test.  If no one gets to it in the next few days, I'll apply it.

It could be augmented with Martin's suggestion to check the
refcount.
msg28942 - (view) Author: Matt Fleming (splitscreen) Date: 2006-07-01 14:47
Logged In: YES 
user_id=1126061

The patch fixes the problem for me too, on NetBSD 3.0, 

revision 47189.

Thanks, Matt
msg28943 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-07-01 15:37
Logged In: YES 
user_id=21627

I committed this as r47190. Adding my test is pointless in
the current state: the test already passes only if the
socket gets released by .close.

The refcount test would have been useful if there was an
explicit self._sock.close() call in close. I tried adding
one, but that would not work because you then can't call
close multiple times anymore.
msg28944 - (view) Author: Irmen de Jong (irmen) (Python triager) Date: 2006-07-01 20:44
Logged In: YES 
user_id=129426

I updated to latest svn and my code works again now.
Thanks for fixing this in such short notice. 
History
Date User Action Args
2022-04-11 14:56:18adminsetgithub: 43559
2006-06-27 09:54:14irmencreate