Bugs item #1019808, was opened at 2004-08-31 12:18 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Federico Schwindt (fgsch) Assigned to: A.M. Kuchling (akuchling) Summary: wrong socket error returned Initial Comment: hi, first, background: OS: OpenBSD-current/i386 Python version: 2.3.4 example script: import socket socket.setdefaulttimeout(30) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('127.0.0.1', 9999)) where nothing is listening on 9999 (ECONNREFUSED should be returned). when ran it i get: Traceback (most recent call last): File "bug.py", line 8, in ? s.connect(('127.0.0.1', 9999)) File "<string>", line 1, in connect socket.error: (22, 'Invalid argument') this is a problem in the socketmodule.c, in the internal_connect() function. getsockopt with SOCK_ERROR should be used once EINPROGRESS is returned to get the real error. this code works on linux, but the connect semantic is, imho, broken. you cannot reuse a socket once it failed (a test afterwards shown that this is valid under linux!!!!). please contact me if you need further details, although i find this very clear. thanks, f.- ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-08 08:15 Message: Logged In: YES user_id=11375 I agree -- this sort of Unix-platform-specific bugfix is always risky. It would have been better if this patch could have been committed in one of the alphas. I'll put this bug in the Python 2.6 group and commit it after 2.5final is released (perhaps it can also go on the release25-maint branch at that time). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-04 01:34 Message: Logged In: YES user_id=33168 Andrew, I'm ok with this patch, but not enthusiastic for 2.5. It might be better to wait for 2.5.1 in order to give this more time to settle. I agree that this change *should* be correct, but who knows if it will break some other platform(s). I leave it to you whether to apply for 2.5 or 2.5.1. It would be good to actually test this condition too. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 10:31 Message: Logged In: YES user_id=11375 Deleting broken patches; attaching a correct version against 2.5 trunk. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 10:18 Message: Logged In: YES user_id=11375 I can confirm the bug on MacOS X, and the failure of the patch to fix it. I think the logic of the patch is wrong; it saves errno in save_errno when errno==EINPROGRESS, does a getsockopt(), and then resets errno to save_errno, which we know is EINPROGRESS. I think the correct action is to do 'errno = <result of the getsockopt>". Revised patch attached; it produces the correct result on OS X. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 10:15 Message: Logged In: YES user_id=11375 I can confirm the bug on MacOS X, and the failure of the patch to fix it. I think the logic of the patch is wrong; it saves errno in save_errno when errno==EINPROGRESS, does a getsockopt(), and then resets errno to save_errno, which we know is EINPROGRESS. I think the correct action is to do 'errno = <result of the getsockopt>". Revised patch attached; it produces the correct result on OS X. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 10:14 Message: Logged In: YES user_id=11375 I can confirm the bug on MacOS X, and the failure of the patch to fix it. I think the logic of the patch is wrong; it saves errno in save_errno when errno==EINPROGRESS, does a getsockopt(), and then resets errno to save_errno, which we know is EINPROGRESS. I think the correct action is to do 'errno = <result of the getsockopt>". Revised patch attached; it produces the correct result on OS X. ---------------------------------------------------------------------- Comment By: Frank Vercruesse (vercruesse) Date: 2006-02-17 15:46 Message: Logged In: YES user_id=202246 I can confirm the bug running Python 2.4.2 on Mac OS X 10.4.5 (PPC). However, the patch doesn't seem to resolve the issue. Now I get the following traceback when running the posted script: Traceback (most recent call last): File "<stdin>", line 1, in ? File "<string>", line 1, in connect socket.error: (36, 'Operation now in progress') ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2005-10-03 15:44 Message: Logged In: YES user_id=50493 patch against 2.4.1 appended. not tested in anything but openbsd. nevertheless, i think it should work in linux and osx. not sure about others. cheers. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 02:02 Message: Logged In: YES user_id=33168 Can you provide a patch that you believe corrects this problem? ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2005-06-24 05:41 Message: Logged In: YES user_id=50493 just tried this with 2.4.1 running in OpenBSD 3.7/amd64 and the problem is still there :-( ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2004-09-22 23:58 Message: Logged In: YES user_id=50493 any news? this may be a problem in other *BSDs as well.. ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2004-08-31 12:22 Message: Logged In: YES user_id=50493 maybe i was not clear. the problem is only happening when setdefaulttimeout is used. otherwise ECONNREFUSED is correctly returned. f.- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com