[ python-Bugs-1685000 ] DoS asyncore vulnerability
Bugs item #1685000, was opened at 2007-03-21 10:15 Message generated for change (Comment added) made by billiejoex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685000&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 Library Group: Python 2.5 Status: Open Resolution: None >Priority: 9 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Nobody/Anonymous (nobody) Summary: DoS asyncore vulnerability Initial Comment: DoS asyncore vulnerability asyncore, independently if used with select() or poll(), suffers a DoS-type vulnerability when a high number of simultaneous connections to handle simultaneously is reached. The number of maximum connections is system-dependent as well as the type of error raised. I attached two simple Proof of Concept scripts demonstrating such bug. If you want to try the behaviours listed below run the attached "asyncore_server.py" and "asyncore_client.py" scripts on your local workstation. On my Windows XP system (Python 2.5), independently if asyncore has been used to develop a server or a client, the error is raised by select() inside asyncore's "poll" function when 512 (socket_map's elements) simultaneous connections are reached. Here's the traceback I get: [...] connections: 510 connections: 511 connections: 512 Traceback (most recent call last): File "C:\scripts\asyncore_server.py", line 38, in asyncore.loop() File "C:\Python25\lib\asyncore.py", line 191, in loop poll_fun(timeout, map) File "C:\Python25\lib\asyncore.py", line 121, in poll r, w, e = select.select(r, w, e, timeout) ValueError: too many file descriptors in select() On my Linux Ubuntu 6.10 (kernel 2.6.17-10, Python 2.5) different type of errors are raised depending on the application (client or server). In an asyncore-based client the error is raised by socket module (dispatcher's "self.socket" attribute) inside 'connect' method of 'dispatcher' class: [...] connections: 1018 connections: 1019 connections: 1020 connections: 1021 Traceback (most recent call last): File "asyncore_client.py", line 31, in File "asyncore.py", line 191, in loop File "asyncore.py", line 138, in poll File "asyncore.py", line 80, in write File "asyncore.py", line 76, in write File "asyncore.py", line 395, in handle_write_event File "asyncore_client.py", line 24, in handle_connect File "asyncore_client.py", line 9, in __init__ File "asyncore.py", line 257, in create_socket File "socket.py", line 156, in __init__ socket.error: (24, 'Too many open files') On an asyncore-based server the error is raised by socket module (dispatcher's "self.socket" attribute) inside 'accept' method of 'dispatcher' class: [...] connections: 1019 connections: 1020 connections: 1021 Traceback (most recent call last): File "asyncore_server.py", line 38, in File "asyncore.py", line 191, in loop File "asyncore.py", line 132, in poll File "asyncore.py", line 72, in read File "asyncore.py", line 68, in read File "asyncore.py", line 384, in handle_read_event File "asyncore_server.py", line 16, in handle_accept File "asyncore.py", line 321, in accept File "socket.py", line 170, in accept socket.error: (24, 'Too many open files') -- >Comment By: billiejoex (billiejoex) Date: 2007-04-06 14:10 Message: Logged In: YES user_id=1357589 Originator: YES > Putting a try/except in place doesn't really help the problem... > if you fail to create a new socket what action will you take? Calling a new dispatcher's method (for example: "handle_exceeded_connection") could be an idea. By default it could close the current session but it can be overriden if the user want to take some other action. > A better approach is to have a configurable limit on the number of > open connections, and then have a server-specific reaction to > exceeding that limit. It doesn't work if I create additional file-objects during the execution of the loop... -- Comment By: Santiago Gala (sgala) Date: 2007-04-06 01:09 Message: Logged In: YES user_id=178886 Originator: NO THe limit of resources that an OS can deal with is limited due to resources, both globally and per user, precisely to avoid DoS attacks by a uses. In the case of linux, you can control it with "ulimit -n " (for the user that runs the test). The default here is 1024 (and the maximum, unless it is globally raised). I imagine windows will have similar limits, and similar (registry, etc.) ways to handle them. -- Comment By: Sam Rushing (rushing) Date: 2007-03-30 19:22 Message: Logged In: YES user_id=73736 Originator: NO Turns out medusa doesn't
[ python-Bugs-1685000 ] asyncore DoS vulnerability
Bugs item #1685000, was opened at 2007-03-21 10:15 Message generated for change (Settings changed) made by billiejoex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685000&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 Library Group: Python 2.5 Status: Open Resolution: None Priority: 9 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Nobody/Anonymous (nobody) >Summary: asyncore DoS vulnerability Initial Comment: DoS asyncore vulnerability asyncore, independently if used with select() or poll(), suffers a DoS-type vulnerability when a high number of simultaneous connections to handle simultaneously is reached. The number of maximum connections is system-dependent as well as the type of error raised. I attached two simple Proof of Concept scripts demonstrating such bug. If you want to try the behaviours listed below run the attached "asyncore_server.py" and "asyncore_client.py" scripts on your local workstation. On my Windows XP system (Python 2.5), independently if asyncore has been used to develop a server or a client, the error is raised by select() inside asyncore's "poll" function when 512 (socket_map's elements) simultaneous connections are reached. Here's the traceback I get: [...] connections: 510 connections: 511 connections: 512 Traceback (most recent call last): File "C:\scripts\asyncore_server.py", line 38, in asyncore.loop() File "C:\Python25\lib\asyncore.py", line 191, in loop poll_fun(timeout, map) File "C:\Python25\lib\asyncore.py", line 121, in poll r, w, e = select.select(r, w, e, timeout) ValueError: too many file descriptors in select() On my Linux Ubuntu 6.10 (kernel 2.6.17-10, Python 2.5) different type of errors are raised depending on the application (client or server). In an asyncore-based client the error is raised by socket module (dispatcher's "self.socket" attribute) inside 'connect' method of 'dispatcher' class: [...] connections: 1018 connections: 1019 connections: 1020 connections: 1021 Traceback (most recent call last): File "asyncore_client.py", line 31, in File "asyncore.py", line 191, in loop File "asyncore.py", line 138, in poll File "asyncore.py", line 80, in write File "asyncore.py", line 76, in write File "asyncore.py", line 395, in handle_write_event File "asyncore_client.py", line 24, in handle_connect File "asyncore_client.py", line 9, in __init__ File "asyncore.py", line 257, in create_socket File "socket.py", line 156, in __init__ socket.error: (24, 'Too many open files') On an asyncore-based server the error is raised by socket module (dispatcher's "self.socket" attribute) inside 'accept' method of 'dispatcher' class: [...] connections: 1019 connections: 1020 connections: 1021 Traceback (most recent call last): File "asyncore_server.py", line 38, in File "asyncore.py", line 191, in loop File "asyncore.py", line 132, in poll File "asyncore.py", line 72, in read File "asyncore.py", line 68, in read File "asyncore.py", line 384, in handle_read_event File "asyncore_server.py", line 16, in handle_accept File "asyncore.py", line 321, in accept File "socket.py", line 170, in accept socket.error: (24, 'Too many open files') -- Comment By: billiejoex (billiejoex) Date: 2007-04-06 14:10 Message: Logged In: YES user_id=1357589 Originator: YES > Putting a try/except in place doesn't really help the problem... > if you fail to create a new socket what action will you take? Calling a new dispatcher's method (for example: "handle_exceeded_connection") could be an idea. By default it could close the current session but it can be overriden if the user want to take some other action. > A better approach is to have a configurable limit on the number of > open connections, and then have a server-specific reaction to > exceeding that limit. It doesn't work if I create additional file-objects during the execution of the loop... -- Comment By: Santiago Gala (sgala) Date: 2007-04-06 01:09 Message: Logged In: YES user_id=178886 Originator: NO THe limit of resources that an OS can deal with is limited due to resources, both globally and per user, precisely to avoid DoS attacks by a uses. In the case of linux, you can control it with "ulimit -n " (for the user that runs the test). The default here is 1024 (and the maximum, unless it is globally raised). I imagine windows will have similar limits, and similar (registry, etc.) ways to handle them. -- Comment By: Sam Rushing (rushing) Date: 2007-03-30 19:22 Message: Logged In: YES user_id=73736 Originator: NO Turns out medusa doesn'
[ python-Bugs-1695688 ] Unexpected feature vs. integer and True values
Bugs item #1695688, was opened at 2007-04-06 15:28 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=1695688&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: [EMAIL PROTECTED] (bacademy) Assigned to: Nobody/Anonymous (nobody) Summary: Unexpected feature vs. integer and True values Initial Comment: Integer 1 interpreted as True. I didn't expect the following: Python 2.5 (r25:51908, Apr 4 2007, 10:19:35) [GCC 4.1.1 20060724 (prerelease) (4.1.1-3mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> v = 2 >>> 0.0 if v == True else float(v) 2.0 >>> v = 1 >>> 0.0 if v == True else float(v) 0.0 I know how to fix this, by writing 0.0 if v is True else float(v) but to casual observer it is not obvious... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1695688&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1695179 ] Failure to build on AIX 5.3
Bugs item #1695179, was opened at 2007-04-05 11:45 Message generated for change (Settings changed) made by tiriss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1695179&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: None Group: None >Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: Jaman Swearingen (tiriss) Assigned to: Nobody/Anonymous (nobody) Summary: Failure to build on AIX 5.3 Initial Comment: AIX 5.3.0.0 gcc 4.0.0 tk8.4 tcl8.4 xlc_r 6.0.0 cc_r 6.0.0 Regardless of which of the compilers I use gcc, xlc_r, or cc_r, I get the following error after I hit make: creating build/temp.aix-5.3-2.5/opt/freeware/src/packages/Python-2.5/Modules gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/opt/freeware/src/packages/Python-2.5/./Include -I./Include -I. -I/usr/local/include -I/opt/freeware/src/packages/Python-2.5/Include -I/opt/freeware/src/packages/Python-2.5 -c /opt/freeware/src/packages/Python-2.5/Modules/_struct.c -o build/temp.aix-5.3-2.5/opt/freeware/src/packages/Python-2.5/Modules/_struct.o creating build/lib.aix-5.3-2.5 ./Modules/ld_so_aix gcc -pthread -bI:Modules/python.exp build/temp.aix-5.3-2.5/opt/freeware/src/packages/Python-2.5/Modules/_struct.o -L/usr/local/lib -lpython2.5 -o build/lib.aix-5.3-2.5/_struct.so collect2: library libpython2.5 not found *** WARNING: renaming "_struct" since importing it failed: 0509-022 Cannot load module build/lib.aix-5.3-2.5. 0509-026 System error: A file or directory in the path name does not exist. error: No such file or directory For some reason when I use xlc_r or gcc, it fails to find the local libpython2.5.a library that is residing in the current directory. When I use cc_r, it fails to find libtcl8.4.so and libtk8.4.so even though there are copies of those in the local . directory. Any help would be appreciated. Here are the configures I used: ./configure --with-gcc="xlc_r -q64" --with-cxx="xlC_r -q64" \ --disable-ipv6 AR="ar -X64" --enable-shared or ./configure --with-gcc --with-cxx=g++ \ --disable-ipv6 --enable-shared or configure --disable-ipv6 Let me know if there is other information you need. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1695179&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1695718 ] PEP 302 broken
Bugs item #1695718, was opened at 2007-04-06 12:32 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=1695718&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: 5 Private: No Submitted By: phil (philipdumont) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 302 broken Initial Comment: The product I'm working on uses a PEP 302 importer hook. It's a home-grown ltihooks clone. (We don't use ltihooks because it's GPLed, and we don't want to be.) Our importer worked on 2.4.3, is broken on 2.5.0. What's broken is that if the hook's find_module() method returns None for a given module name, say 'spam', then that is supposed to cause the import machinery to fall back on the regular unhooked import behavior -- that is, find 'spam.py' (or 'spam.pyc', 'spam.pyo') in the directory in question. This used to be what happened, but no longer. Tracing through the code, the problem seems to be occurring due to the 'continue' at line 1289 (in the 2.5 tarball) of Python/import.c. Slogging through SVN (aside: this would have been easier if your ViewSVN supported annotate/blame -- any chance you could add that?), it appears that the offending continue statement was added in revision 46372, whose checkin comment claims that it was done for performance reasons. I'm all for performance improvements, but not at the expense of breakage. Attached is a tarball with some files that reproduce the problem. (The LibtoolImporter.py file is a stripped-down toy version of what we are really using.) Unwind the tarball, cd to the directory, and run script.py. Here's what I get: shell prompt> pwd /home/phil/pep302_bug shell prompt> ls -CF eggs.la LibtoolImporter.py script.py* spam.py shell prompt> python2.4.3 script.py .la file(s) found in /home/phil/pep302_bug, LibtoolImporter will be used. LibtoolImporter.find_module() couldn't find spam.la or spammodule.la in /home/phil/pep302_bug. Returning None. This is *supposed* to cause a fallback to the default import code looking for spam.py in /home/phil/pep302_bug module spam loaded shell prompt> python2.5 script.py .la file(s) found in /home/phil/pep302_bug, LibtoolImporter will be used. LibtoolImporter.find_module() couldn't find spam.la or spammodule.la in /home/phil/pep302_bug. Returning None. This is *supposed* to cause a fallback to the default import code looking for spam.py in /home/phil/pep302_bug Traceback (most recent call last): File "script.py", line 4, in import spam ImportError: No module named spam shell prompt> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1695718&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1695688 ] Unexpected feature vs. integer and True values
Bugs item #1695688, was opened at 2007-04-06 15:28 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1695688&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: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: [EMAIL PROTECTED] (bacademy) Assigned to: Nobody/Anonymous (nobody) Summary: Unexpected feature vs. integer and True values Initial Comment: Integer 1 interpreted as True. I didn't expect the following: Python 2.5 (r25:51908, Apr 4 2007, 10:19:35) [GCC 4.1.1 20060724 (prerelease) (4.1.1-3mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> v = 2 >>> 0.0 if v == True else float(v) 2.0 >>> v = 1 >>> 0.0 if v == True else float(v) 0.0 I know how to fix this, by writing 0.0 if v is True else float(v) but to casual observer it is not obvious... -- >Comment By: Georg Brandl (gbrandl) Date: 2007-04-06 18:01 Message: Logged In: YES user_id=849994 Originator: NO It may be, but it is not a bug (bool inherits from int) and documented (I think...). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1695688&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1695718 ] PEP 302 broken
Bugs item #1695718, was opened at 2007-04-06 11:32 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1695718&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: 6 Private: No Submitted By: phil (philipdumont) >Assigned to: Georg Brandl (gbrandl) Summary: PEP 302 broken Initial Comment: The product I'm working on uses a PEP 302 importer hook. It's a home-grown ltihooks clone. (We don't use ltihooks because it's GPLed, and we don't want to be.) Our importer worked on 2.4.3, is broken on 2.5.0. What's broken is that if the hook's find_module() method returns None for a given module name, say 'spam', then that is supposed to cause the import machinery to fall back on the regular unhooked import behavior -- that is, find 'spam.py' (or 'spam.pyc', 'spam.pyo') in the directory in question. This used to be what happened, but no longer. Tracing through the code, the problem seems to be occurring due to the 'continue' at line 1289 (in the 2.5 tarball) of Python/import.c. Slogging through SVN (aside: this would have been easier if your ViewSVN supported annotate/blame -- any chance you could add that?), it appears that the offending continue statement was added in revision 46372, whose checkin comment claims that it was done for performance reasons. I'm all for performance improvements, but not at the expense of breakage. Attached is a tarball with some files that reproduce the problem. (The LibtoolImporter.py file is a stripped-down toy version of what we are really using.) Unwind the tarball, cd to the directory, and run script.py. Here's what I get: shell prompt> pwd /home/phil/pep302_bug shell prompt> ls -CF eggs.la LibtoolImporter.py script.py* spam.py shell prompt> python2.4.3 script.py .la file(s) found in /home/phil/pep302_bug, LibtoolImporter will be used. LibtoolImporter.find_module() couldn't find spam.la or spammodule.la in /home/phil/pep302_bug. Returning None. This is *supposed* to cause a fallback to the default import code looking for spam.py in /home/phil/pep302_bug module spam loaded shell prompt> python2.5 script.py .la file(s) found in /home/phil/pep302_bug, LibtoolImporter will be used. LibtoolImporter.find_module() couldn't find spam.la or spammodule.la in /home/phil/pep302_bug. Returning None. This is *supposed* to cause a fallback to the default import code looking for spam.py in /home/phil/pep302_bug Traceback (most recent call last): File "script.py", line 4, in import spam ImportError: No module named spam shell prompt> -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-06 14:21 Message: Logged In: YES user_id=80475 Originator: NO Georg, I believe this was your checkin. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1695718&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1695688 ] Unexpected feature vs. integer and True values
Bugs item #1695688, was opened at 2007-04-06 15:28 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1695688&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: None Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: [EMAIL PROTECTED] (bacademy) Assigned to: Nobody/Anonymous (nobody) Summary: Unexpected feature vs. integer and True values Initial Comment: Integer 1 interpreted as True. I didn't expect the following: Python 2.5 (r25:51908, Apr 4 2007, 10:19:35) [GCC 4.1.1 20060724 (prerelease) (4.1.1-3mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> v = 2 >>> 0.0 if v == True else float(v) 2.0 >>> v = 1 >>> 0.0 if v == True else float(v) 0.0 I know how to fix this, by writing 0.0 if v is True else float(v) but to casual observer it is not obvious... -- >Comment By: Georg Brandl (gbrandl) Date: 2007-04-06 20:56 Message: Logged In: YES user_id=849994 Originator: NO It may be, but it is not a bug (bool inherits from int) and documented (I think...). -- Comment By: Georg Brandl (gbrandl) Date: 2007-04-06 18:01 Message: Logged In: YES user_id=849994 Originator: NO It may be, but it is not a bug (bool inherits from int) and documented (I think...). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1695688&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1694663 ] Overloading int.__pow__ does not work
Bugs item #1694663, was opened at 2007-04-05 01:44 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1694663&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: None Group: Python 2.5 Status: Open Resolution: None Priority: 3 Private: No Submitted By: Terry J. Reedy (tjreedy) Assigned to: Raymond Hettinger (rhettinger) Summary: Overloading int.__pow__ does not work Initial Comment: >From c.l.p: in response to glitch report, 2nd person showed that it is >specific to __pow__ >>> class MyInt(int): ... __sub__ = int.__add__ # similar lines for 9 other methods omitted ... __or__ = int.__add__ ... __pow__ = int.__add__ ... >>> i = MyInt(42) >>> i + 3 45 >>> i - 3 45 # similar outputs omitted >>> i | 3 45 >>> i ** 3 74088 Another person (3rd) confirmed presence in 2.5 Python 2.5 (r25:51908, Jan 21 2007, 03:10:25) [GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] -- >Comment By: Ziga Seilnacht (zseil) Date: 2007-04-07 01:27 Message: Logged In: YES user_id=1326842 Originator: NO Hi Raymond, The problem is not in conversion functions, but in slot inheritance. If you run the example under a debugger you can see that MyInt->tp_as_number->nb_power == int->->tp_as_number->nb_power. This happens because update_one_slot() doesn't fall back to the generic slot function if a SlotWrapper in type's dict has a different conversion function or if it comes from an unrelated type. The patch simply falls back to the generic slot function in this case. -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-05 06:54 Message: Logged In: YES user_id=80475 Originator: NO I'll take a look at your patch. The root problem is that the wrapper functions will return NULL if they are fed the wrong number of arguments (i.e. the int.__add__ wrapper expects exactly two arguments but the ** call provides three) -- you will see a similar result if int.__neg__ or int.__invert__ are assigned to __add__. It looks like an upstream step is seeing the NULL and deciding that it needs to look to skip the given method call and instead try the base the class. Am lowering the priority because there is no good use case for deliberate argument mismatches in the override. Am leaving the bug open because we want the appropriate error message to surface. -- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-05 03:47 Message: Logged In: YES user_id=1326842 Originator: NO Here is a patch (with tests) that should fix this. There was another problem when the slot wrapper came from a different type: >>> class MyInt(int): ... __mul__ = float.__add__ ... >>> MyInt(3) * 3 9 This now raises a TypeError. File Added: mixing_slots.diff -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1694663&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1695948 ] logging.handlers.SocketHandler.makeSocket() blocks app
Bugs item #1695948, was opened at 2007-04-07 14:22 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=1695948&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 Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: jtdeng (jtdeng) Assigned to: Nobody/Anonymous (nobody) Summary: logging.handlers.SocketHandler.makeSocket() blocks app Initial Comment: Python Version: === Any Python Version OS Platform: Debian Linux 2.6.8-2-386 #1 Tue Aug 16 12:46:35 UTC 2005 i686 GNU/Linux Windows XP SP2 Problem: Member function makeSocket() of logging.handlers.SocketHandler creates a socket with no default timeout, and this may block the app on Linux. def makeSocket(self): """ A factory method which allows subclasses to define the precise type of socket they want. """ s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((self.host, self.port)) return s if the log receiver on the destination host is not running, the log sender will block the app on socket.connect(), but on windows, socket.connect() will return immediately. So I propose to provide a default timeout value for makeSocket() like below: def makeSocket(self, timeout=1): """ A factory method which allows subclasses to define the precise type of socket they want. """ s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(timeout) s.connect((self.host, self.port)) return s -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1695948&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
