[ python-Bugs-1513223 ] socket close() hangs client if used without prior shutdown()
Bugs item #1513223, was opened at 2006-06-27 02:54 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513223&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: socket close() hangs client if used without prior shutdown() Initial Comment: 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). -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-01 01:22 Message: 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. -- Comment By: Martin v. Löwis (loewis) Date: 2006-06-30 09:34 Message: 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 -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-29 23:07 Message: 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. -- Comment By: Irmen de Jong (irmen) Date: 2006-06-27 02:55 Message: 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. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513223&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1515471 ] wrong handling of character buffers in stringobject
Bugs item #1515471, was opened at 2006-07-01 09:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515471&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Georg Brandl (gbrandl)
Assigned to: Fredrik Lundh (effbot)
Summary: wrong handling of character buffers in stringobject
Initial Comment:
stringobject.c:
In string_replace, there is
if (PyString_Check(from)) {
/* Can this be made a '!check' after the Unicode
check? */
}
#ifdef Py_USING_UNICODE
if (PyUnicode_Check(from))
return PyUnicode_Replace((PyObject *)self,
from, to, count);
#endif
else if (PyObject_AsCharBuffer(from, &tmp_s, &tmp_len))
return NULL;
[the same check with "to"]
return (PyObject *)replace((PyStringObject *) self,
(PyStringObject *) from,
(PyStringObject *) to, count);
This is not correct if from or to isn't a string
object, but a char buffer compatible object.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515471&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1513223 ] socket close() hangs client if used without prior shutdown()
Bugs item #1513223, was opened at 2006-06-27 09:54 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513223&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: socket close() hangs client if used without prior shutdown() Initial Comment: 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). -- Comment By: Matt Fleming (splitscreen) Date: 2006-07-01 14:47 Message: Logged In: YES user_id=1126061 The patch fixes the problem for me too, on NetBSD 3.0, revision 47189. Thanks, Matt -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-01 08:22 Message: 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. -- Comment By: Martin v. Löwis (loewis) Date: 2006-06-30 16:34 Message: 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 -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-30 06:07 Message: 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. -- Comment By: Irmen de Jong (irmen) Date: 2006-06-27 09:55 Message: 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. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513223&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1513223 ] socket close() hangs client if used without prior shutdown()
Bugs item #1513223, was opened at 2006-06-27 11:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513223&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: socket close() hangs client if used without prior shutdown() Initial Comment: 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). -- >Comment By: Martin v. Löwis (loewis) Date: 2006-07-01 17:37 Message: 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. -- Comment By: Matt Fleming (splitscreen) Date: 2006-07-01 16:47 Message: Logged In: YES user_id=1126061 The patch fixes the problem for me too, on NetBSD 3.0, revision 47189. Thanks, Matt -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-01 10:22 Message: 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. -- Comment By: Martin v. Löwis (loewis) Date: 2006-06-30 18:34 Message: 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 -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-30 08:07 Message: 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. -- Comment By: Irmen de Jong (irmen) Date: 2006-06-27 11:55 Message: 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. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513223&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1296433 ] expat crash python
Bugs item #1296433, was opened at 2005-09-20 10:10
Message generated for change (Comment added) made by fdrake
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296433&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Mike Rozhnov (rozhnov)
Assigned to: Brett Cannon (bcannon)
Summary: expat crash python
Initial Comment:
This simple script crash python.
Parsing of commented xml string work good.
(i.e. raised exception not crash python)
Buffer overflow during convertion to unicode?
Tested on Win XP and linux with kernel 2.4 with same
results.
--
>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-01 12:33
Message:
Logged In: YES
user_id=3066
This is now fixed in the Expat CVS with lib/xmlparse.c
revisions 1.154 and 1.155. I've merged these into the Expat
bundled with Python in revision 47191 (on the trunk), and
moved the crasher test into the tests for xml.parsers.expat.
I don't know when the next Expat release will go out yet,
but this will keep us from being dependent on that schedule.
--
Comment By: Brett Cannon (bcannon)
Date: 2006-06-30 14:06
Message:
Logged In: YES
user_id=357491
The fault is with Expat and not us. I have submitted a bug
report with a possible patch at
http://sourceforge.net/tracker/index.php?func=detail&aid=1515266&group_id=10127&atid=110127
. I don't know what their turn-around time will be with
this so I will email python-dev to see how long people want
to wait on the Expat developers before we just push our own
patch for this.
--
Comment By: Brett Cannon (bcannon)
Date: 2006-06-29 21:33
Message:
Logged In: YES
user_id=357491
Still seems to be failing even with the Expat 2.0 upgrade in
HEAD.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-12 15:53
Message:
Logged In: YES
user_id=33168
I had recently upgraded to expat 1.95.8, so I was hopeful.
But it still crashed for me on linux.
I did get a better stack trace which allowed me to come up
with a patch that solves the problem and passes all the
tests. The patch seems a bit odd and I think there might be
another problem going on here. It would be great if someone
more familiar with xmlparse could take a look at the patch
and figure out if it's right or not.
--
Comment By: Fredrik Lundh (effbot)
Date: 2005-11-12 06:05
Message:
Logged In: YES
user_id=38376
Works for me under 2.3.2 (with expat 1.95.6) and 2.4.1 (with
expat 1.95.8).
Try upgrading your expat and see if the problem goes away.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-22 17:54
Message:
Logged In: YES
user_id=33168
I can reproduce on Linux with current CVS and expat
1.95.5-2. Note the size of the data only needs to be
greater than 1024.
xml = "%s" %
('a' * 1025)
I am not certain this problem is specific to Python. It
might be down in expat only. Need to investigate further.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296433&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
