socket close() hangs client if used without prior shutdown()

[irmen]

BPO	1513223
Nosy	@loewis, @irmen
Files	py25bug.py: socket server to test with socket.diff: v1

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2006-07-01.20:44:21.000>
created_at = <Date 2006-06-27.09:54:14.000>
labels = ['extension-modules']
title = 'socket close() hangs client if used without prior shutdown()'
updated_at = <Date 2006-07-01.20:44:21.000>
user = 'https://github.com/irmen'

bugs.python.org fields:

activity = <Date 2006-07-01.20:44:21.000>
actor = 'irmen'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Extension Modules']
creation = <Date 2006-06-27.09:54:14.000>
creator = 'irmen'
dependencies = []
files = ['2047', '2048']
hgrepos = []
issue_num = 1513223
keywords = []
message_count = 8.0
messages = ['28937', '28938', '28939', '28940', '28941', '28942', '28943', '28944']
nosy_count = 4.0
nosy_names = ['loewis', 'nnorwitz', 'irmen', 'splitscreen']
pr_nums = []
priority = 'high'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1513223'
versions = ['Python 2.5']

[irmen]

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).

[irmen]

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.

[nnorwitz]

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.

[loewis]

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

[nnorwitz]

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.

[splitscreen]

Logged In: YES
user_id=1126061

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

revision 47189.

Thanks, Matt

[loewis]

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.

[irmen]

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.