[ python-Bugs-1428264 ] Crash on invalid coding pragma
Bugs item #1428264, was opened at 2006-02-09 21:07 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=1428264&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.4 Status: Open Resolution: None Priority: 5 Submitted By: ocean-city (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: Crash on invalid coding pragma Initial Comment: Hi. Attached script crashes my Python2.4.2. Note that "xxx" is not valid code name. I'm using Win2000SP4, downloaded python msi package from python.org. Thank you. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1428264&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1428264 ] Crash on invalid coding pragma
Bugs item #1428264, was opened at 2006-02-09 21:07 Message generated for change (Comment added) made by ocean-city You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1428264&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.4 Status: Closed Resolution: Out of Date Priority: 5 Submitted By: ocean-city (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: Crash on invalid coding pragma Initial Comment: Hi. Attached script crashes my Python2.4.2. Note that "xxx" is not valid code name. I'm using Win2000SP4, downloaded python msi package from python.org. Thank you. -- >Comment By: ocean-city (ocean-city) Date: 2006-02-09 21:29 Message: Logged In: YES user_id=1200846 Thank you. I'll wait for next release. :-) -- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-09 21:13 Message: Logged In: YES user_id=1188172 This is fixed in Subversion. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1428264&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1428264 ] Crash on invalid coding pragma
Bugs item #1428264, was opened at 2006-02-09 13:07 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1428264&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.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: ocean-city (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: Crash on invalid coding pragma Initial Comment: Hi. Attached script crashes my Python2.4.2. Note that "xxx" is not valid code name. I'm using Win2000SP4, downloaded python msi package from python.org. Thank you. -- >Comment By: Georg Brandl (birkenfeld) Date: 2006-02-09 13:13 Message: Logged In: YES user_id=1188172 This is fixed in Subversion. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1428264&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-876637 ] Random stack corruption from socketmodule.c
Bugs item #876637, was opened at 2004-01-14 06:41 Message generated for change (Comment added) made by arkadini You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=876637&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.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Mike Pall (mikesfpy) Assigned to: Neal Norwitz (nnorwitz) Summary: Random stack corruption from socketmodule.c Initial Comment: THE PROBLEM: The implementation of the socket_object.settimeout() method (socketmodule.c, function internal_select()) uses the select() system call with an unbounded file descriptor number. This will cause random stack corruption if fd>=FD_SETSIZE. This took me ages to track down! It happened with a massively multithreaded and massively connection-swamped network server. Basically most of the descriptors did not use that routine (because they were either pure blocking or pure non-blocking). But one module used settimeout() and with a little bit of luck got an fd>=FD_SETSIZE and with even more luck corrupted the stack and took down the whole server process. Demonstration script appended. THE SOLUTION: The solution is to use poll() and to favour poll() even if select() is available on a platform. The current trend in modern OS+libc combinations is to emulate select() in libc and call kernel-level poll() anyway. And this emulation is costly (both for the caller and for libc). Not so the other way round (only some systems of historical interest do that BTW), so we definitely want to use poll() if it's available (even if it's an emulation). And if select() is your only choice, then check for FD_SETSIZE before using the FD_SET macro (and raise some strange exception if that fails). [ I should note that using SO_RCVTIMEO and SO_SNDTIMEO would be a lot more efficient (kernel-wise at least). Unfortunately they are not universally available (though defined by most system header files). But a simple runtime test with a fallback to poll()/select() would do. ] A PATCH, A PATCH? Well, the check for FD_SETSIZE is left as an exercise for the reader. :-) Don't forget to merge this with the stray select() way down by adding a return value to internal_select(). But yes, I can do a 'real' patch with poll() [and even one with the SO_RCVTIMEO trick if you are adventurous]. But, I can't test it with dozens of platforms, various include files, compilers and so on. So, dear Python core developers: Please discuss this and tell me, if you want a patch, then you'll get one ASAP. Thank you for your time! -- Comment By: Arek Korbik (arkadini) Date: 2006-02-09 15:20 Message: Logged In: YES user_id=1346917 Unfortunately r42253 breaks things on win32 (at least on my machine). By default FD_SETSIZE is 64 (winsock.h, winsock2.h). Even if the check from select module WAS included, that would end up in 512. Most of the time, first socket I create after starting python gets a fd > 900. What is a reasonable value for FD_SETSIZE then? 1024? Compared to the default value of 64 doesn't look that reasonable, though... Are there plans to "elaborate" on the last fix? -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-07 07:18 Message: Logged In: YES user_id=33168 Thanks! Committed revision 42253. Committed revision 42254. (2.4) -- Comment By: Troels Walsted Hansen (troels) Date: 2004-06-10 12:15 Message: Logged In: YES user_id=32863 I have created a patch to make socketmodule use poll() when available. See http://python.org/sf/970288 (I'm not allowed to attach patches to this bug item.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=876637&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1428789 ] add /usr/local support
Bugs item #1428789, was opened at 2006-02-09 20:55 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=1428789&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: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karol Pietrzak (noodlez84) Assigned to: Nobody/Anonymous (nobody) Summary: add /usr/local support Initial Comment: Generally, /usr/local support needs to be added for python. Many distributions already do this, either partially or completely, causing inconsistencies between Python installations among Linux distributions. 1. There should be a site-packages directory in /usr/local, probably /usr/local/lib/python/site-packages. Just like in /usr, it'll need the appropriate symlinks. x86_64 bit issues also need to be taken into account, so /usr/local/lib64/python2.4/site-packages should be the local site-packages directory for Python 2.4.x on a x86_64 machine. The reasons for these are numerous. $PATH contains /usr/local/bin, $GTK_PATH contains /usr/local, $MANPATH contains /usr/local/share/man, and $PKG_CONFIG_PATH contains /usr/local/lib/pkgconfig. Adding a site-packages directory in /usr/local will simply fill in the hole in the Python configuration. As the FHS points out, /usr may very well be mounted read-only for security purposes. /usr/local should be used instead, especially for non-system / testing software. 2. Distutils should install, by default, in the site-packages directory in /usr/local described in part (1). This will simply mimic the auto(conf| make|etc.) default installation path (isn't the default installation path for Python itself /usr/local?). For simplicity and consistency's sake, the default installation path for distutils should be the site-packages directory in /usr/local. If someone would point me in the right direction, I will gladly write the patch myself. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1428789&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-876637 ] Random stack corruption from socketmodule.c
Bugs item #876637, was opened at 2004-01-14 01:41 Message generated for change (Comment added) made by geekmug You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=876637&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.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Mike Pall (mikesfpy) Assigned to: Neal Norwitz (nnorwitz) Summary: Random stack corruption from socketmodule.c Initial Comment: THE PROBLEM: The implementation of the socket_object.settimeout() method (socketmodule.c, function internal_select()) uses the select() system call with an unbounded file descriptor number. This will cause random stack corruption if fd>=FD_SETSIZE. This took me ages to track down! It happened with a massively multithreaded and massively connection-swamped network server. Basically most of the descriptors did not use that routine (because they were either pure blocking or pure non-blocking). But one module used settimeout() and with a little bit of luck got an fd>=FD_SETSIZE and with even more luck corrupted the stack and took down the whole server process. Demonstration script appended. THE SOLUTION: The solution is to use poll() and to favour poll() even if select() is available on a platform. The current trend in modern OS+libc combinations is to emulate select() in libc and call kernel-level poll() anyway. And this emulation is costly (both for the caller and for libc). Not so the other way round (only some systems of historical interest do that BTW), so we definitely want to use poll() if it's available (even if it's an emulation). And if select() is your only choice, then check for FD_SETSIZE before using the FD_SET macro (and raise some strange exception if that fails). [ I should note that using SO_RCVTIMEO and SO_SNDTIMEO would be a lot more efficient (kernel-wise at least). Unfortunately they are not universally available (though defined by most system header files). But a simple runtime test with a fallback to poll()/select() would do. ] A PATCH, A PATCH? Well, the check for FD_SETSIZE is left as an exercise for the reader. :-) Don't forget to merge this with the stray select() way down by adding a return value to internal_select(). But yes, I can do a 'real' patch with poll() [and even one with the SO_RCVTIMEO trick if you are adventurous]. But, I can't test it with dozens of platforms, various include files, compilers and so on. So, dear Python core developers: Please discuss this and tell me, if you want a patch, then you'll get one ASAP. Thank you for your time! -- Comment By: Scott Dial (geekmug) Date: 2006-02-10 00:12 Message: Logged In: YES user_id=383208 The patch that has been applied has no relevance to Windows and should not be used when compiling for Windows. The use of an internal counter to assign descriptors to the fd_set array avoids the problem noted here so there is no such bug on Windows. Futhermore, as Arek notes, Windows creates descriptor numbers with no bound. -- Comment By: Arek Korbik (arkadini) Date: 2006-02-09 10:20 Message: Logged In: YES user_id=1346917 Unfortunately r42253 breaks things on win32 (at least on my machine). By default FD_SETSIZE is 64 (winsock.h, winsock2.h). Even if the check from select module WAS included, that would end up in 512. Most of the time, first socket I create after starting python gets a fd > 900. What is a reasonable value for FD_SETSIZE then? 1024? Compared to the default value of 64 doesn't look that reasonable, though... Are there plans to "elaborate" on the last fix? -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-07 02:18 Message: Logged In: YES user_id=33168 Thanks! Committed revision 42253. Committed revision 42254. (2.4) -- Comment By: Troels Walsted Hansen (troels) Date: 2004-06-10 06:15 Message: Logged In: YES user_id=32863 I have created a patch to make socketmodule use poll() when available. See http://python.org/sf/970288 (I'm not allowed to attach patches to this bug item.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=876637&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
