From noreply@sourceforge.net Sat Dec 1 02:02:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Nov 2001 18:02:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-487317 ] tcl83.dll is corrupt Message-ID: Bugs item #487317, was opened at 2001-11-29 17:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487317&group_id=5470 Category: Installation Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Barry Kumnick (barryk) Assigned to: Tim Peters (tim_one) Summary: tcl83.dll is corrupt Initial Comment: On NT4 SP6, installation of Python-2.1.1.exe fails with an error message saying tcl83.dll is corrupt. The downloaded file size is correct - 6,310,277 bytes. ---------------------------------------------------------------------- >Comment By: Barry Kumnick (barryk) Date: 2001-11-30 18:02 Message: Logged In: YES user_id=389562 I downloaded it from python.org via ftp using the registered version of Download Accelerator Plus (DAP) version 5.0.0.1. This utility simultaneously establishes four different connections to four different mirror sites and merges the files when the download is complete. It also supports suspend and resume. Alas, I don't have a record of the mirror sites the download actually came from. I did have some problems with the TCP connection timing out a couple of times and I had to restart the download. Perhaps that caused some problem. I don't know. I'll try the download using straight ftp from python.org and let you know how it goes. Thanks, Barry Kumnick ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-30 15:50 Message: Logged In: YES user_id=31435 Barry, from exactly where are you downloading the installer? SourceForge? python.org? If the latter, via HTTP or via FTP? Which program are you using to download? It's remotely possible that one of the master copies recently got corrupted, and if you tell me where you're getting it from, I'd be happy to try downloading it myself too. I hate to mention it, but some corporations are known to run firewalls that systematically corrupt binary downloads. ---------------------------------------------------------------------- Comment By: Barry Kumnick (barryk) Date: 2001-11-30 15:11 Message: Logged In: YES user_id=389562 I got the md5sum to work. It is reporting a different checksum than the one you provided, so the downloaded file must have been corrupted. I'll try to download a new copy. Thanks for your help. Barry Kumnick ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-30 14:54 Message: Logged In: YES user_id=31435 It sounds like you were trying to run md5sum with its "-c" switch: don't. Do it like so: C:\Code>\updates\md5sum Python-2.1.1.exe 39ef54d3e29ea402c8b693b4f3fedd4a *Python-2.1.1.exe C:\Code> There are no corrupt files in the installers we ship, so stop trying to pursue that path: you'll just get in worse trouble if you do. Something else is hosed on your system. BTW, you can open the installer (as a file!) in WinZip, and use WinZip's Action -> Test to test for corruption. md5 is a more powerful whole-file check, but the installer saves a CRC code for each individual file and that's what the WinZip Test looks at. If either md5 or WinZip complains, your installer got corrupted during (or maybe even after) downloading. ---------------------------------------------------------------------- Comment By: Barry Kumnick (barryk) Date: 2001-11-30 14:34 Message: Logged In: YES user_id=389562 Hi, Thanks for getting back to me. First I have a correction to make: it was the tk83.dll not the tcl83.dll that was reported as corrupt. Actually, I am running NT 4 Enterprise Server SP6 on a dual processor PIII box. I tried to install on another box running NT 4 Enterprise Server SP5 with a single processor, and got the same error. However, on that machine I was able to keep pressing retry, and the progress bar kept advancing. In fact it went up a few percent every time I pressed the retry button on the error dialog. It continued to advance past 100%. I stopped trying after it got to around 113% and it said the system needed to be rebooted to complete the installation. I did that. Apparently, everything installed except the tk83.dll. I also tried the md5sum.exe application Martin suggested, but it reports: md5sum: Python-2.1.1.exe: no properly formated MD5 checksum lines found. Do you have another suggestion for computing the MD5 checksum? I don't have md5sum.py on my system. BTW: With the current 2.1.1 installation, I was able to get the Python command shell to execute, but when attempting to launch IDLE, it fails with an error message saying the tk83.dll can not be found. Is there somewhere I can download the tk83.dll separately as a workaround? Thanks, Barry Kumnick ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-30 09:43 Message: Logged In: YES user_id=31435 Thanks for finding that program, Martin! This should be received much better than my usual advice to compute MD5 with md5sum.py . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 08:19 Message: Logged In: YES user_id=21627 Can you please verify the md5sum of the file you've downloaded? It is 39ef54d3e29ea402c8b693b4f3fedd4a Python-2.1.1.exe You can get an md5sum executable from http://etree.org/md5com.html ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-29 18:25 Message: Logged In: YES user_id=31435 Tens of thousands of Windows users have run this installer without problems, so-- and especially given your other bug report about 2.2b2 --the presumption has to be that something is uniquely screwed up on the specific box you tried it on. Can you reproduce on another (physically distinct) machine? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487317&group_id=5470 From noreply@sourceforge.net Sat Dec 1 02:07:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Nov 2001 18:07:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-487743 ] test_builtin fails on 64 bit platform Message-ID: Bugs item #487743, was opened at 2001-11-30 18:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487743&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Mark Favas (mfavas) Assigned to: Nobody/Anonymous (nobody) Summary: test_builtin fails on 64 bit platform Initial Comment: test_builtin fails on Tru64 platform with current (1 Dec) version of CVS - traced to following code: CVS of 26 Nov works, CVS of 1 Dec fails *************** older CVS works *************** 201 mark@gonzo python Python 2.2b2+ (#539, Nov 26 2001, 09:52:25) [C] on osf1V4 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> s=-1-sys.maxint >>> d=`s` >>> d '-9223372036854775808' >>> s -9223372036854775808 >>> ^D *************** current CVS fails ***************** 202 mark@gonzo cd dist/src 203 mark@gonzo ./python Python 2.2b2+ (#541, Dec 1 2001, 08:04:58) [C] on osf1V4 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> s=-1-sys.maxint >>> d=`s` >>> d '8t\x10@\x01' >>> s -9223372036854775808 >>> ^D ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487743&group_id=5470 From noreply@sourceforge.net Sat Dec 1 02:44:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Nov 2001 18:44:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-487743 ] test_builtin fails on 64 bit platform Message-ID: Bugs item #487743, was opened at 2001-11-30 18:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487743&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None >Priority: 8 Submitted By: Mark Favas (mfavas) >Assigned to: Tim Peters (tim_one) Summary: test_builtin fails on 64 bit platform Initial Comment: test_builtin fails on Tru64 platform with current (1 Dec) version of CVS - traced to following code: CVS of 26 Nov works, CVS of 1 Dec fails *************** older CVS works *************** 201 mark@gonzo python Python 2.2b2+ (#539, Nov 26 2001, 09:52:25) [C] on osf1V4 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> s=-1-sys.maxint >>> d=`s` >>> d '-9223372036854775808' >>> s -9223372036854775808 >>> ^D *************** current CVS fails ***************** 202 mark@gonzo cd dist/src 203 mark@gonzo ./python Python 2.2b2+ (#541, Dec 1 2001, 08:04:58) [C] on osf1V4 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> s=-1-sys.maxint >>> d=`s` >>> d '8t\x10@\x01' >>> s -9223372036854775808 >>> ^D ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-11-30 18:44 Message: Logged In: YES user_id=31435 As discussed on Python-Dev, I suspect this is because int_repr only allocates 20 bytes for the output buffer, but needs 21 in this case. Changing a bunch of sprintf calls to PyOS_snprintf calls very recently would make this matter on a sizeof(long) == 8 box. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487743&group_id=5470 From noreply@sourceforge.net Sat Dec 1 02:53:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Nov 2001 18:53:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-487743 ] test_builtin fails on 64 bit platform Message-ID: Bugs item #487743, was opened at 2001-11-30 18:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487743&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 8 Submitted By: Mark Favas (mfavas) Assigned to: Tim Peters (tim_one) Summary: test_builtin fails on 64 bit platform Initial Comment: test_builtin fails on Tru64 platform with current (1 Dec) version of CVS - traced to following code: CVS of 26 Nov works, CVS of 1 Dec fails *************** older CVS works *************** 201 mark@gonzo python Python 2.2b2+ (#539, Nov 26 2001, 09:52:25) [C] on osf1V4 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> s=-1-sys.maxint >>> d=`s` >>> d '-9223372036854775808' >>> s -9223372036854775808 >>> ^D *************** current CVS fails ***************** 202 mark@gonzo cd dist/src 203 mark@gonzo ./python Python 2.2b2+ (#541, Dec 1 2001, 08:04:58) [C] on osf1V4 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> s=-1-sys.maxint >>> d=`s` >>> d '8t\x10@\x01' >>> s -9223372036854775808 >>> ^D ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-11-30 18:53 Message: Logged In: YES user_id=31435 Please see whether revision: 2.77 of Objects/intobject.c fixes your problem. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-30 18:44 Message: Logged In: YES user_id=31435 As discussed on Python-Dev, I suspect this is because int_repr only allocates 20 bytes for the output buffer, but needs 21 in this case. Changing a bunch of sprintf calls to PyOS_snprintf calls very recently would make this matter on a sizeof(long) == 8 box. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487743&group_id=5470 From noreply@sourceforge.net Sat Dec 1 03:18:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Nov 2001 19:18:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-487321 ] Installation fails on module-xmllib.html Message-ID: Bugs item #487321, was opened at 2001-11-29 17:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487321&group_id=5470 Category: Installation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Barry Kumnick (barryk) Assigned to: Tim Peters (tim_one) Summary: Installation fails on module-xmllib.html Initial Comment: On NT 4.0 SP6 installation of Python 2.2b2 hangs with the following message: "Copying Python Documentation (HTML); F:\Python22\Doc\lib\module-xmllib.html Upon further investigation it appears the installation program is getting hung up while it creates an infinite length .tmp file (multiple Gb) that consumes all available disk space on the installation drive. The installation file Python-2.2b2.exe has a file length of 7,008,533 bytes. I've now tried to install both versions 2.1 and 2.2b2 - both installations have failed for different reasons. Please get the Windows installations fixed! ---------------------------------------------------------------------- >Comment By: Barry Kumnick (barryk) Date: 2001-11-30 19:18 Message: Logged In: YES user_id=389562 I re-downloaded the installer directly from python.org using FTP, the md5 checksum was correct and everything worked fine. Apparently, one of the file mirrors I was using before has a corrupted copy of the installer, or their firewall corrupted the binary. Problem closed. Thanks Barry Kumnick ---------------------------------------------------------------------- Comment By: Barry Kumnick (barryk) Date: 2001-11-30 15:15 Message: Logged In: YES user_id=389562 I just generated the md5 sum on Python-2.2b2.exe. It is also coming back bad. I'll have to try downloading again. Thanks, Barry Kumnick ---------------------------------------------------------------------- Comment By: Barry Kumnick (barryk) Date: 2001-11-30 14:42 Message: Logged In: YES user_id=389562 Hi Tim, I have reproduced the same problem on a physically distinct machine per your suggestion. The first machine is an NT4 Enterprise Server Dual Processor Dual Boot PIII box with SP6. The second machine is an NT4 Enterprise Server Single Processor Dual Boot PIII box with SP5. The installations failed on both machines with the symptoms noted in my previous post. Can you advise me how to verify the md5sum on the download file? I downloaded the md5sum.exe program Martin suggested in my other bug report, but it returns a message saying: md5sum: Python-2.2b2.exe: no properly formated MD5 checksum lines found. Also, I don't have the md5sum.py module. I might be able to use that from the command line if you could tell me where to download it. Thanks, Barry Kumnick ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 08:23 Message: Logged In: YES user_id=21627 Can you please verify the md5sum of this file as well? cf59bb416bc43f6bf77a3329db901f6f Python-2.2b2.exe ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-29 18:27 Message: Logged In: YES user_id=31435 See comment on your bug 487317: you're unique here too. Can you reproduce on a physically distinct machine? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487321&group_id=5470 From noreply@sourceforge.net Sat Dec 1 03:44:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Nov 2001 19:44:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-487321 ] Installation fails on module-xmllib.html Message-ID: Bugs item #487321, was opened at 2001-11-29 17:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487321&group_id=5470 Category: Installation >Group: Not a Bug Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Barry Kumnick (barryk) Assigned to: Tim Peters (tim_one) Summary: Installation fails on module-xmllib.html Initial Comment: On NT 4.0 SP6 installation of Python 2.2b2 hangs with the following message: "Copying Python Documentation (HTML); F:\Python22\Doc\lib\module-xmllib.html Upon further investigation it appears the installation program is getting hung up while it creates an infinite length .tmp file (multiple Gb) that consumes all available disk space on the installation drive. The installation file Python-2.2b2.exe has a file length of 7,008,533 bytes. I've now tried to install both versions 2.1 and 2.2b2 - both installations have failed for different reasons. Please get the Windows installations fixed! ---------------------------------------------------------------------- Comment By: Barry Kumnick (barryk) Date: 2001-11-30 19:18 Message: Logged In: YES user_id=389562 I re-downloaded the installer directly from python.org using FTP, the md5 checksum was correct and everything worked fine. Apparently, one of the file mirrors I was using before has a corrupted copy of the installer, or their firewall corrupted the binary. Problem closed. Thanks Barry Kumnick ---------------------------------------------------------------------- Comment By: Barry Kumnick (barryk) Date: 2001-11-30 15:15 Message: Logged In: YES user_id=389562 I just generated the md5 sum on Python-2.2b2.exe. It is also coming back bad. I'll have to try downloading again. Thanks, Barry Kumnick ---------------------------------------------------------------------- Comment By: Barry Kumnick (barryk) Date: 2001-11-30 14:42 Message: Logged In: YES user_id=389562 Hi Tim, I have reproduced the same problem on a physically distinct machine per your suggestion. The first machine is an NT4 Enterprise Server Dual Processor Dual Boot PIII box with SP6. The second machine is an NT4 Enterprise Server Single Processor Dual Boot PIII box with SP5. The installations failed on both machines with the symptoms noted in my previous post. Can you advise me how to verify the md5sum on the download file? I downloaded the md5sum.exe program Martin suggested in my other bug report, but it returns a message saying: md5sum: Python-2.2b2.exe: no properly formated MD5 checksum lines found. Also, I don't have the md5sum.py module. I might be able to use that from the command line if you could tell me where to download it. Thanks, Barry Kumnick ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 08:23 Message: Logged In: YES user_id=21627 Can you please verify the md5sum of this file as well? cf59bb416bc43f6bf77a3329db901f6f Python-2.2b2.exe ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-29 18:27 Message: Logged In: YES user_id=31435 See comment on your bug 487317: you're unique here too. Can you reproduce on a physically distinct machine? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487321&group_id=5470 From noreply@sourceforge.net Sat Dec 1 03:48:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Nov 2001 19:48:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-487317 ] tcl83.dll is corrupt Message-ID: Bugs item #487317, was opened at 2001-11-29 17:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487317&group_id=5470 Category: Installation >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Barry Kumnick (barryk) Assigned to: Tim Peters (tim_one) Summary: tcl83.dll is corrupt Initial Comment: On NT4 SP6, installation of Python-2.1.1.exe fails with an error message saying tcl83.dll is corrupt. The downloaded file size is correct - 6,310,277 bytes. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-11-30 19:48 Message: Logged In: YES user_id=31435 I'm closing this now since your other unique bug was traced to a corrupt installer. From the Pythonic point of vies, Download Accelerator Plus is clearly too fancy to trust . ---------------------------------------------------------------------- Comment By: Barry Kumnick (barryk) Date: 2001-11-30 18:02 Message: Logged In: YES user_id=389562 I downloaded it from python.org via ftp using the registered version of Download Accelerator Plus (DAP) version 5.0.0.1. This utility simultaneously establishes four different connections to four different mirror sites and merges the files when the download is complete. It also supports suspend and resume. Alas, I don't have a record of the mirror sites the download actually came from. I did have some problems with the TCP connection timing out a couple of times and I had to restart the download. Perhaps that caused some problem. I don't know. I'll try the download using straight ftp from python.org and let you know how it goes. Thanks, Barry Kumnick ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-30 15:50 Message: Logged In: YES user_id=31435 Barry, from exactly where are you downloading the installer? SourceForge? python.org? If the latter, via HTTP or via FTP? Which program are you using to download? It's remotely possible that one of the master copies recently got corrupted, and if you tell me where you're getting it from, I'd be happy to try downloading it myself too. I hate to mention it, but some corporations are known to run firewalls that systematically corrupt binary downloads. ---------------------------------------------------------------------- Comment By: Barry Kumnick (barryk) Date: 2001-11-30 15:11 Message: Logged In: YES user_id=389562 I got the md5sum to work. It is reporting a different checksum than the one you provided, so the downloaded file must have been corrupted. I'll try to download a new copy. Thanks for your help. Barry Kumnick ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-30 14:54 Message: Logged In: YES user_id=31435 It sounds like you were trying to run md5sum with its "-c" switch: don't. Do it like so: C:\Code>\updates\md5sum Python-2.1.1.exe 39ef54d3e29ea402c8b693b4f3fedd4a *Python-2.1.1.exe C:\Code> There are no corrupt files in the installers we ship, so stop trying to pursue that path: you'll just get in worse trouble if you do. Something else is hosed on your system. BTW, you can open the installer (as a file!) in WinZip, and use WinZip's Action -> Test to test for corruption. md5 is a more powerful whole-file check, but the installer saves a CRC code for each individual file and that's what the WinZip Test looks at. If either md5 or WinZip complains, your installer got corrupted during (or maybe even after) downloading. ---------------------------------------------------------------------- Comment By: Barry Kumnick (barryk) Date: 2001-11-30 14:34 Message: Logged In: YES user_id=389562 Hi, Thanks for getting back to me. First I have a correction to make: it was the tk83.dll not the tcl83.dll that was reported as corrupt. Actually, I am running NT 4 Enterprise Server SP6 on a dual processor PIII box. I tried to install on another box running NT 4 Enterprise Server SP5 with a single processor, and got the same error. However, on that machine I was able to keep pressing retry, and the progress bar kept advancing. In fact it went up a few percent every time I pressed the retry button on the error dialog. It continued to advance past 100%. I stopped trying after it got to around 113% and it said the system needed to be rebooted to complete the installation. I did that. Apparently, everything installed except the tk83.dll. I also tried the md5sum.exe application Martin suggested, but it reports: md5sum: Python-2.1.1.exe: no properly formated MD5 checksum lines found. Do you have another suggestion for computing the MD5 checksum? I don't have md5sum.py on my system. BTW: With the current 2.1.1 installation, I was able to get the Python command shell to execute, but when attempting to launch IDLE, it fails with an error message saying the tk83.dll can not be found. Is there somewhere I can download the tk83.dll separately as a workaround? Thanks, Barry Kumnick ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-30 09:43 Message: Logged In: YES user_id=31435 Thanks for finding that program, Martin! This should be received much better than my usual advice to compute MD5 with md5sum.py . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 08:19 Message: Logged In: YES user_id=21627 Can you please verify the md5sum of the file you've downloaded? It is 39ef54d3e29ea402c8b693b4f3fedd4a Python-2.1.1.exe You can get an md5sum executable from http://etree.org/md5com.html ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-29 18:25 Message: Logged In: YES user_id=31435 Tens of thousands of Windows users have run this installer without problems, so-- and especially given your other bug report about 2.2b2 --the presumption has to be that something is uniquely screwed up on the specific box you tried it on. Can you reproduce on another (physically distinct) machine? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487317&group_id=5470 From noreply@sourceforge.net Sat Dec 1 03:49:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Nov 2001 19:49:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-485766 ] install hangs Message-ID: Bugs item #485766, was opened at 2001-11-26 12:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485766&group_id=5470 Category: Installation Group: Python 2.1.1 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: install hangs Initial Comment: Install on NT 4.0 appears to go fine until the final step. It says it is finished, but clicking on OK (or finish) leaves server with a blue screen (python install, not system crash). System just sits there & does not change.. CPU at 30% or less...mostly less. Help! User is frantic! Thanks! ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-11-30 19:49 Message: Logged In: YES user_id=31435 As threatened earlier, closed for lack of followup. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-28 09:35 Message: Logged In: YES user_id=31435 Will close this at the end of the week if there's no followup from Anonymous. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-26 16:33 Message: Logged In: YES user_id=31435 Log in to an Administrator account. Don't install over a network (install from local copy). Accept defaults. Ensure there's enough disk space. Kill virus checkers (etc) for the duration ... this is all "general flaky Windows" advice, there's nothing specific to Python here. If all else fails, try the ActiveState or Secret Labs installer. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485766&group_id=5470 From noreply@sourceforge.net Sat Dec 1 03:48:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Nov 2001 19:48:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-486713 ] 2.2b2 IDLE on W2k does not load Message-ID: Bugs item #486713, was opened at 2001-11-28 14:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486713&group_id=5470 Category: IDLE Group: Python 2.2 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: 2.2b2 IDLE on W2k does not load Initial Comment: Hi, 2.2b2 IDLE on W2k does not load, I uninstalled the previous version(which worked fine), installed 2.2b2 which seemed to go Ok, when I now load IDLE, the hourglass appears for about 2 seconds, then nothing. I am adminstrator on W2k Pro. The command line works OK. Thanks;....Andrew ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-11-30 19:48 Message: Logged In: YES user_id=31435 CLosed for lack of followup. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-28 15:00 Message: Logged In: YES user_id=31435 Works for me, and there are no other reports of problems here. Needs more info. Try running Tools\idle\idle.pyw from a DOS box, using python.exe, and see whether that displays any error msgs. The Start menu shortcut uses pythonw.exe (note the trailing "w"), and error msgs end up in the bit bucket then. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486713&group_id=5470 From noreply@sourceforge.net Sat Dec 1 09:28:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 01 Dec 2001 01:28:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-486099 ] socketmodule won't compile on BSDI 4.0 Message-ID: Bugs item #486099, was opened at 2001-11-27 10:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486099&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Martin v. Löwis (loewis) Summary: socketmodule won't compile on BSDI 4.0 Initial Comment: Trying to build 2.2b2 on BSDI BSD/OS 4.0 with gcc 2.7.2.1 and gcc 2.95.2, and the socket module won't build. No problems building socket for Python 2.1.1 on this same machine. % ./configure --with-threads=no # for socket(2), without SSL support. _socket socketmodule.c % gmake gcc -D_HAVE_BSDI -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from ./Modules/socketmodule.c:187: /usr/local/packages/gcc-2.95.2/lib/gcc-lib/i386-pc-bsdi4.0/2.95.2/include/stddef.h:280: conflicting types for `wint_t' /usr/include/wchar.h:7: previous declaration of `wint_t' In file included from ./Modules/socketmodule.c:236: Modules/getaddrinfo.c: In function `gai_strerror': Modules/getaddrinfo.c:205: `EAI_MAX' undeclared (first use in this function) Modules/getaddrinfo.c:205: (Each undeclared identifier is reported only once Modules/getaddrinfo.c:205: for each function it appears in.) Modules/getaddrinfo.c: In function `getaddrinfo': Modules/getaddrinfo.c:285: `EAI_BADHINTS' undeclared (first use in this function) Modules/getaddrinfo.c:286: `AI_MASK' undeclared (first use in this function) Modules/getaddrinfo.c:376: `EAI_PROTOCOL' undeclared (first use in this function) Modules/getaddrinfo.c:464: `AI_NUMERICHOST' undeclared (first use in this function) ./Modules/socketmodule.c: In function `PySocketSock_init': ./Modules/socketmodule.c:1818: warning: function declaration isn't a prototype ./Modules/socketmodule.c: In function `PySocket_fromfd': ./Modules/socketmodule.c:2304: warning: function declaration isn't a prototype gmake: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-01 01:28 Message: Logged In: YES user_id=21627 Thanks, I'm now giving up on getting the C library getaddrinfo to work on your system (I have no idea why it would fail in this place). Instead, I made the patch gai.diff, which should allow compilation of getaddrinfo.c on your system. Please report whether it works. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-11-30 08:24 Message: Logged In: YES user_id=85984 % gcc -o aicheck2 aicheck2.c % ./aicheck2 fail 11 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 01:35 Message: Logged In: YES user_id=21627 Arrghh. I was trying to find out which of the tests fail, but attached the wrong version of the file: I meant to put printfs into each failure. Please try aicheck2.c instead. Anyway, it seems that your system is indeed one of those where the test should find out problems with the C library (unless the test that fails is bogus, which we can investigate once we know what it is that fails). I'll try to come up with a patch that allows usage of the getaddrinfo emulation even on systems where getaddrinfo is in the C library. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-11-29 18:18 Message: Logged In: YES user_id=85984 aicheck.c compiled without problem on my system. % gcc -o aicheck aicheck.c % Running the resulting binary produces no output. I'm not exactly sure what kind of output you are looking for (taking a guess): % gdb /home/jason/temp/aicheck GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-bsdi4.0), Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)... (gdb) run Starting program: /home/jason/temp/aicheck (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Program exited with code 01. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-29 15:51 Message: Logged In: YES user_id=21627 Thansk for the files. I now trying to figure out why Python refuses to use the getaddrinfo implementation in your C library. It may be that it is really broken, in which case we must make getaddrinfo.c work correctly. Perhaps it ought to work,and configure just fails to correctly see that. So please compile the attached file aicheck.c on your system, and report output and status code (looking at $?); if it fails to compile, report the compile errors. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-11-28 12:21 Message: Logged In: YES user_id=85984 Attached are three files: - pyconfig.h from a fresh gcc 2.7.2.1 build - config.log from a fresh gcc 2.7.2.1 build - /usr/include/netdb.h - the getaddrinfo manual page from my system Indeed, EAI_ADDRFAMILY is defined in /usr/include/netdb.h, but EAI_MAX is not. Let me know if I can provide any more information. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-28 01:30 Message: Logged In: YES user_id=21627 Ok, then we need to investigate the configure results. Can you please attach pyconfig.h and config.log to this report? Also, can you please confirm that you build Python from scratch with 2.7.2.1 (i.e untarring a fresh source tree, to avoid using a config.cache left over from gcc 2.95.2)? Furthermore, can you please report details of the getaddrinfo implementation on your system? Does it provide one? In the C library? If not, can you confirm that EAI_ADDRFAMILY is defined in your system headers, but EAI_MAX is not? If yes, can you speculate as to why configure thinks your system does not have getaddrinfo? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-11-27 15:21 Message: Logged In: YES user_id=85984 I probably should have included the output from gcc 2.7.2.1 instead which I know is properly installed. The results are similar, although there is no mention of `wint_t': % gmake gcc -D_HAVE_BSDI -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from Include/pyport.h:93, from Include/Python.h:60, from ./Modules/socketmodule.c:78: /usr/include/math.h:177: warning: function declaration isn't a prototype /usr/include/math.h:257: warning: function declaration isn't a prototype In file included from Include/unicodeobject.h:118, from Include/Python.h:69, from ./Modules/socketmodule.c:78: /usr/include/wchar.h:15: warning: function declaration isn't a prototype In file included from /usr/include/signal.h:46, from ./Modules/socketmodule.c:140: /usr/include/sys/signal.h:121: warning: function declaration isn't a prototype /usr/include/sys/signal.h:164: warning: function declaration isn't a prototype Modules/getaddrinfo.c: In function `gai_strerror': In file included from ./Modules/socketmodule.c:236: Modules/getaddrinfo.c:205: `EAI_MAX' undeclared (first use this function) Modules/getaddrinfo.c:205: (Each undeclared identifier is reported only once Modules/getaddrinfo.c:205: for each function it appears in.) Modules/getaddrinfo.c: In function `getaddrinfo': Modules/getaddrinfo.c:285: `EAI_BADHINTS' undeclared (first use this function) Modules/getaddrinfo.c:286: `AI_MASK' undeclared (first use this function) Modules/getaddrinfo.c:376: `EAI_PROTOCOL' undeclared (first use this function) Modules/getaddrinfo.c:464: `AI_NUMERICHOST' undeclared (first use this function) ./Modules/socketmodule.c: In function `PySocketSock_init': ./Modules/socketmodule.c:1818: warning: function declaration isn't a prototype ./Modules/socketmodule.c: In function `PySocket_fromfd': ./Modules/socketmodule.c:2304: warning: function declaration isn't a prototype gmake: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-27 15:08 Message: Logged In: YES user_id=21627 Are you sure the compiler is properly installed? That you have wint_t definition both in wchar.h and stddef.h (as fixincluded by gcc) is not Python's doing; either the header files of your operating system are corrupt, or the compiler is broken. If you cannot figure out the details, please attach both header files to this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:07 Message: Logged In: YES user_id=31435 Assigned to Martin. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486099&group_id=5470 From noreply@sourceforge.net Sat Dec 1 10:29:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 01 Dec 2001 02:29:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-487743 ] test_builtin fails on 64 bit platform Message-ID: Bugs item #487743, was opened at 2001-11-30 18:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487743&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 8 Submitted By: Mark Favas (mfavas) Assigned to: Tim Peters (tim_one) Summary: test_builtin fails on 64 bit platform Initial Comment: test_builtin fails on Tru64 platform with current (1 Dec) version of CVS - traced to following code: CVS of 26 Nov works, CVS of 1 Dec fails *************** older CVS works *************** 201 mark@gonzo python Python 2.2b2+ (#539, Nov 26 2001, 09:52:25) [C] on osf1V4 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> s=-1-sys.maxint >>> d=`s` >>> d '-9223372036854775808' >>> s -9223372036854775808 >>> ^D *************** current CVS fails ***************** 202 mark@gonzo cd dist/src 203 mark@gonzo ./python Python 2.2b2+ (#541, Dec 1 2001, 08:04:58) [C] on osf1V4 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> s=-1-sys.maxint >>> d=`s` >>> d '8t\x10@\x01' >>> s -9223372036854775808 >>> ^D ---------------------------------------------------------------------- >Comment By: Mark Favas (mfavas) Date: 2001-12-01 02:29 Message: Logged In: YES user_id=44979 Yes, rev 2.77 of Objects/intobject.c (buf[20] -> buf[64]) fixes the problem. (Note also that Tru64 has no native snprintf implementation - at least in V4.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-30 18:53 Message: Logged In: YES user_id=31435 Please see whether revision: 2.77 of Objects/intobject.c fixes your problem. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-30 18:44 Message: Logged In: YES user_id=31435 As discussed on Python-Dev, I suspect this is because int_repr only allocates 20 bytes for the output buffer, but needs 21 in this case. Changing a bunch of sprintf calls to PyOS_snprintf calls very recently would make this matter on a sizeof(long) == 8 box. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487743&group_id=5470 From noreply@sourceforge.net Sat Dec 1 18:46:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 01 Dec 2001 10:46:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-486099 ] socketmodule won't compile on BSDI 4.0 Message-ID: Bugs item #486099, was opened at 2001-11-27 10:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486099&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Martin v. Löwis (loewis) Summary: socketmodule won't compile on BSDI 4.0 Initial Comment: Trying to build 2.2b2 on BSDI BSD/OS 4.0 with gcc 2.7.2.1 and gcc 2.95.2, and the socket module won't build. No problems building socket for Python 2.1.1 on this same machine. % ./configure --with-threads=no # for socket(2), without SSL support. _socket socketmodule.c % gmake gcc -D_HAVE_BSDI -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from ./Modules/socketmodule.c:187: /usr/local/packages/gcc-2.95.2/lib/gcc-lib/i386-pc-bsdi4.0/2.95.2/include/stddef.h:280: conflicting types for `wint_t' /usr/include/wchar.h:7: previous declaration of `wint_t' In file included from ./Modules/socketmodule.c:236: Modules/getaddrinfo.c: In function `gai_strerror': Modules/getaddrinfo.c:205: `EAI_MAX' undeclared (first use in this function) Modules/getaddrinfo.c:205: (Each undeclared identifier is reported only once Modules/getaddrinfo.c:205: for each function it appears in.) Modules/getaddrinfo.c: In function `getaddrinfo': Modules/getaddrinfo.c:285: `EAI_BADHINTS' undeclared (first use in this function) Modules/getaddrinfo.c:286: `AI_MASK' undeclared (first use in this function) Modules/getaddrinfo.c:376: `EAI_PROTOCOL' undeclared (first use in this function) Modules/getaddrinfo.c:464: `AI_NUMERICHOST' undeclared (first use in this function) ./Modules/socketmodule.c: In function `PySocketSock_init': ./Modules/socketmodule.c:1818: warning: function declaration isn't a prototype ./Modules/socketmodule.c: In function `PySocket_fromfd': ./Modules/socketmodule.c:2304: warning: function declaration isn't a prototype gmake: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-01 10:46 Message: Logged In: YES user_id=85984 Still no luck after applying the patch unfortunately. sclp3:~/temp/Python-2.2b2/Modules> patch < ../../gai.diff patching file `addrinfo.h' patching file `getaddrinfo.c' sclp3:~/temp/Python-2.2b2> gmake /bin/sh ./Modules/makesetup -c ./Modules/config.c.in \ -s Modules \ Modules/Setup.config \ Modules/Setup.local \ Modules/Setup The Makefile was updated, you may need to re-run make. gcc -D_HAVE_BSDI -c -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -o Modules/config.o Modules/config.c In file included from Include/pyport.h:93, from Include/Python.h:60, from Modules/config.c:19: /usr/include/math.h:177: warning: function declaration isn't a prototype /usr/include/math.h:257: warning: function declaration isn't a prototype In file included from Include/unicodeobject.h:118, from Include/Python.h:69, from Modules/config.c:19: /usr/include/wchar.h:15: warning: function declaration isn't a prototype gcc -D_HAVE_BSDI -c -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -DPYTHONPATH='":plat-bsdos4:lib-tk"' \ -DPREFIX='"/usr/local"' \ -DEXEC_PREFIX='"/usr/local"' \ -DVERSION='"2.2"' \ -DVPATH='""' \ -o Modules/getpath.o ./Modules/getpath.c In file included from Include/pyport.h:93, from Include/Python.h:60, from ./Modules/getpath.c:3: /usr/include/math.h:177: warning: function declaration isn't a prototype /usr/include/math.h:257: warning: function declaration isn't a prototype In file included from Include/unicodeobject.h:118, from Include/Python.h:69, from ./Modules/getpath.c:3: /usr/include/wchar.h:15: warning: function declaration isn't a prototype gcc -D_HAVE_BSDI -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from Include/pyport.h:93, from Include/Python.h:60, from ./Modules/socketmodule.c:78: /usr/include/math.h:177: warning: function declaration isn't a prototype /usr/include/math.h:257: warning: function declaration isn't a prototype In file included from Include/unicodeobject.h:118, from Include/Python.h:69, from ./Modules/socketmodule.c:78: /usr/include/wchar.h:15: warning: function declaration isn't a prototype In file included from /usr/include/signal.h:46, from ./Modules/socketmodule.c:140: /usr/include/sys/signal.h:121: warning: function declaration isn't a prototype /usr/include/sys/signal.h:164: warning: function declaration isn't a prototype In file included from ./Modules/socketmodule.c:236: Modules/getaddrinfo.c:203: conflicting types for `gai_strerror' /usr/include/netdb.h:172: previous declaration of `gai_strerror' ./Modules/socketmodule.c: In function `PySocketSock_init': ./Modules/socketmodule.c:1818: warning: function declaration isn't a prototype ./Modules/socketmodule.c: In function `PySocket_fromfd': ./Modules/socketmodule.c:2304: warning: function declaration isn't a prototype gmake: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-01 01:28 Message: Logged In: YES user_id=21627 Thanks, I'm now giving up on getting the C library getaddrinfo to work on your system (I have no idea why it would fail in this place). Instead, I made the patch gai.diff, which should allow compilation of getaddrinfo.c on your system. Please report whether it works. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-11-30 08:24 Message: Logged In: YES user_id=85984 % gcc -o aicheck2 aicheck2.c % ./aicheck2 fail 11 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 01:35 Message: Logged In: YES user_id=21627 Arrghh. I was trying to find out which of the tests fail, but attached the wrong version of the file: I meant to put printfs into each failure. Please try aicheck2.c instead. Anyway, it seems that your system is indeed one of those where the test should find out problems with the C library (unless the test that fails is bogus, which we can investigate once we know what it is that fails). I'll try to come up with a patch that allows usage of the getaddrinfo emulation even on systems where getaddrinfo is in the C library. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-11-29 18:18 Message: Logged In: YES user_id=85984 aicheck.c compiled without problem on my system. % gcc -o aicheck aicheck.c % Running the resulting binary produces no output. I'm not exactly sure what kind of output you are looking for (taking a guess): % gdb /home/jason/temp/aicheck GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-bsdi4.0), Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)... (gdb) run Starting program: /home/jason/temp/aicheck (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Program exited with code 01. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-29 15:51 Message: Logged In: YES user_id=21627 Thansk for the files. I now trying to figure out why Python refuses to use the getaddrinfo implementation in your C library. It may be that it is really broken, in which case we must make getaddrinfo.c work correctly. Perhaps it ought to work,and configure just fails to correctly see that. So please compile the attached file aicheck.c on your system, and report output and status code (looking at $?); if it fails to compile, report the compile errors. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-11-28 12:21 Message: Logged In: YES user_id=85984 Attached are three files: - pyconfig.h from a fresh gcc 2.7.2.1 build - config.log from a fresh gcc 2.7.2.1 build - /usr/include/netdb.h - the getaddrinfo manual page from my system Indeed, EAI_ADDRFAMILY is defined in /usr/include/netdb.h, but EAI_MAX is not. Let me know if I can provide any more information. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-28 01:30 Message: Logged In: YES user_id=21627 Ok, then we need to investigate the configure results. Can you please attach pyconfig.h and config.log to this report? Also, can you please confirm that you build Python from scratch with 2.7.2.1 (i.e untarring a fresh source tree, to avoid using a config.cache left over from gcc 2.95.2)? Furthermore, can you please report details of the getaddrinfo implementation on your system? Does it provide one? In the C library? If not, can you confirm that EAI_ADDRFAMILY is defined in your system headers, but EAI_MAX is not? If yes, can you speculate as to why configure thinks your system does not have getaddrinfo? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-11-27 15:21 Message: Logged In: YES user_id=85984 I probably should have included the output from gcc 2.7.2.1 instead which I know is properly installed. The results are similar, although there is no mention of `wint_t': % gmake gcc -D_HAVE_BSDI -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from Include/pyport.h:93, from Include/Python.h:60, from ./Modules/socketmodule.c:78: /usr/include/math.h:177: warning: function declaration isn't a prototype /usr/include/math.h:257: warning: function declaration isn't a prototype In file included from Include/unicodeobject.h:118, from Include/Python.h:69, from ./Modules/socketmodule.c:78: /usr/include/wchar.h:15: warning: function declaration isn't a prototype In file included from /usr/include/signal.h:46, from ./Modules/socketmodule.c:140: /usr/include/sys/signal.h:121: warning: function declaration isn't a prototype /usr/include/sys/signal.h:164: warning: function declaration isn't a prototype Modules/getaddrinfo.c: In function `gai_strerror': In file included from ./Modules/socketmodule.c:236: Modules/getaddrinfo.c:205: `EAI_MAX' undeclared (first use this function) Modules/getaddrinfo.c:205: (Each undeclared identifier is reported only once Modules/getaddrinfo.c:205: for each function it appears in.) Modules/getaddrinfo.c: In function `getaddrinfo': Modules/getaddrinfo.c:285: `EAI_BADHINTS' undeclared (first use this function) Modules/getaddrinfo.c:286: `AI_MASK' undeclared (first use this function) Modules/getaddrinfo.c:376: `EAI_PROTOCOL' undeclared (first use this function) Modules/getaddrinfo.c:464: `AI_NUMERICHOST' undeclared (first use this function) ./Modules/socketmodule.c: In function `PySocketSock_init': ./Modules/socketmodule.c:1818: warning: function declaration isn't a prototype ./Modules/socketmodule.c: In function `PySocket_fromfd': ./Modules/socketmodule.c:2304: warning: function declaration isn't a prototype gmake: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-27 15:08 Message: Logged In: YES user_id=21627 Are you sure the compiler is properly installed? That you have wint_t definition both in wchar.h and stddef.h (as fixincluded by gcc) is not Python's doing; either the header files of your operating system are corrupt, or the compiler is broken. If you cannot figure out the details, please attach both header files to this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:07 Message: Logged In: YES user_id=31435 Assigned to Martin. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486099&group_id=5470 From noreply@sourceforge.net Sat Dec 1 18:50:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 01 Dec 2001 10:50:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-486099 ] socketmodule won't compile on BSDI 4.0 Message-ID: Bugs item #486099, was opened at 2001-11-27 10:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486099&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Martin v. Löwis (loewis) Summary: socketmodule won't compile on BSDI 4.0 Initial Comment: Trying to build 2.2b2 on BSDI BSD/OS 4.0 with gcc 2.7.2.1 and gcc 2.95.2, and the socket module won't build. No problems building socket for Python 2.1.1 on this same machine. % ./configure --with-threads=no # for socket(2), without SSL support. _socket socketmodule.c % gmake gcc -D_HAVE_BSDI -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from ./Modules/socketmodule.c:187: /usr/local/packages/gcc-2.95.2/lib/gcc-lib/i386-pc-bsdi4.0/2.95.2/include/stddef.h:280: conflicting types for `wint_t' /usr/include/wchar.h:7: previous declaration of `wint_t' In file included from ./Modules/socketmodule.c:236: Modules/getaddrinfo.c: In function `gai_strerror': Modules/getaddrinfo.c:205: `EAI_MAX' undeclared (first use in this function) Modules/getaddrinfo.c:205: (Each undeclared identifier is reported only once Modules/getaddrinfo.c:205: for each function it appears in.) Modules/getaddrinfo.c: In function `getaddrinfo': Modules/getaddrinfo.c:285: `EAI_BADHINTS' undeclared (first use in this function) Modules/getaddrinfo.c:286: `AI_MASK' undeclared (first use in this function) Modules/getaddrinfo.c:376: `EAI_PROTOCOL' undeclared (first use in this function) Modules/getaddrinfo.c:464: `AI_NUMERICHOST' undeclared (first use in this function) ./Modules/socketmodule.c: In function `PySocketSock_init': ./Modules/socketmodule.c:1818: warning: function declaration isn't a prototype ./Modules/socketmodule.c: In function `PySocket_fromfd': ./Modules/socketmodule.c:2304: warning: function declaration isn't a prototype gmake: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-01 10:50 Message: Logged In: YES user_id=85984 Martin, I appreciate your help with this, as the socket module is a crucial one on this particular server, and I'd like to be able to upgrade to 2.2 when it is released. If you are finding it difficult to work on this problem by taking guesses, I could make you a temporary account on the server if you think it would help. If so, attach/send me your SSH public key or some other method of getting the account information to you securely (GPG/PGP public key, etc.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-01 10:46 Message: Logged In: YES user_id=85984 Still no luck after applying the patch unfortunately. sclp3:~/temp/Python-2.2b2/Modules> patch < ../../gai.diff patching file `addrinfo.h' patching file `getaddrinfo.c' sclp3:~/temp/Python-2.2b2> gmake /bin/sh ./Modules/makesetup -c ./Modules/config.c.in \ -s Modules \ Modules/Setup.config \ Modules/Setup.local \ Modules/Setup The Makefile was updated, you may need to re-run make. gcc -D_HAVE_BSDI -c -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -o Modules/config.o Modules/config.c In file included from Include/pyport.h:93, from Include/Python.h:60, from Modules/config.c:19: /usr/include/math.h:177: warning: function declaration isn't a prototype /usr/include/math.h:257: warning: function declaration isn't a prototype In file included from Include/unicodeobject.h:118, from Include/Python.h:69, from Modules/config.c:19: /usr/include/wchar.h:15: warning: function declaration isn't a prototype gcc -D_HAVE_BSDI -c -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -DPYTHONPATH='":plat-bsdos4:lib-tk"' \ -DPREFIX='"/usr/local"' \ -DEXEC_PREFIX='"/usr/local"' \ -DVERSION='"2.2"' \ -DVPATH='""' \ -o Modules/getpath.o ./Modules/getpath.c In file included from Include/pyport.h:93, from Include/Python.h:60, from ./Modules/getpath.c:3: /usr/include/math.h:177: warning: function declaration isn't a prototype /usr/include/math.h:257: warning: function declaration isn't a prototype In file included from Include/unicodeobject.h:118, from Include/Python.h:69, from ./Modules/getpath.c:3: /usr/include/wchar.h:15: warning: function declaration isn't a prototype gcc -D_HAVE_BSDI -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from Include/pyport.h:93, from Include/Python.h:60, from ./Modules/socketmodule.c:78: /usr/include/math.h:177: warning: function declaration isn't a prototype /usr/include/math.h:257: warning: function declaration isn't a prototype In file included from Include/unicodeobject.h:118, from Include/Python.h:69, from ./Modules/socketmodule.c:78: /usr/include/wchar.h:15: warning: function declaration isn't a prototype In file included from /usr/include/signal.h:46, from ./Modules/socketmodule.c:140: /usr/include/sys/signal.h:121: warning: function declaration isn't a prototype /usr/include/sys/signal.h:164: warning: function declaration isn't a prototype In file included from ./Modules/socketmodule.c:236: Modules/getaddrinfo.c:203: conflicting types for `gai_strerror' /usr/include/netdb.h:172: previous declaration of `gai_strerror' ./Modules/socketmodule.c: In function `PySocketSock_init': ./Modules/socketmodule.c:1818: warning: function declaration isn't a prototype ./Modules/socketmodule.c: In function `PySocket_fromfd': ./Modules/socketmodule.c:2304: warning: function declaration isn't a prototype gmake: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-01 01:28 Message: Logged In: YES user_id=21627 Thanks, I'm now giving up on getting the C library getaddrinfo to work on your system (I have no idea why it would fail in this place). Instead, I made the patch gai.diff, which should allow compilation of getaddrinfo.c on your system. Please report whether it works. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-11-30 08:24 Message: Logged In: YES user_id=85984 % gcc -o aicheck2 aicheck2.c % ./aicheck2 fail 11 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 01:35 Message: Logged In: YES user_id=21627 Arrghh. I was trying to find out which of the tests fail, but attached the wrong version of the file: I meant to put printfs into each failure. Please try aicheck2.c instead. Anyway, it seems that your system is indeed one of those where the test should find out problems with the C library (unless the test that fails is bogus, which we can investigate once we know what it is that fails). I'll try to come up with a patch that allows usage of the getaddrinfo emulation even on systems where getaddrinfo is in the C library. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-11-29 18:18 Message: Logged In: YES user_id=85984 aicheck.c compiled without problem on my system. % gcc -o aicheck aicheck.c % Running the resulting binary produces no output. I'm not exactly sure what kind of output you are looking for (taking a guess): % gdb /home/jason/temp/aicheck GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-bsdi4.0), Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)... (gdb) run Starting program: /home/jason/temp/aicheck (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Program exited with code 01. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-29 15:51 Message: Logged In: YES user_id=21627 Thansk for the files. I now trying to figure out why Python refuses to use the getaddrinfo implementation in your C library. It may be that it is really broken, in which case we must make getaddrinfo.c work correctly. Perhaps it ought to work,and configure just fails to correctly see that. So please compile the attached file aicheck.c on your system, and report output and status code (looking at $?); if it fails to compile, report the compile errors. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-11-28 12:21 Message: Logged In: YES user_id=85984 Attached are three files: - pyconfig.h from a fresh gcc 2.7.2.1 build - config.log from a fresh gcc 2.7.2.1 build - /usr/include/netdb.h - the getaddrinfo manual page from my system Indeed, EAI_ADDRFAMILY is defined in /usr/include/netdb.h, but EAI_MAX is not. Let me know if I can provide any more information. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-28 01:30 Message: Logged In: YES user_id=21627 Ok, then we need to investigate the configure results. Can you please attach pyconfig.h and config.log to this report? Also, can you please confirm that you build Python from scratch with 2.7.2.1 (i.e untarring a fresh source tree, to avoid using a config.cache left over from gcc 2.95.2)? Furthermore, can you please report details of the getaddrinfo implementation on your system? Does it provide one? In the C library? If not, can you confirm that EAI_ADDRFAMILY is defined in your system headers, but EAI_MAX is not? If yes, can you speculate as to why configure thinks your system does not have getaddrinfo? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-11-27 15:21 Message: Logged In: YES user_id=85984 I probably should have included the output from gcc 2.7.2.1 instead which I know is properly installed. The results are similar, although there is no mention of `wint_t': % gmake gcc -D_HAVE_BSDI -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from Include/pyport.h:93, from Include/Python.h:60, from ./Modules/socketmodule.c:78: /usr/include/math.h:177: warning: function declaration isn't a prototype /usr/include/math.h:257: warning: function declaration isn't a prototype In file included from Include/unicodeobject.h:118, from Include/Python.h:69, from ./Modules/socketmodule.c:78: /usr/include/wchar.h:15: warning: function declaration isn't a prototype In file included from /usr/include/signal.h:46, from ./Modules/socketmodule.c:140: /usr/include/sys/signal.h:121: warning: function declaration isn't a prototype /usr/include/sys/signal.h:164: warning: function declaration isn't a prototype Modules/getaddrinfo.c: In function `gai_strerror': In file included from ./Modules/socketmodule.c:236: Modules/getaddrinfo.c:205: `EAI_MAX' undeclared (first use this function) Modules/getaddrinfo.c:205: (Each undeclared identifier is reported only once Modules/getaddrinfo.c:205: for each function it appears in.) Modules/getaddrinfo.c: In function `getaddrinfo': Modules/getaddrinfo.c:285: `EAI_BADHINTS' undeclared (first use this function) Modules/getaddrinfo.c:286: `AI_MASK' undeclared (first use this function) Modules/getaddrinfo.c:376: `EAI_PROTOCOL' undeclared (first use this function) Modules/getaddrinfo.c:464: `AI_NUMERICHOST' undeclared (first use this function) ./Modules/socketmodule.c: In function `PySocketSock_init': ./Modules/socketmodule.c:1818: warning: function declaration isn't a prototype ./Modules/socketmodule.c: In function `PySocket_fromfd': ./Modules/socketmodule.c:2304: warning: function declaration isn't a prototype gmake: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-27 15:08 Message: Logged In: YES user_id=21627 Are you sure the compiler is properly installed? That you have wint_t definition both in wchar.h and stddef.h (as fixincluded by gcc) is not Python's doing; either the header files of your operating system are corrupt, or the compiler is broken. If you cannot figure out the details, please attach both header files to this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:07 Message: Logged In: YES user_id=31435 Assigned to Martin. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486099&group_id=5470 From noreply@sourceforge.net Sat Dec 1 19:10:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 01 Dec 2001 11:10:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-487743 ] test_builtin fails on 64 bit platform Message-ID: Bugs item #487743, was opened at 2001-11-30 18:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487743&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Mark Favas (mfavas) Assigned to: Tim Peters (tim_one) Summary: test_builtin fails on 64 bit platform Initial Comment: test_builtin fails on Tru64 platform with current (1 Dec) version of CVS - traced to following code: CVS of 26 Nov works, CVS of 1 Dec fails *************** older CVS works *************** 201 mark@gonzo python Python 2.2b2+ (#539, Nov 26 2001, 09:52:25) [C] on osf1V4 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> s=-1-sys.maxint >>> d=`s` >>> d '-9223372036854775808' >>> s -9223372036854775808 >>> ^D *************** current CVS fails ***************** 202 mark@gonzo cd dist/src 203 mark@gonzo ./python Python 2.2b2+ (#541, Dec 1 2001, 08:04:58) [C] on osf1V4 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> s=-1-sys.maxint >>> d=`s` >>> d '8t\x10@\x01' >>> s -9223372036854775808 >>> ^D ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-01 11:10 Message: Logged In: YES user_id=31435 Thank you, Mark! Closing this. ---------------------------------------------------------------------- Comment By: Mark Favas (mfavas) Date: 2001-12-01 02:29 Message: Logged In: YES user_id=44979 Yes, rev 2.77 of Objects/intobject.c (buf[20] -> buf[64]) fixes the problem. (Note also that Tru64 has no native snprintf implementation - at least in V4.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-30 18:53 Message: Logged In: YES user_id=31435 Please see whether revision: 2.77 of Objects/intobject.c fixes your problem. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-30 18:44 Message: Logged In: YES user_id=31435 As discussed on Python-Dev, I suspect this is because int_repr only allocates 20 bytes for the output buffer, but needs 21 in this case. Changing a bunch of sprintf calls to PyOS_snprintf calls very recently would make this matter on a sizeof(long) == 8 box. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487743&group_id=5470 From noreply@sourceforge.net Sat Dec 1 22:25:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 01 Dec 2001 14:25:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-487929 ] minidom.appendChild buggy Message-ID: Bugs item #487929, was opened at 2001-12-01 14:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487929&group_id=5470 Category: Extension Modules Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Nobody/Anonymous (nobody) Summary: minidom.appendChild buggy Initial Comment: minidom.appendChild looses children when it appends a DocumentFragment with more than one childnode ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487929&group_id=5470 From noreply@sourceforge.net Sat Dec 1 23:01:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 01 Dec 2001 15:01:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-476326 ] Unicode and imp.find_module Message-ID: Bugs item #476326, was opened at 2001-10-30 03:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Paul Boddie (pboddie) >Assigned to: M.-A. Lemburg (lemburg) Summary: Unicode and imp.find_module Initial Comment: When a Unicode string is passed as the module name to imp.find_module, the function fails to import the named module even when it exists in the specified path, returning the error message "No module named ..." as a result. The problem in Python 2.0 can be traced to line 922 of Python/import.c which ensures that any strings involved in the find_module function must be standard Python strings and not Unicode strings, since it tests the type of path components against &PyString_Type explicitly. Interestingly, the __import__ built-in function seems to work with Unicode strings. Either way, it would be great if this could be documented or even fixed, but I don't know what the policy is on Unicode module names (even when they only contain ASCII-compatible characters). ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-01 15:01 Message: Logged In: YES user_id=38388 I guess Python should not except non-ASCII module names, so conversion of Unicode to ASCII should be appropriate. Would it suffice to only test this in find_module() or do you think that I need to dig deeper into the import mechanism ? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 From noreply@sourceforge.net Sun Dec 2 12:37:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 04:37:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-486099 ] socketmodule won't compile on BSDI 4.0 Message-ID: Bugs item #486099, was opened at 2001-11-27 10:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486099&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None >Priority: 8 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Martin v. Löwis (loewis) Summary: socketmodule won't compile on BSDI 4.0 Initial Comment: Trying to build 2.2b2 on BSDI BSD/OS 4.0 with gcc 2.7.2.1 and gcc 2.95.2, and the socket module won't build. No problems building socket for Python 2.1.1 on this same machine. % ./configure --with-threads=no # for socket(2), without SSL support. _socket socketmodule.c % gmake gcc -D_HAVE_BSDI -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from ./Modules/socketmodule.c:187: /usr/local/packages/gcc-2.95.2/lib/gcc-lib/i386-pc-bsdi4.0/2.95.2/include/stddef.h:280: conflicting types for `wint_t' /usr/include/wchar.h:7: previous declaration of `wint_t' In file included from ./Modules/socketmodule.c:236: Modules/getaddrinfo.c: In function `gai_strerror': Modules/getaddrinfo.c:205: `EAI_MAX' undeclared (first use in this function) Modules/getaddrinfo.c:205: (Each undeclared identifier is reported only once Modules/getaddrinfo.c:205: for each function it appears in.) Modules/getaddrinfo.c: In function `getaddrinfo': Modules/getaddrinfo.c:285: `EAI_BADHINTS' undeclared (first use in this function) Modules/getaddrinfo.c:286: `AI_MASK' undeclared (first use in this function) Modules/getaddrinfo.c:376: `EAI_PROTOCOL' undeclared (first use in this function) Modules/getaddrinfo.c:464: `AI_NUMERICHOST' undeclared (first use in this function) ./Modules/socketmodule.c: In function `PySocketSock_init': ./Modules/socketmodule.c:1818: warning: function declaration isn't a prototype ./Modules/socketmodule.c: In function `PySocket_fromfd': ./Modules/socketmodule.c:2304: warning: function declaration isn't a prototype gmake: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-01 10:50 Message: Logged In: YES user_id=85984 Martin, I appreciate your help with this, as the socket module is a crucial one on this particular server, and I'd like to be able to upgrade to 2.2 when it is released. If you are finding it difficult to work on this problem by taking guesses, I could make you a temporary account on the server if you think it would help. If so, attach/send me your SSH public key or some other method of getting the account information to you securely (GPG/PGP public key, etc.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-01 10:46 Message: Logged In: YES user_id=85984 Still no luck after applying the patch unfortunately. sclp3:~/temp/Python-2.2b2/Modules> patch < ../../gai.diff patching file `addrinfo.h' patching file `getaddrinfo.c' sclp3:~/temp/Python-2.2b2> gmake /bin/sh ./Modules/makesetup -c ./Modules/config.c.in \ -s Modules \ Modules/Setup.config \ Modules/Setup.local \ Modules/Setup The Makefile was updated, you may need to re-run make. gcc -D_HAVE_BSDI -c -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -o Modules/config.o Modules/config.c In file included from Include/pyport.h:93, from Include/Python.h:60, from Modules/config.c:19: /usr/include/math.h:177: warning: function declaration isn't a prototype /usr/include/math.h:257: warning: function declaration isn't a prototype In file included from Include/unicodeobject.h:118, from Include/Python.h:69, from Modules/config.c:19: /usr/include/wchar.h:15: warning: function declaration isn't a prototype gcc -D_HAVE_BSDI -c -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -DPYTHONPATH='":plat-bsdos4:lib-tk"' \ -DPREFIX='"/usr/local"' \ -DEXEC_PREFIX='"/usr/local"' \ -DVERSION='"2.2"' \ -DVPATH='""' \ -o Modules/getpath.o ./Modules/getpath.c In file included from Include/pyport.h:93, from Include/Python.h:60, from ./Modules/getpath.c:3: /usr/include/math.h:177: warning: function declaration isn't a prototype /usr/include/math.h:257: warning: function declaration isn't a prototype In file included from Include/unicodeobject.h:118, from Include/Python.h:69, from ./Modules/getpath.c:3: /usr/include/wchar.h:15: warning: function declaration isn't a prototype gcc -D_HAVE_BSDI -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from Include/pyport.h:93, from Include/Python.h:60, from ./Modules/socketmodule.c:78: /usr/include/math.h:177: warning: function declaration isn't a prototype /usr/include/math.h:257: warning: function declaration isn't a prototype In file included from Include/unicodeobject.h:118, from Include/Python.h:69, from ./Modules/socketmodule.c:78: /usr/include/wchar.h:15: warning: function declaration isn't a prototype In file included from /usr/include/signal.h:46, from ./Modules/socketmodule.c:140: /usr/include/sys/signal.h:121: warning: function declaration isn't a prototype /usr/include/sys/signal.h:164: warning: function declaration isn't a prototype In file included from ./Modules/socketmodule.c:236: Modules/getaddrinfo.c:203: conflicting types for `gai_strerror' /usr/include/netdb.h:172: previous declaration of `gai_strerror' ./Modules/socketmodule.c: In function `PySocketSock_init': ./Modules/socketmodule.c:1818: warning: function declaration isn't a prototype ./Modules/socketmodule.c: In function `PySocket_fromfd': ./Modules/socketmodule.c:2304: warning: function declaration isn't a prototype gmake: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-01 01:28 Message: Logged In: YES user_id=21627 Thanks, I'm now giving up on getting the C library getaddrinfo to work on your system (I have no idea why it would fail in this place). Instead, I made the patch gai.diff, which should allow compilation of getaddrinfo.c on your system. Please report whether it works. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-11-30 08:24 Message: Logged In: YES user_id=85984 % gcc -o aicheck2 aicheck2.c % ./aicheck2 fail 11 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 01:35 Message: Logged In: YES user_id=21627 Arrghh. I was trying to find out which of the tests fail, but attached the wrong version of the file: I meant to put printfs into each failure. Please try aicheck2.c instead. Anyway, it seems that your system is indeed one of those where the test should find out problems with the C library (unless the test that fails is bogus, which we can investigate once we know what it is that fails). I'll try to come up with a patch that allows usage of the getaddrinfo emulation even on systems where getaddrinfo is in the C library. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-11-29 18:18 Message: Logged In: YES user_id=85984 aicheck.c compiled without problem on my system. % gcc -o aicheck aicheck.c % Running the resulting binary produces no output. I'm not exactly sure what kind of output you are looking for (taking a guess): % gdb /home/jason/temp/aicheck GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-bsdi4.0), Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)... (gdb) run Starting program: /home/jason/temp/aicheck (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Program exited with code 01. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-29 15:51 Message: Logged In: YES user_id=21627 Thansk for the files. I now trying to figure out why Python refuses to use the getaddrinfo implementation in your C library. It may be that it is really broken, in which case we must make getaddrinfo.c work correctly. Perhaps it ought to work,and configure just fails to correctly see that. So please compile the attached file aicheck.c on your system, and report output and status code (looking at $?); if it fails to compile, report the compile errors. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-11-28 12:21 Message: Logged In: YES user_id=85984 Attached are three files: - pyconfig.h from a fresh gcc 2.7.2.1 build - config.log from a fresh gcc 2.7.2.1 build - /usr/include/netdb.h - the getaddrinfo manual page from my system Indeed, EAI_ADDRFAMILY is defined in /usr/include/netdb.h, but EAI_MAX is not. Let me know if I can provide any more information. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-28 01:30 Message: Logged In: YES user_id=21627 Ok, then we need to investigate the configure results. Can you please attach pyconfig.h and config.log to this report? Also, can you please confirm that you build Python from scratch with 2.7.2.1 (i.e untarring a fresh source tree, to avoid using a config.cache left over from gcc 2.95.2)? Furthermore, can you please report details of the getaddrinfo implementation on your system? Does it provide one? In the C library? If not, can you confirm that EAI_ADDRFAMILY is defined in your system headers, but EAI_MAX is not? If yes, can you speculate as to why configure thinks your system does not have getaddrinfo? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-11-27 15:21 Message: Logged In: YES user_id=85984 I probably should have included the output from gcc 2.7.2.1 instead which I know is properly installed. The results are similar, although there is no mention of `wint_t': % gmake gcc -D_HAVE_BSDI -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from Include/pyport.h:93, from Include/Python.h:60, from ./Modules/socketmodule.c:78: /usr/include/math.h:177: warning: function declaration isn't a prototype /usr/include/math.h:257: warning: function declaration isn't a prototype In file included from Include/unicodeobject.h:118, from Include/Python.h:69, from ./Modules/socketmodule.c:78: /usr/include/wchar.h:15: warning: function declaration isn't a prototype In file included from /usr/include/signal.h:46, from ./Modules/socketmodule.c:140: /usr/include/sys/signal.h:121: warning: function declaration isn't a prototype /usr/include/sys/signal.h:164: warning: function declaration isn't a prototype Modules/getaddrinfo.c: In function `gai_strerror': In file included from ./Modules/socketmodule.c:236: Modules/getaddrinfo.c:205: `EAI_MAX' undeclared (first use this function) Modules/getaddrinfo.c:205: (Each undeclared identifier is reported only once Modules/getaddrinfo.c:205: for each function it appears in.) Modules/getaddrinfo.c: In function `getaddrinfo': Modules/getaddrinfo.c:285: `EAI_BADHINTS' undeclared (first use this function) Modules/getaddrinfo.c:286: `AI_MASK' undeclared (first use this function) Modules/getaddrinfo.c:376: `EAI_PROTOCOL' undeclared (first use this function) Modules/getaddrinfo.c:464: `AI_NUMERICHOST' undeclared (first use this function) ./Modules/socketmodule.c: In function `PySocketSock_init': ./Modules/socketmodule.c:1818: warning: function declaration isn't a prototype ./Modules/socketmodule.c: In function `PySocket_fromfd': ./Modules/socketmodule.c:2304: warning: function declaration isn't a prototype gmake: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-27 15:08 Message: Logged In: YES user_id=21627 Are you sure the compiler is properly installed? That you have wint_t definition both in wchar.h and stddef.h (as fixincluded by gcc) is not Python's doing; either the header files of your operating system are corrupt, or the compiler is broken. If you cannot figure out the details, please attach both header files to this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:07 Message: Logged In: YES user_id=31435 Assigned to Martin. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486099&group_id=5470 From noreply@sourceforge.net Sun Dec 2 13:03:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 05:03:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-485679 ] 2.2b2 Won't build on Solaris 2.8 Message-ID: Bugs item #485679, was opened at 2001-11-26 08:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485679&group_id=5470 Category: Build Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David M. Beazley (beazley) Assigned to: Martin v. Löwis (loewis) Summary: 2.2b2 Won't build on Solaris 2.8 Initial Comment: 2.2b2 doesn't build on Sparc Solaris 2.8 with gcc-2.95.2 and gmake-3.77. The following error occurs: make: *** No rule to make target `Python/thread_*.h', needed by `Python/thread.o'. Stop. This occurs with the standard build process (./configure; make). If I had to take a wild guess on this, perhaps the build process (configure or make) is using a non-portable feature of the shell and/or make. -- Dave ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 05:03 Message: Logged In: YES user_id=21627 This should be fixed in Makefile.pre.in 1.68, configure.in 1.283, configure 1.274. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-11-28 07:55 Message: Logged In: YES user_id=31392 Can you take a look Martin? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485679&group_id=5470 From noreply@sourceforge.net Sun Dec 2 13:16:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 05:16:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-487277 ] Different behavior of readline() Message-ID: Bugs item #487277, was opened at 2001-11-29 14:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487277&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Closed Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Tim Peters (tim_one) Summary: Different behavior of readline() Initial Comment: The behavior of readline() has changed on 2.2. This should be documented. Example: Python 2.1 (#1, Jun 22 2001, 17:13:13) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-i386 Type "copyright", "credits" or "license" for more information. >>> open("/etc").readline() '' Python 2.2b2+ (#1, Nov 27 2001, 21:39:35) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-ppc Type "help", "copyright", "credits" or "license" for more information. >>> open("/etc").readline() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 05:16 Message: Logged In: YES user_id=21627 Opening a directory is the only way, on Unix, to get its contents. The file descriptor returned is then passed to getdents(2) or readdir(2) (depending on the OS version). __builtins__.open doesn't fail because it calls fopen right away, which doesn't fail because it calls open(2) with just O_RDONLY and O_LARGEFILE, not with O_DIRECTORY. open(2) will then only return EISDIR if the directory is opened for writing. Since this is the behaviour documented in Posix, it is unlikely that Linux glibc will change. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 14:44 Message: Logged In: YES user_id=38388 For the record, this is what I get with Python 2.2b2 on Linux: >>> f = open('/home/lemburg/') >>> f.read() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory >>> f.readline() '' >>> f.readlines() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory >>> Reading the man-page for open(), it seems that directories play some role (though it's not clear which...): open() options: ... O_DIRECTORY If pathname is not a directory, cause the open to fail. This flag is Linux-specific, and was added in kernel version 2.1.126, to avoid denial-of-ser­ vice problems if opendir(3) is called on a FIFO or tape device, but should not be used outside of the implementation of opendir. errno values: ... EISDIR pathname refers to a directory and the access requested involved writing. EACCES The requested access to the file is not allowed, or one of the directories in pathname did not allow search (execute) permission, or the file did not exist yet and write access to the parent directory is not allowed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-30 14:26 Message: Logged In: YES user_id=31435 Does anyone know why opening a directory for reading doesn't complain on Linux? It has always complained on Windows. If readline() is doomed to fail, why do we allow opening a directory for reading at all? OTOH, if it's not insane to open a directory for reading on Linux, why does readline() complain on Linux? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 08:07 Message: Logged In: YES user_id=21627 No. I think very few of the changes will ever cause problems in real software - including this one. I wouldn't be surprised if this remains the only reported incidence of that change. I *am* saying that for every change that has been made, one could construct an application that breaks under this change. This theoretical potential for breakage shouldn't cause prominent appearance in documentation; everybody who really wants to see documentation for all changes should consult the CVS logs. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-11-30 06:15 Message: Logged In: YES user_id=7887 I beg your pardon. Are you saying that there are many changes in Python 2.2 that will blow up code written in Python 2.1!? Why do we have __future__ than!? Why are we concerned about being careful with division upgrade when we have lots of small stuff breaking up *valid* code written one release ago? And, if this was not enough, these changes won't even be documented!?! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 04:21 Message: Logged In: YES user_id=21627 Well, I wouldn't object to anybody documenting this particular change (even though I won't do that myself, either). I'm just pointing out that there are many more changes of this kind, and that it would be an illusion that you could ever produce a complete list. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 01:36 Message: Logged In: YES user_id=38388 I disagree: any change which could potentially blow up existing programs should at least be mentioned somewhere in the docs, be it the NEWS file, the release page on python.org or (thanks to the great work of Andrew Kuchling) the "What's new in Python x.x" docs. This is simply needed due to the very dynamic way Python works: there's no way to test all paths through a program if you want to port it from one Python version to the next, so we'll have to be very careful about these changes even if they are clearly bug fixes. In the mentioned case, I'd say that the programmer was at fault, though: it's so much easier to test a path for being a directory than to rely on some obscure method return value and also much safer ! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 01:19 Message: Logged In: YES user_id=21627 Any change is user-visible: for any change, I can construct a program that behaves differently with the change. Otherwise, the change would be useless (except that it may add commentary or some such). In fact, the change *is* documented, namely in the CVS log. Extracting all those fragments into a single document would be time-consuming and pointless: nobody can read through hundreds of changes. Your program would have blown up even if there was such a document. If a change has severe effects on many existing programs, it should be implemented differently. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-11-29 16:10 Message: Logged In: YES user_id=7887 I think *any* change visible at user space should be documented. I discovered this change because a program I have never read in my life (in fact, I didn't even know it was written in python) has blown up in my hands. It was reading files and safely ignoring directories by testing readline()'s output. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-29 15:53 Message: Logged In: YES user_id=21627 I don't think this needs to be documented. The change is a bug fix, reading from a directory was never supposed to work (whether in lines or not). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487277&group_id=5470 From noreply@sourceforge.net Sun Dec 2 20:18:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 12:18:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-487277 ] Different behavior of readline() Message-ID: Bugs item #487277, was opened at 2001-11-29 14:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487277&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) >Assigned to: Nobody/Anonymous (nobody) Summary: Different behavior of readline() Initial Comment: The behavior of readline() has changed on 2.2. This should be documented. Example: Python 2.1 (#1, Jun 22 2001, 17:13:13) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-i386 Type "copyright", "credits" or "license" for more information. >>> open("/etc").readline() '' Python 2.2b2+ (#1, Nov 27 2001, 21:39:35) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-ppc Type "help", "copyright", "credits" or "license" for more information. >>> open("/etc").readline() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-02 12:18 Message: Logged In: YES user_id=31435 Well, my question isn't really about libc but about Python: since Python doesn't expose getdents(2) or readdir (2), how could it be anything but a mistake for a Python user on Linux to try to __builtin__.open() a directory? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 05:16 Message: Logged In: YES user_id=21627 Opening a directory is the only way, on Unix, to get its contents. The file descriptor returned is then passed to getdents(2) or readdir(2) (depending on the OS version). __builtins__.open doesn't fail because it calls fopen right away, which doesn't fail because it calls open(2) with just O_RDONLY and O_LARGEFILE, not with O_DIRECTORY. open(2) will then only return EISDIR if the directory is opened for writing. Since this is the behaviour documented in Posix, it is unlikely that Linux glibc will change. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 14:44 Message: Logged In: YES user_id=38388 For the record, this is what I get with Python 2.2b2 on Linux: >>> f = open('/home/lemburg/') >>> f.read() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory >>> f.readline() '' >>> f.readlines() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory >>> Reading the man-page for open(), it seems that directories play some role (though it's not clear which...): open() options: ... O_DIRECTORY If pathname is not a directory, cause the open to fail. This flag is Linux-specific, and was added in kernel version 2.1.126, to avoid denial-of-ser­ vice problems if opendir(3) is called on a FIFO or tape device, but should not be used outside of the implementation of opendir. errno values: ... EISDIR pathname refers to a directory and the access requested involved writing. EACCES The requested access to the file is not allowed, or one of the directories in pathname did not allow search (execute) permission, or the file did not exist yet and write access to the parent directory is not allowed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-30 14:26 Message: Logged In: YES user_id=31435 Does anyone know why opening a directory for reading doesn't complain on Linux? It has always complained on Windows. If readline() is doomed to fail, why do we allow opening a directory for reading at all? OTOH, if it's not insane to open a directory for reading on Linux, why does readline() complain on Linux? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 08:07 Message: Logged In: YES user_id=21627 No. I think very few of the changes will ever cause problems in real software - including this one. I wouldn't be surprised if this remains the only reported incidence of that change. I *am* saying that for every change that has been made, one could construct an application that breaks under this change. This theoretical potential for breakage shouldn't cause prominent appearance in documentation; everybody who really wants to see documentation for all changes should consult the CVS logs. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-11-30 06:15 Message: Logged In: YES user_id=7887 I beg your pardon. Are you saying that there are many changes in Python 2.2 that will blow up code written in Python 2.1!? Why do we have __future__ than!? Why are we concerned about being careful with division upgrade when we have lots of small stuff breaking up *valid* code written one release ago? And, if this was not enough, these changes won't even be documented!?! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 04:21 Message: Logged In: YES user_id=21627 Well, I wouldn't object to anybody documenting this particular change (even though I won't do that myself, either). I'm just pointing out that there are many more changes of this kind, and that it would be an illusion that you could ever produce a complete list. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 01:36 Message: Logged In: YES user_id=38388 I disagree: any change which could potentially blow up existing programs should at least be mentioned somewhere in the docs, be it the NEWS file, the release page on python.org or (thanks to the great work of Andrew Kuchling) the "What's new in Python x.x" docs. This is simply needed due to the very dynamic way Python works: there's no way to test all paths through a program if you want to port it from one Python version to the next, so we'll have to be very careful about these changes even if they are clearly bug fixes. In the mentioned case, I'd say that the programmer was at fault, though: it's so much easier to test a path for being a directory than to rely on some obscure method return value and also much safer ! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 01:19 Message: Logged In: YES user_id=21627 Any change is user-visible: for any change, I can construct a program that behaves differently with the change. Otherwise, the change would be useless (except that it may add commentary or some such). In fact, the change *is* documented, namely in the CVS log. Extracting all those fragments into a single document would be time-consuming and pointless: nobody can read through hundreds of changes. Your program would have blown up even if there was such a document. If a change has severe effects on many existing programs, it should be implemented differently. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-11-29 16:10 Message: Logged In: YES user_id=7887 I think *any* change visible at user space should be documented. I discovered this change because a program I have never read in my life (in fact, I didn't even know it was written in python) has blown up in my hands. It was reading files and safely ignoring directories by testing readline()'s output. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-29 15:53 Message: Logged In: YES user_id=21627 I don't think this needs to be documented. The change is a bug fix, reading from a directory was never supposed to work (whether in lines or not). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487277&group_id=5470 From noreply@sourceforge.net Sun Dec 2 20:27:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 12:27:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-477728 ] .*? matches newlines without DOTALL Message-ID: Bugs item #477728, was opened at 2001-11-02 22:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477728&group_id=5470 Category: Regular Expressions Group: Python 2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Fredrik Lundh (effbot) Summary: .*? matches newlines without DOTALL Initial Comment: ython 2.2b1+ (#25, Oct 30 2001, 22:36:33) [MSC 32 bit (Intel)] on win32 >> text = "one\ntwo\nthree\n" >> import re >> re.match(r'.*?$', text) SRE_Match object at 0x007AD940> >> _.group(0) # oops! one\ntwo\nthree' >> re.match(r'.*$', text) # more like it >> Since . shouldn't match a newline in the absence of re.DOTALL, .*? shouldn't match any newlines, and then minimal match should have failed (as did the maximal match). Found by Bruce Eckel. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-02 12:27 Message: Logged In: YES user_id=31435 Boosted priority: /F, what's the hangup here? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477728&group_id=5470 From noreply@sourceforge.net Sun Dec 2 20:28:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 12:28:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-477728 ] .*? matches newlines without DOTALL Message-ID: Bugs item #477728, was opened at 2001-11-02 22:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477728&group_id=5470 Category: Regular Expressions Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Fredrik Lundh (effbot) Summary: .*? matches newlines without DOTALL Initial Comment: ython 2.2b1+ (#25, Oct 30 2001, 22:36:33) [MSC 32 bit (Intel)] on win32 >> text = "one\ntwo\nthree\n" >> import re >> re.match(r'.*?$', text) SRE_Match object at 0x007AD940> >> _.group(0) # oops! one\ntwo\nthree' >> re.match(r'.*$', text) # more like it >> Since . shouldn't match a newline in the absence of re.DOTALL, .*? shouldn't match any newlines, and then minimal match should have failed (as did the maximal match). Found by Bruce Eckel. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-02 12:28 Message: Logged In: YES user_id=31435 Boosted priority: /F, what's the hangup here? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-02 12:27 Message: Logged In: YES user_id=31435 Boosted priority: /F, what's the hangup here? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477728&group_id=5470 From noreply@sourceforge.net Sun Dec 2 21:08:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 13:08:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-485554 ] Copy menu not enabled Message-ID: Bugs item #485554, was opened at 2001-11-26 02:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485554&group_id=5470 Category: Macintosh Group: None >Status: Closed Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Copy menu not enabled Initial Comment: The "copy" menu command on the console window never seems to be enabled, as of recently (2.2b2). "Paste" is fine. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-02 13:08 Message: Logged In: YES user_id=45365 Fixed in the second build of MacPython 2.2b2. A trace of this bug remains, in that copy still does not work in a console window that was created after an applet crashed, but I will not fix that bug for now. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485554&group_id=5470 From noreply@sourceforge.net Sun Dec 2 21:09:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 13:09:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-487297 ] Copy from stdout after crash Message-ID: Bugs item #487297, was opened at 2001-11-29 15:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487297&group_id=5470 Category: Macintosh Group: Feature Request Status: Open Resolution: None >Priority: 3 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jack Jansen (jackjansen) Summary: Copy from stdout after crash Initial Comment: It would be really nice if one could copy text from the stdout window (e.g. PythonInterpreter.out) after a crash. Apparently this now works in some cases, but still fails after a crash in a delay-console-window applet. I am submitting this to SourceForge as per Jack Jansens' request. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-02 13:09 Message: Logged In: YES user_id=45365 Lowered the priority. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487297&group_id=5470 From noreply@sourceforge.net Sun Dec 2 21:12:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 13:12:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-478851 ] Generates KeyboardInterrupt in bg Message-ID: Bugs item #478851, was opened at 2001-11-06 12:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478851&group_id=5470 Category: Macintosh Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Generates KeyboardInterrupt in bg Initial Comment: The code in MacPython to check for command-period looks in the low-level event queue, but ignores whether MacPython is in the foreground or not. Therefore interrupting any program will potentially also interrupt a MacPython running in the background. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-02 13:12 Message: Logged In: YES user_id=45365 Fixed in 2.2b2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478851&group_id=5470 From noreply@sourceforge.net Sun Dec 2 22:15:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 14:15:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-478428 ] dbm build fails Message-ID: Bugs item #478428, was opened at 2001-11-05 12:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478428&group_id=5470 Category: Macintosh Group: Python 2.2 >Status: Closed Resolution: None Priority: 5 Submitted By: John Buell (dadaist) Assigned to: Jack Jansen (jackjansen) Summary: dbm build fails Initial Comment: Trying a build with cvs source downloaded this morning. I've been sure to do the configure --with-suffix=_ on case-insensitive Mac OS X (10.1), but I'm having some problem with the 'dbm' module. Here's a copy of the messages: building 'dbm' extension /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c: In function `dbm_subscript': /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c:104: warning: implicit declaration of function `dbm_error' /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c:105: warning: implicit declaration of function `dbm_clearerr' cc -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -I. -I/Users/jbuell/Documents/Python/python/dist/src/./Include -I/Users/jbuell/Documents/Python/python/dist/src/./Mac/Include -I/usr/local/include -IInclude/ -c /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c -o build/temp.darwin-1.4-Power Macintosh-2.2/dbmmodule.o cc -bundle -flat_namespace -undefined suppress build/temp.darwin-1.4-Power Macintosh-2.2/dbmmodule.o -L/usr/local/lib -o build/lib.darwin-1.4-Power Macintosh-2.2/dbm.so building 'gdbm' extension dyld: ./python_ Undefined symbols: __ashldi3 make: *** [sharedmods] Error 67 Any suggestions? Anything I can change in my settings to get past this? -John ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-02 14:15 Message: Logged In: YES user_id=45365 As the originator didn't follow up on my previous remark and everything works fine for me I'm closing this bug. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-06 12:45 Message: Logged In: YES user_id=45365 Note that the problem is with gdbm, not with dbm. Dbm seems to build fine (with a warning). I've heard a report of this before. Needless to say, for me there is no problem whatsoever:-) I think that the problem is that setup.py detects files that indicate to it that dbm is available while in fact it is not. Could you check whether you have a libgdbm.a and/or a gdbm.h on your system somewhere? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478428&group_id=5470 From noreply@sourceforge.net Sun Dec 2 22:19:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 14:19:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-488184 ] import with undefineds can crash python Message-ID: Bugs item #488184, was opened at 2001-12-02 14:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488184&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 6 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: import with undefineds can crash python Initial Comment: Importing a module which references undefined externals, or which references libraries that fail initialization, can crash the interpreter. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488184&group_id=5470 From noreply@sourceforge.net Sun Dec 2 23:57:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 15:57:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-487152 ] Framework reports wrong sys.executable Message-ID: Bugs item #487152, was opened at 2001-11-29 10:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487152&group_id=5470 Category: Macintosh Group: Platform-specific >Status: Closed Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jack Jansen (jackjansen) Summary: Framework reports wrong sys.executable Initial Comment: I've run in to this a couple of times since I have been using Python exclusively on OS X built as a Framework. When built and installed as a framework, python reports that sys.executable is: /Library/Frameworks/Python.framework/Versions/ 2.2/Python Which may or may not be technically right. But since certain scripts assume they can execute the value of sys.executable to get a new python interpreter, they fail. Instead, they need to be pointed to /Library/Frameworks/Python.framework/Versions/ 2.2/bin/python.exe Not sure if and how this can be fixed, but it would be nice. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-02 15:57 Message: Logged In: YES user_id=45365 Fixed in Modules/getpath.c rev 1.40. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487152&group_id=5470 From noreply@sourceforge.net Mon Dec 3 00:08:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 16:08:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-485678 ] Use of __del__ on descriptors ambiguous Message-ID: Bugs item #485678, was opened at 2001-11-26 08:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485678&group_id=5470 Category: Type/class unification Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Use of __del__ on descriptors ambiguous Initial Comment: When deleting an attribute described by a descriptor implemented in Python, the descriptor's __del__ method is called by the slot_tp_descr_set dispatch function. This is bogus -- __del__ already has a different meaning. This should be renamed to __delete__. (XXX Should we also rename __get__ and __set__ to something more descriptive, e.g. __descr_get__ and and __descr_set__? Or maybe we should use __prop_ as a prefix?) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-02 16:08 Message: Logged In: YES user_id=6380 Checked in, typeobject.c 2.119. No, I'm not renaming the others. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-28 21:44 Message: Logged In: YES user_id=6380 Here's a patch that renames the method to __delete__. Anyone got problems with checking this in? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485678&group_id=5470 From noreply@sourceforge.net Mon Dec 3 04:27:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 20:27:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-488264 ] Generators should be in the document Message-ID: Bugs item #488264, was opened at 2001-12-02 20:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488264&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Generators should be in the document Initial Comment: The yield statement should appear in the list of statements, and generators should be described either there or in the futuress section of the document. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488264&group_id=5470 From noreply@sourceforge.net Mon Dec 3 06:12:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 02 Dec 2001 22:12:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-487308 ] Tkinter class links broken/missing Message-ID: Bugs item #487308, was opened at 2001-11-29 16:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487308&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Tkinter class links broken/missing Initial Comment: This page of the development documentation: http://www.python.org/doc/2.2/lib/node500.html has links which should lead to the interfaces of the widgets listed. However, the links result in 404 errors. (The individual widget pages also appear to be missing from the Windows 2.2b2 distribution. At any rate, they are missing from the HTML help file I compiled using the .html files from the distribution). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-02 22:12 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/tkinter.tex revision 1.8. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487308&group_id=5470 From noreply@sourceforge.net Mon Dec 3 09:02:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 01:02:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-487277 ] Different behavior of readline() Message-ID: Bugs item #487277, was opened at 2001-11-29 14:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487277&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Nobody/Anonymous (nobody) Summary: Different behavior of readline() Initial Comment: The behavior of readline() has changed on 2.2. This should be documented. Example: Python 2.1 (#1, Jun 22 2001, 17:13:13) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-i386 Type "copyright", "credits" or "license" for more information. >>> open("/etc").readline() '' Python 2.2b2+ (#1, Nov 27 2001, 21:39:35) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-ppc Type "help", "copyright", "credits" or "license" for more information. >>> open("/etc").readline() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-03 01:02 Message: Logged In: YES user_id=21627 I agree that Python should not allow to open a directory. Attached is a patch that implements this check; it is somewhat more involved since it must also check file object that are created through PyFile_FromFile etc. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-02 12:18 Message: Logged In: YES user_id=31435 Well, my question isn't really about libc but about Python: since Python doesn't expose getdents(2) or readdir (2), how could it be anything but a mistake for a Python user on Linux to try to __builtin__.open() a directory? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 05:16 Message: Logged In: YES user_id=21627 Opening a directory is the only way, on Unix, to get its contents. The file descriptor returned is then passed to getdents(2) or readdir(2) (depending on the OS version). __builtins__.open doesn't fail because it calls fopen right away, which doesn't fail because it calls open(2) with just O_RDONLY and O_LARGEFILE, not with O_DIRECTORY. open(2) will then only return EISDIR if the directory is opened for writing. Since this is the behaviour documented in Posix, it is unlikely that Linux glibc will change. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 14:44 Message: Logged In: YES user_id=38388 For the record, this is what I get with Python 2.2b2 on Linux: >>> f = open('/home/lemburg/') >>> f.read() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory >>> f.readline() '' >>> f.readlines() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory >>> Reading the man-page for open(), it seems that directories play some role (though it's not clear which...): open() options: ... O_DIRECTORY If pathname is not a directory, cause the open to fail. This flag is Linux-specific, and was added in kernel version 2.1.126, to avoid denial-of-ser­ vice problems if opendir(3) is called on a FIFO or tape device, but should not be used outside of the implementation of opendir. errno values: ... EISDIR pathname refers to a directory and the access requested involved writing. EACCES The requested access to the file is not allowed, or one of the directories in pathname did not allow search (execute) permission, or the file did not exist yet and write access to the parent directory is not allowed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-30 14:26 Message: Logged In: YES user_id=31435 Does anyone know why opening a directory for reading doesn't complain on Linux? It has always complained on Windows. If readline() is doomed to fail, why do we allow opening a directory for reading at all? OTOH, if it's not insane to open a directory for reading on Linux, why does readline() complain on Linux? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 08:07 Message: Logged In: YES user_id=21627 No. I think very few of the changes will ever cause problems in real software - including this one. I wouldn't be surprised if this remains the only reported incidence of that change. I *am* saying that for every change that has been made, one could construct an application that breaks under this change. This theoretical potential for breakage shouldn't cause prominent appearance in documentation; everybody who really wants to see documentation for all changes should consult the CVS logs. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-11-30 06:15 Message: Logged In: YES user_id=7887 I beg your pardon. Are you saying that there are many changes in Python 2.2 that will blow up code written in Python 2.1!? Why do we have __future__ than!? Why are we concerned about being careful with division upgrade when we have lots of small stuff breaking up *valid* code written one release ago? And, if this was not enough, these changes won't even be documented!?! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 04:21 Message: Logged In: YES user_id=21627 Well, I wouldn't object to anybody documenting this particular change (even though I won't do that myself, either). I'm just pointing out that there are many more changes of this kind, and that it would be an illusion that you could ever produce a complete list. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 01:36 Message: Logged In: YES user_id=38388 I disagree: any change which could potentially blow up existing programs should at least be mentioned somewhere in the docs, be it the NEWS file, the release page on python.org or (thanks to the great work of Andrew Kuchling) the "What's new in Python x.x" docs. This is simply needed due to the very dynamic way Python works: there's no way to test all paths through a program if you want to port it from one Python version to the next, so we'll have to be very careful about these changes even if they are clearly bug fixes. In the mentioned case, I'd say that the programmer was at fault, though: it's so much easier to test a path for being a directory than to rely on some obscure method return value and also much safer ! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 01:19 Message: Logged In: YES user_id=21627 Any change is user-visible: for any change, I can construct a program that behaves differently with the change. Otherwise, the change would be useless (except that it may add commentary or some such). In fact, the change *is* documented, namely in the CVS log. Extracting all those fragments into a single document would be time-consuming and pointless: nobody can read through hundreds of changes. Your program would have blown up even if there was such a document. If a change has severe effects on many existing programs, it should be implemented differently. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-11-29 16:10 Message: Logged In: YES user_id=7887 I think *any* change visible at user space should be documented. I discovered this change because a program I have never read in my life (in fact, I didn't even know it was written in python) has blown up in my hands. It was reading files and safely ignoring directories by testing readline()'s output. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-29 15:53 Message: Logged In: YES user_id=21627 I don't think this needs to be documented. The change is a bug fix, reading from a directory was never supposed to work (whether in lines or not). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487277&group_id=5470 From noreply@sourceforge.net Mon Dec 3 10:47:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 02:47:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-487703 ] Replace strcat, strcpy Message-ID: Bugs item #487703, was opened at 2001-11-30 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487703&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Replace strcat, strcpy Initial Comment: Alex Martelli sent this URL for a paper describing the safer strlcat and strlcpy functions: >http://www.usenix.org/events/usenix99/full_papers/mill ert/millert_html/> ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-03 02:47 Message: Logged In: YES user_id=38388 Time for PyOS_strlcat() and PyOS_strlcpy() ? Looking at the web-site it seems that we could simply copy the code into the Python distro. I'd then suggest to bundle all the string helpers into a new file: e.g. mystrapis.c. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487703&group_id=5470 From noreply@sourceforge.net Mon Dec 3 10:59:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 02:59:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-476326 ] Unicode and imp.find_module Message-ID: Bugs item #476326, was opened at 2001-10-30 03:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 3 Submitted By: Paul Boddie (pboddie) Assigned to: M.-A. Lemburg (lemburg) Summary: Unicode and imp.find_module Initial Comment: When a Unicode string is passed as the module name to imp.find_module, the function fails to import the named module even when it exists in the specified path, returning the error message "No module named ..." as a result. The problem in Python 2.0 can be traced to line 922 of Python/import.c which ensures that any strings involved in the find_module function must be standard Python strings and not Unicode strings, since it tests the type of path components against &PyString_Type explicitly. Interestingly, the __import__ built-in function seems to work with Unicode strings. Either way, it would be great if this could be documented or even fixed, but I don't know what the policy is on Unicode module names (even when they only contain ASCII-compatible characters). ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2001-12-03 02:59 Message: Logged In: YES user_id=226443 For my purposes, I just wrapped the module name in a 'str' function call. I had Unicode strings because I was using text from an XML document and then attempting to use such text with the import mechanism. One issue is whether Python would ever support importing from files which have non-ASCII filenames. I can imagine that certain operating systems support Unicode filenames, for example, but then the Python language probably doesn't support such filenames as the basis for module names when used with the 'import' statement and other related statements. So, there's a wider issue of text encodings in (C)Python scripts as part of the "comprehensive" solution to this problem; the easy solution is just to enforce ASCII-only module names. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-01 15:01 Message: Logged In: YES user_id=38388 I guess Python should not except non-ASCII module names, so conversion of Unicode to ASCII should be appropriate. Would it suffice to only test this in find_module() or do you think that I need to dig deeper into the import mechanism ? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 From noreply@sourceforge.net Mon Dec 3 12:21:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 04:21:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-488387 ] PyErr_Format result type Message-ID: Bugs item #488387, was opened at 2001-12-03 04:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488387&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PyErr_Format result type Initial Comment: In the Python/C API (Exception Handling), the last sentence of the topic for PyErr_Format is wrong (the function always returns NULL, as indicated at the top of the topic). Also, the next-to-last sentence probably should refer to the "error string" (or similar), rather than the "result string". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488387&group_id=5470 From noreply@sourceforge.net Mon Dec 3 13:03:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 05:03:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-487277 ] Different behavior of readline() Message-ID: Bugs item #487277, was opened at 2001-11-29 14:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487277&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Nobody/Anonymous (nobody) Summary: Different behavior of readline() Initial Comment: The behavior of readline() has changed on 2.2. This should be documented. Example: Python 2.1 (#1, Jun 22 2001, 17:13:13) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-i386 Type "copyright", "credits" or "license" for more information. >>> open("/etc").readline() '' Python 2.2b2+ (#1, Nov 27 2001, 21:39:35) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-ppc Type "help", "copyright", "credits" or "license" for more information. >>> open("/etc").readline() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-03 05:03 Message: Logged In: YES user_id=6380 I take it that this needn't be included in 2.2? Who knows what it would break. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-03 01:02 Message: Logged In: YES user_id=21627 I agree that Python should not allow to open a directory. Attached is a patch that implements this check; it is somewhat more involved since it must also check file object that are created through PyFile_FromFile etc. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-02 12:18 Message: Logged In: YES user_id=31435 Well, my question isn't really about libc but about Python: since Python doesn't expose getdents(2) or readdir (2), how could it be anything but a mistake for a Python user on Linux to try to __builtin__.open() a directory? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 05:16 Message: Logged In: YES user_id=21627 Opening a directory is the only way, on Unix, to get its contents. The file descriptor returned is then passed to getdents(2) or readdir(2) (depending on the OS version). __builtins__.open doesn't fail because it calls fopen right away, which doesn't fail because it calls open(2) with just O_RDONLY and O_LARGEFILE, not with O_DIRECTORY. open(2) will then only return EISDIR if the directory is opened for writing. Since this is the behaviour documented in Posix, it is unlikely that Linux glibc will change. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 14:44 Message: Logged In: YES user_id=38388 For the record, this is what I get with Python 2.2b2 on Linux: >>> f = open('/home/lemburg/') >>> f.read() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory >>> f.readline() '' >>> f.readlines() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory >>> Reading the man-page for open(), it seems that directories play some role (though it's not clear which...): open() options: ... O_DIRECTORY If pathname is not a directory, cause the open to fail. This flag is Linux-specific, and was added in kernel version 2.1.126, to avoid denial-of-ser­ vice problems if opendir(3) is called on a FIFO or tape device, but should not be used outside of the implementation of opendir. errno values: ... EISDIR pathname refers to a directory and the access requested involved writing. EACCES The requested access to the file is not allowed, or one of the directories in pathname did not allow search (execute) permission, or the file did not exist yet and write access to the parent directory is not allowed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-30 14:26 Message: Logged In: YES user_id=31435 Does anyone know why opening a directory for reading doesn't complain on Linux? It has always complained on Windows. If readline() is doomed to fail, why do we allow opening a directory for reading at all? OTOH, if it's not insane to open a directory for reading on Linux, why does readline() complain on Linux? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 08:07 Message: Logged In: YES user_id=21627 No. I think very few of the changes will ever cause problems in real software - including this one. I wouldn't be surprised if this remains the only reported incidence of that change. I *am* saying that for every change that has been made, one could construct an application that breaks under this change. This theoretical potential for breakage shouldn't cause prominent appearance in documentation; everybody who really wants to see documentation for all changes should consult the CVS logs. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-11-30 06:15 Message: Logged In: YES user_id=7887 I beg your pardon. Are you saying that there are many changes in Python 2.2 that will blow up code written in Python 2.1!? Why do we have __future__ than!? Why are we concerned about being careful with division upgrade when we have lots of small stuff breaking up *valid* code written one release ago? And, if this was not enough, these changes won't even be documented!?! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 04:21 Message: Logged In: YES user_id=21627 Well, I wouldn't object to anybody documenting this particular change (even though I won't do that myself, either). I'm just pointing out that there are many more changes of this kind, and that it would be an illusion that you could ever produce a complete list. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 01:36 Message: Logged In: YES user_id=38388 I disagree: any change which could potentially blow up existing programs should at least be mentioned somewhere in the docs, be it the NEWS file, the release page on python.org or (thanks to the great work of Andrew Kuchling) the "What's new in Python x.x" docs. This is simply needed due to the very dynamic way Python works: there's no way to test all paths through a program if you want to port it from one Python version to the next, so we'll have to be very careful about these changes even if they are clearly bug fixes. In the mentioned case, I'd say that the programmer was at fault, though: it's so much easier to test a path for being a directory than to rely on some obscure method return value and also much safer ! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 01:19 Message: Logged In: YES user_id=21627 Any change is user-visible: for any change, I can construct a program that behaves differently with the change. Otherwise, the change would be useless (except that it may add commentary or some such). In fact, the change *is* documented, namely in the CVS log. Extracting all those fragments into a single document would be time-consuming and pointless: nobody can read through hundreds of changes. Your program would have blown up even if there was such a document. If a change has severe effects on many existing programs, it should be implemented differently. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-11-29 16:10 Message: Logged In: YES user_id=7887 I think *any* change visible at user space should be documented. I discovered this change because a program I have never read in my life (in fact, I didn't even know it was written in python) has blown up in my hands. It was reading files and safely ignoring directories by testing readline()'s output. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-29 15:53 Message: Logged In: YES user_id=21627 I don't think this needs to be documented. The change is a bug fix, reading from a directory was never supposed to work (whether in lines or not). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487277&group_id=5470 From noreply@sourceforge.net Mon Dec 3 14:22:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 06:22:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-487277 ] Different behavior of readline() Message-ID: Bugs item #487277, was opened at 2001-11-29 14:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487277&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Nobody/Anonymous (nobody) Summary: Different behavior of readline() Initial Comment: The behavior of readline() has changed on 2.2. This should be documented. Example: Python 2.1 (#1, Jun 22 2001, 17:13:13) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-i386 Type "copyright", "credits" or "license" for more information. >>> open("/etc").readline() '' Python 2.2b2+ (#1, Nov 27 2001, 21:39:35) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-ppc Type "help", "copyright", "credits" or "license" for more information. >>> open("/etc").readline() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-03 06:22 Message: Logged In: YES user_id=21627 Yes, changing it later is fine. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-03 05:03 Message: Logged In: YES user_id=6380 I take it that this needn't be included in 2.2? Who knows what it would break. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-03 01:02 Message: Logged In: YES user_id=21627 I agree that Python should not allow to open a directory. Attached is a patch that implements this check; it is somewhat more involved since it must also check file object that are created through PyFile_FromFile etc. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-02 12:18 Message: Logged In: YES user_id=31435 Well, my question isn't really about libc but about Python: since Python doesn't expose getdents(2) or readdir (2), how could it be anything but a mistake for a Python user on Linux to try to __builtin__.open() a directory? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 05:16 Message: Logged In: YES user_id=21627 Opening a directory is the only way, on Unix, to get its contents. The file descriptor returned is then passed to getdents(2) or readdir(2) (depending on the OS version). __builtins__.open doesn't fail because it calls fopen right away, which doesn't fail because it calls open(2) with just O_RDONLY and O_LARGEFILE, not with O_DIRECTORY. open(2) will then only return EISDIR if the directory is opened for writing. Since this is the behaviour documented in Posix, it is unlikely that Linux glibc will change. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 14:44 Message: Logged In: YES user_id=38388 For the record, this is what I get with Python 2.2b2 on Linux: >>> f = open('/home/lemburg/') >>> f.read() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory >>> f.readline() '' >>> f.readlines() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory >>> Reading the man-page for open(), it seems that directories play some role (though it's not clear which...): open() options: ... O_DIRECTORY If pathname is not a directory, cause the open to fail. This flag is Linux-specific, and was added in kernel version 2.1.126, to avoid denial-of-ser­ vice problems if opendir(3) is called on a FIFO or tape device, but should not be used outside of the implementation of opendir. errno values: ... EISDIR pathname refers to a directory and the access requested involved writing. EACCES The requested access to the file is not allowed, or one of the directories in pathname did not allow search (execute) permission, or the file did not exist yet and write access to the parent directory is not allowed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-30 14:26 Message: Logged In: YES user_id=31435 Does anyone know why opening a directory for reading doesn't complain on Linux? It has always complained on Windows. If readline() is doomed to fail, why do we allow opening a directory for reading at all? OTOH, if it's not insane to open a directory for reading on Linux, why does readline() complain on Linux? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 08:07 Message: Logged In: YES user_id=21627 No. I think very few of the changes will ever cause problems in real software - including this one. I wouldn't be surprised if this remains the only reported incidence of that change. I *am* saying that for every change that has been made, one could construct an application that breaks under this change. This theoretical potential for breakage shouldn't cause prominent appearance in documentation; everybody who really wants to see documentation for all changes should consult the CVS logs. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-11-30 06:15 Message: Logged In: YES user_id=7887 I beg your pardon. Are you saying that there are many changes in Python 2.2 that will blow up code written in Python 2.1!? Why do we have __future__ than!? Why are we concerned about being careful with division upgrade when we have lots of small stuff breaking up *valid* code written one release ago? And, if this was not enough, these changes won't even be documented!?! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 04:21 Message: Logged In: YES user_id=21627 Well, I wouldn't object to anybody documenting this particular change (even though I won't do that myself, either). I'm just pointing out that there are many more changes of this kind, and that it would be an illusion that you could ever produce a complete list. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 01:36 Message: Logged In: YES user_id=38388 I disagree: any change which could potentially blow up existing programs should at least be mentioned somewhere in the docs, be it the NEWS file, the release page on python.org or (thanks to the great work of Andrew Kuchling) the "What's new in Python x.x" docs. This is simply needed due to the very dynamic way Python works: there's no way to test all paths through a program if you want to port it from one Python version to the next, so we'll have to be very careful about these changes even if they are clearly bug fixes. In the mentioned case, I'd say that the programmer was at fault, though: it's so much easier to test a path for being a directory than to rely on some obscure method return value and also much safer ! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 01:19 Message: Logged In: YES user_id=21627 Any change is user-visible: for any change, I can construct a program that behaves differently with the change. Otherwise, the change would be useless (except that it may add commentary or some such). In fact, the change *is* documented, namely in the CVS log. Extracting all those fragments into a single document would be time-consuming and pointless: nobody can read through hundreds of changes. Your program would have blown up even if there was such a document. If a change has severe effects on many existing programs, it should be implemented differently. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-11-29 16:10 Message: Logged In: YES user_id=7887 I think *any* change visible at user space should be documented. I discovered this change because a program I have never read in my life (in fact, I didn't even know it was written in python) has blown up in my hands. It was reading files and safely ignoring directories by testing readline()'s output. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-29 15:53 Message: Logged In: YES user_id=21627 I don't think this needs to be documented. The change is a bug fix, reading from a directory was never supposed to work (whether in lines or not). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487277&group_id=5470 From noreply@sourceforge.net Mon Dec 3 14:36:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 06:36:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-488420 ] Search Python Docs script broken Message-ID: Bugs item #488420, was opened at 2001-12-03 06:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488420&group_id=5470 Category: Macintosh Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason Harper (jasonharper) Assigned to: Jack Jansen (jackjansen) Summary: Search Python Docs script broken Initial Comment: The "Search Python Documentation" IDE script is broken in 2.2b2. It uses PyDocSearch.py, which imports some AppleEvent suites that are no longer in the same location. Near the top of the file: import Standard_Suite import Required_Suite import WWW_Suite The first two are now in the StdSuites package rather than being directly on sys.path. WWW_Suite doesn't seem to exist anymore (at least not with that exact name), so I'm not exactly sure how to fix this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488420&group_id=5470 From noreply@sourceforge.net Mon Dec 3 14:51:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 06:51:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-488420 ] Search Python Docs script broken Message-ID: Bugs item #488420, was opened at 2001-12-03 06:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488420&group_id=5470 Category: Macintosh Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason Harper (jasonharper) >Assigned to: Just van Rossum (jvr) Summary: Search Python Docs script broken Initial Comment: The "Search Python Documentation" IDE script is broken in 2.2b2. It uses PyDocSearch.py, which imports some AppleEvent suites that are no longer in the same location. Near the top of the file: import Standard_Suite import Required_Suite import WWW_Suite The first two are now in the StdSuites package rather than being directly on sys.path. WWW_Suite doesn't seem to exist anymore (at least not with that exact name), so I'm not exactly sure how to fix this. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-03 06:51 Message: Logged In: YES user_id=45365 Just, I think this is more in your ballpark. If you disagree assign it back. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488420&group_id=5470 From noreply@sourceforge.net Mon Dec 3 16:33:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 08:33:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-475877 ] Mutable subtype instances are hashable Message-ID: Bugs item #475877, was opened at 2001-10-28 19:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=475877&group_id=5470 Category: Type/class unification Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Guido van Rossum (gvanrossum) Summary: Mutable subtype instances are hashable Initial Comment: >>> class D(dictionary): pass ... >>> d = D() >>> hash(d) 7920544 >>> id(d) 7920544 >>> Ditto for instances of list subclasses: >>> class L(list): pass ... >>> x = L(range(100)) >>> hash(x) 7928992 >>> id(x) 7928992 >>> Among other nasties, this lets them get used as mutable dict keys. Reported by Mark J on c.l.py: """ From: Mark J Sent: Sunday, October 28, 2001 10:03 PM To: python-list@python.org Subject: Python 2.2b1 hashable dictionary bug? Since I haven't had a good hit rate at detecting bugs vs. features, I thought I'd post here before filing a bug report at SourceForge. Python 2.2b1 (#1, Oct 19 2001, 23:11:09) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class D(dictionary): pass ... >>> d = {} >>> d2 = D() >>> d[d2] = "dictionary used as key" >>> d {{}: 'dictionary used as key'} >>> d[D()]="now have two keys that look the same" >>> d {{}: 'now have two keys that look the same', {}: 'dictionary used as key'} >>> d2["key"] = "mutable key in d" >>> d {{}: 'now have two keys that look the same', {'key': 'mutable key in d'}: 'dictionary used as key'} >>> d[d] = "plain dictionary not allowed as key" Traceback (most recent call last): File "", line 1, in ? TypeError: unhashable type >>> d2[d2] = "subclassed dictionary allowed though" >>> d2 {{...}: 'subclassed dictionary allowed though', 'key': 'mutable keys'} >>> #whoa: what just happened: {...} ?? Interesting.... So is this a feature or a bug? """ ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-03 08:33 Message: Logged In: YES user_id=6380 Fixed by adding a hash function to list and dict types that raises an error. This was by far the simplest solution. See checkin comments for discussion (there are plusses and minuses to this approach). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 13:33 Message: Logged In: YES user_id=31435 Assigned to Guido, since he admitted to thinking about it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-29 11:39 Message: Logged In: YES user_id=6380 Interestingly, in Python list.__hash__ is the same as object.__hash__, but in C, list.tp_hash is NULL while object.tp_hash is not. I think that the best solution is to somehow program an exception into add_operators that adds a dummy __hash__ wrapper (which always raises an exception) when the tp_hash field is found to be NULL. (Note that inherit_slots already contains special-casing for tp_hash.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-28 23:36 Message: Logged In: YES user_id=6380 There's an admin setting that auto-assigns certain categories. Documentation gets auto-assugned to Fred; type/class to me; Regular Expressions to Effbot I believe. The hash(sys.stdin) result is expected; files are compared by address and so their hash() is derived from their address too. I'll think about the real issue; this has to do with the way the hash stub gets set. I'm not sure yet whether this is best fixed by adding more code to slot_tp_hash or to the code that sticks slot_to_hash in the tp_hash slot. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-28 19:33 Message: Logged In: YES user_id=31435 I swear I didn't assign this to Guido -- I intended to leave this unassigned for now. That's the second time in two weeks I believe SF made up an assignment on one of my reports. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-28 19:28 Message: Logged In: YES user_id=31435 Jeez, hash() has gone off the deep end: >>> import sys >>> hash(sys.stdin) 7690032 >>> ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=475877&group_id=5470 From noreply@sourceforge.net Mon Dec 3 16:37:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 08:37:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-488387 ] PyErr_Format result type Message-ID: Bugs item #488387, was opened at 2001-12-03 04:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488387&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PyErr_Format result type Initial Comment: In the Python/C API (Exception Handling), the last sentence of the topic for PyErr_Format is wrong (the function always returns NULL, as indicated at the top of the topic). Also, the next-to-last sentence probably should refer to the "error string" (or similar), rather than the "result string". ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-03 08:37 Message: Logged In: YES user_id=3066 Fixed in Doc/api/exceptions.tex revision 1.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488387&group_id=5470 From noreply@sourceforge.net Mon Dec 3 17:05:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 09:05:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-475877 ] Mutable subtype instances are hashable Message-ID: Bugs item #475877, was opened at 2001-10-28 19:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=475877&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Closed Resolution: Fixed Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Guido van Rossum (gvanrossum) Summary: Mutable subtype instances are hashable Initial Comment: >>> class D(dictionary): pass ... >>> d = D() >>> hash(d) 7920544 >>> id(d) 7920544 >>> Ditto for instances of list subclasses: >>> class L(list): pass ... >>> x = L(range(100)) >>> hash(x) 7928992 >>> id(x) 7928992 >>> Among other nasties, this lets them get used as mutable dict keys. Reported by Mark J on c.l.py: """ From: Mark J Sent: Sunday, October 28, 2001 10:03 PM To: python-list@python.org Subject: Python 2.2b1 hashable dictionary bug? Since I haven't had a good hit rate at detecting bugs vs. features, I thought I'd post here before filing a bug report at SourceForge. Python 2.2b1 (#1, Oct 19 2001, 23:11:09) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class D(dictionary): pass ... >>> d = {} >>> d2 = D() >>> d[d2] = "dictionary used as key" >>> d {{}: 'dictionary used as key'} >>> d[D()]="now have two keys that look the same" >>> d {{}: 'now have two keys that look the same', {}: 'dictionary used as key'} >>> d2["key"] = "mutable key in d" >>> d {{}: 'now have two keys that look the same', {'key': 'mutable key in d'}: 'dictionary used as key'} >>> d[d] = "plain dictionary not allowed as key" Traceback (most recent call last): File "", line 1, in ? TypeError: unhashable type >>> d2[d2] = "subclassed dictionary allowed though" >>> d2 {{...}: 'subclassed dictionary allowed though', 'key': 'mutable keys'} >>> #whoa: what just happened: {...} ?? Interesting.... So is this a feature or a bug? """ ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-03 09:05 Message: Logged In: YES user_id=31435 Your solution is fine by me! AFAIK, there's nothing in a type object that screams "I'm immutable" or "I'm mutable", so guessing whether a thing should be hashable was doomed to brittleness -- nothing wrong with being explicit about it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-03 08:33 Message: Logged In: YES user_id=6380 Fixed by adding a hash function to list and dict types that raises an error. This was by far the simplest solution. See checkin comments for discussion (there are plusses and minuses to this approach). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 13:33 Message: Logged In: YES user_id=31435 Assigned to Guido, since he admitted to thinking about it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-29 11:39 Message: Logged In: YES user_id=6380 Interestingly, in Python list.__hash__ is the same as object.__hash__, but in C, list.tp_hash is NULL while object.tp_hash is not. I think that the best solution is to somehow program an exception into add_operators that adds a dummy __hash__ wrapper (which always raises an exception) when the tp_hash field is found to be NULL. (Note that inherit_slots already contains special-casing for tp_hash.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-28 23:36 Message: Logged In: YES user_id=6380 There's an admin setting that auto-assigns certain categories. Documentation gets auto-assugned to Fred; type/class to me; Regular Expressions to Effbot I believe. The hash(sys.stdin) result is expected; files are compared by address and so their hash() is derived from their address too. I'll think about the real issue; this has to do with the way the hash stub gets set. I'm not sure yet whether this is best fixed by adding more code to slot_tp_hash or to the code that sticks slot_to_hash in the tp_hash slot. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-28 19:33 Message: Logged In: YES user_id=31435 I swear I didn't assign this to Guido -- I intended to leave this unassigned for now. That's the second time in two weeks I believe SF made up an assignment on one of my reports. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-28 19:28 Message: Logged In: YES user_id=31435 Jeez, hash() has gone off the deep end: >>> import sys >>> hash(sys.stdin) 7690032 >>> ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=475877&group_id=5470 From noreply@sourceforge.net Mon Dec 3 17:07:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 09:07:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-456420 ] no __methods__ for lists, strings etc. Message-ID: Bugs item #456420, was opened at 2001-08-29 00:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456420&group_id=5470 >Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Detlef Lannert (lannert) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: no __methods__ for lists, strings etc. Initial Comment: With Python 2.2a2+ from cvs, [].__methods__ fails with AttributeError: 'list' object has no attribute '__methods__' Same for a string or a dictionary. The Library Reference section on "Special Attributes" (2.1.9 here) still recommends [].__methods__ for finding out about an object's methods. dir([]) returns [] and doesn't list the attributes either. OK, I can use [].__class__.__dict__.keys() -- but it's not very intuitive ... Detlef ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-03 09:07 Message: Logged In: YES user_id=31435 We haven't gotten more complaints about this, so changed to Docs and reassigned to Fred: __methods__ and __members__ are history in 2.2. I'm not sure where they were documented before, though! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-05 12:26 Message: Logged In: YES user_id=31435 I want more feedback from 2.2a3 first. If __methods__ and __members__ are going to stay dead, then the docs need to be changed, but I'm not yet sure enough that they're going to stay dead. This particular report seemed driven to try them because of 2.2a2 dir() behavior, so I *hope* the 2.2a3 dir() changes will be enough that we don't see another of these. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 11:15 Message: Logged In: YES user_id=6380 Maybe this should be reclassified as a doc bug and assigned to Fred? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-29 15:10 Message: Logged In: YES user_id=31435 Reassigned to me. __members__ and __methods__ were always ugly hacks, and we'd like to get rid of them. I'm making dir() "smarter" again, so that dir([]) will be more informative (see bug 449989). Until then, try using dir(type([])) (more generally, dir (type(object)) instead of the atrocious [].__class__.__dict__.keys(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456420&group_id=5470 From noreply@sourceforge.net Mon Dec 3 17:09:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 09:09:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-488477 ] Reference counting bugs Message-ID: Bugs item #488477, was opened at 2001-12-03 09:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488477&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Reference counting bugs Initial Comment: Various refcounting bugs: 1. Objects/abstract.c: PyObject_Call(): missing Py_DECREF() on the object returned by PyObject_Repr(func). Moreover this function's return value is not tested for NULL, which might crash the interpreter. 2. Objects/funcobjects.c: function_call(): the Py_DECREF(arg) after PyErr_NoMemory() should be removed 3. Python/ceval.c: unpack_iterable(): in the path through the error "too many values to unpack", a Py_DECREF(w) is missing 4. Python/ceval.c: apply_slice(): the slice object returned by PySlice_New() is never Py_DECREF'ed. 5. Python/ceval.c: assign_slice(): the slice object returned by PySlice_New() is never Py_DECREF'ed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488477&group_id=5470 From noreply@sourceforge.net Mon Dec 3 17:14:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 09:14:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-488480 ] integer multiply to return -max_int-1 Message-ID: Bugs item #488480, was opened at 2001-12-03 09:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488480&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integer multiply to return -max_int-1 Initial Comment: integer multiplication never returns '-sys.max_int-1' but signals an OverflowError instead (or in Python 2.2b1 returns a long). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488480&group_id=5470 From noreply@sourceforge.net Mon Dec 3 17:21:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 09:21:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-488482 ] xrange() * large integer Message-ID: Bugs item #488482, was opened at 2001-12-03 09:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488482&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: xrange() * large integer Initial Comment: The (admittedly deprecated) feature that allows xrange objects to be multiplied by an integer no longer detects overflow because of PyNumber_Multiply() returning a long integer object in recent Python versions: Objects/rangeobject.c: long_mul(): we call PyNumber_Multiply() and bail out if the result is NULL, but then use PyInt_AS_LONG() without checking the object type. This gives unexpected results when PyNumber_Multiply() returns a PyLongObject. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488482&group_id=5470 From noreply@sourceforge.net Mon Dec 3 17:21:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 09:21:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-488477 ] Reference counting bugs Message-ID: Bugs item #488477, was opened at 2001-12-03 09:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488477&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Reference counting bugs Initial Comment: Various refcounting bugs: 1. Objects/abstract.c: PyObject_Call(): missing Py_DECREF() on the object returned by PyObject_Repr(func). Moreover this function's return value is not tested for NULL, which might crash the interpreter. 2. Objects/funcobjects.c: function_call(): the Py_DECREF(arg) after PyErr_NoMemory() should be removed 3. Python/ceval.c: unpack_iterable(): in the path through the error "too many values to unpack", a Py_DECREF(w) is missing 4. Python/ceval.c: apply_slice(): the slice object returned by PySlice_New() is never Py_DECREF'ed. 5. Python/ceval.c: assign_slice(): the slice object returned by PySlice_New() is never Py_DECREF'ed. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-03 09:21 Message: Logged In: YES user_id=31435 Boosted priority. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488477&group_id=5470 From noreply@sourceforge.net Mon Dec 3 17:22:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 09:22:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-488480 ] integer multiply to return -max_int-1 Message-ID: Bugs item #488480, was opened at 2001-12-03 09:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488480&group_id=5470 Category: Python Interpreter Core >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Tim Peters (tim_one) Summary: integer multiply to return -max_int-1 Initial Comment: integer multiplication never returns '-sys.max_int-1' but signals an OverflowError instead (or in Python 2.2b1 returns a long). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-03 09:22 Message: Logged In: YES user_id=31435 Confirmed, and assigned to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488480&group_id=5470 From noreply@sourceforge.net Mon Dec 3 17:23:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 09:23:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-488480 ] integer multiply to return -max_int-1 Message-ID: Bugs item #488480, was opened at 2001-12-03 09:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488480&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: integer multiply to return -max_int-1 Initial Comment: integer multiplication never returns '-sys.max_int-1' but signals an OverflowError instead (or in Python 2.2b1 returns a long). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2001-12-03 09:23 Message: Logged In: YES user_id=4771 (sorry, I was not logged in when I submitted this one) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-03 09:22 Message: Logged In: YES user_id=31435 Confirmed, and assigned to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488480&group_id=5470 From noreply@sourceforge.net Mon Dec 3 17:29:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 09:29:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-478428 ] dbm build fails Message-ID: Bugs item #478428, was opened at 2001-11-05 12:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478428&group_id=5470 Category: Macintosh Group: Python 2.2 Status: Closed Resolution: None Priority: 5 Submitted By: John Buell (dadaist) Assigned to: Jack Jansen (jackjansen) Summary: dbm build fails Initial Comment: Trying a build with cvs source downloaded this morning. I've been sure to do the configure --with-suffix=_ on case-insensitive Mac OS X (10.1), but I'm having some problem with the 'dbm' module. Here's a copy of the messages: building 'dbm' extension /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c: In function `dbm_subscript': /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c:104: warning: implicit declaration of function `dbm_error' /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c:105: warning: implicit declaration of function `dbm_clearerr' cc -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -I. -I/Users/jbuell/Documents/Python/python/dist/src/./Include -I/Users/jbuell/Documents/Python/python/dist/src/./Mac/Include -I/usr/local/include -IInclude/ -c /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c -o build/temp.darwin-1.4-Power Macintosh-2.2/dbmmodule.o cc -bundle -flat_namespace -undefined suppress build/temp.darwin-1.4-Power Macintosh-2.2/dbmmodule.o -L/usr/local/lib -o build/lib.darwin-1.4-Power Macintosh-2.2/dbm.so building 'gdbm' extension dyld: ./python_ Undefined symbols: __ashldi3 make: *** [sharedmods] Error 67 Any suggestions? Anything I can change in my settings to get past this? -John ---------------------------------------------------------------------- Comment By: John Buell (dadaist) Date: 2001-12-03 09:29 Message: Logged In: YES user_id=368337 Sorry, I've been busy. I've narrowed it down to being a fink-related problem. My beige G3 without fink can build and install python 2.2 just fine. The iBook WITH fink is what doesn't like the gdbm thing. The odd part is that the fink directories (/sw/*) are NOT part of my path while I'm doing builds, but gdbm seems to be finding the extra files anyway. bash-2.05$ echo $PATH ~/bin/powerpc-apple-darwin:/Users/jbuell/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/X11R6/bin [localhost:/Users/jbuell] root# find / -name libgdbm.a -print /sw/lib/libgdbm.a /usr/local/lib/libgdbm.a [localhost:/Users/jbuell] root# find / -name gdbm.h -print /sw/include/gdbm.h /usr/local/include/gdbm.h Other than uninstalling fink, is there a way to get python's build mechanism to completely ignore /sw and its subdirectories? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-02 14:15 Message: Logged In: YES user_id=45365 As the originator didn't follow up on my previous remark and everything works fine for me I'm closing this bug. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-06 12:45 Message: Logged In: YES user_id=45365 Note that the problem is with gdbm, not with dbm. Dbm seems to build fine (with a warning). I've heard a report of this before. Needless to say, for me there is no problem whatsoever:-) I think that the problem is that setup.py detects files that indicate to it that dbm is available while in fact it is not. Could you check whether you have a libgdbm.a and/or a gdbm.h on your system somewhere? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478428&group_id=5470 From noreply@sourceforge.net Mon Dec 3 17:35:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 09:35:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-456420 ] no __methods__ for lists, strings etc. Message-ID: Bugs item #456420, was opened at 2001-08-29 00:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456420&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Detlef Lannert (lannert) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: no __methods__ for lists, strings etc. Initial Comment: With Python 2.2a2+ from cvs, [].__methods__ fails with AttributeError: 'list' object has no attribute '__methods__' Same for a string or a dictionary. The Library Reference section on "Special Attributes" (2.1.9 here) still recommends [].__methods__ for finding out about an object's methods. dir([]) returns [] and doesn't list the attributes either. OK, I can use [].__class__.__dict__.keys() -- but it's not very intuitive ... Detlef ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-03 09:35 Message: Logged In: YES user_id=3066 Removed most references to __members__ and __methods__, leaving one pair of references that state that these are no longer available and refer the reader to the dir() function. Affected files: Doc/api/newtypes.tex revision 1.3 Doc/lib/libfuncs.tex revision 1.97 Doc/lib/libstdtypes.tex revision 1.77 Doc/ref/ref3.tex revision 1.78 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-03 09:07 Message: Logged In: YES user_id=31435 We haven't gotten more complaints about this, so changed to Docs and reassigned to Fred: __methods__ and __members__ are history in 2.2. I'm not sure where they were documented before, though! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-05 12:26 Message: Logged In: YES user_id=31435 I want more feedback from 2.2a3 first. If __methods__ and __members__ are going to stay dead, then the docs need to be changed, but I'm not yet sure enough that they're going to stay dead. This particular report seemed driven to try them because of 2.2a2 dir() behavior, so I *hope* the 2.2a3 dir() changes will be enough that we don't see another of these. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 11:15 Message: Logged In: YES user_id=6380 Maybe this should be reclassified as a doc bug and assigned to Fred? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-29 15:10 Message: Logged In: YES user_id=31435 Reassigned to me. __members__ and __methods__ were always ugly hacks, and we'd like to get rid of them. I'm making dir() "smarter" again, so that dir([]) will be more informative (see bug 449989). Until then, try using dir(type([])) (more generally, dir (type(object)) instead of the atrocious [].__class__.__dict__.keys(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456420&group_id=5470 From noreply@sourceforge.net Mon Dec 3 17:57:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 09:57:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-485153 ] Erroneous Fail of PyEval_CallObject Message-ID: Bugs item #485153, was opened at 2001-11-24 11:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485153&group_id=5470 Category: Documentation Group: Python 2.1.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Cl. Schmidt (clemm) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Erroneous Fail of PyEval_CallObject Initial Comment: If embedding python v2.1.1 in a Windows MFC project, it shows the following behaviour: When a call to e.g. PyArgParseTuple had failed, a subsequent call to PyEval_CallObject fails. The parameters of the both calls are completely independent and have nothing to do with each other. Trying to retrieve the error text of the failed PyEval_CallObject returns the error of the PyArgParseTuple, namely "new style getargs format but argument list is not a tuple". If the first (erroneous) call to PyArgParseTuple is commented, the PyEval_CallObject works without any problem. The attached code snippet documents the error. No attempts have been made to reproduce the behaviour in other environments. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-03 09:57 Message: Logged In: YES user_id=3066 Clarified the section on exception handling the C API manual in Doc/api/exceptions.tex revision 1.3. ---------------------------------------------------------------------- Comment By: Cl. Schmidt (clemm) Date: 2001-11-28 03:25 Message: Logged In: YES user_id=382038 Maybe I violated a python coding rule. In my case, I am embedding python in a windows C++ program. I am having neither a console window nor a caller to the method where the error occurred. Thus, raising an exception would not have made any sense. It is not correct to state that I ignore the error, because there is a return value from the function which is of course retrieved. It is at least disturbing when after having e.g. forgotten to clear an error, three subsequent calls to the C API succeed (as in my case), and suddenly one fails, reporting something completely irrelevant to that error. This behaviour is different in other cases. In another, very similar scenario, the call to PyEval_CallObject succeeded. I agree that it is a documentation issue. The doc should state something like this: "If you do not raise an exception to python and do not call PyErr_Clear, the results are unpredictable." ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 13:14 Message: Logged In: YES user_id=31435 Changed to Documentation and reassigned to Fred: Fred, I don't think we ever spell out that C API errors must be passed on or explicitly cleared (before calling another C API function). The Exceptions section of the C API manual does not spell this out. It's possible that the "Intermezzo: Errors and Exceptions" section of the Extending and Embedding manual is clear enough -- your call. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:47 Message: Logged In: YES user_id=31435 I don't understand what "the bug" is here: if you get an error return from a Python C API function, and you intend to ignore the error, you must call PyErr_Clear() before calling another Python C API function. You're not doing that. The attachment isn't executable as-is, so I can't say whether that fixes your particular problem -- but it's never legitimate to ignore an error in C API coding (you must either pass it on to your caller or explicitly clear it). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485153&group_id=5470 From noreply@sourceforge.net Mon Dec 3 18:12:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 10:12:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-488420 ] Search Python Docs script broken Message-ID: Bugs item #488420, was opened at 2001-12-03 06:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488420&group_id=5470 Category: Macintosh Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason Harper (jasonharper) Assigned to: Just van Rossum (jvr) Summary: Search Python Docs script broken Initial Comment: The "Search Python Documentation" IDE script is broken in 2.2b2. It uses PyDocSearch.py, which imports some AppleEvent suites that are no longer in the same location. Near the top of the file: import Standard_Suite import Required_Suite import WWW_Suite The first two are now in the StdSuites package rather than being directly on sys.path. WWW_Suite doesn't seem to exist anymore (at least not with that exact name), so I'm not exactly sure how to fix this. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2001-12-03 10:12 Message: Logged In: YES user_id=92689 Fixed in CVS. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-03 06:51 Message: Logged In: YES user_id=45365 Just, I think this is more in your ballpark. If you disagree assign it back. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488420&group_id=5470 From noreply@sourceforge.net Mon Dec 3 18:13:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 10:13:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-488420 ] Search Python Docs script broken Message-ID: Bugs item #488420, was opened at 2001-12-03 06:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488420&group_id=5470 Category: Macintosh Group: Python 2.2 >Status: Closed Resolution: None Priority: 5 Submitted By: Jason Harper (jasonharper) Assigned to: Just van Rossum (jvr) Summary: Search Python Docs script broken Initial Comment: The "Search Python Documentation" IDE script is broken in 2.2b2. It uses PyDocSearch.py, which imports some AppleEvent suites that are no longer in the same location. Near the top of the file: import Standard_Suite import Required_Suite import WWW_Suite The first two are now in the StdSuites package rather than being directly on sys.path. WWW_Suite doesn't seem to exist anymore (at least not with that exact name), so I'm not exactly sure how to fix this. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2001-12-03 10:13 Message: Logged In: YES user_id=92689 ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2001-12-03 10:12 Message: Logged In: YES user_id=92689 Fixed in CVS. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-03 06:51 Message: Logged In: YES user_id=45365 Just, I think this is more in your ballpark. If you disagree assign it back. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488420&group_id=5470 From noreply@sourceforge.net Mon Dec 3 18:38:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 10:38:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-483805 ] mmap docs: Minor description problem Message-ID: Bugs item #483805, was opened at 2001-11-20 06:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=483805&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: mmap docs: Minor description problem Initial Comment: Subject: Re: Mutable strings Date: Sun, 18 Nov 2001 22:45:30 -0500 From: "Fred L. Drake, Jr." To: "Colin J. Williams" CC: Python-docs@python.org References: 1 Colin J. Williams writes: > Section 7.7 of the library (mmap) refers to mutable strings. > > At first glance, this is jarring. We learn early on that strings are > immutable. Please file a bug report at SourceForge for this so I don't lose track of it; I'm sure it won't be a difficult fix, but I can't work on it right now. http://sourceforge.net/projects/python/ > Finally, a little grumble about Active State's conversion of the > docs from HTML to the Microsoft world. Among other things, the > links on the About page force one to use the MS Mailer. My default > browser/email facility is Netscape. We don't have any control over ActiveState's packaging; you'll need to refer to their Web site to find who should hear about this problem. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-03 10:38 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/libmmap.tex revision 1.8. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=483805&group_id=5470 From noreply@sourceforge.net Mon Dec 3 18:51:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 10:51:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-485080 ] lib/test/data not installed Message-ID: Bugs item #485080, was opened at 2001-11-24 02:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485080&group_id=5470 >Category: Installation Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Barry Warsaw (bwarsaw) Summary: lib/test/data not installed Initial Comment: test/data should be inserted in LIBSUBDIRS of file Makefile.pre.in since it's not being installed right now. test/test_email fails. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-03 10:51 Message: Logged In: YES user_id=12800 Fixed in Makefile.pre.in 1.69 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:55 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485080&group_id=5470 From noreply@sourceforge.net Mon Dec 3 18:59:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 10:59:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-487703 ] Replace strcat, strcpy Message-ID: Bugs item #487703, was opened at 2001-11-30 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487703&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Replace strcat, strcpy Initial Comment: Alex Martelli sent this URL for a paper describing the safer strlcat and strlcpy functions: >http://www.usenix.org/events/usenix99/full_papers/mill ert/millert_html/> ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-03 10:59 Message: Logged In: YES user_id=31435 I'm attaching a patch from Alex Martelli; haven't reviewed it, and don't expect to before 2.2 final is released. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-03 02:47 Message: Logged In: YES user_id=38388 Time for PyOS_strlcat() and PyOS_strlcpy() ? Looking at the web-site it seems that we could simply copy the code into the Python distro. I'd then suggest to bundle all the string helpers into a new file: e.g. mystrapis.c. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487703&group_id=5470 From noreply@sourceforge.net Mon Dec 3 19:06:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 11:06:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-488514 ] -Qnew needs work Message-ID: Bugs item #488514, was opened at 2001-12-03 11:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488514&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Tim Peters (tim_one) Summary: -Qnew needs work Initial Comment: -Qnew works as described in the NEWS file, but not as described in the PEP (238). It would be good if the PEP behavior were implemented for 2.2, i.e. that -Qnew have global effect rather than merely affecting __main__. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488514&group_id=5470 From noreply@sourceforge.net Mon Dec 3 19:09:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 11:09:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-479698 ] __coerce__ not working with new classes Message-ID: Bugs item #479698, was opened at 2001-11-08 10:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479698&group_id=5470 >Category: Documentation Group: Python 2.2 Status: Open >Resolution: Wont Fix >Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: __coerce__ not working with new classes Initial Comment: I converted a numeric-like class from the "old-style" Python class to the "new-style" Python class by inheriting from "object". Numerical operations like "__mul__" and "__div__" failed with the "new-style" class. After tracking the problem, I found that the "__coerce__" special method was called when performing mixed-type arithmetic, as expected, with the "old-style" class, but not with the "new-style" class. The arithmetic operations failed because the expected type conversion was not performed with the mixed-type arithmetic. As best I can tell, without examining the Python source code, the following is taking place: 1. The documentation for the "__coerce__" special method states that it is invoked in the case of mixed-type arithmetic only if at least one of the arguments in an arithmetic operation is a class instance. 2. An object created with an "old-style" class is of type "instance", as verified by the "type" function, i.e. 3. An object created with a "new-style" class is of a different type, as also verified by the "type function, i.e. Evidently, because of this change in type, the "__coerce__" function is not longer invoked for "new-style" Python classes. Gary H. Loechelt ON Semiconductor ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-03 11:09 Message: Logged In: YES user_id=6380 Encouraged by the submittor's comment, I've decided not to fix this. New-style class instances cannot be old-style numbers, and the conversion from old-style class to new-style class will have to involve changing any numeric operators to do their own coercions. I'll leave this as a documentation item, at a lower priority (I'll add something to the docs on the web). ---------------------------------------------------------------------- Comment By: Gary H. Loechelt (loechelt) Date: 2001-11-26 07:59 Message: Logged In: YES user_id=142817 After further looking into this, I am not sure that it is a bug "per se". It may have been the intentionally designed behavior. It is certainly possible for a user to rewrite arithmetic methods (i.e. '__add__') to explicitly call a coerce method. However, in the very least, changing from the "old-style" to the "new-style" class does break existing code that relies upon the '__coerce__' method, and this fact is not very well documented. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479698&group_id=5470 From noreply@sourceforge.net Mon Dec 3 19:10:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 11:10:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-488477 ] Reference counting bugs Message-ID: Bugs item #488477, was opened at 2001-12-03 09:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488477&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 7 Submitted By: Armin Rigo (arigo) >Assigned to: Guido van Rossum (gvanrossum) Summary: Reference counting bugs Initial Comment: Various refcounting bugs: 1. Objects/abstract.c: PyObject_Call(): missing Py_DECREF() on the object returned by PyObject_Repr(func). Moreover this function's return value is not tested for NULL, which might crash the interpreter. 2. Objects/funcobjects.c: function_call(): the Py_DECREF(arg) after PyErr_NoMemory() should be removed 3. Python/ceval.c: unpack_iterable(): in the path through the error "too many values to unpack", a Py_DECREF(w) is missing 4. Python/ceval.c: apply_slice(): the slice object returned by PySlice_New() is never Py_DECREF'ed. 5. Python/ceval.c: assign_slice(): the slice object returned by PySlice_New() is never Py_DECREF'ed. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-03 11:10 Message: Logged In: YES user_id=6380 I'll have a look at these. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-03 09:21 Message: Logged In: YES user_id=31435 Boosted priority. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488477&group_id=5470 From noreply@sourceforge.net Mon Dec 3 19:45:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 11:45:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-488477 ] Reference counting bugs Message-ID: Bugs item #488477, was opened at 2001-12-03 09:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488477&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Armin Rigo (arigo) Assigned to: Guido van Rossum (gvanrossum) Summary: Reference counting bugs Initial Comment: Various refcounting bugs: 1. Objects/abstract.c: PyObject_Call(): missing Py_DECREF() on the object returned by PyObject_Repr(func). Moreover this function's return value is not tested for NULL, which might crash the interpreter. 2. Objects/funcobjects.c: function_call(): the Py_DECREF(arg) after PyErr_NoMemory() should be removed 3. Python/ceval.c: unpack_iterable(): in the path through the error "too many values to unpack", a Py_DECREF(w) is missing 4. Python/ceval.c: apply_slice(): the slice object returned by PySlice_New() is never Py_DECREF'ed. 5. Python/ceval.c: assign_slice(): the slice object returned by PySlice_New() is never Py_DECREF'ed. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-03 11:45 Message: Logged In: YES user_id=6380 Thanks, Armin. I'd be interested in finding out which tool you used to find these! - Item #1 is no longer current; this was solved by not calling PyObject_Repr(func) at all (which has all sorts of other bad potential implications, so it's best not to call it for the purpose of creating friendly error messages). - Item #2: Good catch. Must've been a remnant of a transformation long ago, when this code was moved from an in-line position in ceval.c to a separate function. Fixed in cvs, funcobject.c:2.48. - Item #3: Good job again. Fixed in ceval.c:2.292. I've added a test case too, test_iter.py:1.23. - Items #4 and #5: Right. Fixed in ceval.c:2.293. This concludes this bug report. Closing as Fixed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-03 11:10 Message: Logged In: YES user_id=6380 I'll have a look at these. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-03 09:21 Message: Logged In: YES user_id=31435 Boosted priority. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488477&group_id=5470 From noreply@sourceforge.net Mon Dec 3 21:11:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 13:11:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-486530 ] replace sprintf with PyOS_snprintf Message-ID: Bugs item #486530, was opened at 2001-11-28 09:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486530&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None >Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Nobody/Anonymous (nobody) Summary: replace sprintf with PyOS_snprintf Initial Comment: Some or all of the sprintf calls we make are vulnerable to buffer overflows. A few of these calls use stack-allocated buffers, which are real security problems. MAL has fixed three of them, but if we're going to fix any we need to fix them all. We'll try to finish this task as soon as possible. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-03 13:10 Message: Logged In: YES user_id=6380 Most of this is done. There are a few cases left, some intentionally (and carefully analyzed). I won't close it yet, but I see no need for the high priority now. sprintf is still used in: drawfmodule.c (RISCOS\Modules) -- unsafe, only affects one platform getbuildinfo.c (Modules) -- safe getnameinfo.c (Modules) -- safe grammar1.c (Parser) -- safe mactoolboxglue.c (Python) -- safe stringobject.c (Objects) -- safe strtod.c (Python) -- probably safe; AFAICT this file is unused (?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486530&group_id=5470 From noreply@sourceforge.net Mon Dec 3 21:24:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 13:24:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-486530 ] replace sprintf with PyOS_snprintf Message-ID: Bugs item #486530, was opened at 2001-11-28 09:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486530&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) >Assigned to: Jack Jansen (jackjansen) Summary: replace sprintf with PyOS_snprintf Initial Comment: Some or all of the sprintf calls we make are vulnerable to buffer overflows. A few of these calls use stack-allocated buffers, which are real security problems. MAL has fixed three of them, but if we're going to fix any we need to fix them all. We'll try to finish this task as soon as possible. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-03 13:24 Message: Logged In: YES user_id=31435 Reassigned this to Jack. The list Guido gave was derived from a list I gave him, and it didn't include any files under the Mac directory: C:\Code\python\Mac>findstr /m /s sprintf *.c compat\getwd.c modules\calldll.c modules\macfsmodule.c modules\cf\_cfmodule.c modules\ctl\_ctlmodule.c modules\win\_winmodule.c modules\hfsplusmodule.c python\macimport.c ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-03 13:10 Message: Logged In: YES user_id=6380 Most of this is done. There are a few cases left, some intentionally (and carefully analyzed). I won't close it yet, but I see no need for the high priority now. sprintf is still used in: drawfmodule.c (RISCOS\Modules) -- unsafe, only affects one platform getbuildinfo.c (Modules) -- safe getnameinfo.c (Modules) -- safe grammar1.c (Parser) -- safe mactoolboxglue.c (Python) -- safe stringobject.c (Objects) -- safe strtod.c (Python) -- probably safe; AFAICT this file is unused (?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486530&group_id=5470 From noreply@sourceforge.net Mon Dec 3 21:56:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 13:56:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-487331 ] time mod's timezone doesn't honor TZ var Message-ID: Bugs item #487331, was opened at 2001-11-29 18:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487331&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 3 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: M.-A. Lemburg (lemburg) Summary: time mod's timezone doesn't honor TZ var Initial Comment: Python's time module seems to get the timezone name when it's first imported, but it doesn't change it if the TZ environment variable is later set. On the other hand, the time of day DOES change accordingly. Thus, setting TZ after the time module is imported results in a completely broken rfc2822 date - time in the new TZ, but with a bogus UTC offset and timezone (neither the old nor new). Here is the problem illustrated. You will see that after setting TZ, altzone, timezone, and tzname don't change, while asctime does. $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import time,os >>> print time.asctime() Thu Nov 29 18:47:39 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print time.asctime() Fri Nov 30 14:47:52 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') Here is an example of why this is a problem in practice. One of my applications sets the TZ environment variable based on a "TIMEZONE" setting in the user's configuration file. It later uses the `email' module to create a "Date:" header for outgoing mail messages. Because of this bug, the resulting "Date:" is bogus. e.g, $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import email,os >>> print email.Utils.formatdate(localtime=1) Thu, 29 Nov 2001 18:52:34 -0700 >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print email.Utils.formatdate(localtime=1) Fri, 30 Nov 2001 14:52:41 -0600 The `-0600' should be `+1300', and `-0600' isn't correct even for the original timezone! You might say: "Work around this by setting TZ before the time module is first imported." -- No, that is too fragile, and too difficult to do with complex applications. Many other modules in turn import time, etc. I suggest instead that the TZ environment variable be consulted each time the timezone is accessed. ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-03 13:56 Message: Logged In: YES user_id=85984 I'm fairly ignorant of the gory details behind the scenes of the time module, but I still contend this is buggy behavior. That is, setting os.environ['TZ'] in the application totally breaks higher level methods such as email.Utils.formatdate(). Barry had a suggestion which Mark doesn't think is a good idea. Mark, are you sure there isn't anything that can be done? If think that if you disregard this issue, it will come back to haunt the Python community. With regards to your suggestion of mxDateTime: I really can't consider this as I don't want to rely on any external modules or packages. One of my application's strengths is that it "just works" out of the box with Python, so it's very easy to install. I'd like to keep it that way unless it's absolutely necessary to do otherwise. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 12:53 Message: Logged In: YES user_id=38388 I don't know whether this is such a good idea -- after all it's fairly easy to manage timezones in the application rather than trying to fiddle the C libs routines into producing the output you intend. Also note that tzset() is *not* thread safe. BTW, Jason, you may want to have a look at mxDateTime -- perhaps it already has what you are looking for. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-11-30 12:11 Message: Logged In: YES user_id=12800 Perhaps we should expose tzset() to Python? We'd also have to reset timezone, altzone, daylight, and tzname in the module after calling tzset(). It's a bit of work, and adds a feature so it can't go into Python 2.2, but if you think this is a viable approach, re-assign this bug to me and I'll deal with it for Python 2.3. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 11:01 Message: Logged In: YES user_id=38388 The time module is a very thin layer on top of the C lib time APIs. There's nothing much Python can do about errors in those APIs, e.g. not recognizing changes to TZ. Also note that the tzset() API which inits the time APIs w/r to the TZ environment variable is only called at time module import time. To expose the dynamic changes you are looking for, it would have to call tzset() prior to all calls to asctime() et al. -- much too time consuming ! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487331&group_id=5470 From noreply@sourceforge.net Tue Dec 4 01:29:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 17:29:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-488687 ] UMR when assign to __debug__ Message-ID: Bugs item #488687, was opened at 2001-12-03 17:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488687&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: UMR when assign to __debug__ Initial Comment: When doing: __debug__ = None (like in test_compile) The line number (ste_opt_lineno) is not initialized. The following patch fixes the UMR, but doesn't fix the problem (ie, the line # is still wrong): Index: Python/symtable.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/symtable.c,v retrieving revision 2.7 diff -u -r2.7 symtable.c --- Python/symtable.c 2001/11/28 21:36:28 2.7 +++ Python/symtable.c 2001/12/04 01:26:12 @@ -46,6 +46,7 @@ ste->ste_optimized = 0; ste->ste_lineno = lineno; + ste->ste_opt_lineno = lineno; switch (type) { case funcdef: case lambdef: ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488687&group_id=5470 From noreply@sourceforge.net Tue Dec 4 01:42:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 17:42:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-488687 ] UMR when assign to __debug__ Message-ID: Bugs item #488687, was opened at 2001-12-03 17:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488687&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: UMR when assign to __debug__ Initial Comment: When doing: __debug__ = None (like in test_compile) The line number (ste_opt_lineno) is not initialized. The following patch fixes the UMR, but doesn't fix the problem (ie, the line # is still wrong): Index: Python/symtable.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/symtable.c,v retrieving revision 2.7 diff -u -r2.7 symtable.c --- Python/symtable.c 2001/11/28 21:36:28 2.7 +++ Python/symtable.c 2001/12/04 01:26:12 @@ -46,6 +46,7 @@ ste->ste_optimized = 0; ste->ste_lineno = lineno; + ste->ste_opt_lineno = lineno; switch (type) { case funcdef: case lambdef: ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-03 17:42 Message: Logged In: YES user_id=6380 This seems simple enough to deserve being fixed before 2.2 goes out. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488687&group_id=5470 From noreply@sourceforge.net Tue Dec 4 02:23:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 18:23:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-488687 ] UMR when assign to __debug__ Message-ID: Bugs item #488687, was opened at 2001-12-03 17:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488687&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Jeremy Hylton (jhylton) Summary: UMR when assign to __debug__ Initial Comment: When doing: __debug__ = None (like in test_compile) The line number (ste_opt_lineno) is not initialized. The following patch fixes the UMR, but doesn't fix the problem (ie, the line # is still wrong): Index: Python/symtable.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/symtable.c,v retrieving revision 2.7 diff -u -r2.7 symtable.c --- Python/symtable.c 2001/11/28 21:36:28 2.7 +++ Python/symtable.c 2001/12/04 01:26:12 @@ -46,6 +46,7 @@ ste->ste_optimized = 0; ste->ste_lineno = lineno; + ste->ste_opt_lineno = lineno; switch (type) { case funcdef: case lambdef: ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-03 17:42 Message: Logged In: YES user_id=6380 This seems simple enough to deserve being fixed before 2.2 goes out. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488687&group_id=5470 From noreply@sourceforge.net Tue Dec 4 02:24:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 18:24:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-485133 ] memory leak in test_parser Message-ID: Bugs item #485133, was opened at 2001-11-24 10:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485133&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: memory leak in test_parser Initial Comment: parsermodule.c leaks in recursive calls to build_node_children(). see attached file for info ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-03 18:24 Message: Logged In: YES user_id=6380 Fred owns this code. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:06 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485133&group_id=5470 From noreply@sourceforge.net Tue Dec 4 03:02:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 19:02:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-488687 ] UMR when assign to __debug__ Message-ID: Bugs item #488687, was opened at 2001-12-03 17:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488687&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Jeremy Hylton (jhylton) Summary: UMR when assign to __debug__ Initial Comment: When doing: __debug__ = None (like in test_compile) The line number (ste_opt_lineno) is not initialized. The following patch fixes the UMR, but doesn't fix the problem (ie, the line # is still wrong): Index: Python/symtable.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/symtable.c,v retrieving revision 2.7 diff -u -r2.7 symtable.c --- Python/symtable.c 2001/11/28 21:36:28 2.7 +++ Python/symtable.c 2001/12/04 01:26:12 @@ -46,6 +46,7 @@ ste->ste_optimized = 0; ste->ste_lineno = lineno; + ste->ste_opt_lineno = lineno; switch (type) { case funcdef: case lambdef: ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-03 17:42 Message: Logged In: YES user_id=6380 This seems simple enough to deserve being fixed before 2.2 goes out. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488687&group_id=5470 From noreply@sourceforge.net Tue Dec 4 05:14:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 03 Dec 2001 21:14:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-488730 ] oos.popen() seg faults on FreeBSD 5 Message-ID: Bugs item #488730, was opened at 2001-12-03 21:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Marc Culler (marcculler) Assigned to: Nobody/Anonymous (nobody) Summary: oos.popen() seg faults on FreeBSD 5 Initial Comment: Here is the crash with Python 2.1.1 on my FreeBSD 5.0-current system: [ace:culler]$ python Python 2.1.1 (#5, Aug 18 2001, 17:41:43) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') Segmentation fault (core dumped) No problem occurs when I do the same thing in Python 2.0, which was compiled under FreeBSD 4, but is running here under FreeBSD 5: [ace:culler]$ python2.0 Python 2.0 (#2, Nov 16 2000, 22:22:48) [GCC 2.95.2 19991024 (release)] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') >>> mypipe.readlines() ['COPYRIGHT\012', 'bin\012', 'boot\012', 'cdrom\012', 'compat\012', 'dev\012', 'dist\012', 'entropy\012', 'etc\012', 'home\012', 'kernel\012', 'kernel.GENERIC\012', 'kernel.old\012', 'kernel.prev\012', 'mnt\012', 'modules\012', 'modules.old\012', 'proc\012', 'root\012', 'sbin\012', 'shared\012', 'stand\012', 'sys\012', 'tmp\012', 'usr\012', 'var\012'] >>> ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 From noreply@sourceforge.net Tue Dec 4 09:36:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 01:36:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-487331 ] time mod's timezone doesn't honor TZ var Message-ID: Bugs item #487331, was opened at 2001-11-29 18:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487331&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 3 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: M.-A. Lemburg (lemburg) Summary: time mod's timezone doesn't honor TZ var Initial Comment: Python's time module seems to get the timezone name when it's first imported, but it doesn't change it if the TZ environment variable is later set. On the other hand, the time of day DOES change accordingly. Thus, setting TZ after the time module is imported results in a completely broken rfc2822 date - time in the new TZ, but with a bogus UTC offset and timezone (neither the old nor new). Here is the problem illustrated. You will see that after setting TZ, altzone, timezone, and tzname don't change, while asctime does. $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import time,os >>> print time.asctime() Thu Nov 29 18:47:39 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print time.asctime() Fri Nov 30 14:47:52 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') Here is an example of why this is a problem in practice. One of my applications sets the TZ environment variable based on a "TIMEZONE" setting in the user's configuration file. It later uses the `email' module to create a "Date:" header for outgoing mail messages. Because of this bug, the resulting "Date:" is bogus. e.g, $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import email,os >>> print email.Utils.formatdate(localtime=1) Thu, 29 Nov 2001 18:52:34 -0700 >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print email.Utils.formatdate(localtime=1) Fri, 30 Nov 2001 14:52:41 -0600 The `-0600' should be `+1300', and `-0600' isn't correct even for the original timezone! You might say: "Work around this by setting TZ before the time module is first imported." -- No, that is too fragile, and too difficult to do with complex applications. Many other modules in turn import time, etc. I suggest instead that the TZ environment variable be consulted each time the timezone is accessed. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-04 01:36 Message: Logged In: YES user_id=38388 Jason, as I already mentioned in my other reply, exposing tzset() to Python would cause more trouble than do any good because of the side-effects it has. Rather then provide ways to write buggy code in Python, I suggest to look into solving the problem you seem to have using the available tools, e.g. mxDateTime runs on many different platforms and integrates nicely with Python. If the email package is the only one you need fixed, I suggest to write a small helper or patch which implements the needed modifications for this package. BTW, what are you exact requirements ? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-03 13:56 Message: Logged In: YES user_id=85984 I'm fairly ignorant of the gory details behind the scenes of the time module, but I still contend this is buggy behavior. That is, setting os.environ['TZ'] in the application totally breaks higher level methods such as email.Utils.formatdate(). Barry had a suggestion which Mark doesn't think is a good idea. Mark, are you sure there isn't anything that can be done? If think that if you disregard this issue, it will come back to haunt the Python community. With regards to your suggestion of mxDateTime: I really can't consider this as I don't want to rely on any external modules or packages. One of my application's strengths is that it "just works" out of the box with Python, so it's very easy to install. I'd like to keep it that way unless it's absolutely necessary to do otherwise. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 12:53 Message: Logged In: YES user_id=38388 I don't know whether this is such a good idea -- after all it's fairly easy to manage timezones in the application rather than trying to fiddle the C libs routines into producing the output you intend. Also note that tzset() is *not* thread safe. BTW, Jason, you may want to have a look at mxDateTime -- perhaps it already has what you are looking for. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-11-30 12:11 Message: Logged In: YES user_id=12800 Perhaps we should expose tzset() to Python? We'd also have to reset timezone, altzone, daylight, and tzname in the module after calling tzset(). It's a bit of work, and adds a feature so it can't go into Python 2.2, but if you think this is a viable approach, re-assign this bug to me and I'll deal with it for Python 2.3. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 11:01 Message: Logged In: YES user_id=38388 The time module is a very thin layer on top of the C lib time APIs. There's nothing much Python can do about errors in those APIs, e.g. not recognizing changes to TZ. Also note that the tzset() API which inits the time APIs w/r to the TZ environment variable is only called at time module import time. To expose the dynamic changes you are looking for, it would have to call tzset() prior to all calls to asctime() et al. -- much too time consuming ! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487331&group_id=5470 From noreply@sourceforge.net Tue Dec 4 11:21:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 03:21:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-478428 ] dbm build fails Message-ID: Bugs item #478428, was opened at 2001-11-05 12:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478428&group_id=5470 Category: Macintosh Group: Python 2.2 Status: Closed Resolution: None Priority: 5 Submitted By: John Buell (dadaist) Assigned to: Jack Jansen (jackjansen) Summary: dbm build fails Initial Comment: Trying a build with cvs source downloaded this morning. I've been sure to do the configure --with-suffix=_ on case-insensitive Mac OS X (10.1), but I'm having some problem with the 'dbm' module. Here's a copy of the messages: building 'dbm' extension /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c: In function `dbm_subscript': /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c:104: warning: implicit declaration of function `dbm_error' /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c:105: warning: implicit declaration of function `dbm_clearerr' cc -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -I. -I/Users/jbuell/Documents/Python/python/dist/src/./Include -I/Users/jbuell/Documents/Python/python/dist/src/./Mac/Include -I/usr/local/include -IInclude/ -c /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c -o build/temp.darwin-1.4-Power Macintosh-2.2/dbmmodule.o cc -bundle -flat_namespace -undefined suppress build/temp.darwin-1.4-Power Macintosh-2.2/dbmmodule.o -L/usr/local/lib -o build/lib.darwin-1.4-Power Macintosh-2.2/dbm.so building 'gdbm' extension dyld: ./python_ Undefined symbols: __ashldi3 make: *** [sharedmods] Error 67 Any suggestions? Anything I can change in my settings to get past this? -John ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-04 03:21 Message: Logged In: YES user_id=45365 The problem isn't with /sw, it's with the gdbm.h that is installed in /usr/local/include. This is what triggers setup.py to try and build gdbm. The other questrion is of course why it doesn't work: if you have gdbm.h and libgdbm there's really no reason why it shouldn't build. ---------------------------------------------------------------------- Comment By: John Buell (dadaist) Date: 2001-12-03 09:29 Message: Logged In: YES user_id=368337 Sorry, I've been busy. I've narrowed it down to being a fink-related problem. My beige G3 without fink can build and install python 2.2 just fine. The iBook WITH fink is what doesn't like the gdbm thing. The odd part is that the fink directories (/sw/*) are NOT part of my path while I'm doing builds, but gdbm seems to be finding the extra files anyway. bash-2.05$ echo $PATH ~/bin/powerpc-apple-darwin:/Users/jbuell/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/X11R6/bin [localhost:/Users/jbuell] root# find / -name libgdbm.a -print /sw/lib/libgdbm.a /usr/local/lib/libgdbm.a [localhost:/Users/jbuell] root# find / -name gdbm.h -print /sw/include/gdbm.h /usr/local/include/gdbm.h Other than uninstalling fink, is there a way to get python's build mechanism to completely ignore /sw and its subdirectories? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-02 14:15 Message: Logged In: YES user_id=45365 As the originator didn't follow up on my previous remark and everything works fine for me I'm closing this bug. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-06 12:45 Message: Logged In: YES user_id=45365 Note that the problem is with gdbm, not with dbm. Dbm seems to build fine (with a warning). I've heard a report of this before. Needless to say, for me there is no problem whatsoever:-) I think that the problem is that setup.py detects files that indicate to it that dbm is available while in fact it is not. Could you check whether you have a libgdbm.a and/or a gdbm.h on your system somewhere? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478428&group_id=5470 From noreply@sourceforge.net Tue Dec 4 14:16:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 06:16:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-488894 ] bad message for non-string getattr Message-ID: Bugs item #488894, was opened at 2001-12-04 06:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488894&group_id=5470 Category: Tkinter Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: bad message for non-string getattr Initial Comment: object.__getattribute__(obj, 1) prints a bizarre error message, because the error message code assumes the name argument is always a string. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488894&group_id=5470 From noreply@sourceforge.net Tue Dec 4 15:03:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 07:03:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-487331 ] time mod's timezone doesn't honor TZ var Message-ID: Bugs item #487331, was opened at 2001-11-29 18:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487331&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 3 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: M.-A. Lemburg (lemburg) Summary: time mod's timezone doesn't honor TZ var Initial Comment: Python's time module seems to get the timezone name when it's first imported, but it doesn't change it if the TZ environment variable is later set. On the other hand, the time of day DOES change accordingly. Thus, setting TZ after the time module is imported results in a completely broken rfc2822 date - time in the new TZ, but with a bogus UTC offset and timezone (neither the old nor new). Here is the problem illustrated. You will see that after setting TZ, altzone, timezone, and tzname don't change, while asctime does. $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import time,os >>> print time.asctime() Thu Nov 29 18:47:39 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print time.asctime() Fri Nov 30 14:47:52 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') Here is an example of why this is a problem in practice. One of my applications sets the TZ environment variable based on a "TIMEZONE" setting in the user's configuration file. It later uses the `email' module to create a "Date:" header for outgoing mail messages. Because of this bug, the resulting "Date:" is bogus. e.g, $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import email,os >>> print email.Utils.formatdate(localtime=1) Thu, 29 Nov 2001 18:52:34 -0700 >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print email.Utils.formatdate(localtime=1) Fri, 30 Nov 2001 14:52:41 -0600 The `-0600' should be `+1300', and `-0600' isn't correct even for the original timezone! You might say: "Work around this by setting TZ before the time module is first imported." -- No, that is too fragile, and too difficult to do with complex applications. Many other modules in turn import time, etc. I suggest instead that the TZ environment variable be consulted each time the timezone is accessed. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 07:03 Message: Logged In: YES user_id=12800 OT, but what about adding mxDateTime to core Python <2.3 wink>? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-04 01:36 Message: Logged In: YES user_id=38388 Jason, as I already mentioned in my other reply, exposing tzset() to Python would cause more trouble than do any good because of the side-effects it has. Rather then provide ways to write buggy code in Python, I suggest to look into solving the problem you seem to have using the available tools, e.g. mxDateTime runs on many different platforms and integrates nicely with Python. If the email package is the only one you need fixed, I suggest to write a small helper or patch which implements the needed modifications for this package. BTW, what are you exact requirements ? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-03 13:56 Message: Logged In: YES user_id=85984 I'm fairly ignorant of the gory details behind the scenes of the time module, but I still contend this is buggy behavior. That is, setting os.environ['TZ'] in the application totally breaks higher level methods such as email.Utils.formatdate(). Barry had a suggestion which Mark doesn't think is a good idea. Mark, are you sure there isn't anything that can be done? If think that if you disregard this issue, it will come back to haunt the Python community. With regards to your suggestion of mxDateTime: I really can't consider this as I don't want to rely on any external modules or packages. One of my application's strengths is that it "just works" out of the box with Python, so it's very easy to install. I'd like to keep it that way unless it's absolutely necessary to do otherwise. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 12:53 Message: Logged In: YES user_id=38388 I don't know whether this is such a good idea -- after all it's fairly easy to manage timezones in the application rather than trying to fiddle the C libs routines into producing the output you intend. Also note that tzset() is *not* thread safe. BTW, Jason, you may want to have a look at mxDateTime -- perhaps it already has what you are looking for. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-11-30 12:11 Message: Logged In: YES user_id=12800 Perhaps we should expose tzset() to Python? We'd also have to reset timezone, altzone, daylight, and tzname in the module after calling tzset(). It's a bit of work, and adds a feature so it can't go into Python 2.2, but if you think this is a viable approach, re-assign this bug to me and I'll deal with it for Python 2.3. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 11:01 Message: Logged In: YES user_id=38388 The time module is a very thin layer on top of the C lib time APIs. There's nothing much Python can do about errors in those APIs, e.g. not recognizing changes to TZ. Also note that the tzset() API which inits the time APIs w/r to the TZ environment variable is only called at time module import time. To expose the dynamic changes you are looking for, it would have to call tzset() prior to all calls to asctime() et al. -- much too time consuming ! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487331&group_id=5470 From noreply@sourceforge.net Tue Dec 4 15:04:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 07:04:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-487331 ] time mod's timezone doesn't honor TZ var Message-ID: Bugs item #487331, was opened at 2001-11-29 18:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487331&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 3 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: M.-A. Lemburg (lemburg) Summary: time mod's timezone doesn't honor TZ var Initial Comment: Python's time module seems to get the timezone name when it's first imported, but it doesn't change it if the TZ environment variable is later set. On the other hand, the time of day DOES change accordingly. Thus, setting TZ after the time module is imported results in a completely broken rfc2822 date - time in the new TZ, but with a bogus UTC offset and timezone (neither the old nor new). Here is the problem illustrated. You will see that after setting TZ, altzone, timezone, and tzname don't change, while asctime does. $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import time,os >>> print time.asctime() Thu Nov 29 18:47:39 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print time.asctime() Fri Nov 30 14:47:52 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') Here is an example of why this is a problem in practice. One of my applications sets the TZ environment variable based on a "TIMEZONE" setting in the user's configuration file. It later uses the `email' module to create a "Date:" header for outgoing mail messages. Because of this bug, the resulting "Date:" is bogus. e.g, $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import email,os >>> print email.Utils.formatdate(localtime=1) Thu, 29 Nov 2001 18:52:34 -0700 >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print email.Utils.formatdate(localtime=1) Fri, 30 Nov 2001 14:52:41 -0600 The `-0600' should be `+1300', and `-0600' isn't correct even for the original timezone! You might say: "Work around this by setting TZ before the time module is first imported." -- No, that is too fragile, and too difficult to do with complex applications. Many other modules in turn import time, etc. I suggest instead that the TZ environment variable be consulted each time the timezone is accessed. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 07:04 Message: Logged In: YES user_id=12800 BTW, one way to possibly handle this would be to add something to time module that created a "timezone object", encapsulating daylight, timezone, and altzone for arbitrary timezones. Then date producing code like email.Utils.formatdate() could take optional timezone objects to produce dates relative to the given zone. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 07:03 Message: Logged In: YES user_id=12800 OT, but what about adding mxDateTime to core Python <2.3 wink>? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-04 01:36 Message: Logged In: YES user_id=38388 Jason, as I already mentioned in my other reply, exposing tzset() to Python would cause more trouble than do any good because of the side-effects it has. Rather then provide ways to write buggy code in Python, I suggest to look into solving the problem you seem to have using the available tools, e.g. mxDateTime runs on many different platforms and integrates nicely with Python. If the email package is the only one you need fixed, I suggest to write a small helper or patch which implements the needed modifications for this package. BTW, what are you exact requirements ? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-03 13:56 Message: Logged In: YES user_id=85984 I'm fairly ignorant of the gory details behind the scenes of the time module, but I still contend this is buggy behavior. That is, setting os.environ['TZ'] in the application totally breaks higher level methods such as email.Utils.formatdate(). Barry had a suggestion which Mark doesn't think is a good idea. Mark, are you sure there isn't anything that can be done? If think that if you disregard this issue, it will come back to haunt the Python community. With regards to your suggestion of mxDateTime: I really can't consider this as I don't want to rely on any external modules or packages. One of my application's strengths is that it "just works" out of the box with Python, so it's very easy to install. I'd like to keep it that way unless it's absolutely necessary to do otherwise. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 12:53 Message: Logged In: YES user_id=38388 I don't know whether this is such a good idea -- after all it's fairly easy to manage timezones in the application rather than trying to fiddle the C libs routines into producing the output you intend. Also note that tzset() is *not* thread safe. BTW, Jason, you may want to have a look at mxDateTime -- perhaps it already has what you are looking for. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-11-30 12:11 Message: Logged In: YES user_id=12800 Perhaps we should expose tzset() to Python? We'd also have to reset timezone, altzone, daylight, and tzname in the module after calling tzset(). It's a bit of work, and adds a feature so it can't go into Python 2.2, but if you think this is a viable approach, re-assign this bug to me and I'll deal with it for Python 2.3. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 11:01 Message: Logged In: YES user_id=38388 The time module is a very thin layer on top of the C lib time APIs. There's nothing much Python can do about errors in those APIs, e.g. not recognizing changes to TZ. Also note that the tzset() API which inits the time APIs w/r to the TZ environment variable is only called at time module import time. To expose the dynamic changes you are looking for, it would have to call tzset() prior to all calls to asctime() et al. -- much too time consuming ! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487331&group_id=5470 From noreply@sourceforge.net Tue Dec 4 15:48:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 07:48:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-487331 ] time mod's timezone doesn't honor TZ var Message-ID: Bugs item #487331, was opened at 2001-11-29 18:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487331&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 3 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: M.-A. Lemburg (lemburg) Summary: time mod's timezone doesn't honor TZ var Initial Comment: Python's time module seems to get the timezone name when it's first imported, but it doesn't change it if the TZ environment variable is later set. On the other hand, the time of day DOES change accordingly. Thus, setting TZ after the time module is imported results in a completely broken rfc2822 date - time in the new TZ, but with a bogus UTC offset and timezone (neither the old nor new). Here is the problem illustrated. You will see that after setting TZ, altzone, timezone, and tzname don't change, while asctime does. $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import time,os >>> print time.asctime() Thu Nov 29 18:47:39 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print time.asctime() Fri Nov 30 14:47:52 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') Here is an example of why this is a problem in practice. One of my applications sets the TZ environment variable based on a "TIMEZONE" setting in the user's configuration file. It later uses the `email' module to create a "Date:" header for outgoing mail messages. Because of this bug, the resulting "Date:" is bogus. e.g, $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import email,os >>> print email.Utils.formatdate(localtime=1) Thu, 29 Nov 2001 18:52:34 -0700 >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print email.Utils.formatdate(localtime=1) Fri, 30 Nov 2001 14:52:41 -0600 The `-0600' should be `+1300', and `-0600' isn't correct even for the original timezone! You might say: "Work around this by setting TZ before the time module is first imported." -- No, that is too fragile, and too difficult to do with complex applications. Many other modules in turn import time, etc. I suggest instead that the TZ environment variable be consulted each time the timezone is accessed. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-04 07:48 Message: Logged In: YES user_id=38388 Well, this may sound easy, but once you get into timezones things start to become one big can of worms, e.g. just have a look at how daylight savings time is handled in different countries of the world or how time zone names sometimes map to multiple different zones. OTOH, numeric timezones are easy to handle and all that is needed is some simple code to convert a ticks value plus an offset to a nice ISO string representation an vice-versa. That should be easy to add to the time module... About adding mxDateTime to the core: I suppose it's simply too big. Also, I have a slightly different way of maintaining the mx tools than what is considered the Python way -- I usually happily add new features and modules without much fuzz; wouldn't want to have to write a PEP to enhance my own stuff ;-) As compromise, I could add some ISO date/time parsing and formatting code from mxDateTime to Python 2.3. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 07:04 Message: Logged In: YES user_id=12800 BTW, one way to possibly handle this would be to add something to time module that created a "timezone object", encapsulating daylight, timezone, and altzone for arbitrary timezones. Then date producing code like email.Utils.formatdate() could take optional timezone objects to produce dates relative to the given zone. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 07:03 Message: Logged In: YES user_id=12800 OT, but what about adding mxDateTime to core Python <2.3 wink>? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-04 01:36 Message: Logged In: YES user_id=38388 Jason, as I already mentioned in my other reply, exposing tzset() to Python would cause more trouble than do any good because of the side-effects it has. Rather then provide ways to write buggy code in Python, I suggest to look into solving the problem you seem to have using the available tools, e.g. mxDateTime runs on many different platforms and integrates nicely with Python. If the email package is the only one you need fixed, I suggest to write a small helper or patch which implements the needed modifications for this package. BTW, what are you exact requirements ? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-03 13:56 Message: Logged In: YES user_id=85984 I'm fairly ignorant of the gory details behind the scenes of the time module, but I still contend this is buggy behavior. That is, setting os.environ['TZ'] in the application totally breaks higher level methods such as email.Utils.formatdate(). Barry had a suggestion which Mark doesn't think is a good idea. Mark, are you sure there isn't anything that can be done? If think that if you disregard this issue, it will come back to haunt the Python community. With regards to your suggestion of mxDateTime: I really can't consider this as I don't want to rely on any external modules or packages. One of my application's strengths is that it "just works" out of the box with Python, so it's very easy to install. I'd like to keep it that way unless it's absolutely necessary to do otherwise. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 12:53 Message: Logged In: YES user_id=38388 I don't know whether this is such a good idea -- after all it's fairly easy to manage timezones in the application rather than trying to fiddle the C libs routines into producing the output you intend. Also note that tzset() is *not* thread safe. BTW, Jason, you may want to have a look at mxDateTime -- perhaps it already has what you are looking for. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-11-30 12:11 Message: Logged In: YES user_id=12800 Perhaps we should expose tzset() to Python? We'd also have to reset timezone, altzone, daylight, and tzname in the module after calling tzset(). It's a bit of work, and adds a feature so it can't go into Python 2.2, but if you think this is a viable approach, re-assign this bug to me and I'll deal with it for Python 2.3. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 11:01 Message: Logged In: YES user_id=38388 The time module is a very thin layer on top of the C lib time APIs. There's nothing much Python can do about errors in those APIs, e.g. not recognizing changes to TZ. Also note that the tzset() API which inits the time APIs w/r to the TZ environment variable is only called at time module import time. To expose the dynamic changes you are looking for, it would have to call tzset() prior to all calls to asctime() et al. -- much too time consuming ! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487331&group_id=5470 From noreply@sourceforge.net Tue Dec 4 15:49:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 07:49:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-487331 ] time mod's timezone doesn't honor TZ var Message-ID: Bugs item #487331, was opened at 2001-11-29 18:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487331&group_id=5470 Category: Python Library >Group: Feature Request Status: Open Resolution: None Priority: 3 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: M.-A. Lemburg (lemburg) Summary: time mod's timezone doesn't honor TZ var Initial Comment: Python's time module seems to get the timezone name when it's first imported, but it doesn't change it if the TZ environment variable is later set. On the other hand, the time of day DOES change accordingly. Thus, setting TZ after the time module is imported results in a completely broken rfc2822 date - time in the new TZ, but with a bogus UTC offset and timezone (neither the old nor new). Here is the problem illustrated. You will see that after setting TZ, altzone, timezone, and tzname don't change, while asctime does. $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import time,os >>> print time.asctime() Thu Nov 29 18:47:39 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print time.asctime() Fri Nov 30 14:47:52 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') Here is an example of why this is a problem in practice. One of my applications sets the TZ environment variable based on a "TIMEZONE" setting in the user's configuration file. It later uses the `email' module to create a "Date:" header for outgoing mail messages. Because of this bug, the resulting "Date:" is bogus. e.g, $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import email,os >>> print email.Utils.formatdate(localtime=1) Thu, 29 Nov 2001 18:52:34 -0700 >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print email.Utils.formatdate(localtime=1) Fri, 30 Nov 2001 14:52:41 -0600 The `-0600' should be `+1300', and `-0600' isn't correct even for the original timezone! You might say: "Work around this by setting TZ before the time module is first imported." -- No, that is too fragile, and too difficult to do with complex applications. Many other modules in turn import time, etc. I suggest instead that the TZ environment variable be consulted each time the timezone is accessed. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-04 07:48 Message: Logged In: YES user_id=38388 Well, this may sound easy, but once you get into timezones things start to become one big can of worms, e.g. just have a look at how daylight savings time is handled in different countries of the world or how time zone names sometimes map to multiple different zones. OTOH, numeric timezones are easy to handle and all that is needed is some simple code to convert a ticks value plus an offset to a nice ISO string representation an vice-versa. That should be easy to add to the time module... About adding mxDateTime to the core: I suppose it's simply too big. Also, I have a slightly different way of maintaining the mx tools than what is considered the Python way -- I usually happily add new features and modules without much fuzz; wouldn't want to have to write a PEP to enhance my own stuff ;-) As compromise, I could add some ISO date/time parsing and formatting code from mxDateTime to Python 2.3. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 07:04 Message: Logged In: YES user_id=12800 BTW, one way to possibly handle this would be to add something to time module that created a "timezone object", encapsulating daylight, timezone, and altzone for arbitrary timezones. Then date producing code like email.Utils.formatdate() could take optional timezone objects to produce dates relative to the given zone. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 07:03 Message: Logged In: YES user_id=12800 OT, but what about adding mxDateTime to core Python <2.3 wink>? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-04 01:36 Message: Logged In: YES user_id=38388 Jason, as I already mentioned in my other reply, exposing tzset() to Python would cause more trouble than do any good because of the side-effects it has. Rather then provide ways to write buggy code in Python, I suggest to look into solving the problem you seem to have using the available tools, e.g. mxDateTime runs on many different platforms and integrates nicely with Python. If the email package is the only one you need fixed, I suggest to write a small helper or patch which implements the needed modifications for this package. BTW, what are you exact requirements ? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-03 13:56 Message: Logged In: YES user_id=85984 I'm fairly ignorant of the gory details behind the scenes of the time module, but I still contend this is buggy behavior. That is, setting os.environ['TZ'] in the application totally breaks higher level methods such as email.Utils.formatdate(). Barry had a suggestion which Mark doesn't think is a good idea. Mark, are you sure there isn't anything that can be done? If think that if you disregard this issue, it will come back to haunt the Python community. With regards to your suggestion of mxDateTime: I really can't consider this as I don't want to rely on any external modules or packages. One of my application's strengths is that it "just works" out of the box with Python, so it's very easy to install. I'd like to keep it that way unless it's absolutely necessary to do otherwise. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 12:53 Message: Logged In: YES user_id=38388 I don't know whether this is such a good idea -- after all it's fairly easy to manage timezones in the application rather than trying to fiddle the C libs routines into producing the output you intend. Also note that tzset() is *not* thread safe. BTW, Jason, you may want to have a look at mxDateTime -- perhaps it already has what you are looking for. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-11-30 12:11 Message: Logged In: YES user_id=12800 Perhaps we should expose tzset() to Python? We'd also have to reset timezone, altzone, daylight, and tzname in the module after calling tzset(). It's a bit of work, and adds a feature so it can't go into Python 2.2, but if you think this is a viable approach, re-assign this bug to me and I'll deal with it for Python 2.3. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 11:01 Message: Logged In: YES user_id=38388 The time module is a very thin layer on top of the C lib time APIs. There's nothing much Python can do about errors in those APIs, e.g. not recognizing changes to TZ. Also note that the tzset() API which inits the time APIs w/r to the TZ environment variable is only called at time module import time. To expose the dynamic changes you are looking for, it would have to call tzset() prior to all calls to asctime() et al. -- much too time consuming ! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487331&group_id=5470 From noreply@sourceforge.net Tue Dec 4 15:56:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 07:56:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-488894 ] bad message for non-string getattr Message-ID: Bugs item #488894, was opened at 2001-12-04 06:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488894&group_id=5470 >Category: Type/class unification Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: bad message for non-string getattr Initial Comment: object.__getattribute__(obj, 1) prints a bizarre error message, because the error message code assumes the name argument is always a string. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 07:56 Message: Logged In: YES user_id=6380 I decided to fix this by insisting in PyObject_Generic{Gete,Set}Attr() that the attribute name be a string (or ASCII-fiable Unicode), like the other getattr/setattr functions. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488894&group_id=5470 From noreply@sourceforge.net Tue Dec 4 16:11:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 08:11:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-487331 ] time mod's timezone doesn't honor TZ var Message-ID: Bugs item #487331, was opened at 2001-11-29 18:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487331&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 3 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: M.-A. Lemburg (lemburg) Summary: time mod's timezone doesn't honor TZ var Initial Comment: Python's time module seems to get the timezone name when it's first imported, but it doesn't change it if the TZ environment variable is later set. On the other hand, the time of day DOES change accordingly. Thus, setting TZ after the time module is imported results in a completely broken rfc2822 date - time in the new TZ, but with a bogus UTC offset and timezone (neither the old nor new). Here is the problem illustrated. You will see that after setting TZ, altzone, timezone, and tzname don't change, while asctime does. $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import time,os >>> print time.asctime() Thu Nov 29 18:47:39 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print time.asctime() Fri Nov 30 14:47:52 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') Here is an example of why this is a problem in practice. One of my applications sets the TZ environment variable based on a "TIMEZONE" setting in the user's configuration file. It later uses the `email' module to create a "Date:" header for outgoing mail messages. Because of this bug, the resulting "Date:" is bogus. e.g, $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import email,os >>> print email.Utils.formatdate(localtime=1) Thu, 29 Nov 2001 18:52:34 -0700 >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print email.Utils.formatdate(localtime=1) Fri, 30 Nov 2001 14:52:41 -0600 The `-0600' should be `+1300', and `-0600' isn't correct even for the original timezone! You might say: "Work around this by setting TZ before the time module is first imported." -- No, that is too fragile, and too difficult to do with complex applications. Many other modules in turn import time, etc. I suggest instead that the TZ environment variable be consulted each time the timezone is accessed. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 08:11 Message: Logged In: YES user_id=12800 Rightt, all I was thinking about was an object/function to encapsulate the numeric timezone values, daylight, timezone, and altzone, without sucking in all fo the timezone names and abbreviations. As for mxDateTime, yeah putting that into Python would probably mean some compromise on the projmgt side of things. OTOH, it would be damn handy! :) Oh well, plenty of time to think about this for Python 2.3! ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-04 07:48 Message: Logged In: YES user_id=38388 Well, this may sound easy, but once you get into timezones things start to become one big can of worms, e.g. just have a look at how daylight savings time is handled in different countries of the world or how time zone names sometimes map to multiple different zones. OTOH, numeric timezones are easy to handle and all that is needed is some simple code to convert a ticks value plus an offset to a nice ISO string representation an vice-versa. That should be easy to add to the time module... About adding mxDateTime to the core: I suppose it's simply too big. Also, I have a slightly different way of maintaining the mx tools than what is considered the Python way -- I usually happily add new features and modules without much fuzz; wouldn't want to have to write a PEP to enhance my own stuff ;-) As compromise, I could add some ISO date/time parsing and formatting code from mxDateTime to Python 2.3. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 07:04 Message: Logged In: YES user_id=12800 BTW, one way to possibly handle this would be to add something to time module that created a "timezone object", encapsulating daylight, timezone, and altzone for arbitrary timezones. Then date producing code like email.Utils.formatdate() could take optional timezone objects to produce dates relative to the given zone. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 07:03 Message: Logged In: YES user_id=12800 OT, but what about adding mxDateTime to core Python <2.3 wink>? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-04 01:36 Message: Logged In: YES user_id=38388 Jason, as I already mentioned in my other reply, exposing tzset() to Python would cause more trouble than do any good because of the side-effects it has. Rather then provide ways to write buggy code in Python, I suggest to look into solving the problem you seem to have using the available tools, e.g. mxDateTime runs on many different platforms and integrates nicely with Python. If the email package is the only one you need fixed, I suggest to write a small helper or patch which implements the needed modifications for this package. BTW, what are you exact requirements ? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-03 13:56 Message: Logged In: YES user_id=85984 I'm fairly ignorant of the gory details behind the scenes of the time module, but I still contend this is buggy behavior. That is, setting os.environ['TZ'] in the application totally breaks higher level methods such as email.Utils.formatdate(). Barry had a suggestion which Mark doesn't think is a good idea. Mark, are you sure there isn't anything that can be done? If think that if you disregard this issue, it will come back to haunt the Python community. With regards to your suggestion of mxDateTime: I really can't consider this as I don't want to rely on any external modules or packages. One of my application's strengths is that it "just works" out of the box with Python, so it's very easy to install. I'd like to keep it that way unless it's absolutely necessary to do otherwise. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 12:53 Message: Logged In: YES user_id=38388 I don't know whether this is such a good idea -- after all it's fairly easy to manage timezones in the application rather than trying to fiddle the C libs routines into producing the output you intend. Also note that tzset() is *not* thread safe. BTW, Jason, you may want to have a look at mxDateTime -- perhaps it already has what you are looking for. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-11-30 12:11 Message: Logged In: YES user_id=12800 Perhaps we should expose tzset() to Python? We'd also have to reset timezone, altzone, daylight, and tzname in the module after calling tzset(). It's a bit of work, and adds a feature so it can't go into Python 2.2, but if you think this is a viable approach, re-assign this bug to me and I'll deal with it for Python 2.3. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 11:01 Message: Logged In: YES user_id=38388 The time module is a very thin layer on top of the C lib time APIs. There's nothing much Python can do about errors in those APIs, e.g. not recognizing changes to TZ. Also note that the tzset() API which inits the time APIs w/r to the TZ environment variable is only called at time module import time. To expose the dynamic changes you are looking for, it would have to call tzset() prior to all calls to asctime() et al. -- much too time consuming ! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487331&group_id=5470 From noreply@sourceforge.net Tue Dec 4 16:23:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 08:23:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-486144 ] Uninitialized __slot__ vrbl is None Message-ID: Bugs item #486144, was opened at 2001-11-27 11:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486144&group_id=5470 Category: Type/class unification Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Guido van Rossum (gvanrossum) Summary: Uninitialized __slot__ vrbl is None Initial Comment: >>> class C(object): ... __slots__ = ['a'] ... >>> c = C() >>> print c.a None >>> Nothing else in Python works like this -- a (possibly subclass of) NameError exception would be better. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 08:23 Message: Logged In: YES user_id=6380 Fixed in CVS as I described. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-27 18:45 Message: Logged In: YES user_id=6380 While this is not normal for class instances, built-in types have long had this behavior -- if a built-in type has an object pointer attribute described by a structmember with code T_OBJECT, it has this behavior (NULL is treated as None rather than absent attribute). I propose to add a T_OBJECT_EX structmember code, which raises an exception for NULL instead of returning None. This can then be used by the __slots__ code in typeobject.c. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486144&group_id=5470 From noreply@sourceforge.net Tue Dec 4 16:37:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 08:37:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-488482 ] xrange() * large integer Message-ID: Bugs item #488482, was opened at 2001-12-03 09:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488482&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Guido van Rossum (gvanrossum) Summary: xrange() * large integer Initial Comment: The (admittedly deprecated) feature that allows xrange objects to be multiplied by an integer no longer detects overflow because of PyNumber_Multiply() returning a long integer object in recent Python versions: Objects/rangeobject.c: long_mul(): we call PyNumber_Multiply() and bail out if the result is NULL, but then use PyInt_AS_LONG() without checking the object type. This gives unexpected results when PyNumber_Multiply() returns a PyLongObject. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 08:37 Message: Logged In: YES user_id=6380 Fixed in rangeobject.c:2.30. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488482&group_id=5470 From noreply@sourceforge.net Tue Dec 4 16:41:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 08:41:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-487390 ] Modifying type.__module__ behavior Message-ID: Bugs item #487390, was opened at 2001-11-29 21:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487390&group_id=5470 >Category: Type/class unification >Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Burton Radons (loth) >Assigned to: Guido van Rossum (gvanrossum) Summary: Modifying type.__module__ behavior Initial Comment: A __module__ attribute request on a C type will return __builtin__ if the typeobject.c code cannot find a period in the type name. This is always incorrect for extension libraries, and can be a _very_ confusing error when trying to pickle your types (as the error makes it seem as if you're supposed to register your type in __builtin__). I propose that: A) All builtin Python types have a "__builtin__." prefixed to their type declaration's name. B) If the __module__ code cannot find a period, it raises AttributeError with a somewhat descriptive message. This would be in the place where it returns __builtin__. C) The tp_name comment in Include/object.h describe the special semantics. "/* 'module.typename' */", for example. This is a lot of files to change, I know, but it's only one or two line changes each file. The only code this should affect is code which is written incorrectly; it may not understand the name semantics, or it may actually be registering itself in __builtin__ (as I did before I figured out what it was doing). Otherwise we're golden. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 08:41 Message: Logged In: YES user_id=6380 I agree with this in principle, but I don't hve the time to make all the changes. Can you submit a patch? Since, as you say, it's so simple, I wouldn't object against including it in 2.2c1, if it's submitted in time (2.2c1 is planned for December 12 -- give us a couple of days before that). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487390&group_id=5470 From noreply@sourceforge.net Tue Dec 4 16:43:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 08:43:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-487193 ] ftplib violates rfc1123 section 4.1.2.6 Message-ID: Bugs item #487193, was opened at 2001-11-29 11:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487193&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Suchandra Thapa (ssthapa) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib violates rfc1123 section 4.1.2.6 Initial Comment: RFC 1123 specifies that ftp clients can not depend on 227 responses to pasv commands having the format given in the rfc 959. The ftplib assumes that the pasv parameters are returned within parentheses. In particular ftplib breaks when downloading binaries from an anonftpd servre. I've included a patch that uses the re module to obtain the pasv parameters instead. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 08:43 Message: Logged In: YES user_id=6380 This is already fixed in CVS for 2.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487193&group_id=5470 From noreply@sourceforge.net Tue Dec 4 16:43:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 08:43:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-487193 ] ftplib violates rfc1123 section 4.1.2.6 Message-ID: Bugs item #487193, was opened at 2001-11-29 11:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487193&group_id=5470 Category: Python Library Group: Python 2.1.1 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Suchandra Thapa (ssthapa) >Assigned to: Guido van Rossum (gvanrossum) Summary: ftplib violates rfc1123 section 4.1.2.6 Initial Comment: RFC 1123 specifies that ftp clients can not depend on 227 responses to pasv commands having the format given in the rfc 959. The ftplib assumes that the pasv parameters are returned within parentheses. In particular ftplib breaks when downloading binaries from an anonftpd servre. I've included a patch that uses the re module to obtain the pasv parameters instead. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 08:43 Message: Logged In: YES user_id=6380 This is already fixed in CVS for 2.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487193&group_id=5470 From noreply@sourceforge.net Tue Dec 4 16:45:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 08:45:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-487310 ] smtplib mishandles SMTP disconnects Message-ID: Bugs item #487310, was opened at 2001-11-29 16:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487310&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Fazal Majid (majid) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib mishandles SMTP disconnects Initial Comment: smtplib handles SMTP disconnects (e.g. timeouts) inconsistently. The smtplib.SMTP.send() method does not reset self.file on a socket error, unlike getreply(), and thus a close() is necessary for in one case but not in the other. Recommendation: have smtplib.SMTP.send() call close() on socket.error just as smtplib.SMTP.getreply() does on EOF on self.file. In the following test case, I have set the SMTP timeout on my local machine to 10 seconds: Python 2.1.1 (#1, Nov 7 2001, 16:18:10) [GCC 2.95.3 20010315 (release)] on sunos5 Type "copyright", "credits" or "license" for more information. >>> import smtplib >>> s = smtplib.SMTP('localhost', 25) >>> import time >>> time.sleep(10) >>> s.sendmail('fmajid@kefta.com', 'fmajid@kefta.com', '...') Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.1/smtplib.py", line 469, in sendmail (code,resp) = self.helo() File "/usr/local/lib/python2.1/smtplib.py", line 305, in helo self.putcmd("helo", socket.getfqdn()) File "/usr/local/lib/python2.1/smtplib.py", line 249, in putcmd self.send(str) File "/usr/local/lib/python2.1/smtplib.py", line 239, in send raise SMTPServerDisconnected('Server not connected') smtplib.SMTPServerDisconnected: Server not connected >>> s.connect('localhost', 25) Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.1/smtplib.py", line 226, in connect (code,msg)=self.getreply() File "/usr/local/lib/python2.1/smtplib.py", line 271, in getreply raise SMTPServerDisconnected("Connection unexpectedly closed") smtplib.SMTPServerDisconnected: Connection unexpectedly closed >>> s.connect('localhost', 25) (220, 'bayazid.kefta.com ESMTP Postfix') ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 08:45 Message: Logged In: YES user_id=6380 Can you please supply a patch? Upload a context diff, don't forget to check the file upload checkbox. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2001-11-30 07:04 Message: Logged In: YES user_id=110477 I forgot to mention a workaround: if you catch SMTPServerDisconnected, call self.close(). The operation is idempotent so it isn't a problem if you do it twice, for instance if the exception occurs in getreply(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487310&group_id=5470 From noreply@sourceforge.net Tue Dec 4 16:45:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 08:45:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-430753 ] Python 2.1 build fails on hp-ux 11 Message-ID: Bugs item #430753, was opened at 2001-06-06 10:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=430753&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.1 build fails on hp-ux 11 Initial Comment: I'm building on HP-UX 11.00 with HP C B.11.02.02. I've tried it on both Series 700 and 800 hardware. I've attached the make logfile. There are problems with: build.py not adding +z when compiling modules termios.c - may be fixed according to another bug report _cursesmodule.c Please send any fixes to joshua.weage@arup.com Thanks ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-08-30 13:41 Message: Logged In: YES user_id=31392 The attached make output shows a lot of problems compiling the curses support. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=430753&group_id=5470 From noreply@sourceforge.net Tue Dec 4 16:45:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 08:45:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-410993 ] linuxaudiodev fails during "make test". Message-ID: Bugs item #410993, was opened at 2001-03-24 02:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410993&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: Accepted Priority: 4 Submitted By: Sean Reifschneider (jafo) >Assigned to: Nobody/Anonymous (nobody) >Summary: linuxaudiodev fails during "make test". Initial Comment: Picked up 2.1b2 and did "./configure" and "make test" on a RedHat 7.0-based system: test test_linuxaudiodev crashed -- linuxaudiodev.error: (11, 'Resource temporarily unavailable') Was running build as root, and "mpg123" runs successfully before and after. This is on a ThinkPad 240 with esssolo1 driver with 2.2.18 kernel. Sean ---------------------------------------------------------------------- Comment By: Charles G Waldman (cgw) Date: 2001-09-05 11:36 Message: Logged In: YES user_id=7151 I've been out of town and somewhat out of the loop. But I'm back now. I will look into this over the weekend. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 10:56 Message: Logged In: YES user_id=6380 Charles, are you still interested in tackling this bug? If not, let us know! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 21:27 Message: Logged In: YES user_id=6380 We've gone back and forth over this one. It seems to happen for certain drivers for certain audio cards -- the problem has disappeared for most folks, but still works for some hardware (e.g. some Dell laptops running Mandrake). I've assigned this to Charles Waldman since he seems to know this area; he commented in python-dev that the initialization order is invalid. Charles if you still feel you won't touch this module (because you'd rather give us a new module that does the right thing), please close it as Won't Fix -- that's what I almost did until I remembered your interest. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-11 09:36 Message: Logged In: YES user_id=6380 I think you misread his comment. He wasn't mpg123 *during* the test, he ran it before and after the test to verify that in fact his audio was in good working order. But, I do suggest to him to try the CVS version, which is one (relevant) fix ahead of 2.1b2. That version passes the test for me, but I don't hear a thing, so I'm not sure what's going on... ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-04-11 07:19 Message: Logged In: YES user_id=31392 I think we should report this failure as "test skipped." I think it would be essentially correct: The test was skipped because the device was in use. It's not a crash. Not sure how this test is affected by the recent changes to the module to handle EAGAIN. Sean or Guido-- can you try it with the updated module? My Linux audio config is screwed up. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410993&group_id=5470 From noreply@sourceforge.net Tue Dec 4 16:45:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 08:45:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-487471 ] urllib2 proxyhandle won't work. Message-ID: Bugs item #487471, was opened at 2001-11-30 04:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487471&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Ha Shao (hashao) >Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 proxyhandle won't work. Initial Comment: For python 2.2b2: Adding proxyhandler with build_opener, install_opener does not work since order of the handlers does matter (my guess). In the current code, new handlers are appended at the end of the handlers list. At least under windows, the proxyhandle will never got called if it is added with install_opener. HTTPHandler always get called before proxyhandler if the default list is altered. The attached patch try to reserve the order of handlers based on their baseclass when adding new handlers. Handlers with the same baseclasses might be added more than once. Not sure if it is a good thing or bad thing. Current code will raise except when it trys to remove the default handlers twice. Since order does matter, build_opener should be repleased by a list like class such that user can insert their handlers to specific place. ---------------------------------------------------------------------- Comment By: Ha Shao (hashao) Date: 2001-11-30 05:10 Message: Logged In: YES user_id=8717 forgot some code and changed a stupid variable name. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487471&group_id=5470 From noreply@sourceforge.net Tue Dec 4 16:48:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 08:48:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-486247 ] ftplib/URLLib time outs on transfers Message-ID: Bugs item #486247, was opened at 2001-11-27 15:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486247&group_id=5470 Category: Extension Modules Group: Python 2.1.1 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Tom Fillmore (tfillmor) >Assigned to: Guido van Rossum (gvanrossum) Summary: ftplib/URLLib time outs on transfers Initial Comment: Hi - On upgrading to v2.1.1 my ftp apps stopped working, all with time out errors when transferring files of any length. I did set the set_pasv method to false, to emulate the v2.0 behavior, which worked OK, but still got the same time out errors. I also tested them with v2.2b but got the same errors. Bottom line - with versions above v2.0 the urllib and ftp;ib extensions time out on transfers. Simply re-installing v2.0 fixed the problem. It is always possible that I was not setting the method correctly, so here's what I did to the set_pasv method: sessionname.set_pasv("false") My specs are: Win2000 server python v2.01 Nothing. There is no third thing... 8-) Thanks in advance! Tom Fillmore tfillmor@oc-bahai.org ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 08:48 Message: Logged In: YES user_id=6380 set_pasv("false") is the same as set_pasv("true"), i.e. any string argument of nonzero length is considered true. Try set_pasv(0) to disable the default of passive mode. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486247&group_id=5470 From noreply@sourceforge.net Tue Dec 4 16:48:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 08:48:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-471942 ] python2.1.1 SEGV in GC on Solaris 2.7 Message-ID: Bugs item #471942, was opened at 2001-10-16 19:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Anthony Baxter (anthonybaxter) Summary: python2.1.1 SEGV in GC on Solaris 2.7 Initial Comment: I've got a Zope installation where python2.1.1 is segfaulting on Solaris2.7 - it's running a largish ZEO server. The tail of the gdb output is: #128 0x26164 in PyEval_CallObjectWithKeywords () #129 0x264c0 in PyEval_CallObjectWithKeywords () #130 0x26140 in PyEval_CallObjectWithKeywords () #131 0x25fc0 in PyEval_CallObjectWithKeywords () #132 0x517bc in PyInstance_New () #133 0x261a4 in PyEval_CallObjectWithKeywords () #134 0x25fc0 in PyEval_CallObjectWithKeywords () #135 0x42c90 in initgc () It's built with $ gcc -v Reading specs from /opt/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs gcc version 2.95.2 19991024 (release) which is a bit old. I'm going to rebuild with gcc3.0 and also try turning off the GC. Unfortunately I can't get this to happen on a smaller test system - it's only under load that it plows into the ground. I'll also leave symbols in this time... :/ ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-12-04 08:48 Message: Logged In: YES user_id=31392 This was the bug that was tracked down to a problem in try/except/finally, wasn't it? If this is fixed, can you close the bug report? If not, can you provide an udpate on its current status? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-07 14:13 Message: Logged In: YES user_id=21627 Any news on this report: did the problem disappear after backporting changes? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 04:32 Message: Logged In: YES user_id=21627 Looking at the changes since 2.1.1, I can see one bugfix that might explain strange behaviour, namely ceval.c 2.277. If you want to try it out, you can get the change here http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Python/ceval.c.diff?r1=2.276&r2=2.277 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 03:59 Message: Logged In: YES user_id=29957 What's the appropriate way to ask this? drop a line to python-dev? purify's showing a UMR in strop_expandtabs (from memory - don't have it on screen right now) when python starts up. Yeah, the realloc bug concerns me - I have to wonder if something's a little bit/lot screwy. I just don't know where. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 03:46 Message: Logged In: YES user_id=21627 This is something to ask the pythonlabs folks; I believe Python has been purified once in a while - perhaps even with Zope extensions. I'd still suspect a bug in the Zope extensions instead of a Python bug, though: if malloc crashes, chances are high that somebody was overwriting free memory. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 03:31 Message: Logged In: YES user_id=29957 It's not a GC object. I'm positive all the extension objects are correct - I just recompiled, without the 1.5/2.0 headers around. It's a different pointer each time round, unfortunately. It also takes anything from 5 minutes to 2 hours to reproduce. I've got about 4 copies of it running now, and I've got a bunch of different core files. I've grabbed purify and an eval license, and I'm feeding it the binary. The printf approach is probably not going to work - these are busy busy Zope servers. Instead, my plan, assuming that purify doesn't immediately spot a problem, is to change the code so that if it gets a dud GC object, it will just bust it out of the tree and let it leak, and print a message saying so. Then I can quit the program, and purify will tell me 'hey, you leaked!' and also tell me where it was allocated. More concerning, about half the segfaults are not from the GC at all, but from realloc in PyFrame_New (line 161 of frameobject). These are the only two I'm getting - it's split 50-50 amongst the 10 coredumps I have now. I'm not sure whether to open a seperate bug for this. Has python2.1.1 been purified? With Zope and zope's extensions? Wow - it's amazing how this SF bug thing is so painful for conversations :) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 03:11 Message: Logged In: YES user_id=21627 There are two options: a) the object isn't really a GC object, i.e. has no GC header. In gdb, you can try to cast gc to PyObject*, then see if the resulting pointer has a better ob_type (this is unlikely, though, since the logic entering the object was already using fromgc/togc) b) somebody has cleared the ob_type field. Can you guarantee that all extension modules have been compiled with the 2.1.1 header files? Is the problem repeatable in the sense that gc will have the same pointer value on each crash? If so, it is relatively easy to track down: just set a gdb change watchpoint on the address on the ob_type field of that address (note that setting watchpoints is not possible until there is really mapped memory on that address). If you can't analyse it through change breakpoints, I recommend to annotate the interpreter in the following way: in pyobject_init, put a printf that prints the address and the tp_name of the type. In subtract_refs, if the ob_type slot is null, print the address of the object and abort. Then analyse the log to see whether a object really has been allocated on that address, and what its type was (make sure you consider the possibility that address are off by the delta that FROM_GC adds). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-17 21:58 Message: Logged In: YES user_id=29957 Ok, I have an intact core file, and a matching binary, no optimisations, nothing. This crash is showing the crash at line 166 of gcmodule.c traverse = PyObject_FROM_GC(gc)->ob_type->tp_traverse; PyObject_FROM_GC(gc)->ob_type in this case is $24 = {ob_refcnt = 1, ob_type = 0x0} To check my logic, I checked gc_next and gc_prev using the same GDB magic, and they correctly show up as a tuple and an instance method. Some fiddling around seems to rule out stack space as the problem, as well. We're going to try and see if purify helps here, but the problem looks to be a junk object - I have no idea how to track this down further. Help? Would taking the horrible horrible hack of removing the object from the gc linked list if ob_type is null help? Well, it'd stop the crashes, anyway. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-17 13:44 Message: Logged In: YES user_id=21627 It would be interesting what the value of "gc" is at the time of the crash. It looks like you got an object that claims to support GC but has a null tp_traverse. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-17 06:08 Message: Logged In: YES user_id=29957 I'm a doofus who read the gdb trace from the wrong end - too much python lately :) Nonetheless, the other end of the trace failed in gc as well - and building without GC enabled worked. Here's the trace with debugging enabled: #0 0xff00 in ?? () #1 0x402f0 in collect (young=0x9b538, old=0x9b544) at ./Modules/gcmodule.c:379 #2 0x405a8 in collect_generations () at ./Modules/gcmodule.c:484 #3 0x40624 in _PyGC_Insert (op=0xbc1f24) at ./Modules/gcmodule.c:507 #4 0x5a224 in PyList_New (size=0) at Objects/listobject.c:61 #5 0x21bc8 in eval_code2 (co=0x1cb370, globals=0x21bc0, locals=0x67, args=0x0, argcount=1, kws=0xf89b24, kwcount=0, defs=0x0, defcount=0, closure=0xbc1f24) at Python/ceval.c:1741 Next trick is to rebuild without any optimisation (sigh) as I suspect that it's inlined subtract_refs(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 From noreply@sourceforge.net Tue Dec 4 16:48:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 08:48:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-484156 ] no thread support on HP-UX 10.20 Message-ID: Bugs item #484156, was opened at 2001-11-21 05:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=484156&group_id=5470 Category: Threads Group: Platform-specific >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Guido van Rossum (gvanrossum) Summary: no thread support on HP-UX 10.20 Initial Comment: cannot compile with thread support on HP-UX 10.20 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 08:48 Message: Logged In: YES user_id=6380 No details forthcoming. Closing as duplicate (this has been reported umpteen times and is apparently fixed in 2.2). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-23 14:14 Message: Logged In: YES user_id=21627 Can you provide details? Without any details (like: what did you do, what did the computer say, why do you think this is incorrect) we won't be able to do anything about this problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=484156&group_id=5470 From noreply@sourceforge.net Tue Dec 4 16:51:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 08:51:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-483126 ] cgitb does not recover Message-ID: Bugs item #483126, was opened at 2001-11-18 10:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=483126&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Dan Grassi (dgrassi) >Assigned to: Ka-Ping Yee (ping) Summary: cgitb does not recover Initial Comment: chitb does not recover when sys.stdout has been resigned. The fix is simple, set sys.stdout to sys.__stdout__ in cgitb.handle right after the import of sys. line 160: def handle(self, info=None): import sys + sys.stdout = sys.__stdout__ print reset() ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 08:51 Message: Logged In: YES user_id=6380 Passing this to Ping. Note: using sys.__stdout__ is rarely the right thing -- who knows if sys.stdout hasn't been reassigned for a good reason? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=483126&group_id=5470 From noreply@sourceforge.net Tue Dec 4 17:07:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 09:07:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-479967 ] Python/C API manual has no index section Message-ID: Bugs item #479967, was opened at 2001-11-09 04:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479967&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Thomas Heller (theller) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Python/C API manual has no index section Initial Comment: In the development docs, the Python/C API manual the index section is missing. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-04 09:07 Message: Logged In: YES user_id=3066 Fixed in Doc/perl/l2hinit.perl revision 1.58. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-28 21:00 Message: Logged In: YES user_id=3066 Yes -- this is the same bug (I hope!). The "Extending & Embedding" manual's index is also missing. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2001-11-19 06:18 Message: Logged In: YES user_id=86307 The docs included with the Windows 2.2b2 distribution only have indexes (genindex.html) for the lib and mac subdirectories. The indexes for the C API and Python Reference Manual are missing (I assume this is the same bug as reported here). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-09 06:43 Message: Logged In: YES user_id=3066 Raised the severity of this -- this *must* be fixed! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479967&group_id=5470 From noreply@sourceforge.net Tue Dec 4 17:34:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 09:34:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-482574 ] audioop.ratecv crashes Message-ID: Bugs item #482574, was opened at 2001-11-16 10:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482574&group_id=5470 Category: Extension Modules Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Baas (mbaas) >Assigned to: Tim Peters (tim_one) Summary: audioop.ratecv crashes Initial Comment: The ratecv in the audioop module can crash under certain conditions. I'm using Python 2.1.1 under Win98 SE and SuSE Linux 7.2 Here's a small program that demonstrates the problem. It creates an empty sample and tries to call ratecv. ################################################## import audioop nchannels = 2 width = 2 framerate = 44100 nframes = 107880 frames = nchannels*width*nframes*chr(0) newrate = 37083 #newrate = 35002 newfrag,state = audioop.ratecv(frames, width, nchannels, framerate, newrate, None) ################################################## With newrate = 37083 it crashes and with 35002 it creates a MemoryError exception. I already had a look into the source of audioop and found the problem to be in the following line inside audioop_ratecv(): str = PyString_FromStringAndSize( NULL, size * nchannels * (len * outrate + inrate - 1) / inrate); With big enough samples the second argument simply overflows. In the case of newrate=35002 the above expression yields a negative value and so an MemoryError exception occurs. With newrate=37083 the expression yields a positive value, but one that's much too small, so the remainder of the function writes into unallocated memory and crashes. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 09:34 Message: Logged In: YES user_id=6380 You're right. All it's calculating is a safe upper bound for the output buffer size. Tim will fix it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482574&group_id=5470 From noreply@sourceforge.net Tue Dec 4 18:32:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 10:32:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-483126 ] cgitb does not recover Message-ID: Bugs item #483126, was opened at 2001-11-18 10:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=483126&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Dan Grassi (dgrassi) Assigned to: Ka-Ping Yee (ping) Summary: cgitb does not recover Initial Comment: chitb does not recover when sys.stdout has been resigned. The fix is simple, set sys.stdout to sys.__stdout__ in cgitb.handle right after the import of sys. line 160: def handle(self, info=None): import sys + sys.stdout = sys.__stdout__ print reset() ---------------------------------------------------------------------- >Comment By: Ka-Ping Yee (ping) Date: 2001-12-04 10:32 Message: Logged In: YES user_id=45338 It seems strange that sys.stdout should ever get reassigned in a CGI script. Anyway, the CGI specification does state that the output must appear on stdout, so the traceback from cgitb should go to the "real" stdout. We are accepting the user's decision to "import cgitb" as a declaration that they are using CGI, so as a slightly more conservative solution than jumping to sys.__stdout__, i'll have cgitb save sys.stdout at the time that it is first loaded. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 08:51 Message: Logged In: YES user_id=6380 Passing this to Ping. Note: using sys.__stdout__ is rarely the right thing -- who knows if sys.stdout hasn't been reassigned for a good reason? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=483126&group_id=5470 From noreply@sourceforge.net Tue Dec 4 18:46:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 10:46:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-483126 ] cgitb does not recover Message-ID: Bugs item #483126, was opened at 2001-11-18 10:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=483126&group_id=5470 Category: Python Library Group: Python 2.1.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dan Grassi (dgrassi) Assigned to: Ka-Ping Yee (ping) Summary: cgitb does not recover Initial Comment: chitb does not recover when sys.stdout has been resigned. The fix is simple, set sys.stdout to sys.__stdout__ in cgitb.handle right after the import of sys. line 160: def handle(self, info=None): import sys + sys.stdout = sys.__stdout__ print reset() ---------------------------------------------------------------------- >Comment By: Ka-Ping Yee (ping) Date: 2001-12-04 10:46 Message: Logged In: YES user_id=45338 All right. I checked in a fix that adds a 'file' argument to the Hook constructor, so you can redirect the output if you want. By default, sys.stdout is saved in the Hook when it is created (cgitb.enable does this, for instance). ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2001-12-04 10:32 Message: Logged In: YES user_id=45338 It seems strange that sys.stdout should ever get reassigned in a CGI script. Anyway, the CGI specification does state that the output must appear on stdout, so the traceback from cgitb should go to the "real" stdout. We are accepting the user's decision to "import cgitb" as a declaration that they are using CGI, so as a slightly more conservative solution than jumping to sys.__stdout__, i'll have cgitb save sys.stdout at the time that it is first loaded. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 08:51 Message: Logged In: YES user_id=6380 Passing this to Ping. Note: using sys.__stdout__ is rarely the right thing -- who knows if sys.stdout hasn't been reassigned for a good reason? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=483126&group_id=5470 From noreply@sourceforge.net Tue Dec 4 19:16:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 11:16:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-411612 ] cgi.py sometimes ignores QUERY_STRING Message-ID: Bugs item #411612, was opened at 2001-03-27 03:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411612&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 3 Submitted By: Viktor Fougstedt (viktordt) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.py sometimes ignores QUERY_STRING Initial Comment: [Using Python 2.0/Sparc Solaris 8, should be independent of operating system] cgi.py sometimes ignores the QUERY_STRING when REQUEST_METHOD is POST. The CGI specifications says nothing about how programs should respond to this particular combination. It does however state that QUERY_STRING should always be set by the server, regardless of the request method. Since QUERY_STRING is set, it seems reasonable that the cgi module should parse it as well and not just ignore it. If cgi.py intentionally ignores QUERY_STRING under these circumstances, I think it should be documented. :-) What this means is that if i have a HTML form a'la
and some_cgi is a python script using cgi.py, I should get both foo and bar set. Currently, the QUERY_STRING (i.e. "foo=foo") is ignored, and only bar gets set by cgi.py. I consider this a "bug" insofar as it is an unexpected and somewhat inconsistent behaviour. If I e.g. use the url "/cgi-bin/myprog/session_id=10023" everywhere in my program, I must suddenly alter it if the URL is used in a FORM action attribute, and instead insert a hidden variable called session_id into the form to get cgi.py to parse it. The parse() function in cgi.py correctly checks and appends QUERY_STRING if it is set. But the FieldStorage read_urlencoded() method does not, and that is the function that is actually used, not cgi.parse(). The fix should be to add two lines (marked with '>' below) after the initial assignment to qs in the read_urlencoded() method of the FieldStorage class so that it begins: def read_urlencoded(self): """Internal: read data in query string format.""" qs = self.fp.read(self.length) if os.environ.has_key('QUERY_STRING'): if qs: qs = qs + '&' qs = qs + environ['QUERY_STRING'] (the three last lines are new, and identical to the three lines in the cgi.parse() function which accomplishes the same task). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 11:16 Message: Logged In: YES user_id=6380 Rejected for lack of time. I don't have the time to figure out what the right behavior should be, and the patch appears to be broken. Steve Holden, perhaps you might want to submit a patch (for Python 2.3) that does what you think is correct? ---------------------------------------------------------------------- Comment By: Steve Holden (holdenweb) Date: 2001-07-17 04:00 Message: Logged In: YES user_id=88157 This appears to be a somewhat grey area: certainly the CGI specifications say that the QUERY_STRING must be made available, but does it make sense to treat QUERY_STRING data as of equal importance when standard input is present in a POST method request? In particular, if QUERY_STRING contains "spam=eggs" and the standard input contains "spam=chips" then should FieldStorage().getitem("spam") return ["eggs", "chips"]? Appealing to the behaviour of other servers is possibly not the best guide for the cgi library's action, but it might be instructive to see how other systems have approached this problem before changes are made. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 08:30 Message: Logged In: YES user_id=6380 The idea is right, but since nobody volunteered a working patch, this won't make it into 2.1. Sorry. Try again after 2.1! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-03-27 04:23 Message: Logged In: NO Quick check: That "fix" does not work. It duplicates the QUERY_STRING if you use the GET method. Additional checks are necessary to ensure correct operation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411612&group_id=5470 From noreply@sourceforge.net Tue Dec 4 19:17:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 11:17:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-411612 ] cgi.py sometimes ignores QUERY_STRING Message-ID: Bugs item #411612, was opened at 2001-03-27 03:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411612&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Viktor Fougstedt (viktordt) >Assigned to: Guido van Rossum (gvanrossum) Summary: cgi.py sometimes ignores QUERY_STRING Initial Comment: [Using Python 2.0/Sparc Solaris 8, should be independent of operating system] cgi.py sometimes ignores the QUERY_STRING when REQUEST_METHOD is POST. The CGI specifications says nothing about how programs should respond to this particular combination. It does however state that QUERY_STRING should always be set by the server, regardless of the request method. Since QUERY_STRING is set, it seems reasonable that the cgi module should parse it as well and not just ignore it. If cgi.py intentionally ignores QUERY_STRING under these circumstances, I think it should be documented. :-) What this means is that if i have a HTML form a'la
and some_cgi is a python script using cgi.py, I should get both foo and bar set. Currently, the QUERY_STRING (i.e. "foo=foo") is ignored, and only bar gets set by cgi.py. I consider this a "bug" insofar as it is an unexpected and somewhat inconsistent behaviour. If I e.g. use the url "/cgi-bin/myprog/session_id=10023" everywhere in my program, I must suddenly alter it if the URL is used in a FORM action attribute, and instead insert a hidden variable called session_id into the form to get cgi.py to parse it. The parse() function in cgi.py correctly checks and appends QUERY_STRING if it is set. But the FieldStorage read_urlencoded() method does not, and that is the function that is actually used, not cgi.parse(). The fix should be to add two lines (marked with '>' below) after the initial assignment to qs in the read_urlencoded() method of the FieldStorage class so that it begins: def read_urlencoded(self): """Internal: read data in query string format.""" qs = self.fp.read(self.length) if os.environ.has_key('QUERY_STRING'): if qs: qs = qs + '&' qs = qs + environ['QUERY_STRING'] (the three last lines are new, and identical to the three lines in the cgi.parse() function which accomplishes the same task). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 11:16 Message: Logged In: YES user_id=6380 Rejected for lack of time. I don't have the time to figure out what the right behavior should be, and the patch appears to be broken. Steve Holden, perhaps you might want to submit a patch (for Python 2.3) that does what you think is correct? ---------------------------------------------------------------------- Comment By: Steve Holden (holdenweb) Date: 2001-07-17 04:00 Message: Logged In: YES user_id=88157 This appears to be a somewhat grey area: certainly the CGI specifications say that the QUERY_STRING must be made available, but does it make sense to treat QUERY_STRING data as of equal importance when standard input is present in a POST method request? In particular, if QUERY_STRING contains "spam=eggs" and the standard input contains "spam=chips" then should FieldStorage().getitem("spam") return ["eggs", "chips"]? Appealing to the behaviour of other servers is possibly not the best guide for the cgi library's action, but it might be instructive to see how other systems have approached this problem before changes are made. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 08:30 Message: Logged In: YES user_id=6380 The idea is right, but since nobody volunteered a working patch, this won't make it into 2.1. Sorry. Try again after 2.1! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-03-27 04:23 Message: Logged In: NO Quick check: That "fix" does not work. It duplicates the QUERY_STRING if you use the GET method. Additional checks are necessary to ensure correct operation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411612&group_id=5470 From noreply@sourceforge.net Tue Dec 4 19:22:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 11:22:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-485446 ] tutorial: backticks, repr(), str() Message-ID: Bugs item #485446, was opened at 2001-11-25 17:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485446&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: tutorial: backticks, repr(), str() Initial Comment: http://python.sourceforge.net/devel-docs/tut/node9.html: > how do you convert values to strings? Luckily, Python > has a way to convert any value to a string: pass it to > the repr() function, or just write the value between > reverse quotes (``). Some examples: a) str() should probably be mentioned b) is it good to teach newbies to use backticks? i don't remember when i've last seen them in python code and it's easy to confuse them with single quotes. -- erno@iki.fi ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-04 11:22 Message: Logged In: YES user_id=3066 Fixed in Doc/tut/tut.tex revision 1.155. Backticks are still useful: they are concise and reliable, even if __builtin__ gets modified. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485446&group_id=5470 From noreply@sourceforge.net Tue Dec 4 20:13:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 12:13:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-489052 ] define NDEBUG for release builds Message-ID: Bugs item #489052, was opened at 2001-12-04 12:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489052&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: define NDEBUG for release builds Initial Comment: NDEBUG should be defined on the command line during release builds of Python, so that assert() statements go away. We tried defining it in Python.h, but that interferes with extensions linking Python.h (and created real problems for Robin Dunn). The Windows build already does this. The Linux build needs it, and assigned to Fred for that part. Fred, please assign to jackjansen when you're done, so he can consider the Mac build. Any other build need special treatment? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489052&group_id=5470 From noreply@sourceforge.net Tue Dec 4 20:56:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 12:56:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-489052 ] define NDEBUG for release builds Message-ID: Bugs item #489052, was opened at 2001-12-04 12:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489052&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Tim Peters (tim_one) >Assigned to: Jack Jansen (jackjansen) Summary: define NDEBUG for release builds Initial Comment: NDEBUG should be defined on the command line during release builds of Python, so that assert() statements go away. We tried defining it in Python.h, but that interferes with extensions linking Python.h (and created real problems for Robin Dunn). The Windows build already does this. The Linux build needs it, and assigned to Fred for that part. Fred, please assign to jackjansen when you're done, so he can consider the Mac build. Any other build need special treatment? ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-04 12:56 Message: Logged In: YES user_id=3066 The Unix portion of this is fixed in configure.in revision 1.284. Passing to Jack for Mac OS magic. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489052&group_id=5470 From noreply@sourceforge.net Tue Dec 4 21:41:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 13:41:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-483925 ] _hotshot sloppy in error handling Message-ID: Bugs item #483925, was opened at 2001-11-20 12:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=483925&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: _hotshot sloppy in error handling Initial Comment: _hotshot is rather sloppy in its handling of I/O errors. The low-level flush_data() routine checks for I/O errors, sets an exception and returns -1, but all the routines calling flush_data() then happily ignore this. The effect of this is that the exception is orphaned and will come back to haunt you at a completely unexpected moment. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-04 13:41 Message: Logged In: YES user_id=3066 Fixed to do proper propogation of exceptions in Modules/_hotshot.c revision 1.11. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=483925&group_id=5470 From noreply@sourceforge.net Tue Dec 4 22:48:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 14:48:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-486500 ] cgitb,inspect,pydoc Message-ID: Bugs item #486500, was opened at 2001-11-28 07:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486500&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: cgitb,inspect,pydoc Initial Comment: the actual Beta-Version 2.2b2 of Python does not contain any documentation for the above mentioned Modules. So, the one who looks for this can't find it via /doc/ TXN lh, bs ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-04 14:48 Message: Logged In: YES user_id=3066 The "inspect" module already has documentation: http://www.python.org/doc/current/lib/module-inspect.html I'll be checking in documentation for "cgitb" momentarily. SF bug #420498 already reports that "pydoc" is undocumented. Closing as "fixed" (for cgitb) since I can't close it as "fixed"/"duplicate". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486500&group_id=5470 From noreply@sourceforge.net Tue Dec 4 23:06:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 15:06:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-488480 ] integer multiply to return -max_int-1 Message-ID: Bugs item #488480, was opened at 2001-12-03 09:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488480&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: integer multiply to return -max_int-1 Initial Comment: integer multiplication never returns '-sys.max_int-1' but signals an OverflowError instead (or in Python 2.2b1 returns a long). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-04 15:06 Message: Logged In: YES user_id=31435 Actually, it *can* return -sys.maxint-1, but only if the inputs are exactly right. The overflow checking here was a mess; replaced by a vastly simpler method, in Lib/test/test_types.py; new revision: 1.22 Objects/intobject.c; new revision: 2.79 ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2001-12-03 09:23 Message: Logged In: YES user_id=4771 (sorry, I was not logged in when I submitted this one) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-03 09:22 Message: Logged In: YES user_id=31435 Confirmed, and assigned to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488480&group_id=5470 From noreply@sourceforge.net Tue Dec 4 23:38:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 15:38:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-488730 ] os.popen() seg faults on FreeBSD 5 Message-ID: Bugs item #488730, was opened at 2001-12-03 21:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Marc Culler (marcculler) Assigned to: Nobody/Anonymous (nobody) >Summary: os.popen() seg faults on FreeBSD 5 Initial Comment: Here is the crash with Python 2.1.1 on my FreeBSD 5.0-current system: [ace:culler]$ python Python 2.1.1 (#5, Aug 18 2001, 17:41:43) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') Segmentation fault (core dumped) No problem occurs when I do the same thing in Python 2.0, which was compiled under FreeBSD 4, but is running here under FreeBSD 5: [ace:culler]$ python2.0 Python 2.0 (#2, Nov 16 2000, 22:22:48) [GCC 2.95.2 19991024 (release)] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') >>> mypipe.readlines() ['COPYRIGHT\012', 'bin\012', 'boot\012', 'cdrom\012', 'compat\012', 'dev\012', 'dist\012', 'entropy\012', 'etc\012', 'home\012', 'kernel\012', 'kernel.GENERIC\012', 'kernel.old\012', 'kernel.prev\012', 'mnt\012', 'modules\012', 'modules.old\012', 'proc\012', 'root\012', 'sbin\012', 'shared\012', 'stand\012', 'sys\012', 'tmp\012', 'usr\012', 'var\012'] >>> ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 From noreply@sourceforge.net Wed Dec 5 00:30:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 16:30:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-489158 ] Parser fails with TypeError Message-ID: Bugs item #489158, was opened at 2001-12-04 16:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489158&group_id=5470 Category: Parser/Compiler Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Parser fails with TypeError Initial Comment: Attached is a module containing a rather large dictionary literal which refuses to parse. I've looked at it until I'll blurry eyed and cannot fine the error. Since it may be a bug in the parser I'm submitting it here. If you can import it, I'm stumped. I've used Python 2.2b1 and b2 on Windows. -Robin >>> import funny Traceback (most recent call last): File "", line 1, in ? import funny File "funny.py", line 12, in ? _DTD = { 'tt': _basic, TypeError: can only concatenate tuple (not "str") to tuple >>> ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489158&group_id=5470 From noreply@sourceforge.net Wed Dec 5 00:34:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 16:34:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-489158 ] Parser fails with TypeError Message-ID: Bugs item #489158, was opened at 2001-12-04 16:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489158&group_id=5470 Category: Parser/Compiler Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Parser fails with TypeError Initial Comment: Attached is a module containing a rather large dictionary literal which refuses to parse. I've looked at it until I'll blurry eyed and cannot fine the error. Since it may be a bug in the parser I'm submitting it here. If you can import it, I'm stumped. I've used Python 2.2b1 and b2 on Windows. -Robin >>> import funny Traceback (most recent call last): File "", line 1, in ? import funny File "funny.py", line 12, in ? _DTD = { 'tt': _basic, TypeError: can only concatenate tuple (not "str") to tuple >>> ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-04 16:34 Message: Logged In: NO OK The file attachment feature failed. Let me know where I might send the 7KB file. -Robin robinfriedrich@pdq.net ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489158&group_id=5470 From noreply@sourceforge.net Wed Dec 5 00:47:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 16:47:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-489158 ] Parser fails with TypeError Message-ID: Bugs item #489158, was opened at 2001-12-04 16:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489158&group_id=5470 Category: Parser/Compiler Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Parser fails with TypeError Initial Comment: Attached is a module containing a rather large dictionary literal which refuses to parse. I've looked at it until I'll blurry eyed and cannot fine the error. Since it may be a bug in the parser I'm submitting it here. If you can import it, I'm stumped. I've used Python 2.2b1 and b2 on Windows. -Robin >>> import funny Traceback (most recent call last): File "", line 1, in ? import funny File "funny.py", line 12, in ? _DTD = { 'tt': _basic, TypeError: can only concatenate tuple (not "str") to tuple >>> ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 16:47 Message: Logged In: YES user_id=6380 OK, mail it to guido@python.org. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-04 16:34 Message: Logged In: NO OK The file attachment feature failed. Let me know where I might send the 7KB file. -Robin robinfriedrich@pdq.net ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489158&group_id=5470 From noreply@sourceforge.net Wed Dec 5 00:51:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 16:51:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-489158 ] Parser fails with TypeError Message-ID: Bugs item #489158, was opened at 2001-12-04 16:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489158&group_id=5470 Category: Parser/Compiler Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Tim Peters (tim_one) Summary: Parser fails with TypeError Initial Comment: Attached is a module containing a rather large dictionary literal which refuses to parse. I've looked at it until I'll blurry eyed and cannot fine the error. Since it may be a bug in the parser I'm submitting it here. If you can import it, I'm stumped. I've used Python 2.2b1 and b2 on Windows. -Robin >>> import funny Traceback (most recent call last): File "", line 1, in ? import funny File "funny.py", line 12, in ? _DTD = { 'tt': _basic, TypeError: can only concatenate tuple (not "str") to tuple >>> ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-04 16:51 Message: Logged In: YES user_id=31435 It shouldn't be possible for the parser to raise a TypeError. Are you claiming that this exact code worked under some version of Python prior to 2.2b1 (not arguing, I simply can't tell what your claim is)? You can mail the file to me, if you like. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 16:47 Message: Logged In: YES user_id=6380 OK, mail it to guido@python.org. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-04 16:34 Message: Logged In: NO OK The file attachment feature failed. Let me know where I might send the 7KB file. -Robin robinfriedrich@pdq.net ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489158&group_id=5470 From noreply@sourceforge.net Wed Dec 5 02:19:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 18:19:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-489158 ] Parser fails with TypeError Message-ID: Bugs item #489158, was opened at 2001-12-04 16:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489158&group_id=5470 >Category: None >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Guido van Rossum (gvanrossum) Summary: Parser fails with TypeError Initial Comment: Attached is a module containing a rather large dictionary literal which refuses to parse. I've looked at it until I'll blurry eyed and cannot fine the error. Since it may be a bug in the parser I'm submitting it here. If you can import it, I'm stumped. I've used Python 2.2b1 and b2 on Windows. -Robin >>> import funny Traceback (most recent call last): File "", line 1, in ? import funny File "funny.py", line 12, in ? _DTD = { 'tt': _basic, TypeError: can only concatenate tuple (not "str") to tuple >>> ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 18:19 Message: Logged In: YES user_id=6380 It was a simple user error (missing trailing comma in a singleton tuple). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-04 16:51 Message: Logged In: YES user_id=31435 It shouldn't be possible for the parser to raise a TypeError. Are you claiming that this exact code worked under some version of Python prior to 2.2b1 (not arguing, I simply can't tell what your claim is)? You can mail the file to me, if you like. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 16:47 Message: Logged In: YES user_id=6380 OK, mail it to guido@python.org. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-04 16:34 Message: Logged In: NO OK The file attachment feature failed. Let me know where I might send the 7KB file. -Robin robinfriedrich@pdq.net ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489158&group_id=5470 From noreply@sourceforge.net Wed Dec 5 05:47:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 21:47:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-484857 ] print with comma ended Message-ID: Bugs item #484857, was opened at 2001-11-23 05:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=484857&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Hernan Martinez Foffani (hfoffani) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: print with comma ended Initial Comment: python 2.2a1 on windows 2000 professional, and the included IDLE. the following function prints 'AB' in the command line, but 'A B' in IDLE. should print 'AB' as stated in chapter 6.6 item 3 of the Reference manual def test(): print "%c" % 65, sys.stdout.write("") print "%c" % 66 test() ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-04 21:47 Message: Logged In: YES user_id=3066 Fixed in Doc/ref/ref6.tex revision 1.43. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-11-23 18:07 Message: Logged In: YES user_id=6380 You're right, that's what the docs say. I'm in a predicament though: I found at least half a dozen places in IDLE alone where a class defines a write() method in order to be usable as an output file, and I would have to add "self.softspace = 0" to each of these methods. I'm sure there are tons of other "file-like objects" (e.g. StringIO and cStringIO) that also have this same "deficiency" and would have to be fixed the same way. I'd rather update the docs to clarify that while this is the behavior of the standard file object, not all file-like objects behave this way, and programs shouldn't count on this. If you want a reliable way to get rid of the space, assign zero to sys.stdout.softspace yourself, rather than using sys.stdout.write(""). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=484857&group_id=5470 From noreply@sourceforge.net Wed Dec 5 05:49:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 21:49:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-221671 ] bad link David Ascher's compile.py script Message-ID: Bugs item #221671, was opened at 2000-11-05 08:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=221671&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Mark Phillips (mphillips) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: bad link David Ascher's compile.py script Initial Comment: The document "Extending and Embedding the Python Interpreter, October 16, 2000, Release 2.0", at http://www.python.org/doc/current/ext/win-cookbook.html contains a bad link to bad link David Ascher's compile.py script; the link is to http://starship.python.net/crew/da/compile/ but this URL doesn't work (it redirects to one that refuses connections). It'd be great if someone could put compile.py someplace accessible and fix this link! --Mark ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-04 21:49 Message: Logged In: YES user_id=3066 The entire section that links to this script is seriously in need of updating. I'll try to look at this tomorrow. Bumping the priority up, but not so much as to block the release. ---------------------------------------------------------------------- Comment By: David Ascher (david_ascher) Date: 2001-09-05 22:37 Message: Logged In: YES user_id=6114 I'll gladly provide the script, but I've lost any energy keeping a permanent website up. I haven't touched the script in ages. I agree that distutils is probably the way to go at this point. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-11-08 22:38 Message: This is a known problem. I have a copy of the script, but I need someone to test it to make sure it works with Python 2.0. Another possibility is to push the Distutils tools; that may be a better option at this point. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=221671&group_id=5470 From noreply@sourceforge.net Wed Dec 5 05:51:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 21:51:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-489256 ] Lib/profile.doc should be (re?)moved Message-ID: Bugs item #489256, was opened at 2001-12-04 21:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Lib/profile.doc should be (re?)moved Initial Comment: What's Lib/profile.doc doing there? Is it still needed? Why is it in Lib, anyway? (it seems very old - is it still up to date after all the hackery? doesn't seem so) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470 From noreply@sourceforge.net Wed Dec 5 06:08:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 22:08:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-489256 ] Lib/profile.doc should be updated Message-ID: Bugs item #489256, was opened at 2001-12-04 21:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: Lib/profile.doc should be updated Initial Comment: What's Lib/profile.doc doing there? Is it still needed? Why is it in Lib, anyway? (it seems very old - is it still up to date after all the hackery? doesn't seem so) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-04 22:08 Message: Logged In: YES user_id=3066 profile.doc is used as the help file for profile.py, and is read by an external pager (sloppily) using the profile.help() function. Either the document should be updated and the help() function should be more intelligent about the pager, or... ...the document and the help() function should be removed. This is a possibility since help() is not documented. profile.doc should be updated for Python 2.2; other changes will need to wait for Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470 From noreply@sourceforge.net Wed Dec 5 06:11:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 22:11:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-482574 ] audioop.ratecv crashes Message-ID: Bugs item #482574, was opened at 2001-11-16 10:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482574&group_id=5470 Category: Extension Modules Group: Python 2.1.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthias Baas (mbaas) Assigned to: Tim Peters (tim_one) Summary: audioop.ratecv crashes Initial Comment: The ratecv in the audioop module can crash under certain conditions. I'm using Python 2.1.1 under Win98 SE and SuSE Linux 7.2 Here's a small program that demonstrates the problem. It creates an empty sample and tries to call ratecv. ################################################## import audioop nchannels = 2 width = 2 framerate = 44100 nframes = 107880 frames = nchannels*width*nframes*chr(0) newrate = 37083 #newrate = 35002 newfrag,state = audioop.ratecv(frames, width, nchannels, framerate, newrate, None) ################################################## With newrate = 37083 it crashes and with 35002 it creates a MemoryError exception. I already had a look into the source of audioop and found the problem to be in the following line inside audioop_ratecv(): str = PyString_FromStringAndSize( NULL, size * nchannels * (len * outrate + inrate - 1) / inrate); With big enough samples the second argument simply overflows. In the case of newrate=35002 the above expression yields a negative value and so an MemoryError exception occurs. With newrate=37083 the expression yields a positive value, but one that's much too small, so the remainder of the function writes into unallocated memory and crashes. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-04 22:11 Message: Logged In: YES user_id=31435 This is fixed in Modules/audioop.c, revision 1.45. The rates in your test case work fine now, and so does a newrate of 20 million; IOW, ratecv shouldn't suffer spurious overflows anymore, and if you pass absurdly large arguments no legitimate overflows should go undetected anymore either. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 09:34 Message: Logged In: YES user_id=6380 You're right. All it's calculating is a safe upper bound for the output buffer size. Tim will fix it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482574&group_id=5470 From noreply@sourceforge.net Wed Dec 5 07:36:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 23:36:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-469772 ] support additional LINK elements. Message-ID: Bugs item #469772, was opened at 2001-10-09 23:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=469772&group_id=5470 Category: Documentation Group: Feature Request >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Anthony Baxter (anthonybaxter) Summary: support additional LINK elements. Initial Comment: Now that mozilla supports the LINK element properly, it would be most excellent if the python docs were generated with more LINK elements. At the moment they're built with up, previous, and next. Some of the others are defined in http://www.w3.org/TR/REC-html40/types.html#type-links Ones that would be very nice are Top, Contents and Index. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-04 23:36 Message: Logged In: YES user_id=29957 Hm. I think the current set of LINKs is pretty good - I'm not sure if it's worth revisiting this sometime down the track when (hopefully) the state-of-the-art in what LINK does will have become better defined. closing. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-24 15:10 Message: Logged In: YES user_id=3066 Anthony, what do you think of the current status on this? Do we need to worry about this further in the near future? I've marked it fixed but left it open & assigned to you; please comment and either close or re-assign to me as needed. Thanks! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-22 14:27 Message: Logged In: YES user_id=3066 The Mozilla bug I filed (see my previous comment) was declared a duplicate of this bug: http://bugzilla.mozilla.org/show_bug.cgi?id=102915 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-22 10:05 Message: Logged In: YES user_id=3066 OK, I've played with this a bit more, and I've modified the transformation to support more elements (Doc/perl/l2hinit.perl revision 1.56), but the intended semantics are still pretty fuzzy. In particular, the links described seem to work within a tree which can share a single definition of these links throughout. Given that "top", "start", and "first" are not well defined, it's not clear how to apply these. The Python documentation consists of a set of documents which each have specific identities (the Library Reference, Python/C API manual, etc.). Does "start" refer to the front of an individual manual or the collection? How about "top"? The use of "document" to mean "page" in the W3C documents doesn't help. What I've done uses the title page of each document as the "first" link, but doesn't provide the "top" link at all. Mozilla also doesn't seem to understand that multiple indexes are entirely valid; it should probably convert the "Index" entry to a menu when there are multiple indexes -- I'll file a Mozilla bug report for this one. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-22 08:08 Message: Logged In: YES user_id=3066 Added some support for the "up" link in Doc/tools/support.py revision 1.4, but this only affects a couple of pages. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 08:46 Message: Logged In: YES user_id=29957 There's a very nice list of what link relationships do what for mozilla 0.9.5 posted at: http://lists.w3.org/Archives/Public/www-html/2001Oct/0026.html (link stolen from mozillazine) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=469772&group_id=5470 From noreply@sourceforge.net Wed Dec 5 07:38:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 04 Dec 2001 23:38:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-471942 ] python2.1.1 SEGV in GC on Solaris 2.7 Message-ID: Bugs item #471942, was opened at 2001-10-16 19:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Anthony Baxter (anthonybaxter) Summary: python2.1.1 SEGV in GC on Solaris 2.7 Initial Comment: I've got a Zope installation where python2.1.1 is segfaulting on Solaris2.7 - it's running a largish ZEO server. The tail of the gdb output is: #128 0x26164 in PyEval_CallObjectWithKeywords () #129 0x264c0 in PyEval_CallObjectWithKeywords () #130 0x26140 in PyEval_CallObjectWithKeywords () #131 0x25fc0 in PyEval_CallObjectWithKeywords () #132 0x517bc in PyInstance_New () #133 0x261a4 in PyEval_CallObjectWithKeywords () #134 0x25fc0 in PyEval_CallObjectWithKeywords () #135 0x42c90 in initgc () It's built with $ gcc -v Reading specs from /opt/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs gcc version 2.95.2 19991024 (release) which is a bit old. I'm going to rebuild with gcc3.0 and also try turning off the GC. Unfortunately I can't get this to happen on a smaller test system - it's only under load that it plows into the ground. I'll also leave symbols in this time... :/ ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-04 23:38 Message: Logged In: YES user_id=29957 Nah, this is a separate one to the frame bug. I'm still seeing it on a regular regular basis, but haven't narrowed it done to what's causing it. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-04 08:48 Message: Logged In: YES user_id=31392 This was the bug that was tracked down to a problem in try/except/finally, wasn't it? If this is fixed, can you close the bug report? If not, can you provide an udpate on its current status? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-07 14:13 Message: Logged In: YES user_id=21627 Any news on this report: did the problem disappear after backporting changes? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 04:32 Message: Logged In: YES user_id=21627 Looking at the changes since 2.1.1, I can see one bugfix that might explain strange behaviour, namely ceval.c 2.277. If you want to try it out, you can get the change here http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Python/ceval.c.diff?r1=2.276&r2=2.277 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 03:59 Message: Logged In: YES user_id=29957 What's the appropriate way to ask this? drop a line to python-dev? purify's showing a UMR in strop_expandtabs (from memory - don't have it on screen right now) when python starts up. Yeah, the realloc bug concerns me - I have to wonder if something's a little bit/lot screwy. I just don't know where. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 03:46 Message: Logged In: YES user_id=21627 This is something to ask the pythonlabs folks; I believe Python has been purified once in a while - perhaps even with Zope extensions. I'd still suspect a bug in the Zope extensions instead of a Python bug, though: if malloc crashes, chances are high that somebody was overwriting free memory. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 03:31 Message: Logged In: YES user_id=29957 It's not a GC object. I'm positive all the extension objects are correct - I just recompiled, without the 1.5/2.0 headers around. It's a different pointer each time round, unfortunately. It also takes anything from 5 minutes to 2 hours to reproduce. I've got about 4 copies of it running now, and I've got a bunch of different core files. I've grabbed purify and an eval license, and I'm feeding it the binary. The printf approach is probably not going to work - these are busy busy Zope servers. Instead, my plan, assuming that purify doesn't immediately spot a problem, is to change the code so that if it gets a dud GC object, it will just bust it out of the tree and let it leak, and print a message saying so. Then I can quit the program, and purify will tell me 'hey, you leaked!' and also tell me where it was allocated. More concerning, about half the segfaults are not from the GC at all, but from realloc in PyFrame_New (line 161 of frameobject). These are the only two I'm getting - it's split 50-50 amongst the 10 coredumps I have now. I'm not sure whether to open a seperate bug for this. Has python2.1.1 been purified? With Zope and zope's extensions? Wow - it's amazing how this SF bug thing is so painful for conversations :) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 03:11 Message: Logged In: YES user_id=21627 There are two options: a) the object isn't really a GC object, i.e. has no GC header. In gdb, you can try to cast gc to PyObject*, then see if the resulting pointer has a better ob_type (this is unlikely, though, since the logic entering the object was already using fromgc/togc) b) somebody has cleared the ob_type field. Can you guarantee that all extension modules have been compiled with the 2.1.1 header files? Is the problem repeatable in the sense that gc will have the same pointer value on each crash? If so, it is relatively easy to track down: just set a gdb change watchpoint on the address on the ob_type field of that address (note that setting watchpoints is not possible until there is really mapped memory on that address). If you can't analyse it through change breakpoints, I recommend to annotate the interpreter in the following way: in pyobject_init, put a printf that prints the address and the tp_name of the type. In subtract_refs, if the ob_type slot is null, print the address of the object and abort. Then analyse the log to see whether a object really has been allocated on that address, and what its type was (make sure you consider the possibility that address are off by the delta that FROM_GC adds). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-17 21:58 Message: Logged In: YES user_id=29957 Ok, I have an intact core file, and a matching binary, no optimisations, nothing. This crash is showing the crash at line 166 of gcmodule.c traverse = PyObject_FROM_GC(gc)->ob_type->tp_traverse; PyObject_FROM_GC(gc)->ob_type in this case is $24 = {ob_refcnt = 1, ob_type = 0x0} To check my logic, I checked gc_next and gc_prev using the same GDB magic, and they correctly show up as a tuple and an instance method. Some fiddling around seems to rule out stack space as the problem, as well. We're going to try and see if purify helps here, but the problem looks to be a junk object - I have no idea how to track this down further. Help? Would taking the horrible horrible hack of removing the object from the gc linked list if ob_type is null help? Well, it'd stop the crashes, anyway. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-17 13:44 Message: Logged In: YES user_id=21627 It would be interesting what the value of "gc" is at the time of the crash. It looks like you got an object that claims to support GC but has a null tp_traverse. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-17 06:08 Message: Logged In: YES user_id=29957 I'm a doofus who read the gdb trace from the wrong end - too much python lately :) Nonetheless, the other end of the trace failed in gc as well - and building without GC enabled worked. Here's the trace with debugging enabled: #0 0xff00 in ?? () #1 0x402f0 in collect (young=0x9b538, old=0x9b544) at ./Modules/gcmodule.c:379 #2 0x405a8 in collect_generations () at ./Modules/gcmodule.c:484 #3 0x40624 in _PyGC_Insert (op=0xbc1f24) at ./Modules/gcmodule.c:507 #4 0x5a224 in PyList_New (size=0) at Objects/listobject.c:61 #5 0x21bc8 in eval_code2 (co=0x1cb370, globals=0x21bc0, locals=0x67, args=0x0, argcount=1, kws=0xf89b24, kwcount=0, defs=0x0, defcount=0, closure=0xbc1f24) at Python/ceval.c:1741 Next trick is to rebuild without any optimisation (sigh) as I suspect that it's inlined subtract_refs(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 From noreply@sourceforge.net Wed Dec 5 09:37:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 01:37:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-487331 ] time mod's timezone doesn't honor TZ var Message-ID: Bugs item #487331, was opened at 2001-11-29 18:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487331&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 3 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: M.-A. Lemburg (lemburg) Summary: time mod's timezone doesn't honor TZ var Initial Comment: Python's time module seems to get the timezone name when it's first imported, but it doesn't change it if the TZ environment variable is later set. On the other hand, the time of day DOES change accordingly. Thus, setting TZ after the time module is imported results in a completely broken rfc2822 date - time in the new TZ, but with a bogus UTC offset and timezone (neither the old nor new). Here is the problem illustrated. You will see that after setting TZ, altzone, timezone, and tzname don't change, while asctime does. $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import time,os >>> print time.asctime() Thu Nov 29 18:47:39 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print time.asctime() Fri Nov 30 14:47:52 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') Here is an example of why this is a problem in practice. One of my applications sets the TZ environment variable based on a "TIMEZONE" setting in the user's configuration file. It later uses the `email' module to create a "Date:" header for outgoing mail messages. Because of this bug, the resulting "Date:" is bogus. e.g, $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import email,os >>> print email.Utils.formatdate(localtime=1) Thu, 29 Nov 2001 18:52:34 -0700 >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print email.Utils.formatdate(localtime=1) Fri, 30 Nov 2001 14:52:41 -0600 The `-0600' should be `+1300', and `-0600' isn't correct even for the original timezone! You might say: "Work around this by setting TZ before the time module is first imported." -- No, that is too fragile, and too difficult to do with complex applications. Many other modules in turn import time, etc. I suggest instead that the TZ environment variable be consulted each time the timezone is accessed. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-05 01:37 Message: Logged In: YES user_id=38388 Agreed. Let's continue to talk about this after Python 2.2 is out. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 08:11 Message: Logged In: YES user_id=12800 Rightt, all I was thinking about was an object/function to encapsulate the numeric timezone values, daylight, timezone, and altzone, without sucking in all fo the timezone names and abbreviations. As for mxDateTime, yeah putting that into Python would probably mean some compromise on the projmgt side of things. OTOH, it would be damn handy! :) Oh well, plenty of time to think about this for Python 2.3! ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-04 07:48 Message: Logged In: YES user_id=38388 Well, this may sound easy, but once you get into timezones things start to become one big can of worms, e.g. just have a look at how daylight savings time is handled in different countries of the world or how time zone names sometimes map to multiple different zones. OTOH, numeric timezones are easy to handle and all that is needed is some simple code to convert a ticks value plus an offset to a nice ISO string representation an vice-versa. That should be easy to add to the time module... About adding mxDateTime to the core: I suppose it's simply too big. Also, I have a slightly different way of maintaining the mx tools than what is considered the Python way -- I usually happily add new features and modules without much fuzz; wouldn't want to have to write a PEP to enhance my own stuff ;-) As compromise, I could add some ISO date/time parsing and formatting code from mxDateTime to Python 2.3. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 07:04 Message: Logged In: YES user_id=12800 BTW, one way to possibly handle this would be to add something to time module that created a "timezone object", encapsulating daylight, timezone, and altzone for arbitrary timezones. Then date producing code like email.Utils.formatdate() could take optional timezone objects to produce dates relative to the given zone. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 07:03 Message: Logged In: YES user_id=12800 OT, but what about adding mxDateTime to core Python <2.3 wink>? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-04 01:36 Message: Logged In: YES user_id=38388 Jason, as I already mentioned in my other reply, exposing tzset() to Python would cause more trouble than do any good because of the side-effects it has. Rather then provide ways to write buggy code in Python, I suggest to look into solving the problem you seem to have using the available tools, e.g. mxDateTime runs on many different platforms and integrates nicely with Python. If the email package is the only one you need fixed, I suggest to write a small helper or patch which implements the needed modifications for this package. BTW, what are you exact requirements ? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-03 13:56 Message: Logged In: YES user_id=85984 I'm fairly ignorant of the gory details behind the scenes of the time module, but I still contend this is buggy behavior. That is, setting os.environ['TZ'] in the application totally breaks higher level methods such as email.Utils.formatdate(). Barry had a suggestion which Mark doesn't think is a good idea. Mark, are you sure there isn't anything that can be done? If think that if you disregard this issue, it will come back to haunt the Python community. With regards to your suggestion of mxDateTime: I really can't consider this as I don't want to rely on any external modules or packages. One of my application's strengths is that it "just works" out of the box with Python, so it's very easy to install. I'd like to keep it that way unless it's absolutely necessary to do otherwise. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 12:53 Message: Logged In: YES user_id=38388 I don't know whether this is such a good idea -- after all it's fairly easy to manage timezones in the application rather than trying to fiddle the C libs routines into producing the output you intend. Also note that tzset() is *not* thread safe. BTW, Jason, you may want to have a look at mxDateTime -- perhaps it already has what you are looking for. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-11-30 12:11 Message: Logged In: YES user_id=12800 Perhaps we should expose tzset() to Python? We'd also have to reset timezone, altzone, daylight, and tzname in the module after calling tzset(). It's a bit of work, and adds a feature so it can't go into Python 2.2, but if you think this is a viable approach, re-assign this bug to me and I'll deal with it for Python 2.3. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 11:01 Message: Logged In: YES user_id=38388 The time module is a very thin layer on top of the C lib time APIs. There's nothing much Python can do about errors in those APIs, e.g. not recognizing changes to TZ. Also note that the tzset() API which inits the time APIs w/r to the TZ environment variable is only called at time module import time. To expose the dynamic changes you are looking for, it would have to call tzset() prior to all calls to asctime() et al. -- much too time consuming ! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487331&group_id=5470 From noreply@sourceforge.net Wed Dec 5 16:13:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 08:13:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-478428 ] dbm build fails Message-ID: Bugs item #478428, was opened at 2001-11-05 12:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478428&group_id=5470 Category: Macintosh Group: Python 2.2 Status: Closed Resolution: None Priority: 5 Submitted By: John Buell (dadaist) Assigned to: Jack Jansen (jackjansen) Summary: dbm build fails Initial Comment: Trying a build with cvs source downloaded this morning. I've been sure to do the configure --with-suffix=_ on case-insensitive Mac OS X (10.1), but I'm having some problem with the 'dbm' module. Here's a copy of the messages: building 'dbm' extension /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c: In function `dbm_subscript': /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c:104: warning: implicit declaration of function `dbm_error' /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c:105: warning: implicit declaration of function `dbm_clearerr' cc -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -I. -I/Users/jbuell/Documents/Python/python/dist/src/./Include -I/Users/jbuell/Documents/Python/python/dist/src/./Mac/Include -I/usr/local/include -IInclude/ -c /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c -o build/temp.darwin-1.4-Power Macintosh-2.2/dbmmodule.o cc -bundle -flat_namespace -undefined suppress build/temp.darwin-1.4-Power Macintosh-2.2/dbmmodule.o -L/usr/local/lib -o build/lib.darwin-1.4-Power Macintosh-2.2/dbm.so building 'gdbm' extension dyld: ./python_ Undefined symbols: __ashldi3 make: *** [sharedmods] Error 67 Any suggestions? Anything I can change in my settings to get past this? -John ---------------------------------------------------------------------- >Comment By: John Buell (dadaist) Date: 2001-12-05 08:13 Message: Logged In: YES user_id=368337 Okay, further checking shows that the beige G3 does NOT have a gdbm.h ANYWHERE, while the iBook does. No wonder it succeeds on the one and not on the other. [localhost:/Users/jbuell] root# ls -l `find / -name gdbm.h -print` -rw-r--r-- 1 root admin 4744 Oct 1 02:54 /sw/include/gdbm.h -rw-r--r-- 1 root wheel 4744 Feb 27 2001 /usr/local/include/gdbm.h I can include a copy of this gdbm.h if necessary. I'm wondering if it's from an older version that is breaking the python 2.2 build? Where in the build/make trees could I go to comment this out? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-04 03:21 Message: Logged In: YES user_id=45365 The problem isn't with /sw, it's with the gdbm.h that is installed in /usr/local/include. This is what triggers setup.py to try and build gdbm. The other questrion is of course why it doesn't work: if you have gdbm.h and libgdbm there's really no reason why it shouldn't build. ---------------------------------------------------------------------- Comment By: John Buell (dadaist) Date: 2001-12-03 09:29 Message: Logged In: YES user_id=368337 Sorry, I've been busy. I've narrowed it down to being a fink-related problem. My beige G3 without fink can build and install python 2.2 just fine. The iBook WITH fink is what doesn't like the gdbm thing. The odd part is that the fink directories (/sw/*) are NOT part of my path while I'm doing builds, but gdbm seems to be finding the extra files anyway. bash-2.05$ echo $PATH ~/bin/powerpc-apple-darwin:/Users/jbuell/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/X11R6/bin [localhost:/Users/jbuell] root# find / -name libgdbm.a -print /sw/lib/libgdbm.a /usr/local/lib/libgdbm.a [localhost:/Users/jbuell] root# find / -name gdbm.h -print /sw/include/gdbm.h /usr/local/include/gdbm.h Other than uninstalling fink, is there a way to get python's build mechanism to completely ignore /sw and its subdirectories? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-02 14:15 Message: Logged In: YES user_id=45365 As the originator didn't follow up on my previous remark and everything works fine for me I'm closing this bug. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-06 12:45 Message: Logged In: YES user_id=45365 Note that the problem is with gdbm, not with dbm. Dbm seems to build fine (with a warning). I've heard a report of this before. Needless to say, for me there is no problem whatsoever:-) I think that the problem is that setup.py detects files that indicate to it that dbm is available while in fact it is not. Could you check whether you have a libgdbm.a and/or a gdbm.h on your system somewhere? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478428&group_id=5470 From noreply@sourceforge.net Wed Dec 5 18:31:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 10:31:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-489472 ] pprint produces unreadable dict output Message-ID: Bugs item #489472, was opened at 2001-12-05 10:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489472&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jürgen A. Erhard (jae) Assigned to: Nobody/Anonymous (nobody) Summary: pprint produces unreadable dict output Initial Comment: Python 2.2b2 (Debian unstable), this minimal code: x={'243.220.21': 'cache1.nottingham.ac.uk', '186.164.253': 'bw1-164pub253.bluewin.ch'} import pprint print pprint.pformat(x) Output: {'186.164.253': 'bw1-164pub253.bluewin.ch', : '243.220.21''cache1.nottingham.ac.uk'} Removing the first number off *both* keys ("243." and "186.") and everything's fine. python 2.1.1 also fine. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489472&group_id=5470 From noreply@sourceforge.net Wed Dec 5 19:23:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 11:23:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-489472 ] pprint produces unreadable dict output Message-ID: Bugs item #489472, was opened at 2001-12-05 10:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489472&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jürgen A. Erhard (jae) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: pprint produces unreadable dict output Initial Comment: Python 2.2b2 (Debian unstable), this minimal code: x={'243.220.21': 'cache1.nottingham.ac.uk', '186.164.253': 'bw1-164pub253.bluewin.ch'} import pprint print pprint.pformat(x) Output: {'186.164.253': 'bw1-164pub253.bluewin.ch', : '243.220.21''cache1.nottingham.ac.uk'} Removing the first number off *both* keys ("243." and "186.") and everything's fine. python 2.1.1 also fine. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-05 11:23 Message: Logged In: YES user_id=6380 I can't reproduce this on my Linux system with 2.2b+. Assigning to Fred for further investigation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489472&group_id=5470 From noreply@sourceforge.net Wed Dec 5 19:39:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 11:39:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-489472 ] pprint produces unreadable dict output Message-ID: Bugs item #489472, was opened at 2001-12-05 10:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489472&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Jürgen A. Erhard (jae) >Assigned to: Barry Warsaw (bwarsaw) Summary: pprint produces unreadable dict output Initial Comment: Python 2.2b2 (Debian unstable), this minimal code: x={'243.220.21': 'cache1.nottingham.ac.uk', '186.164.253': 'bw1-164pub253.bluewin.ch'} import pprint print pprint.pformat(x) Output: {'186.164.253': 'bw1-164pub253.bluewin.ch', : '243.220.21''cache1.nottingham.ac.uk'} Removing the first number off *both* keys ("243." and "186.") and everything's fine. python 2.1.1 also fine. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-05 11:39 Message: Logged In: YES user_id=12800 This is a duplicate of bug #482003 which I fixed post-2.2b2 (see pprint.py 1.19). Grabbing assignment, and closing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-05 11:23 Message: Logged In: YES user_id=6380 I can't reproduce this on my Linux system with 2.2b+. Assigning to Fred for further investigation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489472&group_id=5470 From noreply@sourceforge.net Wed Dec 5 19:56:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 11:56:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-489513 ] asyncore docs: no loop(), funny structur Message-ID: Bugs item #489513, was opened at 2001-12-05 11:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489513&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: asyncore docs: no loop(), funny structur Initial Comment: asyncore.loop is not documented. Here's a cut at it: \begin{funcdesc}{loop}{\optional{timeout=30.0\optional{, use_poll=0\optional{, map=None}}}} Enter a polling loop that only terminates after all open channels have been closed. All arguments are optional. The \var{timeout} argument sets the timeout parameter for the appropriate \func{select} or \func{poll} call. The \var{use_poll} parameter, if true, indicates that \func{poll} should be used in preference to \func{select}. The \data{map} parameter is a dictionary that gives a list of channels to watch. As channels are closed they are deleted from their map. \end{funcdec} Also, I noticed that the structure of the doc is a bit odd. There are several methoddesc blocks in the documentation after the close of the classdesc block for the dispatcher class. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489513&group_id=5470 From noreply@sourceforge.net Wed Dec 5 19:57:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 11:57:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-489514 ] asyncore docs: no loop(), funny structur Message-ID: Bugs item #489514, was opened at 2001-12-05 11:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489514&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: asyncore docs: no loop(), funny structur Initial Comment: asyncore.loop is not documented. Here's a cut at it: \begin{funcdesc}{loop}{\optional{timeout=30.0\optional{, use_poll=0\optional{, map=None}}}} Enter a polling loop that only terminates after all open channels have been closed. All arguments are optional. The \var{timeout} argument sets the timeout parameter for the appropriate \func{select} or \func{poll} call. The \var{use_poll} parameter, if true, indicates that \func{poll} should be used in preference to \func{select}. The \data{map} parameter is a dictionary that gives a list of channels to watch. As channels are closed they are deleted from their map. \end{funcdec} Also, I noticed that the structure of the doc is a bit odd. There are several methoddesc blocks in the documentation after the close of the classdesc block for the dispatcher class. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489514&group_id=5470 From noreply@sourceforge.net Wed Dec 5 19:59:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 11:59:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-489514 ] asyncore docs: no loop(), funny structur Message-ID: Bugs item #489514, was opened at 2001-12-05 11:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489514&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: asyncore docs: no loop(), funny structur Initial Comment: asyncore.loop is not documented. Here's a cut at it: \begin{funcdesc}{loop}{\optional{timeout=30.0\optional{, use_poll=0\optional{, map=None}}}} Enter a polling loop that only terminates after all open channels have been closed. All arguments are optional. The \var{timeout} argument sets the timeout parameter for the appropriate \func{select} or \func{poll} call. The \var{use_poll} parameter, if true, indicates that \func{poll} should be used in preference to \func{select}. The \data{map} parameter is a dictionary that gives a list of channels to watch. As channels are closed they are deleted from their map. \end{funcdec} Also, I noticed that the structure of the doc is a bit odd. There are several methoddesc blocks in the documentation after the close of the classdesc block for the dispatcher class. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2001-12-05 11:59 Message: Logged In: YES user_id=44345 Sorry - duplicate... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489514&group_id=5470 From noreply@sourceforge.net Wed Dec 5 21:38:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 13:38:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-489513 ] asyncore docs: no loop(), funny structur Message-ID: Bugs item #489513, was opened at 2001-12-05 11:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489513&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: asyncore docs: no loop(), funny structur Initial Comment: asyncore.loop is not documented. Here's a cut at it: \begin{funcdesc}{loop}{\optional{timeout=30.0\optional{, use_poll=0\optional{, map=None}}}} Enter a polling loop that only terminates after all open channels have been closed. All arguments are optional. The \var{timeout} argument sets the timeout parameter for the appropriate \func{select} or \func{poll} call. The \var{use_poll} parameter, if true, indicates that \func{poll} should be used in preference to \func{select}. The \data{map} parameter is a dictionary that gives a list of channels to watch. As channels are closed they are deleted from their map. \end{funcdec} Also, I noticed that the structure of the doc is a bit odd. There are several methoddesc blocks in the documentation after the close of the classdesc block for the dispatcher class. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 13:38 Message: Logged In: YES user_id=3066 Added loop() description in Doc/lib/libasyncore.tex revision 1.10; thanks! There's nothing strange about the non-nesting of the method descriptions; all method descriptions in the library reference are written that way. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489513&group_id=5470 From noreply@sourceforge.net Wed Dec 5 21:45:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 13:45:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-484967 ] bad links at Ref Guide Message-ID: Bugs item #484967, was opened at 2001-11-23 11:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=484967&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: bad links at Ref Guide Initial Comment: There are broken links and bad formed urls at a couple of html files in the Ref manual. On file: Doc/ref/atom-literals.html node20.html#tok-stringliteral node23.html#tok-longinteger On file: Doc/ref/integers.html <> Are the same problems as the #217195 bug report? ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 13:45 Message: Logged In: YES user_id=3066 These are definately different from bug #217195. ;-( ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2001-11-23 11:47 Message: Logged In: YES user_id=112690 "nobody/anonymous" was me: Hernan Foffani. :-) and the errors are in python 2.2b2 docs (windows distrib) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=484967&group_id=5470 From noreply@sourceforge.net Wed Dec 5 22:08:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 14:08:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-489581 ] __slots__ leak!!! Message-ID: Bugs item #489581, was opened at 2001-12-05 14:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489581&group_id=5470 Category: None Group: Python 2.2 Status: Open Resolution: None Priority: 8 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: __slots__ leak!!! Initial Comment: Amazing. Instance variables created by __slots__ are never DECREFed when the instance goes away. Example: class C(object): __slots__ = ['a'] while 1: C().a = {} This leaks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489581&group_id=5470 From noreply@sourceforge.net Wed Dec 5 22:12:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 14:12:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-485133 ] memory leak in test_parser Message-ID: Bugs item #485133, was opened at 2001-11-24 10:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485133&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: memory leak in test_parser Initial Comment: parsermodule.c leaks in recursive calls to build_node_children(). see attached file for info ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 14:12 Message: Logged In: YES user_id=3066 Fix memory leak in the parser module: There were two leaks in parser_tuple2st() and a failure to propogate an error in build_node_children() (masking yet another leak, of course!). I confirmed the bug & fix using Insure++; I don't have Purify. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-03 18:24 Message: Logged In: YES user_id=6380 Fred owns this code. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:06 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485133&group_id=5470 From noreply@sourceforge.net Wed Dec 5 22:22:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 14:22:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-485142 ] memory leak in test_binop Message-ID: Bugs item #485142, was opened at 2001-11-24 10:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485142&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Tim Peters (tim_one) Summary: memory leak in test_binop Initial Comment: test_binop leaks memory in longobjects see attached file for detailed info ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-05 14:22 Message: Logged In: YES user_id=31435 Reassigned to me because I started on it, and boosted priority. Turns out that when an object of a new-style class with __slots__ goes away, the slot vars don't get decref'ed (like the Rat class in test_binop). This is a serious bug and Guido is opening a separate report on it. I'll come back to this bug after it's fixed (it may well be the only problem in test_binop). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:05 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485142&group_id=5470 From noreply@sourceforge.net Wed Dec 5 22:46:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 14:46:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-489581 ] __slots__ leak!!! Message-ID: Bugs item #489581, was opened at 2001-12-05 14:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489581&group_id=5470 Category: None Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: __slots__ leak!!! Initial Comment: Amazing. Instance variables created by __slots__ are never DECREFed when the instance goes away. Example: class C(object): __slots__ = ['a'] while 1: C().a = {} This leaks! ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-05 14:46 Message: Logged In: YES user_id=6380 Fixed in typeobject.c rev. 2.123. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489581&group_id=5470 From noreply@sourceforge.net Wed Dec 5 23:02:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 15:02:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-489052 ] define NDEBUG for release builds Message-ID: Bugs item #489052, was opened at 2001-12-04 12:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489052&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Tim Peters (tim_one) >Assigned to: Tim Peters (tim_one) Summary: define NDEBUG for release builds Initial Comment: NDEBUG should be defined on the command line during release builds of Python, so that assert() statements go away. We tried defining it in Python.h, but that interferes with extensions linking Python.h (and created real problems for Robin Dunn). The Windows build already does this. The Linux build needs it, and assigned to Fred for that part. Fred, please assign to jackjansen when you're done, so he can consider the Mac build. Any other build need special treatment? ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-05 15:02 Message: Logged In: YES user_id=45365 Fixed for MacPython. Assigning it back to Tim, I don't know whether the other maintainers (like for BeOS or OS2) need to be informed of this too. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-04 12:56 Message: Logged In: YES user_id=3066 The Unix portion of this is fixed in configure.in revision 1.284. Passing to Jack for Mac OS magic. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489052&group_id=5470 From noreply@sourceforge.net Wed Dec 5 23:08:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 15:08:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-476858 ] Assignment to () should be legal Message-ID: Bugs item #476858, was opened at 2001-10-31 10:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476858&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Assignment to () should be legal Initial Comment: >From c.l.py: Currently, () = x gives a compile-time error. This should really be allowed (and require that x is an empty sequence, of course) as an end case of (a,b,c) = x # x must be a 3-sequence (a,b) = x # x must be a 2-sequence (a,) = x # x must be a 1-sequence () = x # why can't x be z 0-sequence? ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 15:08 Message: Logged In: YES user_id=3066 Ugh. Sounds terrible, tastes like soap. Let's not allow this. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-10-31 12:39 Message: Logged In: YES user_id=44345 I won't try and counter Tim's vote (besides, he's already got Guido's 51% vote to contend with), but just provide an example used in c.l.py. You might have a function that can return a possibly-empty tuple as part of a larger sequence, e.g.: def contrived(a, *args): return (len(args), args*a) (foo, (bar,)) = contrived(1,2,3) (foo, ()) = contrived(0,1,2) Some folks view this as useful. I reserve judgement on that. ;-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-31 10:37 Message: Logged In: YES user_id=31435 -1. "Assignment statements are used to (re)bind names to values and to modify attributes or items of mutable objects" (from the Ref Man). Since the degenerate cases (don't forget "[] = x" too) don't do that, they're not "assignment statements" in a meanignful sense; they would just be a surprising way to spell if tuple(x): raise ValueError That isn't a frequent enough need to deserve special syntax. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476858&group_id=5470 From noreply@sourceforge.net Wed Dec 5 23:10:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 15:10:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-487310 ] smtplib mishandles SMTP disconnects Message-ID: Bugs item #487310, was opened at 2001-11-29 16:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487310&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Fazal Majid (majid) >Assigned to: Barry Warsaw (bwarsaw) Summary: smtplib mishandles SMTP disconnects Initial Comment: smtplib handles SMTP disconnects (e.g. timeouts) inconsistently. The smtplib.SMTP.send() method does not reset self.file on a socket error, unlike getreply(), and thus a close() is necessary for in one case but not in the other. Recommendation: have smtplib.SMTP.send() call close() on socket.error just as smtplib.SMTP.getreply() does on EOF on self.file. In the following test case, I have set the SMTP timeout on my local machine to 10 seconds: Python 2.1.1 (#1, Nov 7 2001, 16:18:10) [GCC 2.95.3 20010315 (release)] on sunos5 Type "copyright", "credits" or "license" for more information. >>> import smtplib >>> s = smtplib.SMTP('localhost', 25) >>> import time >>> time.sleep(10) >>> s.sendmail('fmajid@kefta.com', 'fmajid@kefta.com', '...') Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.1/smtplib.py", line 469, in sendmail (code,resp) = self.helo() File "/usr/local/lib/python2.1/smtplib.py", line 305, in helo self.putcmd("helo", socket.getfqdn()) File "/usr/local/lib/python2.1/smtplib.py", line 249, in putcmd self.send(str) File "/usr/local/lib/python2.1/smtplib.py", line 239, in send raise SMTPServerDisconnected('Server not connected') smtplib.SMTPServerDisconnected: Server not connected >>> s.connect('localhost', 25) Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.1/smtplib.py", line 226, in connect (code,msg)=self.getreply() File "/usr/local/lib/python2.1/smtplib.py", line 271, in getreply raise SMTPServerDisconnected("Connection unexpectedly closed") smtplib.SMTPServerDisconnected: Connection unexpectedly closed >>> s.connect('localhost', 25) (220, 'bayazid.kefta.com ESMTP Postfix') ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 08:45 Message: Logged In: YES user_id=6380 Can you please supply a patch? Upload a context diff, don't forget to check the file upload checkbox. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2001-11-30 07:04 Message: Logged In: YES user_id=110477 I forgot to mention a workaround: if you catch SMTPServerDisconnected, call self.close(). The operation is idempotent so it isn't a problem if you do it twice, for instance if the exception occurs in getreply(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487310&group_id=5470 From noreply@sourceforge.net Wed Dec 5 23:15:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 15:15:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-478428 ] dbm build fails Message-ID: Bugs item #478428, was opened at 2001-11-05 12:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478428&group_id=5470 Category: Macintosh Group: Python 2.2 Status: Closed Resolution: None Priority: 5 Submitted By: John Buell (dadaist) Assigned to: Jack Jansen (jackjansen) Summary: dbm build fails Initial Comment: Trying a build with cvs source downloaded this morning. I've been sure to do the configure --with-suffix=_ on case-insensitive Mac OS X (10.1), but I'm having some problem with the 'dbm' module. Here's a copy of the messages: building 'dbm' extension /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c: In function `dbm_subscript': /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c:104: warning: implicit declaration of function `dbm_error' /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c:105: warning: implicit declaration of function `dbm_clearerr' cc -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -I. -I/Users/jbuell/Documents/Python/python/dist/src/./Include -I/Users/jbuell/Documents/Python/python/dist/src/./Mac/Include -I/usr/local/include -IInclude/ -c /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c -o build/temp.darwin-1.4-Power Macintosh-2.2/dbmmodule.o cc -bundle -flat_namespace -undefined suppress build/temp.darwin-1.4-Power Macintosh-2.2/dbmmodule.o -L/usr/local/lib -o build/lib.darwin-1.4-Power Macintosh-2.2/dbm.so building 'gdbm' extension dyld: ./python_ Undefined symbols: __ashldi3 make: *** [sharedmods] Error 67 Any suggestions? Anything I can change in my settings to get past this? -John ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-05 15:15 Message: Logged In: YES user_id=45365 John, not so on my iBook (10.1.1, devtools installed), so I'm 99% sure that the gdbm.h you have in /usr/include is also the result of something you installed.... ---------------------------------------------------------------------- Comment By: John Buell (dadaist) Date: 2001-12-05 08:13 Message: Logged In: YES user_id=368337 Okay, further checking shows that the beige G3 does NOT have a gdbm.h ANYWHERE, while the iBook does. No wonder it succeeds on the one and not on the other. [localhost:/Users/jbuell] root# ls -l `find / -name gdbm.h -print` -rw-r--r-- 1 root admin 4744 Oct 1 02:54 /sw/include/gdbm.h -rw-r--r-- 1 root wheel 4744 Feb 27 2001 /usr/local/include/gdbm.h I can include a copy of this gdbm.h if necessary. I'm wondering if it's from an older version that is breaking the python 2.2 build? Where in the build/make trees could I go to comment this out? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-04 03:21 Message: Logged In: YES user_id=45365 The problem isn't with /sw, it's with the gdbm.h that is installed in /usr/local/include. This is what triggers setup.py to try and build gdbm. The other questrion is of course why it doesn't work: if you have gdbm.h and libgdbm there's really no reason why it shouldn't build. ---------------------------------------------------------------------- Comment By: John Buell (dadaist) Date: 2001-12-03 09:29 Message: Logged In: YES user_id=368337 Sorry, I've been busy. I've narrowed it down to being a fink-related problem. My beige G3 without fink can build and install python 2.2 just fine. The iBook WITH fink is what doesn't like the gdbm thing. The odd part is that the fink directories (/sw/*) are NOT part of my path while I'm doing builds, but gdbm seems to be finding the extra files anyway. bash-2.05$ echo $PATH ~/bin/powerpc-apple-darwin:/Users/jbuell/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/X11R6/bin [localhost:/Users/jbuell] root# find / -name libgdbm.a -print /sw/lib/libgdbm.a /usr/local/lib/libgdbm.a [localhost:/Users/jbuell] root# find / -name gdbm.h -print /sw/include/gdbm.h /usr/local/include/gdbm.h Other than uninstalling fink, is there a way to get python's build mechanism to completely ignore /sw and its subdirectories? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-02 14:15 Message: Logged In: YES user_id=45365 As the originator didn't follow up on my previous remark and everything works fine for me I'm closing this bug. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-06 12:45 Message: Logged In: YES user_id=45365 Note that the problem is with gdbm, not with dbm. Dbm seems to build fine (with a warning). I've heard a report of this before. Needless to say, for me there is no problem whatsoever:-) I think that the problem is that setup.py detects files that indicate to it that dbm is available while in fact it is not. Could you check whether you have a libgdbm.a and/or a gdbm.h on your system somewhere? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478428&group_id=5470 From noreply@sourceforge.net Wed Dec 5 23:26:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 15:26:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-487929 ] minidom.appendChild buggy Message-ID: Bugs item #487929, was opened at 2001-12-01 14:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487929&group_id=5470 >Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Dieter Maurer (dmaurer) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: minidom.appendChild buggy Initial Comment: minidom.appendChild looses children when it appends a DocumentFragment with more than one childnode ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 15:26 Message: Logged In: YES user_id=3066 insertBefore() has the same bug. I'll checkin the fix as soon as I've added a test that exercises this; probably tomorrow morning. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487929&group_id=5470 From noreply@sourceforge.net Wed Dec 5 23:28:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 15:28:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-486530 ] replace sprintf with PyOS_snprintf Message-ID: Bugs item #486530, was opened at 2001-11-28 09:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486530&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) >Assigned to: Guido van Rossum (gvanrossum) Summary: replace sprintf with PyOS_snprintf Initial Comment: Some or all of the sprintf calls we make are vulnerable to buffer overflows. A few of these calls use stack-allocated buffers, which are real security problems. MAL has fixed three of them, but if we're going to fix any we need to fix them all. We'll try to finish this task as soon as possible. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-05 15:28 Message: Logged In: YES user_id=45365 The Mac files are either fixed or confirmed harmless, with one exception, Compat/getcwd.c. But this one is not really part of Python, so using PyOS_snprintf might not be a good idea, and in Python's use cases it seems harmless. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-03 13:24 Message: Logged In: YES user_id=31435 Reassigned this to Jack. The list Guido gave was derived from a list I gave him, and it didn't include any files under the Mac directory: C:\Code\python\Mac>findstr /m /s sprintf *.c compat\getwd.c modules\calldll.c modules\macfsmodule.c modules\cf\_cfmodule.c modules\ctl\_ctlmodule.c modules\win\_winmodule.c modules\hfsplusmodule.c python\macimport.c ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-03 13:10 Message: Logged In: YES user_id=6380 Most of this is done. There are a few cases left, some intentionally (and carefully analyzed). I won't close it yet, but I see no need for the high priority now. sprintf is still used in: drawfmodule.c (RISCOS\Modules) -- unsafe, only affects one platform getbuildinfo.c (Modules) -- safe getnameinfo.c (Modules) -- safe grammar1.c (Parser) -- safe mactoolboxglue.c (Python) -- safe stringobject.c (Objects) -- safe strtod.c (Python) -- probably safe; AFAICT this file is unused (?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486530&group_id=5470 From noreply@sourceforge.net Wed Dec 5 23:28:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 15:28:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-485557 ] MacPython doesnt run on 8.1 Message-ID: Bugs item #485557, was opened at 2001-11-26 02:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485557&group_id=5470 Category: Macintosh Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: MacPython doesnt run on 8.1 Initial Comment: MacPython no longer runs on MacOS 8.1. The problem seems to be hard-linking against DialogsLib. Check whether there is an easy way to weak-link against it (the routines in DialogsLib are of minor importance only, and not used by IDE or any other part of the distribution), otherwise 8.1 support will have to be dropped. Adapt the readme and installer minimal system version settings. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-05 15:28 Message: Logged In: YES user_id=45365 Fixed in current CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485557&group_id=5470 From noreply@sourceforge.net Wed Dec 5 23:31:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 15:31:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-485142 ] memory leak in test_binop Message-ID: Bugs item #485142, was opened at 2001-11-24 10:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485142&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Tim Peters (tim_one) Summary: memory leak in test_binop Initial Comment: test_binop leaks memory in longobjects see attached file for detailed info ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-05 15:31 Message: Logged In: YES user_id=31435 Thank you for finding this, Neal! test_binop in an infinite loop no longer grows, after Guido fixed the __slots__ leak, so closing this one (it grew megabytes per second before that fix). The connection to longs is simply that the Rat class stores some long objects in its __slots__; if it had stored floats instead, this would have looked leak a float leak; etc. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-05 14:22 Message: Logged In: YES user_id=31435 Reassigned to me because I started on it, and boosted priority. Turns out that when an object of a new-style class with __slots__ goes away, the slot vars don't get decref'ed (like the Rat class in test_binop). This is a serious bug and Guido is opening a separate report on it. I'll come back to this bug after it's fixed (it may well be the only problem in test_binop). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:05 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485142&group_id=5470 From noreply@sourceforge.net Wed Dec 5 23:42:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 15:42:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-487310 ] smtplib mishandles SMTP disconnects Message-ID: Bugs item #487310, was opened at 2001-11-29 16:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487310&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Fazal Majid (majid) Assigned to: Barry Warsaw (bwarsaw) Summary: smtplib mishandles SMTP disconnects Initial Comment: smtplib handles SMTP disconnects (e.g. timeouts) inconsistently. The smtplib.SMTP.send() method does not reset self.file on a socket error, unlike getreply(), and thus a close() is necessary for in one case but not in the other. Recommendation: have smtplib.SMTP.send() call close() on socket.error just as smtplib.SMTP.getreply() does on EOF on self.file. In the following test case, I have set the SMTP timeout on my local machine to 10 seconds: Python 2.1.1 (#1, Nov 7 2001, 16:18:10) [GCC 2.95.3 20010315 (release)] on sunos5 Type "copyright", "credits" or "license" for more information. >>> import smtplib >>> s = smtplib.SMTP('localhost', 25) >>> import time >>> time.sleep(10) >>> s.sendmail('fmajid@kefta.com', 'fmajid@kefta.com', '...') Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.1/smtplib.py", line 469, in sendmail (code,resp) = self.helo() File "/usr/local/lib/python2.1/smtplib.py", line 305, in helo self.putcmd("helo", socket.getfqdn()) File "/usr/local/lib/python2.1/smtplib.py", line 249, in putcmd self.send(str) File "/usr/local/lib/python2.1/smtplib.py", line 239, in send raise SMTPServerDisconnected('Server not connected') smtplib.SMTPServerDisconnected: Server not connected >>> s.connect('localhost', 25) Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.1/smtplib.py", line 226, in connect (code,msg)=self.getreply() File "/usr/local/lib/python2.1/smtplib.py", line 271, in getreply raise SMTPServerDisconnected("Connection unexpectedly closed") smtplib.SMTPServerDisconnected: Connection unexpectedly closed >>> s.connect('localhost', 25) (220, 'bayazid.kefta.com ESMTP Postfix') ---------------------------------------------------------------------- >Comment By: Fazal Majid (majid) Date: 2001-12-05 15:42 Message: Logged In: YES user_id=110477 I am attaching a patch that calls self.close() before raising the SMTPServerDisconnected exception. There does not seem to be a standard unit test for smtplib. I have run this patch through a unit test of my own that exercises smtplib. I don't have a way to test a broken MTA that disconnects on EHLO, however. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 08:45 Message: Logged In: YES user_id=6380 Can you please supply a patch? Upload a context diff, don't forget to check the file upload checkbox. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2001-11-30 07:04 Message: Logged In: YES user_id=110477 I forgot to mention a workaround: if you catch SMTPServerDisconnected, call self.close(). The operation is idempotent so it isn't a problem if you do it twice, for instance if the exception occurs in getreply(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487310&group_id=5470 From noreply@sourceforge.net Wed Dec 5 23:44:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 15:44:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-487310 ] smtplib mishandles SMTP disconnects Message-ID: Bugs item #487310, was opened at 2001-11-29 16:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487310&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Fazal Majid (majid) Assigned to: Barry Warsaw (bwarsaw) Summary: smtplib mishandles SMTP disconnects Initial Comment: smtplib handles SMTP disconnects (e.g. timeouts) inconsistently. The smtplib.SMTP.send() method does not reset self.file on a socket error, unlike getreply(), and thus a close() is necessary for in one case but not in the other. Recommendation: have smtplib.SMTP.send() call close() on socket.error just as smtplib.SMTP.getreply() does on EOF on self.file. In the following test case, I have set the SMTP timeout on my local machine to 10 seconds: Python 2.1.1 (#1, Nov 7 2001, 16:18:10) [GCC 2.95.3 20010315 (release)] on sunos5 Type "copyright", "credits" or "license" for more information. >>> import smtplib >>> s = smtplib.SMTP('localhost', 25) >>> import time >>> time.sleep(10) >>> s.sendmail('fmajid@kefta.com', 'fmajid@kefta.com', '...') Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.1/smtplib.py", line 469, in sendmail (code,resp) = self.helo() File "/usr/local/lib/python2.1/smtplib.py", line 305, in helo self.putcmd("helo", socket.getfqdn()) File "/usr/local/lib/python2.1/smtplib.py", line 249, in putcmd self.send(str) File "/usr/local/lib/python2.1/smtplib.py", line 239, in send raise SMTPServerDisconnected('Server not connected') smtplib.SMTPServerDisconnected: Server not connected >>> s.connect('localhost', 25) Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.1/smtplib.py", line 226, in connect (code,msg)=self.getreply() File "/usr/local/lib/python2.1/smtplib.py", line 271, in getreply raise SMTPServerDisconnected("Connection unexpectedly closed") smtplib.SMTPServerDisconnected: Connection unexpectedly closed >>> s.connect('localhost', 25) (220, 'bayazid.kefta.com ESMTP Postfix') ---------------------------------------------------------------------- >Comment By: Fazal Majid (majid) Date: 2001-12-05 15:44 Message: Logged In: YES user_id=110477 Oops... forgot to check the checkbox for attachments. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2001-12-05 15:42 Message: Logged In: YES user_id=110477 I am attaching a patch that calls self.close() before raising the SMTPServerDisconnected exception. There does not seem to be a standard unit test for smtplib. I have run this patch through a unit test of my own that exercises smtplib. I don't have a way to test a broken MTA that disconnects on EHLO, however. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 08:45 Message: Logged In: YES user_id=6380 Can you please supply a patch? Upload a context diff, don't forget to check the file upload checkbox. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2001-11-30 07:04 Message: Logged In: YES user_id=110477 I forgot to mention a workaround: if you catch SMTPServerDisconnected, call self.close(). The operation is idempotent so it isn't a problem if you do it twice, for instance if the exception occurs in getreply(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487310&group_id=5470 From noreply@sourceforge.net Wed Dec 5 23:58:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 15:58:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-487331 ] time mod's timezone doesn't honor TZ var Message-ID: Bugs item #487331, was opened at 2001-11-29 18:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487331&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 3 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: M.-A. Lemburg (lemburg) Summary: time mod's timezone doesn't honor TZ var Initial Comment: Python's time module seems to get the timezone name when it's first imported, but it doesn't change it if the TZ environment variable is later set. On the other hand, the time of day DOES change accordingly. Thus, setting TZ after the time module is imported results in a completely broken rfc2822 date - time in the new TZ, but with a bogus UTC offset and timezone (neither the old nor new). Here is the problem illustrated. You will see that after setting TZ, altzone, timezone, and tzname don't change, while asctime does. $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import time,os >>> print time.asctime() Thu Nov 29 18:47:39 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print time.asctime() Fri Nov 30 14:47:52 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') Here is an example of why this is a problem in practice. One of my applications sets the TZ environment variable based on a "TIMEZONE" setting in the user's configuration file. It later uses the `email' module to create a "Date:" header for outgoing mail messages. Because of this bug, the resulting "Date:" is bogus. e.g, $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import email,os >>> print email.Utils.formatdate(localtime=1) Thu, 29 Nov 2001 18:52:34 -0700 >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print email.Utils.formatdate(localtime=1) Fri, 30 Nov 2001 14:52:41 -0600 The `-0600' should be `+1300', and `-0600' isn't correct even for the original timezone! You might say: "Work around this by setting TZ before the time module is first imported." -- No, that is too fragile, and too difficult to do with complex applications. Many other modules in turn import time, etc. I suggest instead that the TZ environment variable be consulted each time the timezone is accessed. ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-05 15:58 Message: Logged In: YES user_id=85984 Mark, To answer your question from a couple days ago, my exact requirements are: The ability to produce an rfc2822 compliant "Date" string that corresponds to the current value of 'TZ' in the environment. I'm currently using email.Utils.formatdate() to produce the Date, but this breaks as soon as I set 'TZ' within my application. Setting 'TZ' from within Python is necessary. I don't currently know of a way to get around this problem as the breakage is in the lower level time module. Again, mxDateTime is NOT an option. Whether it integrates nicely with Python and runs on many platforms is not relevant. I'm sure both of these facts are true, but I don't want my application to depend on any external packages. This complicates the installation procedure unnecessarily. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-05 01:37 Message: Logged In: YES user_id=38388 Agreed. Let's continue to talk about this after Python 2.2 is out. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 08:11 Message: Logged In: YES user_id=12800 Rightt, all I was thinking about was an object/function to encapsulate the numeric timezone values, daylight, timezone, and altzone, without sucking in all fo the timezone names and abbreviations. As for mxDateTime, yeah putting that into Python would probably mean some compromise on the projmgt side of things. OTOH, it would be damn handy! :) Oh well, plenty of time to think about this for Python 2.3! ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-04 07:48 Message: Logged In: YES user_id=38388 Well, this may sound easy, but once you get into timezones things start to become one big can of worms, e.g. just have a look at how daylight savings time is handled in different countries of the world or how time zone names sometimes map to multiple different zones. OTOH, numeric timezones are easy to handle and all that is needed is some simple code to convert a ticks value plus an offset to a nice ISO string representation an vice-versa. That should be easy to add to the time module... About adding mxDateTime to the core: I suppose it's simply too big. Also, I have a slightly different way of maintaining the mx tools than what is considered the Python way -- I usually happily add new features and modules without much fuzz; wouldn't want to have to write a PEP to enhance my own stuff ;-) As compromise, I could add some ISO date/time parsing and formatting code from mxDateTime to Python 2.3. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 07:04 Message: Logged In: YES user_id=12800 BTW, one way to possibly handle this would be to add something to time module that created a "timezone object", encapsulating daylight, timezone, and altzone for arbitrary timezones. Then date producing code like email.Utils.formatdate() could take optional timezone objects to produce dates relative to the given zone. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 07:03 Message: Logged In: YES user_id=12800 OT, but what about adding mxDateTime to core Python <2.3 wink>? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-04 01:36 Message: Logged In: YES user_id=38388 Jason, as I already mentioned in my other reply, exposing tzset() to Python would cause more trouble than do any good because of the side-effects it has. Rather then provide ways to write buggy code in Python, I suggest to look into solving the problem you seem to have using the available tools, e.g. mxDateTime runs on many different platforms and integrates nicely with Python. If the email package is the only one you need fixed, I suggest to write a small helper or patch which implements the needed modifications for this package. BTW, what are you exact requirements ? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-03 13:56 Message: Logged In: YES user_id=85984 I'm fairly ignorant of the gory details behind the scenes of the time module, but I still contend this is buggy behavior. That is, setting os.environ['TZ'] in the application totally breaks higher level methods such as email.Utils.formatdate(). Barry had a suggestion which Mark doesn't think is a good idea. Mark, are you sure there isn't anything that can be done? If think that if you disregard this issue, it will come back to haunt the Python community. With regards to your suggestion of mxDateTime: I really can't consider this as I don't want to rely on any external modules or packages. One of my application's strengths is that it "just works" out of the box with Python, so it's very easy to install. I'd like to keep it that way unless it's absolutely necessary to do otherwise. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 12:53 Message: Logged In: YES user_id=38388 I don't know whether this is such a good idea -- after all it's fairly easy to manage timezones in the application rather than trying to fiddle the C libs routines into producing the output you intend. Also note that tzset() is *not* thread safe. BTW, Jason, you may want to have a look at mxDateTime -- perhaps it already has what you are looking for. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-11-30 12:11 Message: Logged In: YES user_id=12800 Perhaps we should expose tzset() to Python? We'd also have to reset timezone, altzone, daylight, and tzname in the module after calling tzset(). It's a bit of work, and adds a feature so it can't go into Python 2.2, but if you think this is a viable approach, re-assign this bug to me and I'll deal with it for Python 2.3. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 11:01 Message: Logged In: YES user_id=38388 The time module is a very thin layer on top of the C lib time APIs. There's nothing much Python can do about errors in those APIs, e.g. not recognizing changes to TZ. Also note that the tzset() API which inits the time APIs w/r to the TZ environment variable is only called at time module import time. To expose the dynamic changes you are looking for, it would have to call tzset() prior to all calls to asctime() et al. -- much too time consuming ! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487331&group_id=5470 From noreply@sourceforge.net Thu Dec 6 00:34:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 16:34:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-487331 ] time mod's timezone doesn't honor TZ var Message-ID: Bugs item #487331, was opened at 2001-11-29 18:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487331&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 3 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: M.-A. Lemburg (lemburg) Summary: time mod's timezone doesn't honor TZ var Initial Comment: Python's time module seems to get the timezone name when it's first imported, but it doesn't change it if the TZ environment variable is later set. On the other hand, the time of day DOES change accordingly. Thus, setting TZ after the time module is imported results in a completely broken rfc2822 date - time in the new TZ, but with a bogus UTC offset and timezone (neither the old nor new). Here is the problem illustrated. You will see that after setting TZ, altzone, timezone, and tzname don't change, while asctime does. $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import time,os >>> print time.asctime() Thu Nov 29 18:47:39 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print time.asctime() Fri Nov 30 14:47:52 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') Here is an example of why this is a problem in practice. One of my applications sets the TZ environment variable based on a "TIMEZONE" setting in the user's configuration file. It later uses the `email' module to create a "Date:" header for outgoing mail messages. Because of this bug, the resulting "Date:" is bogus. e.g, $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import email,os >>> print email.Utils.formatdate(localtime=1) Thu, 29 Nov 2001 18:52:34 -0700 >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print email.Utils.formatdate(localtime=1) Fri, 30 Nov 2001 14:52:41 -0600 The `-0600' should be `+1300', and `-0600' isn't correct even for the original timezone! You might say: "Work around this by setting TZ before the time module is first imported." -- No, that is too fragile, and too difficult to do with complex applications. Many other modules in turn import time, etc. I suggest instead that the TZ environment variable be consulted each time the timezone is accessed. ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-05 16:34 Message: Logged In: YES user_id=85984 Marc-André, I apologize for previously misspelling your name a bunch of times. Oops. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-05 15:58 Message: Logged In: YES user_id=85984 Mark, To answer your question from a couple days ago, my exact requirements are: The ability to produce an rfc2822 compliant "Date" string that corresponds to the current value of 'TZ' in the environment. I'm currently using email.Utils.formatdate() to produce the Date, but this breaks as soon as I set 'TZ' within my application. Setting 'TZ' from within Python is necessary. I don't currently know of a way to get around this problem as the breakage is in the lower level time module. Again, mxDateTime is NOT an option. Whether it integrates nicely with Python and runs on many platforms is not relevant. I'm sure both of these facts are true, but I don't want my application to depend on any external packages. This complicates the installation procedure unnecessarily. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-05 01:37 Message: Logged In: YES user_id=38388 Agreed. Let's continue to talk about this after Python 2.2 is out. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 08:11 Message: Logged In: YES user_id=12800 Rightt, all I was thinking about was an object/function to encapsulate the numeric timezone values, daylight, timezone, and altzone, without sucking in all fo the timezone names and abbreviations. As for mxDateTime, yeah putting that into Python would probably mean some compromise on the projmgt side of things. OTOH, it would be damn handy! :) Oh well, plenty of time to think about this for Python 2.3! ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-04 07:48 Message: Logged In: YES user_id=38388 Well, this may sound easy, but once you get into timezones things start to become one big can of worms, e.g. just have a look at how daylight savings time is handled in different countries of the world or how time zone names sometimes map to multiple different zones. OTOH, numeric timezones are easy to handle and all that is needed is some simple code to convert a ticks value plus an offset to a nice ISO string representation an vice-versa. That should be easy to add to the time module... About adding mxDateTime to the core: I suppose it's simply too big. Also, I have a slightly different way of maintaining the mx tools than what is considered the Python way -- I usually happily add new features and modules without much fuzz; wouldn't want to have to write a PEP to enhance my own stuff ;-) As compromise, I could add some ISO date/time parsing and formatting code from mxDateTime to Python 2.3. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 07:04 Message: Logged In: YES user_id=12800 BTW, one way to possibly handle this would be to add something to time module that created a "timezone object", encapsulating daylight, timezone, and altzone for arbitrary timezones. Then date producing code like email.Utils.formatdate() could take optional timezone objects to produce dates relative to the given zone. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 07:03 Message: Logged In: YES user_id=12800 OT, but what about adding mxDateTime to core Python <2.3 wink>? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-04 01:36 Message: Logged In: YES user_id=38388 Jason, as I already mentioned in my other reply, exposing tzset() to Python would cause more trouble than do any good because of the side-effects it has. Rather then provide ways to write buggy code in Python, I suggest to look into solving the problem you seem to have using the available tools, e.g. mxDateTime runs on many different platforms and integrates nicely with Python. If the email package is the only one you need fixed, I suggest to write a small helper or patch which implements the needed modifications for this package. BTW, what are you exact requirements ? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-03 13:56 Message: Logged In: YES user_id=85984 I'm fairly ignorant of the gory details behind the scenes of the time module, but I still contend this is buggy behavior. That is, setting os.environ['TZ'] in the application totally breaks higher level methods such as email.Utils.formatdate(). Barry had a suggestion which Mark doesn't think is a good idea. Mark, are you sure there isn't anything that can be done? If think that if you disregard this issue, it will come back to haunt the Python community. With regards to your suggestion of mxDateTime: I really can't consider this as I don't want to rely on any external modules or packages. One of my application's strengths is that it "just works" out of the box with Python, so it's very easy to install. I'd like to keep it that way unless it's absolutely necessary to do otherwise. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 12:53 Message: Logged In: YES user_id=38388 I don't know whether this is such a good idea -- after all it's fairly easy to manage timezones in the application rather than trying to fiddle the C libs routines into producing the output you intend. Also note that tzset() is *not* thread safe. BTW, Jason, you may want to have a look at mxDateTime -- perhaps it already has what you are looking for. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-11-30 12:11 Message: Logged In: YES user_id=12800 Perhaps we should expose tzset() to Python? We'd also have to reset timezone, altzone, daylight, and tzname in the module after calling tzset(). It's a bit of work, and adds a feature so it can't go into Python 2.2, but if you think this is a viable approach, re-assign this bug to me and I'll deal with it for Python 2.3. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 11:01 Message: Logged In: YES user_id=38388 The time module is a very thin layer on top of the C lib time APIs. There's nothing much Python can do about errors in those APIs, e.g. not recognizing changes to TZ. Also note that the tzset() API which inits the time APIs w/r to the TZ environment variable is only called at time module import time. To expose the dynamic changes you are looking for, it would have to call tzset() prior to all calls to asctime() et al. -- much too time consuming ! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487331&group_id=5470 From noreply@sourceforge.net Thu Dec 6 02:40:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 18:40:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-489669 ] memory leak in test_descr (unicode) Message-ID: Bugs item #489669, was opened at 2001-12-05 18:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489669&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak in test_descr (unicode) Initial Comment: leak from unicode object when running test_descr may be related to bug "memory leak in test_unicode" see attached file for details ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489669&group_id=5470 From noreply@sourceforge.net Thu Dec 6 02:42:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 18:42:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-489670 ] memory leak in test_re Message-ID: Bugs item #489670, was opened at 2001-12-05 18:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489670&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak in test_re Initial Comment: leak when running test_descr may be related to bug #485152 "memory leak from marshal.c (test_email)" see attached file for details ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489670&group_id=5470 From noreply@sourceforge.net Thu Dec 6 02:44:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 18:44:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-489671 ] memory leak in test_richcmp Message-ID: Bugs item #489671, was opened at 2001-12-05 18:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489671&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak in test_richcmp Initial Comment: leak when running test_richcmp see attached file for details ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489671&group_id=5470 From noreply@sourceforge.net Thu Dec 6 02:45:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 18:45:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-489672 ] memory leak in test_sre Message-ID: Bugs item #489672, was opened at 2001-12-05 18:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak in test_sre Initial Comment: leak when running test_sre see attached file for details ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 From noreply@sourceforge.net Thu Dec 6 02:47:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 18:47:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-489673 ] memory leak in test_symtable Message-ID: Bugs item #489673, was opened at 2001-12-05 18:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489673&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak in test_symtable Initial Comment: leak when running test_symtable see attached file for details ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489673&group_id=5470 From noreply@sourceforge.net Thu Dec 6 04:27:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 20:27:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-489709 ] Building Fails under Cygwin Message-ID: Bugs item #489709, was opened at 2001-12-05 20:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489709&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: Building Fails under Cygwin Initial Comment: Even after applying the h2py patch, building under Cygwin ends with the following error: building 'gdbm' extension gcc -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT - I. -I/cygdrive/e/Python-2.2b2/./Include - I/usr/local/include -IInclude/ -c /cygdrive/e/Python- 2.2b2/Modules/gdbmmodule.c -o build/temp.cygwin-1.3. 5-i686-2.2/gdbmmodule.o e:\buildpy\python.exe: *** unable to remap C:\cygnus\bin\cygssl.dll to same address as parent -- 0x1A7C0000 0 [main] python 1292 sync_with_child: child 1108 (0xF0) died before initialization with status code 0x1 25901 [main] python 1292 sync_with_child: *** child state child loading dlls error: Resource temporarily unavailable make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489709&group_id=5470 From noreply@sourceforge.net Thu Dec 6 04:32:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 20:32:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-487929 ] minidom.appendChild buggy Message-ID: Bugs item #487929, was opened at 2001-12-01 14:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487929&group_id=5470 Category: Python Library Group: Python 2.1.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: minidom.appendChild buggy Initial Comment: minidom.appendChild looses children when it appends a DocumentFragment with more than one childnode ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 20:32 Message: Logged In: YES user_id=3066 Fixed in Lib/xml/dom/minidom.py revision 1.42. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 15:26 Message: Logged In: YES user_id=3066 insertBefore() has the same bug. I'll checkin the fix as soon as I've added a test that exercises this; probably tomorrow morning. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487929&group_id=5470 From noreply@sourceforge.net Thu Dec 6 06:24:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 05 Dec 2001 22:24:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-488514 ] -Qnew needs work Message-ID: Bugs item #488514, was opened at 2001-12-03 11:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488514&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Tim Peters (tim_one) Summary: -Qnew needs work Initial Comment: -Qnew works as described in the NEWS file, but not as described in the PEP (238). It would be good if the PEP behavior were implemented for 2.2, i.e. that -Qnew have global effect rather than merely affecting __main__. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-05 22:24 Message: Logged In: YES user_id=31435 This is done now, except that three standard tests fail under -Qnew; it's not clear that they can't fail, though (they're more-than-less testing classic division), so closing this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488514&group_id=5470 From noreply@sourceforge.net Thu Dec 6 09:02:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 01:02:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-485145 ] memory leak in test_unicode Message-ID: Bugs item #485145, was opened at 2001-11-24 10:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485145&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Barry Warsaw (bwarsaw) Summary: memory leak in test_unicode Initial Comment: test_unicode leaks memory see attached file for details ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-06 01:02 Message: Logged In: YES user_id=38388 Note that the "leak" could be caused the fact that Unicode shares length 1 Unicode strings in the Latin-1 range. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:05 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485145&group_id=5470 From noreply@sourceforge.net Thu Dec 6 11:39:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 03:39:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-485145 ] memory leak in test_unicode Message-ID: Bugs item #485145, was opened at 2001-11-24 10:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485145&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Barry Warsaw (bwarsaw) Summary: memory leak in test_unicode Initial Comment: test_unicode leaks memory see attached file for details ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-06 03:39 Message: Logged In: YES user_id=38388 I've done some tests and found that the leaks have to be somewhere in test_unicode.py below the line "Testing builtin unicode()...". Since the code immediately below that line uses type subclassing I guess that the new type system could have something to do with the leakage. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-06 01:02 Message: Logged In: YES user_id=38388 Note that the "leak" could be caused the fact that Unicode shares length 1 Unicode strings in the Latin-1 range. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:05 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485145&group_id=5470 From noreply@sourceforge.net Thu Dec 6 12:03:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 04:03:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-485145 ] memory leak in test_unicode Message-ID: Bugs item #485145, was opened at 2001-11-24 10:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485145&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Barry Warsaw (bwarsaw) Summary: memory leak in test_unicode Initial Comment: test_unicode leaks memory see attached file for details ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-06 04:03 Message: Logged In: YES user_id=38388 Indeed, if I comment out the section "Testing builtin unicode()..." the leak goes away. Barry, that's where you should start looking ! ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-06 03:39 Message: Logged In: YES user_id=38388 I've done some tests and found that the leaks have to be somewhere in test_unicode.py below the line "Testing builtin unicode()...". Since the code immediately below that line uses type subclassing I guess that the new type system could have something to do with the leakage. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-06 01:02 Message: Logged In: YES user_id=38388 Note that the "leak" could be caused the fact that Unicode shares length 1 Unicode strings in the Latin-1 range. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:05 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485145&group_id=5470 From noreply@sourceforge.net Thu Dec 6 13:53:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 05:53:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-489709 ] Building Fails under Cygwin Message-ID: Bugs item #489709, was opened at 2001-12-05 20:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489709&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) >Assigned to: Michael Hudson (mwh) Summary: Building Fails under Cygwin Initial Comment: Even after applying the h2py patch, building under Cygwin ends with the following error: building 'gdbm' extension gcc -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT - I. -I/cygdrive/e/Python-2.2b2/./Include - I/usr/local/include -IInclude/ -c /cygdrive/e/Python- 2.2b2/Modules/gdbmmodule.c -o build/temp.cygwin-1.3. 5-i686-2.2/gdbmmodule.o e:\buildpy\python.exe: *** unable to remap C:\cygnus\bin\cygssl.dll to same address as parent -- 0x1A7C0000 0 [main] python 1292 sync_with_child: child 1108 (0xF0) died before initialization with status code 0x1 25901 [main] python 1292 sync_with_child: *** child state child loading dlls error: Resource temporarily unavailable make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-06 05:53 Message: Logged In: YES user_id=6656 Just to say that I'm seeing this too. What OS? I'm on NT4 SP6. Which cygwin? I'm [Administrator@MATHS-PC150 QUAKE]$ uname -a CYGWIN_NT-4.0 MATHS-PC150 1.3.6(0.47/3/2) 2001-12-03 15:41 i686 unknown I was actually assuming this was a cygwin bug. Are you on the cygwin mailing list? Maybe you could try raising it there? I would, but I *really* don't need another subscription to a high-volume mailing list right now. PS: can we add jason as a developer? then we can assign bugs to him . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489709&group_id=5470 From noreply@sourceforge.net Thu Dec 6 14:11:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 06:11:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-489669 ] memory leak in test_descr (unicode) Message-ID: Bugs item #489669, was opened at 2001-12-05 18:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489669&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak in test_descr (unicode) Initial Comment: leak from unicode object when running test_descr may be related to bug "memory leak in test_unicode" see attached file for details ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 06:11 Message: Logged In: YES user_id=6380 I may or may not have fixed this through plugging a leak in ceval.c. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489669&group_id=5470 From noreply@sourceforge.net Thu Dec 6 14:19:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 06:19:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-489673 ] memory leak in test_symtable Message-ID: Bugs item #489673, was opened at 2001-12-05 18:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489673&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Jeremy Hylton (jhylton) Summary: memory leak in test_symtable Initial Comment: leak when running test_symtable see attached file for details ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489673&group_id=5470 From noreply@sourceforge.net Thu Dec 6 14:25:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 06:25:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-485152 ] memory leak in test_scope Message-ID: Bugs item #485152, was opened at 2001-11-24 11:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485152&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Jeremy Hylton (jhylton) Summary: memory leak in test_scope Initial Comment: test_scope leaks memory see attached file for details ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:04 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485152&group_id=5470 From noreply@sourceforge.net Thu Dec 6 14:35:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 06:35:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-489673 ] memory leak in test_symtable Message-ID: Bugs item #489673, was opened at 2001-12-05 18:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489673&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Jeremy Hylton (jhylton) Summary: memory leak in test_symtable Initial Comment: leak when running test_symtable see attached file for details ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-12-06 06:35 Message: Logged In: YES user_id=31392 Fixed in rev 1.5 of symtablemodule.c ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489673&group_id=5470 From noreply@sourceforge.net Thu Dec 6 14:43:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 06:43:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-416423 ] Python2.0-Darwin - test_rc failed Message-ID: Bugs item #416423, was opened at 2001-04-16 05:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416423&group_id=5470 Category: Build Group: Platform-specific >Status: Closed >Resolution: Duplicate Priority: 3 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Michael Hudson (mwh) Summary: Python2.0-Darwin - test_rc failed Initial Comment: I have a Apple PBG4 with Mac OS X and the latest Updates and 256MB RAM. I tried to compile Python2.0 and got these output - hth Pitz ------------------------------ [localhost:~/Documents/src/Python-2.0] % uname - a Darwin localhost 1.3 Darwin Kernel Version 1.3: Fri Mar 30 20:45:03 PST 2001; root:xnu/xnu- 124.1.obj~1/RELEASE_PPC Powe r Macintosh powerpc [localhost:~/Documents/src/Python-2.0] % ./ configure --with-dyld --with-suffix=.app --with- threads --with-libdb [localhost:~/Documents/src/Python-2.0] % make [localhost:~/Documents/src/Python-2.0] % make test [localhost:~/Documents/src/Python-2.0] % Python/ python ./Lib/test/test_fcntl.py Status from fnctl with O_NONBLOCK: 0 struct.pack: '\000\003\000\000\000\000\000\000\ 000\000\000\000\000\000\000\000' Traceback (most recent call last): File "./Lib/test/test_fcntl.py", line 31, in ? rv = fcntl.fcntl(f.fileno(), FCNTL.F_SETLKW, lockdata) IOError: [Errno 22] Invalid argument [localhost:~/Documents/src/Python-2.0] % Python/ python ./Lib/test/test_re.py Running tests on re.search and re.match Running tests on re.sub Running tests on symbolic references Running tests on re.subn Running tests on re.split Running tests on re.findall Running tests on re.match Running tests on re.escape Pickling a RegexObject instance Test engine limitations Segmentation fault ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-06 06:43 Message: Logged In: YES user_id=6656 This was named a dup months ago. Close it. ---------------------------------------------------------------------- Comment By: Dan Wolfe (dkwolfe) Date: 2001-04-17 16:49 Message: Logged In: YES user_id=80173 test_re and test_sre will both fail due to the default small stacksize (512K) on Darwin/Mac OS X. The temporary workaround is to enter 'limit stacksize 2M' on CL before running make tests. This bug is a dup of 416526. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-16 08:21 Message: Logged In: YES user_id=6380 Please try again with Python 2.1c2, downloadable from python.org/2.1/. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416423&group_id=5470 From noreply@sourceforge.net Thu Dec 6 14:48:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 06:48:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-485152 ] memory leak in test_scope Message-ID: Bugs item #485152, was opened at 2001-11-24 11:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485152&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Jeremy Hylton (jhylton) Summary: memory leak in test_scope Initial Comment: test_scope leaks memory see attached file for details ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-12-06 06:48 Message: Logged In: YES user_id=31392 Weird. The leak is reported in PyString_FormatString(), which is called because of a string interpolation call in test_scope: "_%s__%s" % (klass.__name__, name). That's the only use of % on a string in the module. Unfortunately, the line numbers in the Purify output don't match the current CVS version of stringobject.c. Neal-- Would it be hard to do a new run with the current CVS? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:04 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485152&group_id=5470 From noreply@sourceforge.net Thu Dec 6 14:58:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 06:58:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-417779 ] Fails to build on RH 5.1 Message-ID: Bugs item #417779, was opened at 2001-04-20 18:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417779&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Michael Hudson (mwh) Summary: Fails to build on RH 5.1 Initial Comment: Im trying to build and install on RH 5.1 i get the following errors. gcc -c -g -O2 -Wall -Wstrict-prototypes -I. - I./Include -DHAVE_CONFIG_H -o Objects/fileobject.o Objects/fileobject.c Objects/fileobject.c: In function `_portable_fseek': Objects/fileobject.c:229: warning: implicit declaration of function `fseeko' gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include - DHAVE_CONFIG_H -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c:4032: sys/statvfs.h: No such file or directory ./Modules/posixmodule.c:4081: sys/statvfs.h: No such file or directory Am i missing something? Regards Andrew ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-06 06:58 Message: Logged In: YES user_id=6656 Closed for lack of response. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 12:05 Message: Logged In: YES user_id=6380 Please try again with current CVS, or with the 2.2a3 release that will be out in a few days. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417779&group_id=5470 From noreply@sourceforge.net Thu Dec 6 15:05:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 07:05:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-421728 ] readline returns '' when interrupted Message-ID: Bugs item #421728, was opened at 2001-05-05 15:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421728&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Michael Hudson (mwh) Summary: readline returns '' when interrupted Initial Comment: When file.readline() is waiting for a line to be read, and is interrupted by a handled signal, it returns the empty string, ''. It does not raise a IOError exception (interrupted system call), as I would expect. Although the documentation is not explicit about what the behavior should be in this case, returning '' is a bad idea since it looks just like an end of file, even though there is more data that can be read. There is some discussion of this in the python-list mailing list -- the thread is "Signals and readline()". In that thread, Jeff Epler advanced a theory as to a possible source change to fix this. It is easy to reproduce, and produces the same behavior on both Linux (Mandrake 7.2) and FreeBSD (4.0). Using Python 2.0. To reproduce: Enter this Python program interactively (under Unix): import sys, os, signal print os.getpid() signal.signal(signal.SIGUSR2, lambda *x: None) sys.stdin.readline() >From another shell, send SIGUSR2 to the printed PID: kill -SIGUSR2, The readline will return ''. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-06 07:05 Message: Logged In: YES user_id=6656 Hmm. Works for me. Looks like it was fixed by patch #441229 which was applied by Guido on 2001/08/09 in revision 2.117 of Objects/fileobject.c. Closing. (I'll get the "open & unassigned" bugs on one page soon :) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421728&group_id=5470 From noreply@sourceforge.net Thu Dec 6 15:07:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 07:07:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-426504 ] urllib fail with MS proxy Message-ID: Bugs item #426504, was opened at 2001-05-22 17:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426504&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: urllib fail with MS proxy Initial Comment: urllib can not perform due to the present of MS proxy. After remove the auto-detect portation, it works. I have to force remove the getproxies code to make it work: class URLopener: """Class to open URLs. This is a class rather than just a subroutine because we may need more than one set of global protocol-specific options. Note -- this is a base class for those who don't want the automatic handling of errors type 302 (relocated) and 401 (authorization needed).""" __tempfiles = None version = "Python-urllib/%s" % __version__ # Constructor def __init__(self, proxies=None, **x509): if proxies is None: proxies = {} # proxies = getproxies() ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-06 07:07 Message: Logged In: YES user_id=6656 This seems to be a dup of #426866 (which hasn't seen life since July, but ne'er mind that). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426504&group_id=5470 From noreply@sourceforge.net Thu Dec 6 15:08:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 07:08:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-485152 ] memory leak in test_scope Message-ID: Bugs item #485152, was opened at 2001-11-24 11:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485152&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Jeremy Hylton (jhylton) Summary: memory leak in test_scope Initial Comment: test_scope leaks memory see attached file for details ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2001-12-06 07:08 Message: Logged In: YES user_id=33168 Attached a new file that was built with current CVS and w/o optimization so the line #s should be good ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-06 06:48 Message: Logged In: YES user_id=31392 Weird. The leak is reported in PyString_FormatString(), which is called because of a string interpolation call in test_scope: "_%s__%s" % (klass.__name__, name). That's the only use of % on a string in the module. Unfortunately, the line numbers in the Purify output don't match the current CVS version of stringobject.c. Neal-- Would it be hard to do a new run with the current CVS? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:04 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485152&group_id=5470 From noreply@sourceforge.net Thu Dec 6 15:11:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 07:11:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-443784 ] test_poll hangs in cygwin Message-ID: Bugs item #443784, was opened at 2001-07-23 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443784&group_id=5470 Category: Windows Group: Platform-specific >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Jeff Epler (jepler) >Assigned to: Michael Hudson (mwh) Summary: test_poll hangs in cygwin Initial Comment: Fresh install of cygwin32. Fresh checkout of descr- branch. Windows 98. test_poll hangs. Output when running test_poll manually: Running poll test 1 This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/test/test_poll.py", line 171, in ? test_poll1() File "/usr/lib/python2.1/test/test_poll.py", line 65, in test_poll1 poll_unit_tests() File "/usr/lib/python2.1/test/test_poll.py", line 77, in poll_unit_tests r = p.poll() KeyboardInterrupt ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-06 07:11 Message: Logged In: YES user_id=6656 This now works. Or rather, it worked when Python still built on cygwin, but that's another problem (and may not be Python's fault). Closing. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-23 14:00 Message: Logged In: YES user_id=31435 test_poll's failure on Cygwin is already noted in the main README file, and isn't unique to descr-branch. You need a platform expert for this; since the chance of me fixing it is 0, unassigned the bug. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443784&group_id=5470 From noreply@sourceforge.net Thu Dec 6 15:12:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 07:12:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-489709 ] Building Fails under Cygwin Message-ID: Bugs item #489709, was opened at 2001-12-05 20:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489709&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Michael Hudson (mwh) Summary: Building Fails under Cygwin Initial Comment: Even after applying the h2py patch, building under Cygwin ends with the following error: building 'gdbm' extension gcc -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT - I. -I/cygdrive/e/Python-2.2b2/./Include - I/usr/local/include -IInclude/ -c /cygdrive/e/Python- 2.2b2/Modules/gdbmmodule.c -o build/temp.cygwin-1.3. 5-i686-2.2/gdbmmodule.o e:\buildpy\python.exe: *** unable to remap C:\cygnus\bin\cygssl.dll to same address as parent -- 0x1A7C0000 0 [main] python 1292 sync_with_child: child 1108 (0xF0) died before initialization with status code 0x1 25901 [main] python 1292 sync_with_child: *** child state child loading dlls error: Resource temporarily unavailable make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- >Comment By: David Abrahams (david_abrahams) Date: 2001-12-06 07:12 Message: Logged In: YES user_id=52572 I'm using Win2K CYGWIN_NT-5.0 MOREPIE 1.3.5(0.47/3/2) 2001-11-13 23:16 i686 unknown And I've built and installed GCC 3.0.2, thought the Python build seems to use 2.95.x anyway. I am not on the cygwin mailing list, sorry ;-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-06 05:53 Message: Logged In: YES user_id=6656 Just to say that I'm seeing this too. What OS? I'm on NT4 SP6. Which cygwin? I'm [Administrator@MATHS-PC150 QUAKE]$ uname -a CYGWIN_NT-4.0 MATHS-PC150 1.3.6(0.47/3/2) 2001-12-03 15:41 i686 unknown I was actually assuming this was a cygwin bug. Are you on the cygwin mailing list? Maybe you could try raising it there? I would, but I *really* don't need another subscription to a high-volume mailing list right now. PS: can we add jason as a developer? then we can assign bugs to him . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489709&group_id=5470 From noreply@sourceforge.net Thu Dec 6 15:14:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 07:14:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-485152 ] memory leak in test_scope Message-ID: Bugs item #485152, was opened at 2001-11-24 11:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485152&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Jeremy Hylton (jhylton) Summary: memory leak in test_scope Initial Comment: test_scope leaks memory see attached file for details ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-12-06 07:14 Message: Logged In: YES user_id=31392 This one is strange! I've attached a new file (smaller.py) that reproduces the leak more quickly than test_scope.py. I've been unable to simplify further. The leak seems to occur in the presence of three things: - an installed trace function - a string format operation - a nested lambda that causes the string to be a cell ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2001-12-06 07:08 Message: Logged In: YES user_id=33168 Attached a new file that was built with current CVS and w/o optimization so the line #s should be good ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-06 06:48 Message: Logged In: YES user_id=31392 Weird. The leak is reported in PyString_FormatString(), which is called because of a string interpolation call in test_scope: "_%s__%s" % (klass.__name__, name). That's the only use of % on a string in the module. Unfortunately, the line numbers in the Purify output don't match the current CVS version of stringobject.c. Neal-- Would it be hard to do a new run with the current CVS? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:04 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485152&group_id=5470 From noreply@sourceforge.net Thu Dec 6 15:16:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 07:16:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-489709 ] Building Fails under Cygwin Message-ID: Bugs item #489709, was opened at 2001-12-05 20:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489709&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Michael Hudson (mwh) Summary: Building Fails under Cygwin Initial Comment: Even after applying the h2py patch, building under Cygwin ends with the following error: building 'gdbm' extension gcc -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT - I. -I/cygdrive/e/Python-2.2b2/./Include - I/usr/local/include -IInclude/ -c /cygdrive/e/Python- 2.2b2/Modules/gdbmmodule.c -o build/temp.cygwin-1.3. 5-i686-2.2/gdbmmodule.o e:\buildpy\python.exe: *** unable to remap C:\cygnus\bin\cygssl.dll to same address as parent -- 0x1A7C0000 0 [main] python 1292 sync_with_child: child 1108 (0xF0) died before initialization with status code 0x1 25901 [main] python 1292 sync_with_child: *** child state child loading dlls error: Resource temporarily unavailable make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-06 07:16 Message: Logged In: YES user_id=6656 Hmm. Seems pretty similar to mine. I'll bug Jason Tishler and see if he knows anything about it. ---------------------------------------------------------------------- Comment By: David Abrahams (david_abrahams) Date: 2001-12-06 07:12 Message: Logged In: YES user_id=52572 I'm using Win2K CYGWIN_NT-5.0 MOREPIE 1.3.5(0.47/3/2) 2001-11-13 23:16 i686 unknown And I've built and installed GCC 3.0.2, thought the Python build seems to use 2.95.x anyway. I am not on the cygwin mailing list, sorry ;-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-06 05:53 Message: Logged In: YES user_id=6656 Just to say that I'm seeing this too. What OS? I'm on NT4 SP6. Which cygwin? I'm [Administrator@MATHS-PC150 QUAKE]$ uname -a CYGWIN_NT-4.0 MATHS-PC150 1.3.6(0.47/3/2) 2001-12-03 15:41 i686 unknown I was actually assuming this was a cygwin bug. Are you on the cygwin mailing list? Maybe you could try raising it there? I would, but I *really* don't need another subscription to a high-volume mailing list right now. PS: can we add jason as a developer? then we can assign bugs to him . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489709&group_id=5470 From noreply@sourceforge.net Thu Dec 6 15:25:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 07:25:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-489872 ] PyString_FromString(NULL) seg faults Message-ID: Bugs item #489872, was opened at 2001-12-06 07:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489872&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Merritt (jmerritt5) Assigned to: Nobody/Anonymous (nobody) Summary: PyString_FromString(NULL) seg faults Initial Comment: Python 1.5.4 and Python 2.0.1, the only two I have installed, produce a segmentation violation when a NULL is passed to, at least, PyString_FromString. The solution is to check the argument and return Py_None. I saw in FAQ (wizard) 8.16 that you should return Py_Build(""), but, on Python 1.5.4, I don't have Py_Build. I use SWIG 1.3.*, and I have modified my version of SWIG to generate code to check the arguement prior to calling PyString_FromString. if (result == NULL) return Py_None; resultobj = PyString_FromString(result); return resultobj; This works like a charm. John ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489872&group_id=5470 From noreply@sourceforge.net Thu Dec 6 15:26:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 07:26:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-421728 ] readline returns '' when interrupted Message-ID: Bugs item #421728, was opened at 2001-05-05 15:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421728&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Michael Hudson (mwh) Summary: readline returns '' when interrupted Initial Comment: When file.readline() is waiting for a line to be read, and is interrupted by a handled signal, it returns the empty string, ''. It does not raise a IOError exception (interrupted system call), as I would expect. Although the documentation is not explicit about what the behavior should be in this case, returning '' is a bad idea since it looks just like an end of file, even though there is more data that can be read. There is some discussion of this in the python-list mailing list -- the thread is "Signals and readline()". In that thread, Jeff Epler advanced a theory as to a possible source change to fix this. It is easy to reproduce, and produces the same behavior on both Linux (Mandrake 7.2) and FreeBSD (4.0). Using Python 2.0. To reproduce: Enter this Python program interactively (under Unix): import sys, os, signal print os.getpid() signal.signal(signal.SIGUSR2, lambda *x: None) sys.stdin.readline() >From another shell, send SIGUSR2 to the printed PID: kill -SIGUSR2, The readline will return ''. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 07:26 Message: Logged In: YES user_id=6380 Thanks for doing this, Michael!!! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-06 07:05 Message: Logged In: YES user_id=6656 Hmm. Works for me. Looks like it was fixed by patch #441229 which was applied by Guido on 2001/08/09 in revision 2.117 of Objects/fileobject.c. Closing. (I'll get the "open & unassigned" bugs on one page soon :) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421728&group_id=5470 From noreply@sourceforge.net Thu Dec 6 15:38:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 07:38:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-489872 ] PyString_FromString(NULL) seg faults Message-ID: Bugs item #489872, was opened at 2001-12-06 07:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489872&group_id=5470 >Category: Python Interpreter Core >Group: Not a Bug >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: John Merritt (jmerritt5) Assigned to: Nobody/Anonymous (nobody) Summary: PyString_FromString(NULL) seg faults Initial Comment: Python 1.5.4 and Python 2.0.1, the only two I have installed, produce a segmentation violation when a NULL is passed to, at least, PyString_FromString. The solution is to check the argument and return Py_None. I saw in FAQ (wizard) 8.16 that you should return Py_Build(""), but, on Python 1.5.4, I don't have Py_Build. I use SWIG 1.3.*, and I have modified my version of SWIG to generate code to check the arguement prior to calling PyString_FromString. if (result == NULL) return Py_None; resultobj = PyString_FromString(result); return resultobj; This works like a charm. John ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 07:38 Message: Logged In: YES user_id=6380 Where in the docs does it say that you're allowed to pass NULL to PyString_FromString()? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489872&group_id=5470 From noreply@sourceforge.net Thu Dec 6 15:44:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 07:44:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-410878 ] Distutils should have a Setup parser Message-ID: Bugs item #410878, was opened at 2001-03-23 09:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410878&group_id=5470 Category: Distutils Group: Feature Request Status: Open Resolution: None >Priority: 9 Submitted By: A.M. Kuchling (akuchling) Assigned to: A.M. Kuchling (akuchling) Summary: Distutils should have a Setup parser Initial Comment: Setup files are handy for allowing user overrides. I do a minimal parse in Python 2.1's setup.py, and Pete Shinners wrote a more complete one for pygame's config.py. Support for parsing Setup files should be added to the Distutils API, so packagers can easily make overrides for C extension compile flags. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410878&group_id=5470 From noreply@sourceforge.net Thu Dec 6 15:51:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 07:51:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-489872 ] PyString_FromString(NULL) seg faults Message-ID: Bugs item #489872, was opened at 2001-12-06 07:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489872&group_id=5470 Category: Python Interpreter Core >Group: Feature Request >Status: Open Resolution: Rejected Priority: 5 Submitted By: John Merritt (jmerritt5) Assigned to: Nobody/Anonymous (nobody) Summary: PyString_FromString(NULL) seg faults Initial Comment: Python 1.5.4 and Python 2.0.1, the only two I have installed, produce a segmentation violation when a NULL is passed to, at least, PyString_FromString. The solution is to check the argument and return Py_None. I saw in FAQ (wizard) 8.16 that you should return Py_Build(""), but, on Python 1.5.4, I don't have Py_Build. I use SWIG 1.3.*, and I have modified my version of SWIG to generate code to check the arguement prior to calling PyString_FromString. if (result == NULL) return Py_None; resultobj = PyString_FromString(result); return resultobj; This works like a charm. John ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 07:51 Message: Logged In: YES user_id=3066 The FAQ should refer to Py_BuildValue() instead of Py_Build(); I've fixed that in the FAQ. I'm not sure that PyString_FromString() should return None if passed NULL; I'd expect a separate call about be appropriate for that behavior. It would not be unreasonable for PyString_FromString() to check for NULL and raise a SystemError though. Categorizing as a feature request. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 07:38 Message: Logged In: YES user_id=6380 Where in the docs does it say that you're allowed to pass NULL to PyString_FromString()? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489872&group_id=5470 From noreply@sourceforge.net Thu Dec 6 15:49:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 07:49:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-485152 ] memory leak in test_scope Message-ID: Bugs item #485152, was opened at 2001-11-24 11:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485152&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Jeremy Hylton (jhylton) Summary: memory leak in test_scope Initial Comment: test_scope leaks memory see attached file for details ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-12-06 07:49 Message: Logged In: YES user_id=31392 Fixed in rev 2.59 of frameobject.c. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-06 07:35 Message: Logged In: YES user_id=31392 And that's it! The leak is in the code that maps between the frame and the locals dict when calling the trace function. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-06 07:14 Message: Logged In: YES user_id=31392 This one is strange! I've attached a new file (smaller.py) that reproduces the leak more quickly than test_scope.py. I've been unable to simplify further. The leak seems to occur in the presence of three things: - an installed trace function - a string format operation - a nested lambda that causes the string to be a cell ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2001-12-06 07:08 Message: Logged In: YES user_id=33168 Attached a new file that was built with current CVS and w/o optimization so the line #s should be good ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-06 06:48 Message: Logged In: YES user_id=31392 Weird. The leak is reported in PyString_FormatString(), which is called because of a string interpolation call in test_scope: "_%s__%s" % (klass.__name__, name). That's the only use of % on a string in the module. Unfortunately, the line numbers in the Purify output don't match the current CVS version of stringobject.c. Neal-- Would it be hard to do a new run with the current CVS? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:04 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485152&group_id=5470 From noreply@sourceforge.net Thu Dec 6 15:48:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 07:48:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-220993 ] Installation flaky with multiple installers, old versions Message-ID: Bugs item #220993, was opened at 2000-11-01 05:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=220993&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 7 Submitted By: Greg Ward (gward) >Assigned to: Nobody/Anonymous (nobody) Summary: Installation flaky with multiple installers, old versions Initial Comment: Installation tends to have problems when there are old installations present, especially when a different user is doing the new installation. In particular, it appears that the chmod() done in 'copy_file()' (as a result of the "install" command attempting to preserve the mode of files from the build tree) fails, because you can't chmod() a file owned by somebody else. Paul Dubois suggests that simply unlinking the target file before doing the copy should work. I think he's right, but need to think about it and test it a bit first. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-09-20 11:41 Message: Logged In: YES user_id=11375 I think unlinking first is the right thing to do, having just run into another problem that seems to be caused by this. Installing *.so files to an NFS partition messed up other people, I think because they had the *.so file loaded into memory and the kernel's VM got confused. (That's the theory, anyway.) Bumping up the priority as a reminder to myself... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=220993&group_id=5470 From noreply@sourceforge.net Thu Dec 6 15:35:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 07:35:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-485152 ] memory leak in test_scope Message-ID: Bugs item #485152, was opened at 2001-11-24 11:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485152&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Jeremy Hylton (jhylton) Summary: memory leak in test_scope Initial Comment: test_scope leaks memory see attached file for details ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-12-06 07:35 Message: Logged In: YES user_id=31392 And that's it! The leak is in the code that maps between the frame and the locals dict when calling the trace function. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-06 07:14 Message: Logged In: YES user_id=31392 This one is strange! I've attached a new file (smaller.py) that reproduces the leak more quickly than test_scope.py. I've been unable to simplify further. The leak seems to occur in the presence of three things: - an installed trace function - a string format operation - a nested lambda that causes the string to be a cell ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2001-12-06 07:08 Message: Logged In: YES user_id=33168 Attached a new file that was built with current CVS and w/o optimization so the line #s should be good ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-06 06:48 Message: Logged In: YES user_id=31392 Weird. The leak is reported in PyString_FormatString(), which is called because of a string interpolation call in test_scope: "_%s__%s" % (klass.__name__, name). That's the only use of % on a string in the module. Unfortunately, the line numbers in the Purify output don't match the current CVS version of stringobject.c. Neal-- Would it be hard to do a new run with the current CVS? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:04 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485152&group_id=5470 From noreply@sourceforge.net Thu Dec 6 15:56:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 07:56:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-489671 ] memory leak in test_richcmp Message-ID: Bugs item #489671, was opened at 2001-12-05 18:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489671&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak in test_richcmp Initial Comment: leak when running test_richcmp see attached file for details ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-12-06 07:56 Message: Logged In: YES user_id=31392 It's specifically the testvector() function that causes the leak in test_richcmp. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489671&group_id=5470 From noreply@sourceforge.net Thu Dec 6 15:58:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 07:58:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-480882 ] oot builds don't build _curses_panel Message-ID: Bugs item #480882, was opened at 2001-11-12 04:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=480882&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: A.M. Kuchling (akuchling) Summary: oot builds don't build _curses_panel Initial Comment: Out-of-tree builds of python (i.e. $ cd PATH/TO/Python/src $ mkdir build $ cd ./build $ ../configure && make ) don't build the _curses_panel extension. I think this line from setup.py: if (os.path.exists('Modules/_curses_panel.c') and ... is why. Either (1) this line should be fixed to actually point at the source (2) this check should simply be hacked out. What's it doing there? ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-12-06 07:58 Message: Logged In: YES user_id=11375 The check was probably there so people could try out the setup.py with old versions of Python, and not just the latest CVS tree. Removed in rev. 1.67 of setup.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=480882&group_id=5470 From noreply@sourceforge.net Thu Dec 6 16:09:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 08:09:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-489872 ] PyString_FromString(NULL) seg faults Message-ID: Bugs item #489872, was opened at 2001-12-06 07:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489872&group_id=5470 Category: Python Interpreter Core Group: Feature Request >Status: Closed Resolution: Rejected Priority: 5 Submitted By: John Merritt (jmerritt5) Assigned to: Nobody/Anonymous (nobody) Summary: PyString_FromString(NULL) seg faults Initial Comment: Python 1.5.4 and Python 2.0.1, the only two I have installed, produce a segmentation violation when a NULL is passed to, at least, PyString_FromString. The solution is to check the argument and return Py_None. I saw in FAQ (wizard) 8.16 that you should return Py_Build(""), but, on Python 1.5.4, I don't have Py_Build. I use SWIG 1.3.*, and I have modified my version of SWIG to generate code to check the arguement prior to calling PyString_FromString. if (result == NULL) return Py_None; resultobj = PyString_FromString(result); return resultobj; This works like a charm. John ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 08:08 Message: Logged In: YES user_id=6380 I'm rejecting the feature request. This would unnecessarily slow it down. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 07:51 Message: Logged In: YES user_id=3066 The FAQ should refer to Py_BuildValue() instead of Py_Build(); I've fixed that in the FAQ. I'm not sure that PyString_FromString() should return None if passed NULL; I'd expect a separate call about be appropriate for that behavior. It would not be unreasonable for PyString_FromString() to check for NULL and raise a SystemError though. Categorizing as a feature request. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 07:38 Message: Logged In: YES user_id=6380 Where in the docs does it say that you're allowed to pass NULL to PyString_FromString()? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489872&group_id=5470 From noreply@sourceforge.net Thu Dec 6 16:12:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 08:12:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-489669 ] memory leak in test_descr (unicode) Message-ID: Bugs item #489669, was opened at 2001-12-05 18:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489669&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak in test_descr (unicode) Initial Comment: leak from unicode object when running test_descr may be related to bug "memory leak in test_unicode" see attached file for details ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 08:12 Message: Logged In: YES user_id=6380 This is still there. The leak is in buffer_inherit(). It can be reduced to: | while 1: | class U(unicode): | pass | U() ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 06:11 Message: Logged In: YES user_id=6380 I may or may not have fixed this through plugging a leak in ceval.c. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489669&group_id=5470 From noreply@sourceforge.net Thu Dec 6 16:15:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 08:15:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-484994 ] bugs in Tix.py ListNoteBook PanedWindow Message-ID: Bugs item #484994, was opened at 2001-11-23 14:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=484994&group_id=5470 Category: Tkinter Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Robert Roy (rjroy) Assigned to: Nobody/Anonymous (nobody) Summary: bugs in Tix.py ListNoteBook PanedWindow Initial Comment: Python 2.2b2 Tix.py 1) class ListNoteBook, __init__ method calls base class __init__ method with "tixDirList" instead of "tixListNoteBook" 2) class PanedWindow, panes method, does not split the string returned from self.tk.call(self._w, 'panes') patch also adds: access to the paned window in ListNoteBook class dummyPanedWindow to support above paneconfigure methods to PanedWindow pageConfigure methods to NoteBook and ListNoteBook page and pages methods to ListNoteBook I am attaching the pathched file as well as the following diff ################ 1044c1044,1046 < TixWidget.__init__(self, master, 'tixDirList', ['options'], cnf, kw) --- > TixWidget.__init__(self, master, 'tixListNoteBook', ['options'], cnf, kw) > self.subwidget_list['pane'] = _dummyPanedWindow(self, 'pane', > destroy_physically=0) 1048d1049 < 1054a1056,1070 > def page(self, name): > return self.subwidget(name) > > def pages(self): > # Can't call subwidgets_all directly because we don't want .nbframe > names = self.tk.split(self.tk.call (self._w, 'pages')) > ret = [] > for x in names: > ret.append(self.subwidget(x)) > return ret > > def pageconfigure(self, name, **kw): > apply(self.tk.call, > (self._w, 'pageconfigure', name) + self._options(kw)) > 1099a1116,1119 > def pageconfigure(self, name, **kw): > apply(self.tk.call, > (self._w, 'pageconfigure', name) + self._options(kw)) > 1162c1182 < names = self.tk.call(self._w, 'panes') --- > names = self.tk.split(self.tk.call (self._w, 'panes')) 1167a1188,1191 > def paneconfigure(self, name, **kw): > apply(self.tk.call, > (self._w, 'paneconfigure', name) + self._options(kw)) > 1571a1596,1599 > TixSubWidget.__init__(self, master, name, destroy_physically) > > class _dummyPanedWindow(PanedWindow, TixSubWidget): > def __init__(self, master, name, destroy_physically=1): ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 08:15 Message: Logged In: YES user_id=3066 I've asked Mike Clarkson (Tix.py guru) to take a look at this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=484994&group_id=5470 From noreply@sourceforge.net Thu Dec 6 16:18:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 08:18:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-233259 ] Ugly traceback for DistutilsPlatformError Message-ID: Bugs item #233259, was opened at 2001-02-20 08:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=233259&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Ward (gward) Assigned to: A.M. Kuchling (akuchling) Summary: Ugly traceback for DistutilsPlatformError Initial Comment: >From Chad Lester: > I was setting up a new redhat machine, and had forgotten to install the > python-devel rpm. The distutils provide a fairly ugly stack trace / error > message. Luckily, it meant something to me... but it's not terribly user > friendly! > > ... > File "/usr/lib/python1.5/site-packages/distutils/sysconfig.py", line > 368, in get_config_vars > func() > File "/usr/lib/python1.5/site-packages/distutils/sysconfig.py", line > 280, in _init_posix > raise DistutilsPlatformError, my_msg > distutils.errors.DistutilsPlatformError: invalid Python > installation: unable to open /usr/lib/python1.5/config/Makefile (No such > file or directory) > > ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-12-06 08:18 Message: Logged In: YES user_id=11375 Greg, I don't understand your last comment on this bug. Surely the traceback will still be ugly for people running Python 2.2 or whatever who don't have the python-devel RPM installed? I don't see how this is only a 1.5.2 or a "installing Distutils" question. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2001-02-20 08:24 Message: This only applies for people installing Distutils under Python 1.5.2, so it will only be fixed if there is another Distutils release to support 1.5.2 -- which is unlikely. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=233259&group_id=5470 From noreply@sourceforge.net Thu Dec 6 16:26:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 08:26:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-489669 ] memory leak in test_descr (unicode) Message-ID: Bugs item #489669, was opened at 2001-12-05 18:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489669&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Guido van Rossum (gvanrossum) Summary: memory leak in test_descr (unicode) Initial Comment: leak from unicode object when running test_descr may be related to bug "memory leak in test_unicode" see attached file for details ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 08:26 Message: Logged In: YES user_id=6380 If we call the constructor like U(u"xxxxxxxxxx") instead, it leaks faster. With a really large unicode string argument, it leaks fenomenally fast. Using debug mode and printing the remaining objects at the end by setting $PYTHONDUMPREFS=y doesn't reveal any leaked objects. So it's leaking a copy of the Unicode data. I'll look into it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 08:12 Message: Logged In: YES user_id=6380 This is still there. The leak is in buffer_inherit(). It can be reduced to: | while 1: | class U(unicode): | pass | U() ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 06:11 Message: Logged In: YES user_id=6380 I may or may not have fixed this through plugging a leak in ceval.c. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489669&group_id=5470 From noreply@sourceforge.net Thu Dec 6 16:35:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 08:35:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-459270 ] System-wide distutils cfg file misnamed Message-ID: Bugs item #459270, was opened at 2001-09-06 11:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459270&group_id=5470 Category: Distutils Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Paul Sidorsky (paulsid) Assigned to: A.M. Kuchling (akuchling) Summary: System-wide distutils cfg file misnamed Initial Comment: Not sure whether this is a bug or a documentation error. The documentation says you can put a pydistutils.cfg file in your distutils directory to configure Distutils, as seen here: http://python.sourceforge.net/devel-docs/inst/config-syntax.html Distutils wouldn't load this file for me, so I did some digging and I found that Distutils' dist.py contains this line (around line 284): sys_file = os.path.join(sys_dir, "distutils.cfg") I renamed my pydistutils.cfg file to distutils.cfg and it worked, as verified with DISTUTILS_DEBUG turned on: Distribution.parse_config_files(): reading e:\python21\lib\distutils\distutils.cfg The docstring for parse_config_files() also specifies pydistutils.cfg as the system-wide file in a couple of places, which added to the confusion. On a related note, that same docstring seems to be all wrong WRT its behaviour under Windows: On Windows and Mac OS, there are two possible config files: pydistutils.cfg in the Python installation directory (sys.prefix) and setup.cfg in the current directory. >From what I can tell, sys.prefix isn't the right directory (the distutils path is), and you can also put a config file in a home directory (a la Unix) if the home directory is defined by a HOME environment variable. I'm running Python 2.1 under Windows ME. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-12-06 08:35 Message: Logged In: YES user_id=11375 It's a documentation bug. Fixed in rev. 1.51 of dist.py and rev. 1.37 of inst.tex. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459270&group_id=5470 From noreply@sourceforge.net Thu Dec 6 16:38:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 08:38:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-451285 ] distutils ignores environment variables Message-ID: Bugs item #451285, was opened at 2001-08-15 12:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451285&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) >Assigned to: Thomas Heller (theller) Summary: distutils ignores environment variables Initial Comment: Visual C++ 6.0 sets up environment variables for use by command-line users -- MSDEVDIR, INCLUDE, LIB. It also provides VCVARS32.BAT to set these environment variables. They specify where to find cl.exe and its header files and libraries. distutils ignores those in favor of the registry. I think distutils should honor the environment variables if they are set. In my case, the registry was pointing to an old, removed install of VC. I later installed a new version in a new location, but that install did not modify the registry. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-12-06 08:38 Message: Logged In: YES user_id=11375 As a Unix guy, I have no idea whether this is worth doing, though it certainly seems reasonable to check for the environment variables and use them if present. Thomas, you actually develop for Windows so I'll leave the decision up to you. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-05 12:37 Message: Logged In: YES user_id=31435 It would be a reasonable feature request to honor envars if the registry info wasn't found. This wouldn't have helped Jeremy, but so it goes (the 2nd time he installed MSVC, he didn't install the IDE, and that's why the registry didn't get updated; and he didn't properly uninstall his old MSVC either, which is why the stale registry entries didn't get removed -- and this combination of wrong turns has to be as rare as a Unix guy trying to build something on Windows ). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-09-05 12:05 Message: Logged In: YES user_id=11105 I'm unsure what to do. On one hand, this request makes sense, on the other hand, environment vars are IMO much more fragile than registry entries. I'll assign this to the current distutils maintainer to decide what to do. Or should it be marked as feature request? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-15 12:49 Message: Logged In: YES user_id=31435 Jeremy, do you know how to run regedit? It's a GUI registry browser. Do Start -> Run and type "regedit" (no quotes) then click OK. I want you to navigate to two places: HKEY_LOCAL_MACHINE\ Software\ Microsoft\ Devstudio\ 6.0\ Build System\ and exactly the same except starting at HKEY_CURRENT_USER instead. My *bet* is that you're going to find that path in both places, but that under HKEY_LOCAL_MACHINE it's pointing to a wrong place. This would be a side-effect of not having properly uninstalled your previous MSVC. If that's all true, select the DevStudio node under HKEY_LOCAL_MACHINE and then do Edit->Delete. This will get rid of the obsolete registry setting. Close regedit then. disutils *should* look under HKEY_CURRENT_USER before looking under HKEY_LOCAL_MACHINE, because per-user settings are suppused to take precedence over per-machine settings, and especially under Win2K. That appears to be a repeated buglet in msvccompiler.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451285&group_id=5470 From noreply@sourceforge.net Thu Dec 6 16:43:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 08:43:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-489669 ] memory leak in test_descr (unicode) Message-ID: Bugs item #489669, was opened at 2001-12-05 18:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489669&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Guido van Rossum (gvanrossum) Summary: memory leak in test_descr (unicode) Initial Comment: leak from unicode object when running test_descr may be related to bug "memory leak in test_unicode" see attached file for details ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-06 08:43 Message: Logged In: YES user_id=38388 Could be the PyUnicode_CheckExact() test in unicode_dealloc() which is triggering this behaviour. It seems that for subclassed types, there is no chance for the various DECREFs in that code to get executed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 08:26 Message: Logged In: YES user_id=6380 If we call the constructor like U(u"xxxxxxxxxx") instead, it leaks faster. With a really large unicode string argument, it leaks fenomenally fast. Using debug mode and printing the remaining objects at the end by setting $PYTHONDUMPREFS=y doesn't reveal any leaked objects. So it's leaking a copy of the Unicode data. I'll look into it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 08:12 Message: Logged In: YES user_id=6380 This is still there. The leak is in buffer_inherit(). It can be reduced to: | while 1: | class U(unicode): | pass | U() ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 06:11 Message: Logged In: YES user_id=6380 I may or may not have fixed this through plugging a leak in ceval.c. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489669&group_id=5470 From noreply@sourceforge.net Thu Dec 6 16:52:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 08:52:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-438517 ] tkSimpleDialog.askString option Message-ID: Bugs item #438517, was opened at 2001-07-04 05:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438517&group_id=5470 Category: Tkinter Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: tkSimpleDialog.askString option Initial Comment: I read the documentation of tkSimpleDialog.askString and found that there are only two options: initialvalue and parent. However, it doesn't support the option, show, from the Entry widget option that avoids echoing the string I input. I found the tkSimpleDialog.askString is a perfect fit for dialogs asking for encryption key or password. Although it is easy to write my own, I don't see the need because of an option. Many thanks Joe ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 08:52 Message: Logged In: YES user_id=3066 Fixed in Lib/lib-tk/tkSimpleDialog.py revision 1.8. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-12 14:12 Message: Logged In: YES user_id=6380 If you can submit this as a patch to the existing code it'll breeze right through. If you wait for one of us to write it, it may be a loooooooong time before we get to it (like when we need this ourselves :-). Since you know how to do it, it shouldn't be too hard for you to prepare a patch. See http://python.sourceforge.net/sf-faq.html#patches ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438517&group_id=5470 From noreply@sourceforge.net Thu Dec 6 17:31:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 09:31:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-417634 ] configuring without C++ compiler name Message-ID: Bugs item #417634, was opened at 2001-04-20 07:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417634&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Guido van Rossum (gvanrossum) Summary: configuring without C++ compiler name Initial Comment: If you check out a clean copy of Python 2.1 on a Solaris 5.8 machine, and run: ./configure -with-cxx rather than: ./configure -with-cxx=g++ It generates a makefile with "CXX=yes", so "make" produces: bash-2.03$ make yes -c -g -O2 -Wall -Wstrict-prototypes -I. \ -I./Include -DHAVE_CONFIG_H \ -o Modules/ccpython.o \ ./Modules/ccpython.cc make: yes: Command not found ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-06 09:31 Message: Logged In: YES user_id=6656 Two options: (1) apply the braindead fix I've just attached (2) ignore the problem and close the report. I don't really have an opinion on which is better. An autoconf guru may have a better idea, but it hardly seems worth putting too much effort into. Assigned to Guido for a quick decision -- please don't think too hard about it! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417634&group_id=5470 From noreply@sourceforge.net Thu Dec 6 19:05:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 11:05:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-486099 ] socketmodule won't compile on BSDI 4.0 Message-ID: Bugs item #486099, was opened at 2001-11-27 10:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486099&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Martin v. Löwis (loewis) Summary: socketmodule won't compile on BSDI 4.0 Initial Comment: Trying to build 2.2b2 on BSDI BSD/OS 4.0 with gcc 2.7.2.1 and gcc 2.95.2, and the socket module won't build. No problems building socket for Python 2.1.1 on this same machine. % ./configure --with-threads=no # for socket(2), without SSL support. _socket socketmodule.c % gmake gcc -D_HAVE_BSDI -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from ./Modules/socketmodule.c:187: /usr/local/packages/gcc-2.95.2/lib/gcc-lib/i386-pc-bsdi4.0/2.95.2/include/stddef.h:280: conflicting types for `wint_t' /usr/include/wchar.h:7: previous declaration of `wint_t' In file included from ./Modules/socketmodule.c:236: Modules/getaddrinfo.c: In function `gai_strerror': Modules/getaddrinfo.c:205: `EAI_MAX' undeclared (first use in this function) Modules/getaddrinfo.c:205: (Each undeclared identifier is reported only once Modules/getaddrinfo.c:205: for each function it appears in.) Modules/getaddrinfo.c: In function `getaddrinfo': Modules/getaddrinfo.c:285: `EAI_BADHINTS' undeclared (first use in this function) Modules/getaddrinfo.c:286: `AI_MASK' undeclared (first use in this function) Modules/getaddrinfo.c:376: `EAI_PROTOCOL' undeclared (first use in this function) Modules/getaddrinfo.c:464: `AI_NUMERICHOST' undeclared (first use in this function) ./Modules/socketmodule.c: In function `PySocketSock_init': ./Modules/socketmodule.c:1818: warning: function declaration isn't a prototype ./Modules/socketmodule.c: In function `PySocket_fromfd': ./Modules/socketmodule.c:2304: warning: function declaration isn't a prototype gmake: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-06 11:05 Message: Logged In: YES user_id=21627 Fixed with addrinfo.h 1.4. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-01 10:50 Message: Logged In: YES user_id=85984 Martin, I appreciate your help with this, as the socket module is a crucial one on this particular server, and I'd like to be able to upgrade to 2.2 when it is released. If you are finding it difficult to work on this problem by taking guesses, I could make you a temporary account on the server if you think it would help. If so, attach/send me your SSH public key or some other method of getting the account information to you securely (GPG/PGP public key, etc.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-01 10:46 Message: Logged In: YES user_id=85984 Still no luck after applying the patch unfortunately. sclp3:~/temp/Python-2.2b2/Modules> patch < ../../gai.diff patching file `addrinfo.h' patching file `getaddrinfo.c' sclp3:~/temp/Python-2.2b2> gmake /bin/sh ./Modules/makesetup -c ./Modules/config.c.in \ -s Modules \ Modules/Setup.config \ Modules/Setup.local \ Modules/Setup The Makefile was updated, you may need to re-run make. gcc -D_HAVE_BSDI -c -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -o Modules/config.o Modules/config.c In file included from Include/pyport.h:93, from Include/Python.h:60, from Modules/config.c:19: /usr/include/math.h:177: warning: function declaration isn't a prototype /usr/include/math.h:257: warning: function declaration isn't a prototype In file included from Include/unicodeobject.h:118, from Include/Python.h:69, from Modules/config.c:19: /usr/include/wchar.h:15: warning: function declaration isn't a prototype gcc -D_HAVE_BSDI -c -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -DPYTHONPATH='":plat-bsdos4:lib-tk"' \ -DPREFIX='"/usr/local"' \ -DEXEC_PREFIX='"/usr/local"' \ -DVERSION='"2.2"' \ -DVPATH='""' \ -o Modules/getpath.o ./Modules/getpath.c In file included from Include/pyport.h:93, from Include/Python.h:60, from ./Modules/getpath.c:3: /usr/include/math.h:177: warning: function declaration isn't a prototype /usr/include/math.h:257: warning: function declaration isn't a prototype In file included from Include/unicodeobject.h:118, from Include/Python.h:69, from ./Modules/getpath.c:3: /usr/include/wchar.h:15: warning: function declaration isn't a prototype gcc -D_HAVE_BSDI -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from Include/pyport.h:93, from Include/Python.h:60, from ./Modules/socketmodule.c:78: /usr/include/math.h:177: warning: function declaration isn't a prototype /usr/include/math.h:257: warning: function declaration isn't a prototype In file included from Include/unicodeobject.h:118, from Include/Python.h:69, from ./Modules/socketmodule.c:78: /usr/include/wchar.h:15: warning: function declaration isn't a prototype In file included from /usr/include/signal.h:46, from ./Modules/socketmodule.c:140: /usr/include/sys/signal.h:121: warning: function declaration isn't a prototype /usr/include/sys/signal.h:164: warning: function declaration isn't a prototype In file included from ./Modules/socketmodule.c:236: Modules/getaddrinfo.c:203: conflicting types for `gai_strerror' /usr/include/netdb.h:172: previous declaration of `gai_strerror' ./Modules/socketmodule.c: In function `PySocketSock_init': ./Modules/socketmodule.c:1818: warning: function declaration isn't a prototype ./Modules/socketmodule.c: In function `PySocket_fromfd': ./Modules/socketmodule.c:2304: warning: function declaration isn't a prototype gmake: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-01 01:28 Message: Logged In: YES user_id=21627 Thanks, I'm now giving up on getting the C library getaddrinfo to work on your system (I have no idea why it would fail in this place). Instead, I made the patch gai.diff, which should allow compilation of getaddrinfo.c on your system. Please report whether it works. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-11-30 08:24 Message: Logged In: YES user_id=85984 % gcc -o aicheck2 aicheck2.c % ./aicheck2 fail 11 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 01:35 Message: Logged In: YES user_id=21627 Arrghh. I was trying to find out which of the tests fail, but attached the wrong version of the file: I meant to put printfs into each failure. Please try aicheck2.c instead. Anyway, it seems that your system is indeed one of those where the test should find out problems with the C library (unless the test that fails is bogus, which we can investigate once we know what it is that fails). I'll try to come up with a patch that allows usage of the getaddrinfo emulation even on systems where getaddrinfo is in the C library. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-11-29 18:18 Message: Logged In: YES user_id=85984 aicheck.c compiled without problem on my system. % gcc -o aicheck aicheck.c % Running the resulting binary produces no output. I'm not exactly sure what kind of output you are looking for (taking a guess): % gdb /home/jason/temp/aicheck GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-bsdi4.0), Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)... (gdb) run Starting program: /home/jason/temp/aicheck (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Program exited with code 01. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-29 15:51 Message: Logged In: YES user_id=21627 Thansk for the files. I now trying to figure out why Python refuses to use the getaddrinfo implementation in your C library. It may be that it is really broken, in which case we must make getaddrinfo.c work correctly. Perhaps it ought to work,and configure just fails to correctly see that. So please compile the attached file aicheck.c on your system, and report output and status code (looking at $?); if it fails to compile, report the compile errors. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-11-28 12:21 Message: Logged In: YES user_id=85984 Attached are three files: - pyconfig.h from a fresh gcc 2.7.2.1 build - config.log from a fresh gcc 2.7.2.1 build - /usr/include/netdb.h - the getaddrinfo manual page from my system Indeed, EAI_ADDRFAMILY is defined in /usr/include/netdb.h, but EAI_MAX is not. Let me know if I can provide any more information. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-28 01:30 Message: Logged In: YES user_id=21627 Ok, then we need to investigate the configure results. Can you please attach pyconfig.h and config.log to this report? Also, can you please confirm that you build Python from scratch with 2.7.2.1 (i.e untarring a fresh source tree, to avoid using a config.cache left over from gcc 2.95.2)? Furthermore, can you please report details of the getaddrinfo implementation on your system? Does it provide one? In the C library? If not, can you confirm that EAI_ADDRFAMILY is defined in your system headers, but EAI_MAX is not? If yes, can you speculate as to why configure thinks your system does not have getaddrinfo? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-11-27 15:21 Message: Logged In: YES user_id=85984 I probably should have included the output from gcc 2.7.2.1 instead which I know is properly installed. The results are similar, although there is no mention of `wint_t': % gmake gcc -D_HAVE_BSDI -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from Include/pyport.h:93, from Include/Python.h:60, from ./Modules/socketmodule.c:78: /usr/include/math.h:177: warning: function declaration isn't a prototype /usr/include/math.h:257: warning: function declaration isn't a prototype In file included from Include/unicodeobject.h:118, from Include/Python.h:69, from ./Modules/socketmodule.c:78: /usr/include/wchar.h:15: warning: function declaration isn't a prototype In file included from /usr/include/signal.h:46, from ./Modules/socketmodule.c:140: /usr/include/sys/signal.h:121: warning: function declaration isn't a prototype /usr/include/sys/signal.h:164: warning: function declaration isn't a prototype Modules/getaddrinfo.c: In function `gai_strerror': In file included from ./Modules/socketmodule.c:236: Modules/getaddrinfo.c:205: `EAI_MAX' undeclared (first use this function) Modules/getaddrinfo.c:205: (Each undeclared identifier is reported only once Modules/getaddrinfo.c:205: for each function it appears in.) Modules/getaddrinfo.c: In function `getaddrinfo': Modules/getaddrinfo.c:285: `EAI_BADHINTS' undeclared (first use this function) Modules/getaddrinfo.c:286: `AI_MASK' undeclared (first use this function) Modules/getaddrinfo.c:376: `EAI_PROTOCOL' undeclared (first use this function) Modules/getaddrinfo.c:464: `AI_NUMERICHOST' undeclared (first use this function) ./Modules/socketmodule.c: In function `PySocketSock_init': ./Modules/socketmodule.c:1818: warning: function declaration isn't a prototype ./Modules/socketmodule.c: In function `PySocket_fromfd': ./Modules/socketmodule.c:2304: warning: function declaration isn't a prototype gmake: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-27 15:08 Message: Logged In: YES user_id=21627 Are you sure the compiler is properly installed? That you have wint_t definition both in wchar.h and stddef.h (as fixincluded by gcc) is not Python's doing; either the header files of your operating system are corrupt, or the compiler is broken. If you cannot figure out the details, please attach both header files to this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:07 Message: Logged In: YES user_id=31435 Assigned to Martin. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486099&group_id=5470 From noreply@sourceforge.net Thu Dec 6 19:38:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 11:38:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-417634 ] configuring without C++ compiler name Message-ID: Bugs item #417634, was opened at 2001-04-20 07:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417634&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Michael Hudson (mwh) Summary: configuring without C++ compiler name Initial Comment: If you check out a clean copy of Python 2.1 on a Solaris 5.8 machine, and run: ./configure -with-cxx rather than: ./configure -with-cxx=g++ It generates a makefile with "CXX=yes", so "make" produces: bash-2.03$ make yes -c -g -O2 -Wall -Wstrict-prototypes -I. \ -I./Include -DHAVE_CONFIG_H \ -o Modules/ccpython.o \ ./Modules/ccpython.cc make: yes: Command not found ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 11:38 Message: Logged In: YES user_id=6380 Where's the attached fix? Back to MWH. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-06 09:31 Message: Logged In: YES user_id=6656 Two options: (1) apply the braindead fix I've just attached (2) ignore the problem and close the report. I don't really have an opinion on which is better. An autoconf guru may have a better idea, but it hardly seems worth putting too much effort into. Assigned to Guido for a quick decision -- please don't think too hard about it! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417634&group_id=5470 From noreply@sourceforge.net Thu Dec 6 20:04:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 12:04:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-489671 ] memory leak in test_richcmp Message-ID: Bugs item #489671, was opened at 2001-12-05 18:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489671&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Guido van Rossum (gvanrossum) Summary: memory leak in test_richcmp Initial Comment: leak when running test_richcmp see attached file for details ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-06 07:56 Message: Logged In: YES user_id=31392 It's specifically the testvector() function that causes the leak in test_richcmp. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489671&group_id=5470 From noreply@sourceforge.net Thu Dec 6 20:04:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 12:04:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-489669 ] memory leak in test_descr (unicode) Message-ID: Bugs item #489669, was opened at 2001-12-05 18:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489669&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Guido van Rossum (gvanrossum) Summary: memory leak in test_descr (unicode) Initial Comment: leak from unicode object when running test_descr may be related to bug "memory leak in test_unicode" see attached file for details ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 12:04 Message: Logged In: YES user_id=6380 Thanks, Marc-Andre! That was it. Fixed in unicodeobject.c rev. 2.124. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-06 08:43 Message: Logged In: YES user_id=38388 Could be the PyUnicode_CheckExact() test in unicode_dealloc() which is triggering this behaviour. It seems that for subclassed types, there is no chance for the various DECREFs in that code to get executed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 08:26 Message: Logged In: YES user_id=6380 If we call the constructor like U(u"xxxxxxxxxx") instead, it leaks faster. With a really large unicode string argument, it leaks fenomenally fast. Using debug mode and printing the remaining objects at the end by setting $PYTHONDUMPREFS=y doesn't reveal any leaked objects. So it's leaking a copy of the Unicode data. I'll look into it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 08:12 Message: Logged In: YES user_id=6380 This is still there. The leak is in buffer_inherit(). It can be reduced to: | while 1: | class U(unicode): | pass | U() ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 06:11 Message: Logged In: YES user_id=6380 I may or may not have fixed this through plugging a leak in ceval.c. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489669&group_id=5470 From noreply@sourceforge.net Thu Dec 6 20:15:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 12:15:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-489052 ] define NDEBUG for release builds Message-ID: Bugs item #489052, was opened at 2001-12-04 12:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489052&group_id=5470 Category: Build Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Tim Peters (tim_one) Summary: define NDEBUG for release builds Initial Comment: NDEBUG should be defined on the command line during release builds of Python, so that assert() statements go away. We tried defining it in Python.h, but that interferes with extensions linking Python.h (and created real problems for Robin Dunn). The Windows build already does this. The Linux build needs it, and assigned to Fred for that part. Fred, please assign to jackjansen when you're done, so he can consider the Mac build. Any other build need special treatment? ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-06 12:15 Message: Logged In: YES user_id=31435 Thanks, Jack. I'm closing this now. If the BeOS or OS2 maintainters exist, they're welcome to identify themselves . BTW, are you sure you wanted to #define NDEBUG in header files on the Mac? The thrust of the bug report was to get rid of that very practice on Linux. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-05 15:02 Message: Logged In: YES user_id=45365 Fixed for MacPython. Assigning it back to Tim, I don't know whether the other maintainers (like for BeOS or OS2) need to be informed of this too. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-04 12:56 Message: Logged In: YES user_id=3066 The Unix portion of this is fixed in configure.in revision 1.284. Passing to Jack for Mac OS magic. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489052&group_id=5470 From noreply@sourceforge.net Thu Dec 6 20:23:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 12:23:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-489872 ] PyString_FromString(NULL) seg faults Message-ID: Bugs item #489872, was opened at 2001-12-06 07:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489872&group_id=5470 >Category: Documentation Group: Feature Request >Status: Open Resolution: Rejected Priority: 5 Submitted By: John Merritt (jmerritt5) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PyString_FromString(NULL) seg faults Initial Comment: Python 1.5.4 and Python 2.0.1, the only two I have installed, produce a segmentation violation when a NULL is passed to, at least, PyString_FromString. The solution is to check the argument and return Py_None. I saw in FAQ (wizard) 8.16 that you should return Py_Build(""), but, on Python 1.5.4, I don't have Py_Build. I use SWIG 1.3.*, and I have modified my version of SWIG to generate code to check the arguement prior to calling PyString_FromString. if (result == NULL) return Py_None; resultobj = PyString_FromString(result); return resultobj; This works like a charm. John ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-06 12:23 Message: Logged In: YES user_id=31435 Reopened, changed to Doc, and assigned to Fred: the PyString_FromString docs (C API ref man) should say that NULL isn't allowed. Since NULL *is* allowed for the related PyString_FromStringAndSize, it's not obvious that PyString_FromString is more restrictive. Note to John: your workaround code needs to Py_INCREF (Py_None) before returning it. Take this seriously . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 08:08 Message: Logged In: YES user_id=6380 I'm rejecting the feature request. This would unnecessarily slow it down. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 07:51 Message: Logged In: YES user_id=3066 The FAQ should refer to Py_BuildValue() instead of Py_Build(); I've fixed that in the FAQ. I'm not sure that PyString_FromString() should return None if passed NULL; I'd expect a separate call about be appropriate for that behavior. It would not be unreasonable for PyString_FromString() to check for NULL and raise a SystemError though. Categorizing as a feature request. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 07:38 Message: Logged In: YES user_id=6380 Where in the docs does it say that you're allowed to pass NULL to PyString_FromString()? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489872&group_id=5470 From noreply@sourceforge.net Thu Dec 6 20:29:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 12:29:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-485145 ] memory leak in test_unicode Message-ID: Bugs item #485145, was opened at 2001-11-24 10:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485145&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Barry Warsaw (bwarsaw) Summary: memory leak in test_unicode Initial Comment: test_unicode leaks memory see attached file for details ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2001-12-06 12:29 Message: Logged In: YES user_id=33168 This leak was plugged with the unicode fix for #489669 "memory leak in test_descr (unicode)" ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-06 04:03 Message: Logged In: YES user_id=38388 Indeed, if I comment out the section "Testing builtin unicode()..." the leak goes away. Barry, that's where you should start looking ! ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-06 03:39 Message: Logged In: YES user_id=38388 I've done some tests and found that the leaks have to be somewhere in test_unicode.py below the line "Testing builtin unicode()...". Since the code immediately below that line uses type subclassing I guess that the new type system could have something to do with the leakage. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-06 01:02 Message: Logged In: YES user_id=38388 Note that the "leak" could be caused the fact that Unicode shares length 1 Unicode strings in the Latin-1 range. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:05 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485145&group_id=5470 From noreply@sourceforge.net Thu Dec 6 20:31:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 12:31:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-489671 ] memory leak in test_richcmp Message-ID: Bugs item #489671, was opened at 2001-12-05 18:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489671&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Guido van Rossum (gvanrossum) Summary: memory leak in test_richcmp Initial Comment: leak when running test_richcmp see attached file for details ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 12:31 Message: Logged In: YES user_id=6380 Boiled down to this test case: | class C: # new-style class leaks too | | def foo(self): | (self, 1/0) # This leaks | 1/0 # This doesn't | | while 1: | a = C() | try: | a.foo() # This leaks | (a, 1/0) # This doesn't | except: | pass ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-06 07:56 Message: Logged In: YES user_id=31392 It's specifically the testvector() function that causes the leak in test_richcmp. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489671&group_id=5470 From noreply@sourceforge.net Thu Dec 6 20:32:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 12:32:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-483789 ] another *? greedy bug Message-ID: Bugs item #483789, was opened at 2001-11-20 06:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=483789&group_id=5470 Category: Regular Expressions Group: Python 2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Bastian Kleineidam (calvin) Assigned to: Fredrik Lundh (effbot) Summary: another *? greedy bug Initial Comment: Hm, it took me one hour debugging until I reached the regex level of my application :) Python 2.2b2 (#26, Nov 16 2001, 11:44:11) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> re.search(r"a[^>]*?b", "a>b") ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=483789&group_id=5470 From noreply@sourceforge.net Thu Dec 6 20:38:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 12:38:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-489872 ] PyString_FromString(NULL) seg faults Message-ID: Bugs item #489872, was opened at 2001-12-06 07:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489872&group_id=5470 Category: Documentation >Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John Merritt (jmerritt5) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PyString_FromString(NULL) seg faults Initial Comment: Python 1.5.4 and Python 2.0.1, the only two I have installed, produce a segmentation violation when a NULL is passed to, at least, PyString_FromString. The solution is to check the argument and return Py_None. I saw in FAQ (wizard) 8.16 that you should return Py_Build(""), but, on Python 1.5.4, I don't have Py_Build. I use SWIG 1.3.*, and I have modified my version of SWIG to generate code to check the arguement prior to calling PyString_FromString. if (result == NULL) return Py_None; resultobj = PyString_FromString(result); return resultobj; This works like a charm. John ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 12:38 Message: Logged In: YES user_id=3066 Documentation updated in Doc/api/concrete.tex revision 1.4 and Doc/api/api.tex revision 1.117.2.11. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 12:23 Message: Logged In: YES user_id=31435 Reopened, changed to Doc, and assigned to Fred: the PyString_FromString docs (C API ref man) should say that NULL isn't allowed. Since NULL *is* allowed for the related PyString_FromStringAndSize, it's not obvious that PyString_FromString is more restrictive. Note to John: your workaround code needs to Py_INCREF (Py_None) before returning it. Take this seriously . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 08:08 Message: Logged In: YES user_id=6380 I'm rejecting the feature request. This would unnecessarily slow it down. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 07:51 Message: Logged In: YES user_id=3066 The FAQ should refer to Py_BuildValue() instead of Py_Build(); I've fixed that in the FAQ. I'm not sure that PyString_FromString() should return None if passed NULL; I'd expect a separate call about be appropriate for that behavior. It would not be unreasonable for PyString_FromString() to check for NULL and raise a SystemError though. Categorizing as a feature request. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 07:38 Message: Logged In: YES user_id=6380 Where in the docs does it say that you're allowed to pass NULL to PyString_FromString()? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489872&group_id=5470 From noreply@sourceforge.net Thu Dec 6 20:43:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 12:43:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-410993 ] linuxaudiodev fails during "make test". Message-ID: Bugs item #410993, was opened at 2001-03-24 02:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410993&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: Accepted Priority: 4 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) >Summary: linuxaudiodev fails during "make test". Initial Comment: Picked up 2.1b2 and did "./configure" and "make test" on a RedHat 7.0-based system: test test_linuxaudiodev crashed -- linuxaudiodev.error: (11, 'Resource temporarily unavailable') Was running build as root, and "mpg123" runs successfully before and after. This is on a ThinkPad 240 with esssolo1 driver with 2.2.18 kernel. Sean ---------------------------------------------------------------------- >Comment By: Charles G Waldman (cgw) Date: 2001-12-06 12:43 Message: Logged In: YES user_id=7151 Please see patch #489989 and the comments attached there. I have submitted a patch with the minimal fix. The reason this took so long was that I started working on a complete replacement for the audio output modules, which would detect ALSA/OSS/esd/etc, then I discovered the "libao" audio output library which does this. I think that any future work on an audio module for Python should just wrap libao. Patch 489989 can't do any harm, and it might help. ---------------------------------------------------------------------- Comment By: Charles G Waldman (cgw) Date: 2001-09-05 11:36 Message: Logged In: YES user_id=7151 I've been out of town and somewhat out of the loop. But I'm back now. I will look into this over the weekend. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 10:56 Message: Logged In: YES user_id=6380 Charles, are you still interested in tackling this bug? If not, let us know! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-10 21:27 Message: Logged In: YES user_id=6380 We've gone back and forth over this one. It seems to happen for certain drivers for certain audio cards -- the problem has disappeared for most folks, but still works for some hardware (e.g. some Dell laptops running Mandrake). I've assigned this to Charles Waldman since he seems to know this area; he commented in python-dev that the initialization order is invalid. Charles if you still feel you won't touch this module (because you'd rather give us a new module that does the right thing), please close it as Won't Fix -- that's what I almost did until I remembered your interest. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-11 09:36 Message: Logged In: YES user_id=6380 I think you misread his comment. He wasn't mpg123 *during* the test, he ran it before and after the test to verify that in fact his audio was in good working order. But, I do suggest to him to try the CVS version, which is one (relevant) fix ahead of 2.1b2. That version passes the test for me, but I don't hear a thing, so I'm not sure what's going on... ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-04-11 07:19 Message: Logged In: YES user_id=31392 I think we should report this failure as "test skipped." I think it would be essentially correct: The test was skipped because the device was in use. It's not a crash. Not sure how this test is affected by the recent changes to the module to handle EAGAIN. Sean or Guido-- can you try it with the updated module? My Linux audio config is screwed up. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410993&group_id=5470 From noreply@sourceforge.net Thu Dec 6 20:47:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 12:47:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-482460 ] dumbdbm fails to overwrite existing key Message-ID: Bugs item #482460, was opened at 2001-11-16 05:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482460&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None >Priority: 4 Submitted By: Michael McCandless (mikemccand) >Assigned to: Skip Montanaro (montanaro) Summary: dumbdbm fails to overwrite existing key Initial Comment: Here's a simple test case that shows the bug: import dumbdbm db = dumbdbm.open('db', 'c') db['1'] = 'hello' db['1'] = 'hello2' db.close() db = dumbdbm.open('db', 'c') print db['1'] db.close() This prints out 'hello' but should print out 'hello2'. As far as I can tell, this bug did not exist 1.5.2, but then appeared in 2.0 and is still present in 2.2b1. The problem is, when overwriting the key, dumbdbm fails to update the .dir file. I believe this patch fixes the bug: > diff -c Lib/dumbdbm.py Lib/dumbdbm.py.new *** Lib/dumbdbm.py Tue Sep 4 15:14:13 2001 --- Lib/dumbdbm.py.new Fri Nov 16 08:16:42 2001 *************** *** 124,129 **** --- 124,132 ---- else: pos, siz = self._addval(val) self._index[key] = pos, siz + tup = (pos, siz) + if self._index[key] != tup: + self._addkey(key, tup) def __delitem__(self, key): del self._index[key] ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 12:47 Message: Logged In: YES user_id=3066 Assigned to Skip since he's shown an interest. ;-) Just use your judgement, Skip; I've lowered the priority since performance and space savings just aren't important for dumbdbm. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-11-16 08:16 Message: Logged In: YES user_id=44345 Performance isn't a big issue with dumbdbm, so I think the code should be as simple as possible. I have a local version I was working on a bit. I simply delete then add in __setitem__: def __setitem__(self, key, val): if not type(key) == type('') == type(val): raise TypeError, "keys and values must be strings" if self._index.has_key(key): del self[key] (pos, siz) = self._addval(val) self._addkey(key, (pos, siz)) I also have code in my local version to reuse space though. I also want to add file locking (which is the motivation for me to be fiddling with this stuff). ---------------------------------------------------------------------- Comment By: Michael McCandless (mikemccand) Date: 2001-11-16 05:38 Message: Logged In: YES user_id=323786 Sorry -- that previous patch does not work. I believe this one does: > diff -c Lib/dumbdbm.py Lib/dumbdbm.py.new *** Lib/dumbdbm.py Fri Nov 16 08:36:36 2001 --- Lib/dumbdbm.py.new Fri Nov 16 08:36:50 2001 *************** *** 116,121 **** --- 116,122 ---- self._addkey(key, (pos, siz)) else: pos, siz = self._index[key] + startTup = (pos, siz) oldblocks = (siz + _BLOCKSIZE - 1) / _BLOCKSIZE newblocks = (len(val) + _BLOCKSIZE - 1) / _BLOCKSIZE if newblocks <= oldblocks: *************** *** 124,129 **** --- 125,133 ---- else: pos, siz = self._addval(val) self._index[key] = pos, siz + tup = (pos, siz) + if startTup != tup: + self._addkey(key, tup) def __delitem__(self, key): del self._index[key] ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482460&group_id=5470 From noreply@sourceforge.net Thu Dec 6 20:52:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 12:52:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-451285 ] distutils ignores environment variables Message-ID: Bugs item #451285, was opened at 2001-08-15 12:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451285&group_id=5470 Category: Distutils Group: Platform-specific >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Thomas Heller (theller) Summary: distutils ignores environment variables Initial Comment: Visual C++ 6.0 sets up environment variables for use by command-line users -- MSDEVDIR, INCLUDE, LIB. It also provides VCVARS32.BAT to set these environment variables. They specify where to find cl.exe and its header files and libraries. distutils ignores those in favor of the registry. I think distutils should honor the environment variables if they are set. In my case, the registry was pointing to an old, removed install of VC. I later installed a new version in a new location, but that install did not modify the registry. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2001-12-06 12:52 Message: Logged In: YES user_id=11105 Jeremy is the only one having this problem, and he had a broken setup, so I'll mark this as won't fix and close it. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-12-06 08:38 Message: Logged In: YES user_id=11375 As a Unix guy, I have no idea whether this is worth doing, though it certainly seems reasonable to check for the environment variables and use them if present. Thomas, you actually develop for Windows so I'll leave the decision up to you. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-05 12:37 Message: Logged In: YES user_id=31435 It would be a reasonable feature request to honor envars if the registry info wasn't found. This wouldn't have helped Jeremy, but so it goes (the 2nd time he installed MSVC, he didn't install the IDE, and that's why the registry didn't get updated; and he didn't properly uninstall his old MSVC either, which is why the stale registry entries didn't get removed -- and this combination of wrong turns has to be as rare as a Unix guy trying to build something on Windows ). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-09-05 12:05 Message: Logged In: YES user_id=11105 I'm unsure what to do. On one hand, this request makes sense, on the other hand, environment vars are IMO much more fragile than registry entries. I'll assign this to the current distutils maintainer to decide what to do. Or should it be marked as feature request? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-15 12:49 Message: Logged In: YES user_id=31435 Jeremy, do you know how to run regedit? It's a GUI registry browser. Do Start -> Run and type "regedit" (no quotes) then click OK. I want you to navigate to two places: HKEY_LOCAL_MACHINE\ Software\ Microsoft\ Devstudio\ 6.0\ Build System\ and exactly the same except starting at HKEY_CURRENT_USER instead. My *bet* is that you're going to find that path in both places, but that under HKEY_LOCAL_MACHINE it's pointing to a wrong place. This would be a side-effect of not having properly uninstalled your previous MSVC. If that's all true, select the DevStudio node under HKEY_LOCAL_MACHINE and then do Edit->Delete. This will get rid of the obsolete registry setting. Close regedit then. disutils *should* look under HKEY_CURRENT_USER before looking under HKEY_LOCAL_MACHINE, because per-user settings are suppused to take precedence over per-machine settings, and especially under Win2K. That appears to be a repeated buglet in msvccompiler.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451285&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:12:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:12:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-482460 ] dumbdbm fails to overwrite existing key Message-ID: Bugs item #482460, was opened at 2001-11-16 05:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482460&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 4 Submitted By: Michael McCandless (mikemccand) Assigned to: Skip Montanaro (montanaro) Summary: dumbdbm fails to overwrite existing key Initial Comment: Here's a simple test case that shows the bug: import dumbdbm db = dumbdbm.open('db', 'c') db['1'] = 'hello' db['1'] = 'hello2' db.close() db = dumbdbm.open('db', 'c') print db['1'] db.close() This prints out 'hello' but should print out 'hello2'. As far as I can tell, this bug did not exist 1.5.2, but then appeared in 2.0 and is still present in 2.2b1. The problem is, when overwriting the key, dumbdbm fails to update the .dir file. I believe this patch fixes the bug: > diff -c Lib/dumbdbm.py Lib/dumbdbm.py.new *** Lib/dumbdbm.py Tue Sep 4 15:14:13 2001 --- Lib/dumbdbm.py.new Fri Nov 16 08:16:42 2001 *************** *** 124,129 **** --- 124,132 ---- else: pos, siz = self._addval(val) self._index[key] = pos, siz + tup = (pos, siz) + if self._index[key] != tup: + self._addkey(key, tup) def __delitem__(self, key): del self._index[key] ---------------------------------------------------------------------- >Comment By: Michael McCandless (mikemccand) Date: 2001-12-06 13:12 Message: Logged In: YES user_id=323786 Please note that this bug is not just a performance issue -- dumbdbm fails to save data for certain keys, even when it's used entirely normally. The different proposed fixes, however, have different performance characteristics ... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 12:47 Message: Logged In: YES user_id=3066 Assigned to Skip since he's shown an interest. ;-) Just use your judgement, Skip; I've lowered the priority since performance and space savings just aren't important for dumbdbm. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-11-16 08:16 Message: Logged In: YES user_id=44345 Performance isn't a big issue with dumbdbm, so I think the code should be as simple as possible. I have a local version I was working on a bit. I simply delete then add in __setitem__: def __setitem__(self, key, val): if not type(key) == type('') == type(val): raise TypeError, "keys and values must be strings" if self._index.has_key(key): del self[key] (pos, siz) = self._addval(val) self._addkey(key, (pos, siz)) I also have code in my local version to reuse space though. I also want to add file locking (which is the motivation for me to be fiddling with this stuff). ---------------------------------------------------------------------- Comment By: Michael McCandless (mikemccand) Date: 2001-11-16 05:38 Message: Logged In: YES user_id=323786 Sorry -- that previous patch does not work. I believe this one does: > diff -c Lib/dumbdbm.py Lib/dumbdbm.py.new *** Lib/dumbdbm.py Fri Nov 16 08:36:36 2001 --- Lib/dumbdbm.py.new Fri Nov 16 08:36:50 2001 *************** *** 116,121 **** --- 116,122 ---- self._addkey(key, (pos, siz)) else: pos, siz = self._index[key] + startTup = (pos, siz) oldblocks = (siz + _BLOCKSIZE - 1) / _BLOCKSIZE newblocks = (len(val) + _BLOCKSIZE - 1) / _BLOCKSIZE if newblocks <= oldblocks: *************** *** 124,129 **** --- 125,133 ---- else: pos, siz = self._addval(val) self._index[key] = pos, siz + tup = (pos, siz) + if startTup != tup: + self._addkey(key, tup) def __delitem__(self, key): del self._index[key] ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482460&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:14:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:14:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-453515 ] filecmp.dircmp case sensitivity bug Message-ID: Bugs item #453515, was opened at 2001-08-20 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453515&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Rik Kabel (ving) Assigned to: Nobody/Anonymous (nobody) Summary: filecmp.dircmp case sensitivity bug Initial Comment: (warning: python newbie submission) Platforms: W2K w/Activestate 2.1.1 (same library source found in 2.0 and 2.11 on NetBSD). filecmp.dircmp performs incorrect filename comparisons when building lists of common and directory-unique files. In particular, it sets a dictionary key to the filename (and value to 1) for each file in the right-hand tree, and looks for matching names (has_key). This fails on case-insensitive platforms when the names are equivalent except for case. A simple workaround would be to use os.path.normcase() around the filenames before storing and comparing, but this is not case-preserving. Case preservation is to be preferred. A case-preserving workaround might use os.path.normcase() for the dictionary entry keys, but store the unchanged filename as the value, and use that value when constructing the list from the dictionary. -- Rik creating tomorrow's legacy systems, today ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 13:14 Message: Logged In: YES user_id=3066 I've attached a preliminary patch for this, completely untested. Problems: - We don't have any tests for the filecmp module. - Im not running Windows, so I can't test this in an environment similar to that for which the bug was reported. If someone can create a test case for this, and test the patch, that would really help. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 11:12 Message: Logged In: YES user_id=6380 While this was reported as an ActivePython bug, the problem is the same with filecmp.py in CVS, so I'm unassigning this from Paul (it's not like Paul's track record of responding to bug reports is so great :-). ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-08-28 08:34 Message: Logged In: YES user_id=31392 Can you look at this, Paul? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453515&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:28:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:28:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-489671 ] memory leak in test_richcmp Message-ID: Bugs item #489671, was opened at 2001-12-05 18:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489671&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Guido van Rossum (gvanrossum) Summary: memory leak in test_richcmp Initial Comment: leak when running test_richcmp see attached file for details ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 13:28 Message: Logged In: YES user_id=6380 Further boiled it down to this testcase: | def bar(a): | a + (1/0) | | while 1: | try: | bar([]) | except: | pass Apparently the stack is not cleared properly when an exception happens with something on the stack. [...] After a debug session with Tim and some CVS digging, I realized that in the pre-generators days, there was a little loop clearing the stack after the /* main loop */ comment, that's no longer there. Turns out in Neil's generators patch had commented this code out, and the merge completely removed it -- but it was needed and the proper solution is to execute this code EXCEPT when yielding from a generator. Much thanks to Tim for his help in finding this! This is fixed in ceval.c 2.296. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 12:31 Message: Logged In: YES user_id=6380 Boiled down to this test case: | class C: # new-style class leaks too | | def foo(self): | (self, 1/0) # This leaks | 1/0 # This doesn't | | while 1: | a = C() | try: | a.foo() # This leaks | (a, 1/0) # This doesn't | except: | pass ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-06 07:56 Message: Logged In: YES user_id=31392 It's specifically the testvector() function that causes the leak in test_richcmp. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489671&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:32:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:32:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-486530 ] replace sprintf with PyOS_snprintf Message-ID: Bugs item #486530, was opened at 2001-11-28 09:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486530&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Guido van Rossum (gvanrossum) Summary: replace sprintf with PyOS_snprintf Initial Comment: Some or all of the sprintf calls we make are vulnerable to buffer overflows. A few of these calls use stack-allocated buffers, which are real security problems. MAL has fixed three of them, but if we're going to fix any we need to fix them all. We'll try to finish this task as soon as possible. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 13:32 Message: Logged In: YES user_id=6380 I'm calling this a resounding success. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-05 15:28 Message: Logged In: YES user_id=45365 The Mac files are either fixed or confirmed harmless, with one exception, Compat/getcwd.c. But this one is not really part of Python, so using PyOS_snprintf might not be a good idea, and in Python's use cases it seems harmless. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-03 13:24 Message: Logged In: YES user_id=31435 Reassigned this to Jack. The list Guido gave was derived from a list I gave him, and it didn't include any files under the Mac directory: C:\Code\python\Mac>findstr /m /s sprintf *.c compat\getwd.c modules\calldll.c modules\macfsmodule.c modules\cf\_cfmodule.c modules\ctl\_ctlmodule.c modules\win\_winmodule.c modules\hfsplusmodule.c python\macimport.c ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-03 13:10 Message: Logged In: YES user_id=6380 Most of this is done. There are a few cases left, some intentionally (and carefully analyzed). I won't close it yet, but I see no need for the high priority now. sprintf is still used in: drawfmodule.c (RISCOS\Modules) -- unsafe, only affects one platform getbuildinfo.c (Modules) -- safe getnameinfo.c (Modules) -- safe grammar1.c (Parser) -- safe mactoolboxglue.c (Python) -- safe stringobject.c (Objects) -- safe strtod.c (Python) -- probably safe; AFAICT this file is unused (?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486530&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:40:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:40:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-459705 ] always return 0 command status Message-ID: Bugs item #459705, was opened at 2001-09-07 18:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459705&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) >Assigned to: Nobody/Anonymous (nobody) Summary: always return 0 command status Initial Comment: Context: Python 2.1.1 Description: Python's setup.py build script always return 0 status, without regard to failures. Looking more closely at the problem, it seems that the function distutils.core.setup() has no means of effectively returning to the caller its execution status, and no exception is raised when an extension fails to build. This prevents integration of setup.py programs in scripts (ksh...) or Makefiles which rely on testing the command exit status... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459705&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:40:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:40:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-409430 ] pydoc install broken Message-ID: Bugs item #409430, was opened at 2001-03-17 10:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409430&group_id=5470 Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Nobody/Anonymous (nobody) Summary: pydoc install broken Initial Comment: I've moaned about this on python-dev but I want to make sure it doesn't get forgotten. I've just built from CVS, installed in /usr/local, and: $ pydoc -g Traceback (most recent call last): File "/usr/local/bin/pydoc", line 3, in ? import pydoc ImportError: No module named pydoc because the /usr/bin/env python thing hits the older python in /usr first. Don't really know how best to implement this, not being a distutils whiz. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-11 07:40 Message: Logged In: YES user_id=6656 Oops, not paying attention. Revision 1.9 of Lib/distutils/command/build_scripts.py seemed to be aimed at fixing this; however, I now have a ~/bin/pydoc that starts: #!python which isn't too helpful. This command either needs to do something different when building Python, or a different command needs to be used to install the pydoc script. Or you could wedge the install path into sys.executable in setup.py, I suppose. Assigned to Greg, as I don't think he's had this patch yet. Also bumped priority, as we now seem to be installing decidely broken scripts, and changed summary. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-10 21:56 Message: Logged In: NO I am having similar problems with the win 2.1 ver it seems none of my saved .py files are recognised. Is this simply a case of not configed as an executable or a version clash? (solutions as well as opinions would be nice) I can however import string,sys and other modules if that muddies the water any. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 12:11 Message: Logged In: YES user_id=6380 OK, ping-pong. Ping, do you have any bright ideas? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-04-10 10:57 Message: Logged In: YES user_id=11375 The pydoc script is Ping's, really. Fixing this requires Distutils hackery, and I don't see that this is worth fixing. Leaving it to someone else to make the decision to close it, though. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-17 22:23 Message: Logged In: YES user_id=31435 Assigned to Andrew because I seem to recall he wrote the pydoc script. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409430&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:41:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:41:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-413144 ] sdist can't create empty directories Message-ID: Bugs item #413144, was opened at 2001-04-02 08:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=413144&group_id=5470 Category: Distutils Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) >Assigned to: Nobody/Anonymous (nobody) Summary: sdist can't create empty directories Initial Comment: If a file fails an os.path.isfile() check, sdist.py skips it and prints a warning. That's probably worth loosening so an empty directory can be created in a source distribution by listing it in the MANIFEST. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=413144&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:41:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:41:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-454086 ] distutils/mingw32 links to dbg libs Message-ID: Bugs item #454086, was opened at 2001-08-21 21:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454086&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 7 Submitted By: Gerhard Häring (ghaering) >Assigned to: Nobody/Anonymous (nobody) Summary: distutils/mingw32 links to dbg libs Initial Comment: When compiling extension modules on Windows with debugging enabled for the native mode of the GNU compilers ("--compiler=mingw32 --debug"), distutils tries to link with the debugging version of the libraries (python21_d.dll, ...). This may be useful for Microsoft Visual C++, but for the GNU compilers, it isn't. GNU tools have a different debugging symbol format than MS tools, so there's no point in doing this. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2001-09-18 20:30 Message: Logged In: YES user_id=163326 OK, see patch #462754. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-09-04 12:56 Message: Logged In: YES user_id=11375 Hmm... I can't see any code in cygwinccompiler.py that adds the _d prefix in the current CVS. Can you please track down the code that adds it, and submit a patch to fix the problem? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454086&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:41:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:41:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-410541 ] bdist builds bogus .zips Message-ID: Bugs item #410541, was opened at 2001-03-22 08:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) >Assigned to: Nobody/Anonymous (nobody) Summary: bdist builds bogus .zips Initial Comment: According to Thomas Heller: "... the resulting zip-file from 'bdist --formats=zip' is unusable because it contains filenames relative to the root directory)" Such paths may be OK for Unix (cd / and unzip it, perhaps?), but isn't much good for Windows, where Python might be installed anywhere. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2001-05-27 15:33 Message: Logged In: YES user_id=149084 gztar, ztar, tar, and zip appear to create the same install tree rooted at / . Only the compression differs. (I guess wininst is the intended way to create a Windows distribution.) The Unix tree contains PythonX.X in its paths, so not only is the full tree NG for Windows, but if someone prepares a bdist package on a Unix system running 2.2, it appears that it is not going to install correctly on a Unix system running 2.1. It is impractical to ask developers to update their Tools distributions for each version of Python, so what to do? It may be that the bdist paths should be rooted at site-packages, with script installation to prefix/bin. If there are extensions to go into lib-dynload, the path is ../lib-dynload from site-packages. Then the user would unpack the file in the site-package directory. Note that right now the file names for source and 'binary' distribution are very similar, but the method of installation is different, and this has to be made clear to the user. GvR seems to be interested in making the install trees the same on Linux and Windows, that would help. Incidently, the distutils docs say the default is to install relative to prefix, but it appears that that has not been implemented, the default is / . Also, though the docs mention Windows installers, rpms, etc., they don't say anything about install files prepared with bdist. Maybe no one uses bdist? If there is something I can do here, let me know. It seems it may take some discussion on python-dev first, though. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-05-21 13:39 Message: Logged In: YES user_id=11375 I expect no one will install from a .zip file on Unix. Options: 1) Make both the .tgz and .zip relative to sys.prefix or something. 2) Make only the .zip relative. 3) Document this as being broken and forget about it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:41:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:41:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-233259 ] Ugly traceback for DistutilsPlatformError Message-ID: Bugs item #233259, was opened at 2001-02-20 08:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=233259&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Ward (gward) >Assigned to: Nobody/Anonymous (nobody) Summary: Ugly traceback for DistutilsPlatformError Initial Comment: >From Chad Lester: > I was setting up a new redhat machine, and had forgotten to install the > python-devel rpm. The distutils provide a fairly ugly stack trace / error > message. Luckily, it meant something to me... but it's not terribly user > friendly! > > ... > File "/usr/lib/python1.5/site-packages/distutils/sysconfig.py", line > 368, in get_config_vars > func() > File "/usr/lib/python1.5/site-packages/distutils/sysconfig.py", line > 280, in _init_posix > raise DistutilsPlatformError, my_msg > distutils.errors.DistutilsPlatformError: invalid Python > installation: unable to open /usr/lib/python1.5/config/Makefile (No such > file or directory) > > ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-12-06 08:18 Message: Logged In: YES user_id=11375 Greg, I don't understand your last comment on this bug. Surely the traceback will still be ugly for people running Python 2.2 or whatever who don't have the python-devel RPM installed? I don't see how this is only a 1.5.2 or a "installing Distutils" question. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2001-02-20 08:24 Message: This only applies for people installing Distutils under Python 1.5.2, so it will only be fixed if there is another Distutils release to support 1.5.2 -- which is unlikely. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=233259&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:41:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:41:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-443238 ] Perm. in ../lib/python2.2/lib-dynload Message-ID: Bugs item #443238, was opened at 2001-07-20 17:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443238&group_id=5470 Category: Installation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) >Assigned to: Nobody/Anonymous (nobody) Summary: Perm. in ../lib/python2.2/lib-dynload Initial Comment: "make install" does not set the permissions for all *.so to a+r. Instead u+rwx is set. All other files in the lib/python2.2 folder are fine. Env. Linux 2.4.5 i386 Andreas ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-17 09:59 Message: Logged In: YES user_id=6380 Andrew, can you look into this? ---------------------------------------------------------------------- Comment By: Allan Digiby (just_gnu_it) Date: 2001-07-22 01:10 Message: Logged In: YES user_id=277768 For a more detailed view, check out: 443490 || 2.2 Install on Linux/Mod Install Error ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443238&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:42:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:42:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-413582 ] g++ must be called for c++ extensions Message-ID: Bugs item #413582, was opened at 2001-04-03 17:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=413582&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Nobody/Anonymous (nobody) Summary: g++ must be called for c++ extensions Initial Comment: When building c++ extension using distutils setup, the compiler that was used to build python distribution is always called. On Linux, it is normally gcc. When gcc is called to link shared library, it does not link certain c++ runtime stuff. As a result, when extension is imported, missing symbols are reported, e.g.: >>> import ex_ext1 Traceback (most recent call last): File "", line 1, in ? ImportError: ./ex_ext1.so: undefined symbol: __vt_13runtime_error >>> I tried to use "extra_link_args = ['-x c++']" in setup.py (it tells gcc to link as c++), but that gets added to the end of compiler's command line, which results in: gcc -shared build/temp.linux-i686-2.1/ex_ext1.o -L../boost/libs/python -lboost_python -o build/lib.linux-i686-2.1/ex_ext1.so -x c++ gcc: Warning: `-x c++' after last input file has no effect Proposed solution: either use CXX= variable from Python Makefile when c++ files are involved, or prepend extra_link_args to compiler's arguments instead of appending them. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 08:51 Message: Logged In: YES user_id=6380 Assigning this to Andrew, who is the current distutils maintainer. ---------------------------------------------------------------------- Comment By: Andrei Tovtchigretchko (andreitd) Date: 2001-04-04 17:23 Message: Logged In: YES user_id=189208 Follow-up: If I link with a static library (-lboost_python is libboost_python.a in bug post example), the problem shows. If I link with shared c++ library (libboost_python.so), everything is ok. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=413582&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:42:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:42:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-436259 ] [Windows] exec*/spawn* problem with spaces in args Message-ID: Bugs item #436259, was opened at 2001-06-25 20:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436259&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Ben Hutchings (wom-work) >Assigned to: Nobody/Anonymous (nobody) Summary: [Windows] exec*/spawn* problem with spaces in args Initial Comment: DOS and Windows processes are not given an argument vector, as Unix processes are; instead they are given a command line and are expected to perform any necessary argument parsing themselves. Each C run-time library must convert command lines into argument vectors for the main() function, and if it includes exec* and spawn* functions then those must convert argument vectors into a command-line. Naturally, the various implementations differ in interesting ways. The Visual C++ run-time library (MSVCRT) implementation of the exec* and spawn* functions is particularly awful in that it simply concatenates the strings with spaces in-between (see source file cenvarg.c), which means that arguments with embedded spaces are likely to turn into multiple arguments in the new process. Obviously, when Python is built using Visual C++, its os.exec* and os.spawn* functions behave in this way too. MS prefers to work around this bug (see Knowledge Base article Q145937) rather than to fix it. Therefore I think Python must work around it too when built with Visual C++. I experimented with MSVCRT and Cygwin (using the attached program print_args.c) and could not find a way to convert an argument vector into a command line that they would both convert back to the same argument vector, but I got close. MSVCRT's parser requires spaces that are part of an argument to be enclosed in double-quotes. The double-quotes do not have to enclose the whole argument. Literal double-quotes must be escaped by preceding them with a backslash. If an argument contains literal backslashes before a literal or delimiting double-quote, those backslashes must be escaped by doubling them. If there is an unmatched enclosing double-quote then the parser behaves as if there was another double-quote at the end of the line. Cygwin's parser requires spaces that are part of an argument to be enclosed in double-quotes. The double-quotes do not have to enclose the whole argument. Literal double-quotes may be escaped by preceding them with a backslash, but then they count as enclosing double-quote as well, which appears to be a bug. They may also be escaped by doubling them, in which case they must be enclosed in double-quotes; since MSVCRT does not accept this, it's useless. As far as I can see, literal backslashes before a literal double-quote must not be escaped and literal backslashes before an enclosing double-quote *cannot* be escaped. It's really quite hard to understand what its rules are for backslashes and double-quotes, and I think it's broken. If there is an unmatched enclosing double-quote then the parser behaves as if there was another double-quote at the end of the line. Here's a Python version of a partial fix for use in nt.exec* and nt.spawn*. This function modifies argument strings so that the resulting command line will satisfy programs that use MSVCRT, and programs that use Cygwin if that's possible. def escape(arg): import re # If arg contains no space or double-quote then # no escaping is needed. if not re.search(r'[ "]', arg): return arg # Otherwise the argument must be quoted and all # double-quotes, preceding backslashes, and # trailing backslashes, must be escaped. def repl(match): if match.group(2): return match.group(1) * 2 + '\"' else: return match.group(1) * 2 return '"' + re.sub(r'(\*)("|$)', repl, arg) + '"' This could perhaps be used as a workaround for the problem. Unfortunately it would conflict with workarounds implemented at the Python level (which I have been using for a while). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 21:57 Message: Logged In: YES user_id=31435 distutils is *trying* to make spawn work the same way across platforms, via spawn.py. Help it! You're not likely to get anywhere with a change to the os.spawn family because you already know it will break code -- and it will break disutils in particular. If you want to break code, this needs a PEP first: write up your "two stage" approach in PEP and let the community have at it. If you read c.l.py, you should have a feel for how warmly that's likely to be received . The bit about __argv was just FYI (you seemed unaware of it; I agree it's irrelevant to what you want to achieve). ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2001-07-11 21:30 Message: Logged In: YES user_id=203860 "Note that processes using WinMain can get at argc and argv under MSVC via including stdlib.h and using __argc and __argv instead." This is irrelevant. The OS passes the command line into a process as a single string, which it makes accessible through the GetCommandLine() function. The argument vector received by main() or accessible as __argv is generated from this by the C run-time library. "The right way to address this is to add more smarts to spawn.py in distutils" I disagree. The right thing to do is to make these functions behave in the same way across platforms, as far as possible. Perhaps this could be done in two stages - in the first release, make the fix optional, and in the second, use it all the time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 19:32 Message: Logged In: YES user_id=31435 Note that processes using WinMain can get at argc and argv under MSVC via including stdlib.h and using __argc and __argv instead. I agree the space behavior sucks regardless. However, as you've discovered, there's nothing magical we can do about it without breaking the workarounds people have already developed on their own -- including distutils. The right way to address this is to add more smarts to spawn.py in distutils, then press to adopt that in the std library (distutils already does *some* magical arg quoting on win32 systems, and could use your help to do a better job of it). Accordingly, I added [Windows] to the summary line, changed the category to distutils, and reassigned to Greg Ward for consideration. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436259&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:42:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:42:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-434944 ] setup.py - nonstandard paths Message-ID: Bugs item #434944, was opened at 2001-06-20 15:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434944&group_id=5470 Category: Build Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Robert Minsk (rminsk) >Assigned to: Nobody/Anonymous (nobody) Summary: setup.py - nonstandard paths Initial Comment: In my build environment I have to ensure that the same version of each software package is available across many different platforms. To do this I compile code into a directory structure when the root path of /usr/tools/fw. So a tools like flex would result in files /usr/tools/fw/bin/flex, /usr/tools/fw/include/FlexLexer.h, /usr/tools/fw/lib/libfl.a, ... In the Python 2.1 build environment it does not seem that you can pass extra search paths too setup.py. I must either hack setup.py to look in /usr/tools/fw or manually add each module to Modules/Setup. It would be nice for setup.py to be able to take extra search paths. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434944&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:42:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:42:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-425007 ] Python 2.1 installs shared libs with mode 0700 Message-ID: Bugs item #425007, was opened at 2001-05-17 16:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 6 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.1 installs shared libs with mode 0700 Initial Comment: I have gone back and tried Python 1.6 and 2.0. Both work fine. When I install Python 2.1, everything is broken. The problem is that when a module is a shared library (.so), python refuses to load the module. Example: import os import sys import SocketServer Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/SocketServer.py", line 126, in ? import socket File "/usr/lib/python2.1/socket.py", line 41, in ? from _socket import * ImportError: No module named _socket Now, do a "locate _socket.so" and I get: /usr/lib/python2.1/site-packages/_socket.so /usr/lib/python2.1/lib-dynload/_socket.so Clearly they are there, it's just that Python refuses to load them. I made Python 2.1 from source as fetched from the 2.1 tar ball. It makes cleanly. During the installation, I see some items that I believe to be minor that popup, but don't currectly expect that they are the problem. I have tried many times using different configure options to get this to work, deleting the previous installation each time. I've even tried installing in different locations. As is, Python 2.1 is completely broken for me. Surely I'm not the only one having this problem, especially since 1.5, 1.6, and 2.0 all work correctly. Any help would be great. BTW, doing a "print sys.path" gives me: ['', '/usr/lib/python2.1', '/usr/lib/python2.1/plat-linux2', '/usr/lib/python2.1/lib-tk', '/usr/lib/python2.1/lib-dynload', '/usr/lib/python2.1/site-packages'] As you can see, lib-dynload is in the path, so I'm not really sure what's going on. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2001-05-21 23:24 Message: Logged In: YES user_id=149084 INSTALLATION: Confirm. Built with umask 077, group and others have no permissions in source tree. (Note that if I su to install, the 077 follows! ok, install with umask of 022, normal for root.). Everything in installation looks ok except for lib-dynload, which has 700 permissions on files. No _socket.so in site-packages. REINSTALLATION: I suspect there is more to this than distutils...Redo the build with umask 022. Then chmod the whole previously installed tree to 700 and if you then repeat the install on top of it you find that while the .py files have been correctly copied by /usr/bin/install with 644, the .pyc and .pyo are still 700 though recompiled. This also happens in 1.5.2. The lib-dynload files are 755. This is with a umask of 022 for both the build user and root. Finally, delete a few files from lib-dynload, chmod the rest to 700, and make install again! The deleted files are restored at 755, the rest stay at 700. In general, messed up permissions are not fixed by a re-install. It would seem desirable that re-installing should result in exactly the same install tree as the initial install, including permissions, except that any non-distribution files (e.g. "site-packages") added by the user would be unaffected. If the user had modified some distribution .py files they would be reverted by the re-install, which does seem to be the case. A broken installation could be repaired by re-installing. Would that be a reasonable policy? Or is it too difficult to fix up all the permissions? A compromise might be to delete the .pyo .pyc before compiling, and explicitly chmod all the lib-dynload files during install. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-05-21 13:15 Message: Logged In: YES user_id=11375 Reclassifying as a Distutils bug. The install_lib subcommand simply copies the contents of the BUILD/ tree. It needs to pointedly ignore the umask and set the proper permissions on the installed files. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-05-21 12:32 Message: Logged In: YES user_id=6380 Assigning this to Andrew -- clearly the setup.py script (or distutils) needs to be fixed to fix this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-05-21 12:24 Message: Logged In: YES user_id=6380 I didn't mean to imply that you did something incorrectly. I just meant that there was some interaction between your system and Python that didn't work out the way it was supposed to be. Since Python installs correctly on most systems, I was implying that there's something unusual in your system that the Python install procedure doesn't anticipate. The mode 0700 for the shared libraries is a big hint at what was wrong (and if you had done an ls -l of the file when first reporting this we would have figured out the problem much quicker). Is perhaps the umask of the user who built (not installed) the files set to 077? In that case, the cause is that the "make install" by root doesn't change the file modes to something more reasonable (I've confirmed that this indeed happens). I'll look into whether this can be fixed. I'm changing the subject line of this bug report to reflect more accurately that the problem is with the file modes of shared libs. I still believe that the _socket.so in site-packages could not have been placed there by the normal Python install procedure. ---------------------------------------------------------------------- Comment By: Greg Copeland (oracle) Date: 2001-05-21 08:13 Message: Logged In: YES user_id=40173 The problem is that the installation is partially broken. It didn't install the shared libraries with proper permissions. When Python installed the shared libs, it installed the libs as root.root having 0700 permissions. When I tried to execute it as a normal user, obviously, it fails to load the shared lib. Python then, incorrectly reports that the shared lib can not be found. Of course, the correct solution is for Python to accurately report the problem and to have the installation always install the libraries with correct ownership and permission. I don't think I'm asking for too much here. Seems pretty reasonable to me. Anyone stating that I did not install correctly is woefully incorrect. Simply put, the installation is not 100%. As for some of the libraries existing twice. Well, simply put, the installation is not 100%. At any rate, I think it's safe to close this bug but we might want to add it to the faq-o-matic somewhere or some such thing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-05-20 10:35 Message: Logged In: YES user_id=6380 Clearly it's something you have done to yourself. :-) The question is how to find out what. Try "python -v" or even "python -vv" and see what it prints when you try to import _socket. This should give you some clues (it shows where it searches for modules during import). As kbk says, that other _socket.so is mysterious. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2001-05-19 17:16 Message: Logged In: YES user_id=149084 Well, import SocketServer works ok for me with Python built both from the 2.1 tar file and the 2.2a0 CVS tree. I'm running Linux 2.2.5 (RH 6.2) on Pentium. Did you make clean after changing the configure options? It is not normal to have _socket.so in .../site-packages; it should be only in .../lib-dynload. Default installation has only the README file in site-packages. Your sys.path looks normal, except that Python default installs at /usr/local/[bin/lib]. I tried a build targeted at /usr/[bin/lib] and it was ok. You could try make clobber, but it's almost as fast to start over. Try a vanilla installation: 1. delete your install tree @ /usr/local/lib/python2.1 (and/or /usr/lib) 2. delete your source tree from wherever you unpacked the tar file. 3. untar again, cd to source directory it created 4. without changing any files, and no configure options, run ./configure, then make, then make install If that doesn't help, what Linux are you running, on what box, and where did you get your 2.1 tar file? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:43:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:43:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-477371 ] build_scripts can use wrong #! line Message-ID: Bugs item #477371, was opened at 2001-11-01 19:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477371&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) >Assigned to: Nobody/Anonymous (nobody) Summary: build_scripts can use wrong #! line Initial Comment: When the build_scripts command is run, it places into build/scripts a copy of the script with the #! line modified to call the python version directly. But if you subsequently call setup.py with a different python version, the script is not updated to use the correct python executable path. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477371&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:43:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:43:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-445902 ] runtime_library_dirs and gcc don't mix Message-ID: Bugs item #445902, was opened at 2001-07-30 03:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445902&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 7 Submitted By: Gary Capell (gcapell) >Assigned to: Nobody/Anonymous (nobody) Summary: runtime_library_dirs and gcc don't mix Initial Comment: providing runtime_library_dirs =["/foo"], setup.py build does: gcc -shared -R/foo ... whereas it requires gcc -shared -Wl,-R/foo to get the option through to the linker. My configuration: python2.1.1, gcc 2.9.6, binutils 2.10.91.0.2, redhat 7.1, intel Please let me know if I'm just doing something stupid. Thanks heaps for the distutils stuff, it makes playing with extensions way easier. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-11 00:53 Message: Logged In: YES user_id=21627 It somewhat depends on the platform; on Solaris, gcc will accept -R. On Linux, it doesn't, so this is really distutils fault, not yours. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445902&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:47:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:47:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-454030 ] distutils cannot link C++ code with GCC Message-ID: Bugs item #454030, was opened at 2001-08-21 16:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454030&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: Barry Alan Scott (barry-scott) >Assigned to: Nobody/Anonymous (nobody) Summary: distutils cannot link C++ code with GCC Initial Comment: It is mandatory to link C++ code against -lstdc++ -lm when creating an extension. distutils does not do this in 2.1.1 Here is a setup.py for Python CXX that works around the problem, but it would be better for distutils to understand enough about C++ to do the right thing. THen the code for other compilers could be added. But GCC is important enough to do first. You can get the CXX sources from http://sourceforge.net/projects/cxx/ from distutils.core import setup, Extension if os.name == 'posix': CXX_libraries = ['stdc++','m'] else: CXX_libraries = [] setup(name="pycxx_demo", version="1.0", ext_modules= [Extension( "example", sources = [ "Demo/example.cxx", "Demo/python.cxx", "Demo/range.cxx", "Demo/rangetest.cxx", "Src/cxx_extensions.cxx", "Src/cxxextensions.c", "Src/cxxsupport.cxx", "Src/IndirectPythonInterface.cxx" ], include_dirs = [ ".", "Demo" ], libraries = CXX_libraries ) ] ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454030&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:47:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:47:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-479469 ] File copy fails on True64 AFS file syste Message-ID: Bugs item #479469, was opened at 2001-11-08 00:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479469&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Konrad Hinsen (hinsen) >Assigned to: Nobody/Anonymous (nobody) Summary: File copy fails on True64 AFS file syste Initial Comment: The following report comes from an MMTK user who has a peculiar installation problem which is probably caused by some Distutils bug/feature: ------------------------------------------------ As an aside, I'm having problems with the installation of MMTK itself on Alpha/Tru64. I keep getting these: copying MMTK/Database/Groups/aspartic_acid_uni2 -> /afs/bi/v/@sys/languages/python/latest/lib/python2.0/site-packages/MMTK/Database/Groups error: /afs/bi/v/@sys/languages/python/latest/lib/python2.0/site-packages/MMTK/Database/Groups/aspartic_acid_uni2: Not owner The file is copied, but the installation process halts there. I am able to proceed by rerunning the python setup.py install; it notices that that file got there OK, copies the next one, and halts again. As you notice, we have the AFS file system (whose chmod/chown semantics are quite different from regular UNIX). This is not a problem on Linux, HP, SGI or Sun, only on Alpha. Also, it does not matter whether I have my normal account or the administrator account on AFS. What is the installation program trying to do and is it altogether necessary? ------------------------------------------------- The setup.py script is attached. The file mentioned above is one of the data files that end up in the data_files variable. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479469&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:47:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:47:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-452144 ] How to install some stuff to /usr/sbin Message-ID: Bugs item #452144, was opened at 2001-08-17 09:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452144&group_id=5470 Category: Distutils Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jon Nelson (jnelson) >Assigned to: Nobody/Anonymous (nobody) Summary: How to install some stuff to /usr/sbin Initial Comment: I'd like behavior identical to "scripts" but want certain files to go to /usr/sbin instead of /usr/bin How can I accomplish this? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452144&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:47:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:47:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-480480 ] pydoc #!/build-directory/python Message-ID: Bugs item #480480, was opened at 2001-11-10 16:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=480480&group_id=5470 Category: Distutils Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Brian Zhou (bzhou) >Assigned to: Nobody/Anonymous (nobody) Summary: pydoc #!/build-directory/python Initial Comment: Starting from source for example http://www.python.org/ftp/python/2.2/rpms/python2.2- 2.2b1-2.src.rpm "make install" copies and later packages a version of pydoc which has hard-coded #!/build-directory/python This pydoc will be installed on redhat 7.x. The unwanted dependency will also cause the binary RPM installation to fail on redhat 6.2. "make install" should be fixed to use "#!/usr/bin/env python" or simply pick-up Tools/scripts/pydoc. A quick workaround for rpm is to change the python-2.2.spec file: 162,163c162 < sed 's|#!/usr/bin/env python|#!/usr/bin/env python'%{binsuffix}'|' \ < pydoc.old >pydoc --- > sed 's|#!.*python$|#!/usr/bin/env python'% {binsuffix}'|' pydoc.old >pydoc ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-11 07:02 Message: Logged In: YES user_id=21627 Putting in /usr/bin/env is certainly not the right solution. distutils was specifically designed to adjust the path of scripts, to make sure that the Python binary used at run-time is indeed the one used at installation time. Otherwise, the user may break pydoc by putting a different Python installation in front of the path. Instead, distutils should be fixed to assume that the Python interpreter will be in BINDIR. Recategorizing as distutils bug, and raising the priority. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=480480&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:48:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:48:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-472881 ] distutils does not deduce dependencies Message-ID: Bugs item #472881, was opened at 2001-10-19 11:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Nobody/Anonymous (nobody) Summary: distutils does not deduce dependencies Initial Comment: I just "cvs up"d my Python tree and executed "make". Nothing much changed, except patchlevel.h. Make got this right and rebuilt everything (patchlevel.h is included from Python.h, so changing patchlevel.h should cause make to rebuild just about everything). Distutils failed to notice this, however, so it didn't rebuild any modules. In this case, I think the failure to rebuild is probably innocuous, but I'm not at all confident it will do the right thing if I modify some other file. For example, I've noticed that it's not sufficient to delete a module's .o file when you want to rebuild it. Distutils still thinks the .so file is okay. If distutils is going to take the place of make I think it's going to need to do a much better job deducing file dependencies or provide a robust way for a person to tell it what those dependencies are. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:48:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:48:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-466200 ] ability to specify a 'verify' script Message-ID: Bugs item #466200, was opened at 2001-09-28 14:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466200&group_id=5470 Category: Distutils Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jon Nelson (jnelson) >Assigned to: Nobody/Anonymous (nobody) Summary: ability to specify a 'verify' script Initial Comment: The following patch adds the ability to specify a 'verify' script (as used by the %verify). Treatment is exactly the same as with post_install, etc... --- bdist_rpm.py Wed Sep 12 11:42:17 2001 +++ /home/agamemnon/jnelson/bdist_rpm.py Fri Sep 28 16:09:18 2001 @@ -131,6 +131,7 @@ self.post_install = None self.pre_uninstall = None self.post_uninstall = None + self.verifyscript = None self.prep = None self.provides = None self.requires = None @@ -210,6 +211,7 @@ self.ensure_filename('post_install') self.ensure_filename('pre_uninstall') self.ensure_filename('post_uninstall') + self.ensure_filename('verifyscript') # XXX don't forget we punted on summaries and descriptions -- they # should be handled here eventually! @@ -423,6 +425,7 @@ ('post', 'post_install', None), ('preun', 'pre_uninstall', None), ('postun', 'post_uninstall', None), + ('verify', 'verifyscript', None), ] for (rpm_opt, attr, default) in script_options: ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=466200&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:48:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:48:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-458343 ] distutils should zap .o as well as .so Message-ID: Bugs item #458343, was opened at 2001-09-04 04:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=458343&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Nobody/Anonymous (nobody) Summary: distutils should zap .o as well as .so Initial Comment: Just rebuilt from CVS and got this toward the end: skipping 'pyexpat' extension (up-to-date) WARNING: removing "pyexpat" since importing it failed It would have been nice to know why the import failed. Also, instead of just deleting the .so file it should delete the .o file as well. In this case, deleting the .o file to force recompilation instead of just relinking solved the problem. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-09-04 20:41 Message: Logged In: YES user_id=44345 > Unfortunately, setup doen't honor dependencies, ... While Distutils is a very clever piece of software, I have always had this sneaking suspicion that it was trying to do too much, subsuming some or all of the roles of make, autoconf, libtool, etc. In this particular case, the more I think about it, the more I think it has to delete the .o file. When import of the .so fails, setup.py has no idea why it failed, just that something's amiss. It might have been overly aggressive compiler switches, missing shared libraries, or other things, so to be on the safe side it should delete the .so file and any .o files that were compiled to create the module that failed to load. The GNU build tools have progressed quite a way in the past couple years, including improvements in portability (I believe some or all of them will run on Windows now, at least in certain configurations, like cygwin). While their output can be hell to debug, they do a much more complete job of dependency analysis than setup.py. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-04 13:57 Message: Logged In: YES user_id=6380 > when working from > CVS it doesn't seem to me like I should always need > to "make clean", > presuming the make dependencies are done right. Unfortunately, setup doen't honor dependencies, and when a header file has changed that affects the extensions, you have to manually remove the build subdirectory (I do "rm -rf build" :-) to get this to work. I wish that this could be fixed too. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-09-04 13:20 Message: Logged In: YES user_id=44345 > what did you use to clean up *.so files that didn't clean > up *.o files? The usual: cvs up . cd build ../configure make Maybe this won't be a problem for people who routinely download tarballs and build afresh, but when working from CVS it doesn't seem to me like I should always need to "make clean", presuming the make dependencies are done right. The only thing I'm suggesting is that if distutils performs an import to see if the newly built .so file is okay and finds that it isn't, it should delete both the .so file and the .o file from which it was built. The message it emits indicates that it is already zapping the .so file. Skip ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-09-04 12:46 Message: Logged In: YES user_id=11375 I'm not clear on the problem here; what did you use to clean up *.so files that didn't clean up *.o files? "make clean" runs rm `find -name *.o`, and "python setup.py clean" blows away an entire directory under build/, so both of those seem to be correct. What were you using? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=458343&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:50:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:50:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-454030 ] distutils cannot link C++ code with GCC Message-ID: Bugs item #454030, was opened at 2001-08-21 16:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454030&group_id=5470 >Category: Distutils Group: None Status: Open Resolution: None >Priority: 5 Submitted By: Barry Alan Scott (barry-scott) Assigned to: Nobody/Anonymous (nobody) Summary: distutils cannot link C++ code with GCC Initial Comment: It is mandatory to link C++ code against -lstdc++ -lm when creating an extension. distutils does not do this in 2.1.1 Here is a setup.py for Python CXX that works around the problem, but it would be better for distutils to understand enough about C++ to do the right thing. THen the code for other compilers could be added. But GCC is important enough to do first. You can get the CXX sources from http://sourceforge.net/projects/cxx/ from distutils.core import setup, Extension if os.name == 'posix': CXX_libraries = ['stdc++','m'] else: CXX_libraries = [] setup(name="pycxx_demo", version="1.0", ext_modules= [Extension( "example", sources = [ "Demo/example.cxx", "Demo/python.cxx", "Demo/range.cxx", "Demo/rangetest.cxx", "Src/cxx_extensions.cxx", "Src/cxxextensions.c", "Src/cxxsupport.cxx", "Src/IndirectPythonInterface.cxx" ], include_dirs = [ ".", "Demo" ], libraries = CXX_libraries ) ] ) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 13:50 Message: Logged In: YES user_id=6380 Nobody at PL understands distutils well enough to do this, so lowering the priority -- there's no way this will hold up the release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454030&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:52:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:52:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-480480 ] pydoc #!/build-directory/python Message-ID: Bugs item #480480, was opened at 2001-11-10 16:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=480480&group_id=5470 Category: Distutils Group: Python 2.2 Status: Open Resolution: None >Priority: 5 Submitted By: Brian Zhou (bzhou) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc #!/build-directory/python Initial Comment: Starting from source for example http://www.python.org/ftp/python/2.2/rpms/python2.2- 2.2b1-2.src.rpm "make install" copies and later packages a version of pydoc which has hard-coded #!/build-directory/python This pydoc will be installed on redhat 7.x. The unwanted dependency will also cause the binary RPM installation to fail on redhat 6.2. "make install" should be fixed to use "#!/usr/bin/env python" or simply pick-up Tools/scripts/pydoc. A quick workaround for rpm is to change the python-2.2.spec file: 162,163c162 < sed 's|#!/usr/bin/env python|#!/usr/bin/env python'%{binsuffix}'|' \ < pydoc.old >pydoc --- > sed 's|#!.*python$|#!/usr/bin/env python'% {binsuffix}'|' pydoc.old >pydoc ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 13:52 Message: Logged In: YES user_id=6380 Nobody knows how to fix this, so I'm lowering the priority -- it would take a miracle to fix this before 2.2 goes out. There is essentially nobody who maintains distutils at this point. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-11 07:02 Message: Logged In: YES user_id=21627 Putting in /usr/bin/env is certainly not the right solution. distutils was specifically designed to adjust the path of scripts, to make sure that the Python binary used at run-time is indeed the one used at installation time. Otherwise, the user may break pydoc by putting a different Python installation in front of the path. Instead, distutils should be fixed to assume that the Python interpreter will be in BINDIR. Recategorizing as distutils bug, and raising the priority. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=480480&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:52:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:52:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-489052 ] define NDEBUG for release builds Message-ID: Bugs item #489052, was opened at 2001-12-04 12:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489052&group_id=5470 Category: Build Group: Python 2.2 Status: Closed Resolution: Fixed Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Tim Peters (tim_one) Summary: define NDEBUG for release builds Initial Comment: NDEBUG should be defined on the command line during release builds of Python, so that assert() statements go away. We tried defining it in Python.h, but that interferes with extensions linking Python.h (and created real problems for Robin Dunn). The Windows build already does this. The Linux build needs it, and assigned to Fred for that part. Fred, please assign to jackjansen when you're done, so he can consider the Mac build. Any other build need special treatment? ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-06 13:52 Message: Logged In: YES user_id=45365 Little to be done about this: these files are the equivalent of unix -D options. If someone comes across an extension for which this is a problem they'll have to roll their one definitions file without the NDEBUG. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 12:15 Message: Logged In: YES user_id=31435 Thanks, Jack. I'm closing this now. If the BeOS or OS2 maintainters exist, they're welcome to identify themselves . BTW, are you sure you wanted to #define NDEBUG in header files on the Mac? The thrust of the bug report was to get rid of that very practice on Linux. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-05 15:02 Message: Logged In: YES user_id=45365 Fixed for MacPython. Assigning it back to Tim, I don't know whether the other maintainers (like for BeOS or OS2) need to be informed of this too. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-04 12:56 Message: Logged In: YES user_id=3066 The Unix portion of this is fixed in configure.in revision 1.284. Passing to Jack for Mac OS magic. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489052&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:54:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:54:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-486565 ] Mac OS 10.1: unobvious: --with-suffix Message-ID: Bugs item #486565, was opened at 2001-11-28 10:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486565&group_id=5470 Category: Macintosh Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Jack Jansen (jackjansen) Summary: Mac OS 10.1: unobvious: --with-suffix Initial Comment: First attempts to install Python-2.2b2 under Mac OS 10.1 on a HFS+ filesystem failed at the point of linking the python executable. When browsing comp.lang.python it became clear that the --with- suffix=.exe configure option has to be used. Currently, configure only reports: checking for executable suffix... no checking for --with-suffix... It would be a big improvement if configure could issue a very visible warning, or even better, supply the suffix automatically and tell the user at the very end that python is python.exe. Thanks! Ralf ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-06 13:54 Message: Logged In: YES user_id=45365 Fixed in the CVS tree: we now check wether we're building on a case-insensitive file system, and if that is the case we add a .exe suffix to python, but only to the copy in the build directory. The installed binary doesn't get the suffix. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2001-11-28 14:01 Message: Logged In: YES user_id=71407 > Yes, this is a serious problem. Configure _does_ give a warning, ... I cannot even see the warning when I am looking for it. A full output of running 2.2b2 configure under MacOS 10.1 is available at this location: http://cci.lbl.gov/~rwgk/tmp/MacOS10.1_Python- 2.2b2_configure_output.txt Is the warning in there? > Would you happen to know of a way to test for this? You could simply try to detect the very feature that is causing the default build to fail: 1. Create an empty file with some dummy, lowercase name: touch zap 2. Now test the existence of the file under the uppercase name: test -f ZAP 3. On HFS, $status == 0, on UFS or NFS, $status == 1. Ralf ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-28 12:42 Message: Logged In: YES user_id=45365 Yes, this is a serious problem. Configure _does_ give a warning, but it gets lost in the stream of output it produces. The problem is that I don't know how to test whether we're building on an HFS+ filesystem. Only then should we add the --with-suffix automatically, if you're building on a UFS or NFS filesystem there is no problem. Would you happen to know of a way to test for this? Or should I simply always use --with-suffix on OSX? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486565&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:56:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:56:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-220993 ] Installation flaky with multiple installers, old versions Message-ID: Bugs item #220993, was opened at 2000-11-01 05:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=220993&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None >Priority: 5 Submitted By: Greg Ward (gward) Assigned to: Nobody/Anonymous (nobody) Summary: Installation flaky with multiple installers, old versions Initial Comment: Installation tends to have problems when there are old installations present, especially when a different user is doing the new installation. In particular, it appears that the chmod() done in 'copy_file()' (as a result of the "install" command attempting to preserve the mode of files from the build tree) fails, because you can't chmod() a file owned by somebody else. Paul Dubois suggests that simply unlinking the target file before doing the copy should work. I think he's right, but need to think about it and test it a bit first. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-09-20 11:41 Message: Logged In: YES user_id=11375 I think unlinking first is the right thing to do, having just run into another problem that seems to be caused by this. Installing *.so files to an NFS partition messed up other people, I think because they had the *.so file loaded into memory and the kernel's VM got confused. (That's the theory, anyway.) Bumping up the priority as a reminder to myself... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=220993&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:56:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:56:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-454086 ] distutils/mingw32 links to dbg libs Message-ID: Bugs item #454086, was opened at 2001-08-21 21:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454086&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None >Priority: 5 Submitted By: Gerhard Häring (ghaering) Assigned to: Nobody/Anonymous (nobody) Summary: distutils/mingw32 links to dbg libs Initial Comment: When compiling extension modules on Windows with debugging enabled for the native mode of the GNU compilers ("--compiler=mingw32 --debug"), distutils tries to link with the debugging version of the libraries (python21_d.dll, ...). This may be useful for Microsoft Visual C++, but for the GNU compilers, it isn't. GNU tools have a different debugging symbol format than MS tools, so there's no point in doing this. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2001-09-18 20:30 Message: Logged In: YES user_id=163326 OK, see patch #462754. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-09-04 12:56 Message: Logged In: YES user_id=11375 Hmm... I can't see any code in cygwinccompiler.py that adds the _d prefix in the current CVS. Can you please track down the code that adds it, and submit a patch to fix the problem? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454086&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:57:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:57:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-445902 ] runtime_library_dirs and gcc don't mix Message-ID: Bugs item #445902, was opened at 2001-07-30 03:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445902&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None >Priority: 7 Submitted By: Gary Capell (gcapell) Assigned to: Nobody/Anonymous (nobody) Summary: runtime_library_dirs and gcc don't mix Initial Comment: providing runtime_library_dirs =["/foo"], setup.py build does: gcc -shared -R/foo ... whereas it requires gcc -shared -Wl,-R/foo to get the option through to the linker. My configuration: python2.1.1, gcc 2.9.6, binutils 2.10.91.0.2, redhat 7.1, intel Please let me know if I'm just doing something stupid. Thanks heaps for the distutils stuff, it makes playing with extensions way easier. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 13:57 Message: Logged In: YES user_id=3066 I've attached a proposed patch, but it's way too hackish, and doesn't generalize at all. But it probably solves the most common case. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-11 00:53 Message: Logged In: YES user_id=21627 It somewhat depends on the platform; on Solaris, gcc will accept -R. On Linux, it doesn't, so this is really distutils fault, not yours. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445902&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:56:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:56:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-425007 ] Python 2.1 installs shared libs with mode 0700 Message-ID: Bugs item #425007, was opened at 2001-05-17 16:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None >Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.1 installs shared libs with mode 0700 Initial Comment: I have gone back and tried Python 1.6 and 2.0. Both work fine. When I install Python 2.1, everything is broken. The problem is that when a module is a shared library (.so), python refuses to load the module. Example: import os import sys import SocketServer Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/SocketServer.py", line 126, in ? import socket File "/usr/lib/python2.1/socket.py", line 41, in ? from _socket import * ImportError: No module named _socket Now, do a "locate _socket.so" and I get: /usr/lib/python2.1/site-packages/_socket.so /usr/lib/python2.1/lib-dynload/_socket.so Clearly they are there, it's just that Python refuses to load them. I made Python 2.1 from source as fetched from the 2.1 tar ball. It makes cleanly. During the installation, I see some items that I believe to be minor that popup, but don't currectly expect that they are the problem. I have tried many times using different configure options to get this to work, deleting the previous installation each time. I've even tried installing in different locations. As is, Python 2.1 is completely broken for me. Surely I'm not the only one having this problem, especially since 1.5, 1.6, and 2.0 all work correctly. Any help would be great. BTW, doing a "print sys.path" gives me: ['', '/usr/lib/python2.1', '/usr/lib/python2.1/plat-linux2', '/usr/lib/python2.1/lib-tk', '/usr/lib/python2.1/lib-dynload', '/usr/lib/python2.1/site-packages'] As you can see, lib-dynload is in the path, so I'm not really sure what's going on. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2001-05-21 23:24 Message: Logged In: YES user_id=149084 INSTALLATION: Confirm. Built with umask 077, group and others have no permissions in source tree. (Note that if I su to install, the 077 follows! ok, install with umask of 022, normal for root.). Everything in installation looks ok except for lib-dynload, which has 700 permissions on files. No _socket.so in site-packages. REINSTALLATION: I suspect there is more to this than distutils...Redo the build with umask 022. Then chmod the whole previously installed tree to 700 and if you then repeat the install on top of it you find that while the .py files have been correctly copied by /usr/bin/install with 644, the .pyc and .pyo are still 700 though recompiled. This also happens in 1.5.2. The lib-dynload files are 755. This is with a umask of 022 for both the build user and root. Finally, delete a few files from lib-dynload, chmod the rest to 700, and make install again! The deleted files are restored at 755, the rest stay at 700. In general, messed up permissions are not fixed by a re-install. It would seem desirable that re-installing should result in exactly the same install tree as the initial install, including permissions, except that any non-distribution files (e.g. "site-packages") added by the user would be unaffected. If the user had modified some distribution .py files they would be reverted by the re-install, which does seem to be the case. A broken installation could be repaired by re-installing. Would that be a reasonable policy? Or is it too difficult to fix up all the permissions? A compromise might be to delete the .pyo .pyc before compiling, and explicitly chmod all the lib-dynload files during install. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-05-21 13:15 Message: Logged In: YES user_id=11375 Reclassifying as a Distutils bug. The install_lib subcommand simply copies the contents of the BUILD/ tree. It needs to pointedly ignore the umask and set the proper permissions on the installed files. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-05-21 12:32 Message: Logged In: YES user_id=6380 Assigning this to Andrew -- clearly the setup.py script (or distutils) needs to be fixed to fix this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-05-21 12:24 Message: Logged In: YES user_id=6380 I didn't mean to imply that you did something incorrectly. I just meant that there was some interaction between your system and Python that didn't work out the way it was supposed to be. Since Python installs correctly on most systems, I was implying that there's something unusual in your system that the Python install procedure doesn't anticipate. The mode 0700 for the shared libraries is a big hint at what was wrong (and if you had done an ls -l of the file when first reporting this we would have figured out the problem much quicker). Is perhaps the umask of the user who built (not installed) the files set to 077? In that case, the cause is that the "make install" by root doesn't change the file modes to something more reasonable (I've confirmed that this indeed happens). I'll look into whether this can be fixed. I'm changing the subject line of this bug report to reflect more accurately that the problem is with the file modes of shared libs. I still believe that the _socket.so in site-packages could not have been placed there by the normal Python install procedure. ---------------------------------------------------------------------- Comment By: Greg Copeland (oracle) Date: 2001-05-21 08:13 Message: Logged In: YES user_id=40173 The problem is that the installation is partially broken. It didn't install the shared libraries with proper permissions. When Python installed the shared libs, it installed the libs as root.root having 0700 permissions. When I tried to execute it as a normal user, obviously, it fails to load the shared lib. Python then, incorrectly reports that the shared lib can not be found. Of course, the correct solution is for Python to accurately report the problem and to have the installation always install the libraries with correct ownership and permission. I don't think I'm asking for too much here. Seems pretty reasonable to me. Anyone stating that I did not install correctly is woefully incorrect. Simply put, the installation is not 100%. As for some of the libraries existing twice. Well, simply put, the installation is not 100%. At any rate, I think it's safe to close this bug but we might want to add it to the faq-o-matic somewhere or some such thing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-05-20 10:35 Message: Logged In: YES user_id=6380 Clearly it's something you have done to yourself. :-) The question is how to find out what. Try "python -v" or even "python -vv" and see what it prints when you try to import _socket. This should give you some clues (it shows where it searches for modules during import). As kbk says, that other _socket.so is mysterious. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2001-05-19 17:16 Message: Logged In: YES user_id=149084 Well, import SocketServer works ok for me with Python built both from the 2.1 tar file and the 2.2a0 CVS tree. I'm running Linux 2.2.5 (RH 6.2) on Pentium. Did you make clean after changing the configure options? It is not normal to have _socket.so in .../site-packages; it should be only in .../lib-dynload. Default installation has only the README file in site-packages. Your sys.path looks normal, except that Python default installs at /usr/local/[bin/lib]. I tried a build targeted at /usr/[bin/lib] and it was ok. You could try make clobber, but it's almost as fast to start over. Try a vanilla installation: 1. delete your install tree @ /usr/local/lib/python2.1 (and/or /usr/lib) 2. delete your source tree from wherever you unpacked the tar file. 3. untar again, cd to source directory it created 4. without changing any files, and no configure options, run ./configure, then make, then make install If that doesn't help, what Linux are you running, on what box, and where did you get your 2.1 tar file? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470 From noreply@sourceforge.net Thu Dec 6 22:08:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 14:08:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-489672 ] memory leak in test_sre Message-ID: Bugs item #489672, was opened at 2001-12-05 18:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak in test_sre Initial Comment: leak when running test_sre see attached file for details ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 14:08 Message: Logged In: YES user_id=6380 It's hard to make progress on this. In a loop it doesn't leak or leaks too slowly to be useful. The code is not in a function so it's hard to whittle down effectively. The first leak reported by Purify is a string literal (or actially, 4 string literals); this isn't much of a hint since the code is chock full of those. The second leak reported is also a string, but one created through concatenation. There aren't too many of those in test_sre.py, but still, who knows which one it is... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 From noreply@sourceforge.net Thu Dec 6 22:07:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 14:07:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-477728 ] .*? matches newlines without DOTALL Message-ID: Bugs item #477728, was opened at 2001-11-02 22:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477728&group_id=5470 Category: Regular Expressions Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Fredrik Lundh (effbot) Summary: .*? matches newlines without DOTALL Initial Comment: ython 2.2b1+ (#25, Oct 30 2001, 22:36:33) [MSC 32 bit (Intel)] on win32 >> text = "one\ntwo\nthree\n" >> import re >> re.match(r'.*?$', text) SRE_Match object at 0x007AD940> >> _.group(0) # oops! one\ntwo\nthree' >> re.match(r'.*$', text) # more like it >> Since . shouldn't match a newline in the absence of re.DOTALL, .*? shouldn't match any newlines, and then minimal match should have failed (as did the maximal match). Found by Bruce Eckel. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2001-12-06 14:07 Message: Logged In: YES user_id=38376 A quick fix (which I originally planned to check in tonight) would be to back out of a recent patch that attempts to avoid recursion in some cases. But after a careful code review, I'm beginning to think that I might be able to tweak the patch into something that works also in this case. But I better do that some night when I haven't been out celebrating the PythonWorks 1.3 release... (tomorrow, in other words) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-02 12:28 Message: Logged In: YES user_id=31435 Boosted priority: /F, what's the hangup here? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-02 12:27 Message: Logged In: YES user_id=31435 Boosted priority: /F, what's the hangup here? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477728&group_id=5470 From noreply@sourceforge.net Thu Dec 6 21:56:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 13:56:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-445902 ] runtime_library_dirs and gcc don't mix Message-ID: Bugs item #445902, was opened at 2001-07-30 03:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445902&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None >Priority: 5 Submitted By: Gary Capell (gcapell) Assigned to: Nobody/Anonymous (nobody) Summary: runtime_library_dirs and gcc don't mix Initial Comment: providing runtime_library_dirs =["/foo"], setup.py build does: gcc -shared -R/foo ... whereas it requires gcc -shared -Wl,-R/foo to get the option through to the linker. My configuration: python2.1.1, gcc 2.9.6, binutils 2.10.91.0.2, redhat 7.1, intel Please let me know if I'm just doing something stupid. Thanks heaps for the distutils stuff, it makes playing with extensions way easier. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-11 00:53 Message: Logged In: YES user_id=21627 It somewhat depends on the platform; on Solaris, gcc will accept -R. On Linux, it doesn't, so this is really distutils fault, not yours. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445902&group_id=5470 From noreply@sourceforge.net Thu Dec 6 22:12:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 14:12:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-485150 ] memory leak from marshal.c (test_email) Message-ID: Bugs item #485150, was opened at 2001-11-24 11:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485150&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Barry Warsaw (bwarsaw) Summary: memory leak from marshal.c (test_email) Initial Comment: marshal.c seems to be the culprit in leaking data from running test_email see attached file for details ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 14:12 Message: Logged In: YES user_id=6380 It's not marshal's fault -- we see this all the time when a constant loaded from a .pyc file is leaked by some code that gets it passed in as an argument. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:04 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485150&group_id=5470 From noreply@sourceforge.net Thu Dec 6 22:10:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 14:10:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-489670 ] memory leak in test_re Message-ID: Bugs item #489670, was opened at 2001-12-05 18:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489670&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak in test_re Initial Comment: leak when running test_descr may be related to bug #485152 "memory leak from marshal.c (test_email)" see attached file for details ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 14:10 Message: Logged In: YES user_id=6380 Hard to say what's going on here, and hard to whittle it down (see my comments for the leak in test_sre.py -- they apply here too, since it's almost the same test suite). Again, all that Purify tells us is that the leaked object is a string (this time read from a .pyc file). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489670&group_id=5470 From noreply@sourceforge.net Thu Dec 6 22:24:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 14:24:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-485139 ] mem leak in interpreter from syntax err Message-ID: Bugs item #485139, was opened at 2001-11-24 10:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485139&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Guido van Rossum (gvanrossum) Summary: mem leak in interpreter from syntax err Initial Comment: when a syntax error occurs in the interpreter, the interpreter leaks see the attached file for more info ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:05 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485139&group_id=5470 From noreply@sourceforge.net Thu Dec 6 22:24:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 14:24:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-489670 ] memory leak in test_re Message-ID: Bugs item #489670, was opened at 2001-12-05 18:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489670&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Guido van Rossum (gvanrossum) Summary: memory leak in test_re Initial Comment: leak when running test_descr may be related to bug #485152 "memory leak from marshal.c (test_email)" see attached file for details ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 14:10 Message: Logged In: YES user_id=6380 Hard to say what's going on here, and hard to whittle it down (see my comments for the leak in test_sre.py -- they apply here too, since it's almost the same test suite). Again, all that Purify tells us is that the leaked object is a string (this time read from a .pyc file). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489670&group_id=5470 From noreply@sourceforge.net Thu Dec 6 22:24:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 14:24:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-489672 ] memory leak in test_sre Message-ID: Bugs item #489672, was opened at 2001-12-05 18:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Guido van Rossum (gvanrossum) Summary: memory leak in test_sre Initial Comment: leak when running test_sre see attached file for details ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 14:08 Message: Logged In: YES user_id=6380 It's hard to make progress on this. In a loop it doesn't leak or leaks too slowly to be useful. The code is not in a function so it's hard to whittle down effectively. The first leak reported by Purify is a string literal (or actially, 4 string literals); this isn't much of a hint since the code is chock full of those. The second leak reported is also a string, but one created through concatenation. There aren't too many of those in test_sre.py, but still, who knows which one it is... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 From noreply@sourceforge.net Thu Dec 6 22:24:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 14:24:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-485150 ] memory leak from marshal.c (test_email) Message-ID: Bugs item #485150, was opened at 2001-11-24 11:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485150&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Guido van Rossum (gvanrossum) Summary: memory leak from marshal.c (test_email) Initial Comment: marshal.c seems to be the culprit in leaking data from running test_email see attached file for details ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 14:12 Message: Logged In: YES user_id=6380 It's not marshal's fault -- we see this all the time when a constant loaded from a .pyc file is leaked by some code that gets it passed in as an argument. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:04 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485150&group_id=5470 From noreply@sourceforge.net Thu Dec 6 22:56:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 14:56:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-488184 ] import with undefineds can crash python Message-ID: Bugs item #488184, was opened at 2001-12-02 14:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488184&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: import with undefineds can crash python Initial Comment: Importing a module which references undefined externals, or which references libraries that fail initialization, can crash the interpreter. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-06 14:56 Message: Logged In: YES user_id=45365 Unfortunately the fix I had in mind, adding the "return on error" flag to NSLinkModule(), is not good enough. Python crashes while the initialization routine for the dynamic library is running, and NSLinkModule also never gets control back, it seems. I now think this is definitely an Apple bug. Lowering the priority because of that, not because it's not important. I did find an easy way to reproduce the bug, though: "su" to someone else (not root, someone who can't access your window server) and import _Win or something similar. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488184&group_id=5470 From noreply@sourceforge.net Thu Dec 6 23:01:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 15:01:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-458343 ] distutils should zap .o as well as .so Message-ID: Bugs item #458343, was opened at 2001-09-04 04:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=458343&group_id=5470 Category: Distutils Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: distutils should zap .o as well as .so Initial Comment: Just rebuilt from CVS and got this toward the end: skipping 'pyexpat' extension (up-to-date) WARNING: removing "pyexpat" since importing it failed It would have been nice to know why the import failed. Also, instead of just deleting the .so file it should delete the .o file as well. In this case, deleting the .o file to force recompilation instead of just relinking solved the problem. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 15:01 Message: Logged In: YES user_id=3066 The resolution should read "Fixed, painfully." I've checked in a hackish solution as setup.py 1.69 and Lib/distutils/command/build_ext.py 1.77. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-09-04 20:41 Message: Logged In: YES user_id=44345 > Unfortunately, setup doen't honor dependencies, ... While Distutils is a very clever piece of software, I have always had this sneaking suspicion that it was trying to do too much, subsuming some or all of the roles of make, autoconf, libtool, etc. In this particular case, the more I think about it, the more I think it has to delete the .o file. When import of the .so fails, setup.py has no idea why it failed, just that something's amiss. It might have been overly aggressive compiler switches, missing shared libraries, or other things, so to be on the safe side it should delete the .so file and any .o files that were compiled to create the module that failed to load. The GNU build tools have progressed quite a way in the past couple years, including improvements in portability (I believe some or all of them will run on Windows now, at least in certain configurations, like cygwin). While their output can be hell to debug, they do a much more complete job of dependency analysis than setup.py. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-04 13:57 Message: Logged In: YES user_id=6380 > when working from > CVS it doesn't seem to me like I should always need > to "make clean", > presuming the make dependencies are done right. Unfortunately, setup doen't honor dependencies, and when a header file has changed that affects the extensions, you have to manually remove the build subdirectory (I do "rm -rf build" :-) to get this to work. I wish that this could be fixed too. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-09-04 13:20 Message: Logged In: YES user_id=44345 > what did you use to clean up *.so files that didn't clean > up *.o files? The usual: cvs up . cd build ../configure make Maybe this won't be a problem for people who routinely download tarballs and build afresh, but when working from CVS it doesn't seem to me like I should always need to "make clean", presuming the make dependencies are done right. The only thing I'm suggesting is that if distutils performs an import to see if the newly built .so file is okay and finds that it isn't, it should delete both the .so file and the .o file from which it was built. The message it emits indicates that it is already zapping the .so file. Skip ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-09-04 12:46 Message: Logged In: YES user_id=11375 I'm not clear on the problem here; what did you use to clean up *.so files that didn't clean up *.o files? "make clean" runs rm `find -name *.o`, and "python setup.py clean" blows away an entire directory under build/, so both of those seem to be correct. What were you using? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=458343&group_id=5470 From noreply@sourceforge.net Thu Dec 6 23:18:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 15:18:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-489672 ] memory leak in test_sre Message-ID: Bugs item #489672, was opened at 2001-12-05 18:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Tim Peters (tim_one) Summary: memory leak in test_sre Initial Comment: leak when running test_sre see attached file for details ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-06 15:18 Message: Logged In: YES user_id=31435 Hard? Unpleasant? Mine ! Reassigned to me, cuz in a moment of weakness I said I would. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 14:08 Message: Logged In: YES user_id=6380 It's hard to make progress on this. In a loop it doesn't leak or leaks too slowly to be useful. The code is not in a function so it's hard to whittle down effectively. The first leak reported by Purify is a string literal (or actially, 4 string literals); this isn't much of a hint since the code is chock full of those. The second leak reported is also a string, but one created through concatenation. There aren't too many of those in test_sre.py, but still, who knows which one it is... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 From noreply@sourceforge.net Fri Dec 7 02:35:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 18:35:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-489672 ] memory leak in test_sre Message-ID: Bugs item #489672, was opened at 2001-12-05 18:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 >Category: Regular Expressions Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Fredrik Lundh (effbot) Summary: memory leak in test_sre Initial Comment: leak when running test_sre see attached file for details ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-06 18:35 Message: Logged In: YES user_id=31435 This derived snippet leaks at a prodigious rate: import re while 1: re.sub('(a)', '\1', 'a') Variations don't leak if the capturing group is removed from the regexp, or if the replacement text doesn't reference the group. I'm reassigning to /F based on that evidence (it appears to have to do with re.sub internals, not with a general Python screwup). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 15:18 Message: Logged In: YES user_id=31435 Hard? Unpleasant? Mine ! Reassigned to me, cuz in a moment of weakness I said I would. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 14:08 Message: Logged In: YES user_id=6380 It's hard to make progress on this. In a loop it doesn't leak or leaks too slowly to be useful. The code is not in a function so it's hard to whittle down effectively. The first leak reported by Purify is a string literal (or actially, 4 string literals); this isn't much of a hint since the code is chock full of those. The second leak reported is also a string, but one created through concatenation. There aren't too many of those in test_sre.py, but still, who knows which one it is... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 From noreply@sourceforge.net Fri Dec 7 02:42:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 18:42:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-490098 ] dumbdbm docs: flag,mode ignored Message-ID: Bugs item #490098, was opened at 2001-12-06 18:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490098&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: dumbdbm docs: flag,mode ignored Initial Comment: The docs for dumbdbm contain references to flags and modes, but don't note that these are utterly ignored by the dumbdbm module. In particular, anyone using the docs and assuming the 'n' flag works as described will find their life getting unpleasant. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490098&group_id=5470 From noreply@sourceforge.net Fri Dec 7 02:56:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 18:56:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-489672 ] memory leak in test_sre Message-ID: Bugs item #489672, was opened at 2001-12-05 18:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 Category: Regular Expressions Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Fredrik Lundh (effbot) Summary: memory leak in test_sre Initial Comment: leak when running test_sre see attached file for details ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 18:56 Message: Logged In: YES user_id=6380 Hm. For me (on Linux) that snippet doesn't leak at all. Are you sure this is it? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 18:35 Message: Logged In: YES user_id=31435 This derived snippet leaks at a prodigious rate: import re while 1: re.sub('(a)', '\1', 'a') Variations don't leak if the capturing group is removed from the regexp, or if the replacement text doesn't reference the group. I'm reassigning to /F based on that evidence (it appears to have to do with re.sub internals, not with a general Python screwup). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 15:18 Message: Logged In: YES user_id=31435 Hard? Unpleasant? Mine ! Reassigned to me, cuz in a moment of weakness I said I would. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 14:08 Message: Logged In: YES user_id=6380 It's hard to make progress on this. In a loop it doesn't leak or leaks too slowly to be useful. The code is not in a function so it's hard to whittle down effectively. The first leak reported by Purify is a string literal (or actially, 4 string literals); this isn't much of a hint since the code is chock full of those. The second leak reported is also a string, but one created through concatenation. There aren't too many of those in test_sre.py, but still, who knows which one it is... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 From noreply@sourceforge.net Fri Dec 7 03:04:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 19:04:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-489672 ] memory leak in test_sre Message-ID: Bugs item #489672, was opened at 2001-12-05 18:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 Category: Regular Expressions Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Fredrik Lundh (effbot) Summary: memory leak in test_sre Initial Comment: leak when running test_sre see attached file for details ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-06 19:04 Message: Logged In: YES user_id=31435 Guido, did you take the snippet from email or from the web page? It doesn't "look right" in email (for a change!). The 2nd argument to re.sub must have two backslashes; one of them vanishes in the email version ... I'll try attaching it as a file. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 18:56 Message: Logged In: YES user_id=6380 Hm. For me (on Linux) that snippet doesn't leak at all. Are you sure this is it? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 18:35 Message: Logged In: YES user_id=31435 This derived snippet leaks at a prodigious rate: import re while 1: re.sub('(a)', '\1', 'a') Variations don't leak if the capturing group is removed from the regexp, or if the replacement text doesn't reference the group. I'm reassigning to /F based on that evidence (it appears to have to do with re.sub internals, not with a general Python screwup). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 15:18 Message: Logged In: YES user_id=31435 Hard? Unpleasant? Mine ! Reassigned to me, cuz in a moment of weakness I said I would. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 14:08 Message: Logged In: YES user_id=6380 It's hard to make progress on this. In a loop it doesn't leak or leaks too slowly to be useful. The code is not in a function so it's hard to whittle down effectively. The first leak reported by Purify is a string literal (or actially, 4 string literals); this isn't much of a hint since the code is chock full of those. The second leak reported is also a string, but one created through concatenation. There aren't too many of those in test_sre.py, but still, who knows which one it is... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 From noreply@sourceforge.net Fri Dec 7 03:11:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 19:11:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-485139 ] mem leak in interpreter from syntax err Message-ID: Bugs item #485139, was opened at 2001-11-24 10:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485139&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Guido van Rossum (gvanrossum) Summary: mem leak in interpreter from syntax err Initial Comment: when a syntax error occurs in the interpreter, the interpreter leaks see the attached file for more info ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 19:11 Message: Logged In: YES user_id=6380 Neil, can you provide more evidence? I can't see this leak in a loop, like this: | while 1: | try: compile("/", "", "exec") | except SyntaxError: pass ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:05 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485139&group_id=5470 From noreply@sourceforge.net Fri Dec 7 03:43:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 19:43:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-485150 ] memory leak from marshal.c (test_email) Message-ID: Bugs item #485150, was opened at 2001-11-24 11:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485150&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Guido van Rossum (gvanrossum) Summary: memory leak from marshal.c (test_email) Initial Comment: marshal.c seems to be the culprit in leaking data from running test_email see attached file for details ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 19:43 Message: Logged In: YES user_id=6380 I can't get any of the test suites from test_email.py to grow when I place them in a loop. Maybe this is another one-time leak? Or maybe the leak is related to import? (Historically, there have often been small one-time leaks in import -- these are hard to find but also relatively unimportant, since one rarely re-imports modules over and over.) If that's the case, maybe it's possible to construct a test case out of a small module that's reloaded over and over? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 14:12 Message: Logged In: YES user_id=6380 It's not marshal's fault -- we see this all the time when a constant loaded from a .pyc file is leaked by some code that gets it passed in as an argument. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:04 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485150&group_id=5470 From noreply@sourceforge.net Fri Dec 7 03:44:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 19:44:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-489672 ] memory leak in test_sre Message-ID: Bugs item #489672, was opened at 2001-12-05 18:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 Category: Regular Expressions Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Fredrik Lundh (effbot) Summary: memory leak in test_sre Initial Comment: leak when running test_sre see attached file for details ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 19:44 Message: Logged In: YES user_id=6380 >From email. That was it. With two backslashes it leaks like a sieve. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 19:04 Message: Logged In: YES user_id=31435 Guido, did you take the snippet from email or from the web page? It doesn't "look right" in email (for a change!). The 2nd argument to re.sub must have two backslashes; one of them vanishes in the email version ... I'll try attaching it as a file. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 18:56 Message: Logged In: YES user_id=6380 Hm. For me (on Linux) that snippet doesn't leak at all. Are you sure this is it? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 18:35 Message: Logged In: YES user_id=31435 This derived snippet leaks at a prodigious rate: import re while 1: re.sub('(a)', '\1', 'a') Variations don't leak if the capturing group is removed from the regexp, or if the replacement text doesn't reference the group. I'm reassigning to /F based on that evidence (it appears to have to do with re.sub internals, not with a general Python screwup). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 15:18 Message: Logged In: YES user_id=31435 Hard? Unpleasant? Mine ! Reassigned to me, cuz in a moment of weakness I said I would. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 14:08 Message: Logged In: YES user_id=6380 It's hard to make progress on this. In a loop it doesn't leak or leaks too slowly to be useful. The code is not in a function so it's hard to whittle down effectively. The first leak reported by Purify is a string literal (or actially, 4 string literals); this isn't much of a hint since the code is chock full of those. The second leak reported is also a string, but one created through concatenation. There aren't too many of those in test_sre.py, but still, who knows which one it is... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 From noreply@sourceforge.net Fri Dec 7 04:09:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 20:09:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-489672 ] memory leak in test_sre Message-ID: Bugs item #489672, was opened at 2001-12-05 18:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 Category: Regular Expressions Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Guido van Rossum (gvanrossum) Summary: memory leak in test_sre Initial Comment: leak when running test_sre see attached file for details ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 20:09 Message: Logged In: YES user_id=6380 I think I've found this. There's a missing Py_DECREF(filter) in pattern_subx() in _sre.c. I'll check it in once I've got more confidence in the fix. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 19:44 Message: Logged In: YES user_id=6380 >From email. That was it. With two backslashes it leaks like a sieve. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 19:04 Message: Logged In: YES user_id=31435 Guido, did you take the snippet from email or from the web page? It doesn't "look right" in email (for a change!). The 2nd argument to re.sub must have two backslashes; one of them vanishes in the email version ... I'll try attaching it as a file. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 18:56 Message: Logged In: YES user_id=6380 Hm. For me (on Linux) that snippet doesn't leak at all. Are you sure this is it? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 18:35 Message: Logged In: YES user_id=31435 This derived snippet leaks at a prodigious rate: import re while 1: re.sub('(a)', '\1', 'a') Variations don't leak if the capturing group is removed from the regexp, or if the replacement text doesn't reference the group. I'm reassigning to /F based on that evidence (it appears to have to do with re.sub internals, not with a general Python screwup). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 15:18 Message: Logged In: YES user_id=31435 Hard? Unpleasant? Mine ! Reassigned to me, cuz in a moment of weakness I said I would. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 14:08 Message: Logged In: YES user_id=6380 It's hard to make progress on this. In a loop it doesn't leak or leaks too slowly to be useful. The code is not in a function so it's hard to whittle down effectively. The first leak reported by Purify is a string literal (or actially, 4 string literals); this isn't much of a hint since the code is chock full of those. The second leak reported is also a string, but one created through concatenation. There aren't too many of those in test_sre.py, but still, who knows which one it is... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 From noreply@sourceforge.net Fri Dec 7 04:13:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 20:13:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-489672 ] memory leak in test_sre Message-ID: Bugs item #489672, was opened at 2001-12-05 18:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 Category: Regular Expressions Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Guido van Rossum (gvanrossum) Summary: memory leak in test_sre Initial Comment: leak when running test_sre see attached file for details ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-06 20:13 Message: Logged In: YES user_id=31435 Heh -- I have the same fix and already have confidence. I was just about to check it in, but will wait to make sure you don't first. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 20:09 Message: Logged In: YES user_id=6380 I think I've found this. There's a missing Py_DECREF(filter) in pattern_subx() in _sre.c. I'll check it in once I've got more confidence in the fix. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 19:44 Message: Logged In: YES user_id=6380 >From email. That was it. With two backslashes it leaks like a sieve. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 19:04 Message: Logged In: YES user_id=31435 Guido, did you take the snippet from email or from the web page? It doesn't "look right" in email (for a change!). The 2nd argument to re.sub must have two backslashes; one of them vanishes in the email version ... I'll try attaching it as a file. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 18:56 Message: Logged In: YES user_id=6380 Hm. For me (on Linux) that snippet doesn't leak at all. Are you sure this is it? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 18:35 Message: Logged In: YES user_id=31435 This derived snippet leaks at a prodigious rate: import re while 1: re.sub('(a)', '\1', 'a') Variations don't leak if the capturing group is removed from the regexp, or if the replacement text doesn't reference the group. I'm reassigning to /F based on that evidence (it appears to have to do with re.sub internals, not with a general Python screwup). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 15:18 Message: Logged In: YES user_id=31435 Hard? Unpleasant? Mine ! Reassigned to me, cuz in a moment of weakness I said I would. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 14:08 Message: Logged In: YES user_id=6380 It's hard to make progress on this. In a loop it doesn't leak or leaks too slowly to be useful. The code is not in a function so it's hard to whittle down effectively. The first leak reported by Purify is a string literal (or actially, 4 string literals); this isn't much of a hint since the code is chock full of those. The second leak reported is also a string, but one created through concatenation. There aren't too many of those in test_sre.py, but still, who knows which one it is... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 From noreply@sourceforge.net Fri Dec 7 04:26:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 20:26:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-489670 ] memory leak in test_re Message-ID: Bugs item #489670, was opened at 2001-12-05 18:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489670&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None >Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Guido van Rossum (gvanrossum) Summary: memory leak in test_re Initial Comment: leak when running test_descr may be related to bug #485152 "memory leak from marshal.c (test_email)" see attached file for details ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 20:26 Message: Logged In: YES user_id=6380 Neil, can you test this one again? I'm expecting it's fixed by the fix to _sre.c that I checked in to fix the test_sre leak you reported. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 14:10 Message: Logged In: YES user_id=6380 Hard to say what's going on here, and hard to whittle it down (see my comments for the leak in test_sre.py -- they apply here too, since it's almost the same test suite). Again, all that Purify tells us is that the leaked object is a string (this time read from a .pyc file). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489670&group_id=5470 From noreply@sourceforge.net Fri Dec 7 04:26:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 20:26:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-489672 ] memory leak in test_sre Message-ID: Bugs item #489672, was opened at 2001-12-05 18:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 Category: Regular Expressions Group: Python 2.2 Status: Open Resolution: None >Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Fredrik Lundh (effbot) Summary: memory leak in test_sre Initial Comment: leak when running test_sre see attached file for details ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 20:26 Message: Logged In: YES user_id=6380 Checked in as _sre.c rev. 2.75. Fredrik, please review, and close unless you disagree. Neil, can you run your test again? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 20:13 Message: Logged In: YES user_id=31435 Heh -- I have the same fix and already have confidence. I was just about to check it in, but will wait to make sure you don't first. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 20:09 Message: Logged In: YES user_id=6380 I think I've found this. There's a missing Py_DECREF(filter) in pattern_subx() in _sre.c. I'll check it in once I've got more confidence in the fix. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 19:44 Message: Logged In: YES user_id=6380 >From email. That was it. With two backslashes it leaks like a sieve. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 19:04 Message: Logged In: YES user_id=31435 Guido, did you take the snippet from email or from the web page? It doesn't "look right" in email (for a change!). The 2nd argument to re.sub must have two backslashes; one of them vanishes in the email version ... I'll try attaching it as a file. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 18:56 Message: Logged In: YES user_id=6380 Hm. For me (on Linux) that snippet doesn't leak at all. Are you sure this is it? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 18:35 Message: Logged In: YES user_id=31435 This derived snippet leaks at a prodigious rate: import re while 1: re.sub('(a)', '\1', 'a') Variations don't leak if the capturing group is removed from the regexp, or if the replacement text doesn't reference the group. I'm reassigning to /F based on that evidence (it appears to have to do with re.sub internals, not with a general Python screwup). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 15:18 Message: Logged In: YES user_id=31435 Hard? Unpleasant? Mine ! Reassigned to me, cuz in a moment of weakness I said I would. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 14:08 Message: Logged In: YES user_id=6380 It's hard to make progress on this. In a loop it doesn't leak or leaks too slowly to be useful. The code is not in a function so it's hard to whittle down effectively. The first leak reported by Purify is a string literal (or actially, 4 string literals); this isn't much of a hint since the code is chock full of those. The second leak reported is also a string, but one created through concatenation. There aren't too many of those in test_sre.py, but still, who knows which one it is... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 From noreply@sourceforge.net Fri Dec 7 04:53:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 06 Dec 2001 20:53:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-489672 ] memory leak in test_sre Message-ID: Bugs item #489672, was opened at 2001-12-05 18:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 Category: Regular Expressions Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Fredrik Lundh (effbot) Summary: memory leak in test_sre Initial Comment: leak when running test_sre see attached file for details ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-06 20:53 Message: Logged In: YES user_id=31435 FYI, the substitution tests were the only ones that leaked when run in an infinite loop (I had broken test_re.py into a couple dozen distinct test files). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 20:26 Message: Logged In: YES user_id=6380 Checked in as _sre.c rev. 2.75. Fredrik, please review, and close unless you disagree. Neil, can you run your test again? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 20:13 Message: Logged In: YES user_id=31435 Heh -- I have the same fix and already have confidence. I was just about to check it in, but will wait to make sure you don't first. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 20:09 Message: Logged In: YES user_id=6380 I think I've found this. There's a missing Py_DECREF(filter) in pattern_subx() in _sre.c. I'll check it in once I've got more confidence in the fix. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 19:44 Message: Logged In: YES user_id=6380 >From email. That was it. With two backslashes it leaks like a sieve. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 19:04 Message: Logged In: YES user_id=31435 Guido, did you take the snippet from email or from the web page? It doesn't "look right" in email (for a change!). The 2nd argument to re.sub must have two backslashes; one of them vanishes in the email version ... I'll try attaching it as a file. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 18:56 Message: Logged In: YES user_id=6380 Hm. For me (on Linux) that snippet doesn't leak at all. Are you sure this is it? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 18:35 Message: Logged In: YES user_id=31435 This derived snippet leaks at a prodigious rate: import re while 1: re.sub('(a)', '\1', 'a') Variations don't leak if the capturing group is removed from the regexp, or if the replacement text doesn't reference the group. I'm reassigning to /F based on that evidence (it appears to have to do with re.sub internals, not with a general Python screwup). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 15:18 Message: Logged In: YES user_id=31435 Hard? Unpleasant? Mine ! Reassigned to me, cuz in a moment of weakness I said I would. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 14:08 Message: Logged In: YES user_id=6380 It's hard to make progress on this. In a loop it doesn't leak or leaks too slowly to be useful. The code is not in a function so it's hard to whittle down effectively. The first leak reported by Purify is a string literal (or actially, 4 string literals); this isn't much of a hint since the code is chock full of those. The second leak reported is also a string, but one created through concatenation. There aren't too many of those in test_sre.py, but still, who knows which one it is... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 From noreply@sourceforge.net Fri Dec 7 09:16:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 01:16:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-490168 ] shutil.copy(path, path) deletes contents Message-ID: Bugs item #490168, was opened at 2001-12-07 01:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490168&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copy(path, path) deletes contents Initial Comment: If source equals destination path the contents of the file is deleted. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490168&group_id=5470 From noreply@sourceforge.net Fri Dec 7 10:08:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 02:08:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-417634 ] configuring without C++ compiler name Message-ID: Bugs item #417634, was opened at 2001-04-20 07:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417634&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Michael Hudson (mwh) Summary: configuring without C++ compiler name Initial Comment: If you check out a clean copy of Python 2.1 on a Solaris 5.8 machine, and run: ./configure -with-cxx rather than: ./configure -with-cxx=g++ It generates a makefile with "CXX=yes", so "make" produces: bash-2.03$ make yes -c -g -O2 -Wall -Wstrict-prototypes -I. \ -I./Include -DHAVE_CONFIG_H \ -o Modules/ccpython.o \ ./Modules/ccpython.cc make: yes: Command not found ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-07 02:08 Message: Logged In: YES user_id=6656 Oh good grief, sf is such a *pain* sometimes. Trying again... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 11:38 Message: Logged In: YES user_id=6380 Where's the attached fix? Back to MWH. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-06 09:31 Message: Logged In: YES user_id=6656 Two options: (1) apply the braindead fix I've just attached (2) ignore the problem and close the report. I don't really have an opinion on which is better. An autoconf guru may have a better idea, but it hardly seems worth putting too much effort into. Assigned to Guido for a quick decision -- please don't think too hard about it! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417634&group_id=5470 From noreply@sourceforge.net Fri Dec 7 10:09:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 02:09:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-417634 ] configuring without C++ compiler name Message-ID: Bugs item #417634, was opened at 2001-04-20 07:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417634&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Guido van Rossum (gvanrossum) Summary: configuring without C++ compiler name Initial Comment: If you check out a clean copy of Python 2.1 on a Solaris 5.8 machine, and run: ./configure -with-cxx rather than: ./configure -with-cxx=g++ It generates a makefile with "CXX=yes", so "make" produces: bash-2.03$ make yes -c -g -O2 -Wall -Wstrict-prototypes -I. \ -I./Include -DHAVE_CONFIG_H \ -o Modules/ccpython.o \ ./Modules/ccpython.cc make: yes: Command not found ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-07 02:09 Message: Logged In: YES user_id=6656 Yay, it's there now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 02:08 Message: Logged In: YES user_id=6656 Oh good grief, sf is such a *pain* sometimes. Trying again... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 11:38 Message: Logged In: YES user_id=6380 Where's the attached fix? Back to MWH. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-06 09:31 Message: Logged In: YES user_id=6656 Two options: (1) apply the braindead fix I've just attached (2) ignore the problem and close the report. I don't really have an opinion on which is better. An autoconf guru may have a better idea, but it hardly seems worth putting too much effort into. Assigned to Guido for a quick decision -- please don't think too hard about it! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417634&group_id=5470 From noreply@sourceforge.net Fri Dec 7 10:21:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 02:21:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-445902 ] runtime_library_dirs and gcc don't mix Message-ID: Bugs item #445902, was opened at 2001-07-30 03:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445902&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 7 Submitted By: Gary Capell (gcapell) Assigned to: Nobody/Anonymous (nobody) Summary: runtime_library_dirs and gcc don't mix Initial Comment: providing runtime_library_dirs =["/foo"], setup.py build does: gcc -shared -R/foo ... whereas it requires gcc -shared -Wl,-R/foo to get the option through to the linker. My configuration: python2.1.1, gcc 2.9.6, binutils 2.10.91.0.2, redhat 7.1, intel Please let me know if I'm just doing something stupid. Thanks heaps for the distutils stuff, it makes playing with extensions way easier. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-07 02:21 Message: Logged In: YES user_id=21627 It is hackish, but it looks acceptable to me. When I applying this patch, I recommend to add a comment indicating what problem this fragment solves. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 13:57 Message: Logged In: YES user_id=3066 I've attached a proposed patch, but it's way too hackish, and doesn't generalize at all. But it probably solves the most common case. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-11 00:53 Message: Logged In: YES user_id=21627 It somewhat depends on the platform; on Solaris, gcc will accept -R. On Linux, it doesn't, so this is really distutils fault, not yours. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445902&group_id=5470 From noreply@sourceforge.net Fri Dec 7 11:34:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 03:34:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-489672 ] memory leak in test_sre Message-ID: Bugs item #489672, was opened at 2001-12-05 18:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 Category: Regular Expressions Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Fredrik Lundh (effbot) Summary: memory leak in test_sre Initial Comment: leak when running test_sre see attached file for details ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2001-12-07 03:34 Message: Logged In: YES user_id=38376 I'm currently doing an "on paper" code review, and had already spotted two possible leaks in pattern_subx. But not the same leaks, and not the big one. (With enough eyes... ;-) Thanks /F ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 20:53 Message: Logged In: YES user_id=31435 FYI, the substitution tests were the only ones that leaked when run in an infinite loop (I had broken test_re.py into a couple dozen distinct test files). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 20:26 Message: Logged In: YES user_id=6380 Checked in as _sre.c rev. 2.75. Fredrik, please review, and close unless you disagree. Neil, can you run your test again? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 20:13 Message: Logged In: YES user_id=31435 Heh -- I have the same fix and already have confidence. I was just about to check it in, but will wait to make sure you don't first. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 20:09 Message: Logged In: YES user_id=6380 I think I've found this. There's a missing Py_DECREF(filter) in pattern_subx() in _sre.c. I'll check it in once I've got more confidence in the fix. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 19:44 Message: Logged In: YES user_id=6380 >From email. That was it. With two backslashes it leaks like a sieve. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 19:04 Message: Logged In: YES user_id=31435 Guido, did you take the snippet from email or from the web page? It doesn't "look right" in email (for a change!). The 2nd argument to re.sub must have two backslashes; one of them vanishes in the email version ... I'll try attaching it as a file. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 18:56 Message: Logged In: YES user_id=6380 Hm. For me (on Linux) that snippet doesn't leak at all. Are you sure this is it? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 18:35 Message: Logged In: YES user_id=31435 This derived snippet leaks at a prodigious rate: import re while 1: re.sub('(a)', '\1', 'a') Variations don't leak if the capturing group is removed from the regexp, or if the replacement text doesn't reference the group. I'm reassigning to /F based on that evidence (it appears to have to do with re.sub internals, not with a general Python screwup). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-06 15:18 Message: Logged In: YES user_id=31435 Hard? Unpleasant? Mine ! Reassigned to me, cuz in a moment of weakness I said I would. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 14:08 Message: Logged In: YES user_id=6380 It's hard to make progress on this. In a loop it doesn't leak or leaks too slowly to be useful. The code is not in a function so it's hard to whittle down effectively. The first leak reported by Purify is a string literal (or actially, 4 string literals); this isn't much of a hint since the code is chock full of those. The second leak reported is also a string, but one created through concatenation. There aren't too many of those in test_sre.py, but still, who knows which one it is... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489672&group_id=5470 From noreply@sourceforge.net Fri Dec 7 12:27:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 04:27:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-486565 ] Mac OS 10.1: unobvious: --with-suffix Message-ID: Bugs item #486565, was opened at 2001-11-28 10:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486565&group_id=5470 Category: Macintosh Group: Python 2.2 >Status: Closed Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Jack Jansen (jackjansen) Summary: Mac OS 10.1: unobvious: --with-suffix Initial Comment: First attempts to install Python-2.2b2 under Mac OS 10.1 on a HFS+ filesystem failed at the point of linking the python executable. When browsing comp.lang.python it became clear that the --with- suffix=.exe configure option has to be used. Currently, configure only reports: checking for executable suffix... no checking for --with-suffix... It would be a big improvement if configure could issue a very visible warning, or even better, supply the suffix automatically and tell the user at the very end that python is python.exe. Thanks! Ralf ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-06 13:54 Message: Logged In: YES user_id=45365 Fixed in the CVS tree: we now check wether we're building on a case-insensitive file system, and if that is the case we add a .exe suffix to python, but only to the copy in the build directory. The installed binary doesn't get the suffix. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2001-11-28 14:01 Message: Logged In: YES user_id=71407 > Yes, this is a serious problem. Configure _does_ give a warning, ... I cannot even see the warning when I am looking for it. A full output of running 2.2b2 configure under MacOS 10.1 is available at this location: http://cci.lbl.gov/~rwgk/tmp/MacOS10.1_Python- 2.2b2_configure_output.txt Is the warning in there? > Would you happen to know of a way to test for this? You could simply try to detect the very feature that is causing the default build to fail: 1. Create an empty file with some dummy, lowercase name: touch zap 2. Now test the existence of the file under the uppercase name: test -f ZAP 3. On HFS, $status == 0, on UFS or NFS, $status == 1. Ralf ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-28 12:42 Message: Logged In: YES user_id=45365 Yes, this is a serious problem. Configure _does_ give a warning, but it gets lost in the stream of output it produces. The problem is that I don't know how to test whether we're building on an HFS+ filesystem. Only then should we add the --with-suffix automatically, if you're building on a UFS or NFS filesystem there is no problem. Would you happen to know of a way to test for this? Or should I simply always use --with-suffix on OSX? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=486565&group_id=5470 From noreply@sourceforge.net Fri Dec 7 12:36:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 04:36:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-472881 ] distutils does not deduce dependencies Message-ID: Bugs item #472881, was opened at 2001-10-19 11:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: distutils does not deduce dependencies Initial Comment: I just "cvs up"d my Python tree and executed "make". Nothing much changed, except patchlevel.h. Make got this right and rebuilt everything (patchlevel.h is included from Python.h, so changing patchlevel.h should cause make to rebuild just about everything). Distutils failed to notice this, however, so it didn't rebuild any modules. In this case, I think the failure to rebuild is probably innocuous, but I'm not at all confident it will do the right thing if I modify some other file. For example, I've noticed that it's not sufficient to delete a module's .o file when you want to rebuild it. Distutils still thinks the .so file is okay. If distutils is going to take the place of make I think it's going to need to do a much better job deducing file dependencies or provide a robust way for a person to tell it what those dependencies are. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-07 04:36 Message: Logged In: YES user_id=6656 Would a "good enough" solution be to check (in setup.py) if pyconfig.h or anything in Include/ has changed since the last build and if so blow away the & build directory? Doing a "proper" job seems frankly unlikely, and would have much the same effect as the above anyway for building Python... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470 From noreply@sourceforge.net Fri Dec 7 13:08:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 05:08:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-409430 ] pydoc install broken Message-ID: Bugs item #409430, was opened at 2001-03-17 10:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409430&group_id=5470 Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc install broken Initial Comment: I've moaned about this on python-dev but I want to make sure it doesn't get forgotten. I've just built from CVS, installed in /usr/local, and: $ pydoc -g Traceback (most recent call last): File "/usr/local/bin/pydoc", line 3, in ? import pydoc ImportError: No module named pydoc because the /usr/bin/env python thing hits the older python in /usr first. Don't really know how best to implement this, not being a distutils whiz. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:08 Message: Logged In: YES user_id=6656 I finally got off my fat butt and had a go at fixing this. I've no idea who to assign this to to get it reviewed, I'm afraid. Someone have a look please! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-11 07:40 Message: Logged In: YES user_id=6656 Oops, not paying attention. Revision 1.9 of Lib/distutils/command/build_scripts.py seemed to be aimed at fixing this; however, I now have a ~/bin/pydoc that starts: #!python which isn't too helpful. This command either needs to do something different when building Python, or a different command needs to be used to install the pydoc script. Or you could wedge the install path into sys.executable in setup.py, I suppose. Assigned to Greg, as I don't think he's had this patch yet. Also bumped priority, as we now seem to be installing decidely broken scripts, and changed summary. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-10 21:56 Message: Logged In: NO I am having similar problems with the win 2.1 ver it seems none of my saved .py files are recognised. Is this simply a case of not configed as an executable or a version clash? (solutions as well as opinions would be nice) I can however import string,sys and other modules if that muddies the water any. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 12:11 Message: Logged In: YES user_id=6380 OK, ping-pong. Ping, do you have any bright ideas? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-04-10 10:57 Message: Logged In: YES user_id=11375 The pydoc script is Ping's, really. Fixing this requires Distutils hackery, and I don't see that this is worth fixing. Leaving it to someone else to make the decision to close it, though. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-17 22:23 Message: Logged In: YES user_id=31435 Assigned to Andrew because I seem to recall he wrote the pydoc script. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409430&group_id=5470 From noreply@sourceforge.net Fri Dec 7 13:11:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 05:11:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-480480 ] pydoc #!/build-directory/python Message-ID: Bugs item #480480, was opened at 2001-11-10 16:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=480480&group_id=5470 Category: Distutils Group: Python 2.2 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Brian Zhou (bzhou) >Assigned to: Michael Hudson (mwh) Summary: pydoc #!/build-directory/python Initial Comment: Starting from source for example http://www.python.org/ftp/python/2.2/rpms/python2.2- 2.2b1-2.src.rpm "make install" copies and later packages a version of pydoc which has hard-coded #!/build-directory/python This pydoc will be installed on redhat 7.x. The unwanted dependency will also cause the binary RPM installation to fail on redhat 6.2. "make install" should be fixed to use "#!/usr/bin/env python" or simply pick-up Tools/scripts/pydoc. A quick workaround for rpm is to change the python-2.2.spec file: 162,163c162 < sed 's|#!/usr/bin/env python|#!/usr/bin/env python'%{binsuffix}'|' \ < pydoc.old >pydoc --- > sed 's|#!.*python$|#!/usr/bin/env python'% {binsuffix}'|' pydoc.old >pydoc ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:11 Message: Logged In: YES user_id=6656 I think this is a dup of #409430, which I've just attached a patch to. Please have a look! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 13:52 Message: Logged In: YES user_id=6380 Nobody knows how to fix this, so I'm lowering the priority -- it would take a miracle to fix this before 2.2 goes out. There is essentially nobody who maintains distutils at this point. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-11 07:02 Message: Logged In: YES user_id=21627 Putting in /usr/bin/env is certainly not the right solution. distutils was specifically designed to adjust the path of scripts, to make sure that the Python binary used at run-time is indeed the one used at installation time. Otherwise, the user may break pydoc by putting a different Python installation in front of the path. Instead, distutils should be fixed to assume that the Python interpreter will be in BINDIR. Recategorizing as distutils bug, and raising the priority. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=480480&group_id=5470 From noreply@sourceforge.net Fri Dec 7 13:16:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 05:16:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-443238 ] Perm. in ../lib/python2.2/lib-dynload Message-ID: Bugs item #443238, was opened at 2001-07-20 17:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443238&group_id=5470 Category: Installation Group: Python 2.2 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Andreas Jung (ajung) >Assigned to: Michael Hudson (mwh) Summary: Perm. in ../lib/python2.2/lib-dynload Initial Comment: "make install" does not set the permissions for all *.so to a+r. Instead u+rwx is set. All other files in the lib/python2.2 folder are fine. Env. Linux 2.4.5 i386 Andreas ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:16 Message: Logged In: YES user_id=6656 This is the same as #425007. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-17 09:59 Message: Logged In: YES user_id=6380 Andrew, can you look into this? ---------------------------------------------------------------------- Comment By: Allan Digiby (just_gnu_it) Date: 2001-07-22 01:10 Message: Logged In: YES user_id=277768 For a more detailed view, check out: 443490 || 2.2 Install on Linux/Mod Install Error ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443238&group_id=5470 From noreply@sourceforge.net Fri Dec 7 13:28:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 05:28:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-477371 ] build_scripts can use wrong #! line Message-ID: Bugs item #477371, was opened at 2001-11-01 19:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477371&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: build_scripts can use wrong #! line Initial Comment: When the build_scripts command is run, it places into build/scripts a copy of the script with the #! line modified to call the python version directly. But if you subsequently call setup.py with a different python version, the script is not updated to use the correct python executable path. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:28 Message: Logged In: YES user_id=6656 So don't do that then? Surely you're going to get problems with various other bits of distutils if you're not consistent about which Python you run setup.py with? Very much inclined to close this... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477371&group_id=5470 From noreply@sourceforge.net Fri Dec 7 13:40:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 05:40:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-472881 ] distutils does not deduce dependencies Message-ID: Bugs item #472881, was opened at 2001-10-19 11:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: distutils does not deduce dependencies Initial Comment: I just "cvs up"d my Python tree and executed "make". Nothing much changed, except patchlevel.h. Make got this right and rebuilt everything (patchlevel.h is included from Python.h, so changing patchlevel.h should cause make to rebuild just about everything). Distutils failed to notice this, however, so it didn't rebuild any modules. In this case, I think the failure to rebuild is probably innocuous, but I'm not at all confident it will do the right thing if I modify some other file. For example, I've noticed that it's not sufficient to delete a module's .o file when you want to rebuild it. Distutils still thinks the .so file is okay. If distutils is going to take the place of make I think it's going to need to do a much better job deducing file dependencies or provide a robust way for a person to tell it what those dependencies are. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 05:40 Message: Logged In: YES user_id=6380 Hm, how do you know when the last build was? Also, since in 99% of the cases this is unnecessary and rebuilding all extensions takes a long time, I'd like this to be optional -- maybe it can ask the user before zapping build? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 04:36 Message: Logged In: YES user_id=6656 Would a "good enough" solution be to check (in setup.py) if pyconfig.h or anything in Include/ has changed since the last build and if so blow away the & build directory? Doing a "proper" job seems frankly unlikely, and would have much the same effect as the above anyway for building Python... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470 From noreply@sourceforge.net Fri Dec 7 13:48:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 05:48:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-409430 ] pydoc install broken Message-ID: Bugs item #409430, was opened at 2001-03-17 10:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409430&group_id=5470 Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: pydoc install broken Initial Comment: I've moaned about this on python-dev but I want to make sure it doesn't get forgotten. I've just built from CVS, installed in /usr/local, and: $ pydoc -g Traceback (most recent call last): File "/usr/local/bin/pydoc", line 3, in ? import pydoc ImportError: No module named pydoc because the /usr/bin/env python thing hits the older python in /usr first. Don't really know how best to implement this, not being a distutils whiz. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 05:48 Message: Logged In: YES user_id=6380 Fred, can you have a quick look at this and bounce it back to MWH with a yea or nay? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:08 Message: Logged In: YES user_id=6656 I finally got off my fat butt and had a go at fixing this. I've no idea who to assign this to to get it reviewed, I'm afraid. Someone have a look please! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-11 07:40 Message: Logged In: YES user_id=6656 Oops, not paying attention. Revision 1.9 of Lib/distutils/command/build_scripts.py seemed to be aimed at fixing this; however, I now have a ~/bin/pydoc that starts: #!python which isn't too helpful. This command either needs to do something different when building Python, or a different command needs to be used to install the pydoc script. Or you could wedge the install path into sys.executable in setup.py, I suppose. Assigned to Greg, as I don't think he's had this patch yet. Also bumped priority, as we now seem to be installing decidely broken scripts, and changed summary. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-10 21:56 Message: Logged In: NO I am having similar problems with the win 2.1 ver it seems none of my saved .py files are recognised. Is this simply a case of not configed as an executable or a version clash? (solutions as well as opinions would be nice) I can however import string,sys and other modules if that muddies the water any. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 12:11 Message: Logged In: YES user_id=6380 OK, ping-pong. Ping, do you have any bright ideas? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-04-10 10:57 Message: Logged In: YES user_id=11375 The pydoc script is Ping's, really. Fixing this requires Distutils hackery, and I don't see that this is worth fixing. Leaving it to someone else to make the decision to close it, though. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-17 22:23 Message: Logged In: YES user_id=31435 Assigned to Andrew because I seem to recall he wrote the pydoc script. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409430&group_id=5470 From noreply@sourceforge.net Fri Dec 7 13:53:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 05:53:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-472881 ] distutils does not deduce dependencies Message-ID: Bugs item #472881, was opened at 2001-10-19 11:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: distutils does not deduce dependencies Initial Comment: I just "cvs up"d my Python tree and executed "make". Nothing much changed, except patchlevel.h. Make got this right and rebuilt everything (patchlevel.h is included from Python.h, so changing patchlevel.h should cause make to rebuild just about everything). Distutils failed to notice this, however, so it didn't rebuild any modules. In this case, I think the failure to rebuild is probably innocuous, but I'm not at all confident it will do the right thing if I modify some other file. For example, I've noticed that it's not sufficient to delete a module's .o file when you want to rebuild it. Distutils still thinks the .so file is okay. If distutils is going to take the place of make I think it's going to need to do a much better job deducing file dependencies or provide a robust way for a person to tell it what those dependencies are. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:53 Message: Logged In: YES user_id=6656 Eh, I was going to add a os.system("touch last_build") thingy to setup.py. Not aiming for elegance here. Is it really 99% of the time that changes in headers are irrelevant? Then what make does is a bit silly, surely. It would presumably be easy enough to ask the user, but I know I'd find that really annoying (I generally fire a biuld off, do something else for a few minutes and come back. OTOH, I almost always go through a "rm -rfv build && mkdir build && cd build && ../configure --prefix=$HOME && make" ritual anyway so this issue doesn't affect me in the slightest). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 05:40 Message: Logged In: YES user_id=6380 Hm, how do you know when the last build was? Also, since in 99% of the cases this is unnecessary and rebuilding all extensions takes a long time, I'd like this to be optional -- maybe it can ask the user before zapping build? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 04:36 Message: Logged In: YES user_id=6656 Would a "good enough" solution be to check (in setup.py) if pyconfig.h or anything in Include/ has changed since the last build and if so blow away the & build directory? Doing a "proper" job seems frankly unlikely, and would have much the same effect as the above anyway for building Python... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470 From noreply@sourceforge.net Fri Dec 7 13:54:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 05:54:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-409430 ] pydoc install broken Message-ID: Bugs item #409430, was opened at 2001-03-17 10:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409430&group_id=5470 Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: pydoc install broken Initial Comment: I've moaned about this on python-dev but I want to make sure it doesn't get forgotten. I've just built from CVS, installed in /usr/local, and: $ pydoc -g Traceback (most recent call last): File "/usr/local/bin/pydoc", line 3, in ? import pydoc ImportError: No module named pydoc because the /usr/bin/env python thing hits the older python in /usr first. Don't really know how best to implement this, not being a distutils whiz. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:54 Message: Logged In: YES user_id=6656 Please consider the obvious typo to be fixed; I've lost the "!" in the "#!", doh. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 05:48 Message: Logged In: YES user_id=6380 Fred, can you have a quick look at this and bounce it back to MWH with a yea or nay? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:08 Message: Logged In: YES user_id=6656 I finally got off my fat butt and had a go at fixing this. I've no idea who to assign this to to get it reviewed, I'm afraid. Someone have a look please! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-11 07:40 Message: Logged In: YES user_id=6656 Oops, not paying attention. Revision 1.9 of Lib/distutils/command/build_scripts.py seemed to be aimed at fixing this; however, I now have a ~/bin/pydoc that starts: #!python which isn't too helpful. This command either needs to do something different when building Python, or a different command needs to be used to install the pydoc script. Or you could wedge the install path into sys.executable in setup.py, I suppose. Assigned to Greg, as I don't think he's had this patch yet. Also bumped priority, as we now seem to be installing decidely broken scripts, and changed summary. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-10 21:56 Message: Logged In: NO I am having similar problems with the win 2.1 ver it seems none of my saved .py files are recognised. Is this simply a case of not configed as an executable or a version clash? (solutions as well as opinions would be nice) I can however import string,sys and other modules if that muddies the water any. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 12:11 Message: Logged In: YES user_id=6380 OK, ping-pong. Ping, do you have any bright ideas? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-04-10 10:57 Message: Logged In: YES user_id=11375 The pydoc script is Ping's, really. Fixing this requires Distutils hackery, and I don't see that this is worth fixing. Leaving it to someone else to make the decision to close it, though. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-17 22:23 Message: Logged In: YES user_id=31435 Assigned to Andrew because I seem to recall he wrote the pydoc script. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409430&group_id=5470 From noreply@sourceforge.net Fri Dec 7 14:54:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 06:54:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-472881 ] distutils does not deduce dependencies Message-ID: Bugs item #472881, was opened at 2001-10-19 11:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: distutils does not deduce dependencies Initial Comment: I just "cvs up"d my Python tree and executed "make". Nothing much changed, except patchlevel.h. Make got this right and rebuilt everything (patchlevel.h is included from Python.h, so changing patchlevel.h should cause make to rebuild just about everything). Distutils failed to notice this, however, so it didn't rebuild any modules. In this case, I think the failure to rebuild is probably innocuous, but I'm not at all confident it will do the right thing if I modify some other file. For example, I've noticed that it's not sufficient to delete a module's .o file when you want to rebuild it. Distutils still thinks the .so file is okay. If distutils is going to take the place of make I think it's going to need to do a much better job deducing file dependencies or provide a robust way for a person to tell it what those dependencies are. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 06:54 Message: Logged In: YES user_id=6380 It depends on what kind of change you are making to a header file. 99% of the time I find that a change to a header is something innocuous like add a new function, and it still causes a rebuild of the world. That's particularly annoying when I'm experimenting with a new object type and adding things to the header file one at a time -- each time the header gets touched everything gets rebuilt. But it's easy enough to only rebuild the core ("make python") so I'm not sure if I really oppose your simple solution. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:53 Message: Logged In: YES user_id=6656 Eh, I was going to add a os.system("touch last_build") thingy to setup.py. Not aiming for elegance here. Is it really 99% of the time that changes in headers are irrelevant? Then what make does is a bit silly, surely. It would presumably be easy enough to ask the user, but I know I'd find that really annoying (I generally fire a biuld off, do something else for a few minutes and come back. OTOH, I almost always go through a "rm -rfv build && mkdir build && cd build && ../configure --prefix=$HOME && make" ritual anyway so this issue doesn't affect me in the slightest). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 05:40 Message: Logged In: YES user_id=6380 Hm, how do you know when the last build was? Also, since in 99% of the cases this is unnecessary and rebuilding all extensions takes a long time, I'd like this to be optional -- maybe it can ask the user before zapping build? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 04:36 Message: Logged In: YES user_id=6656 Would a "good enough" solution be to check (in setup.py) if pyconfig.h or anything in Include/ has changed since the last build and if so blow away the & build directory? Doing a "proper" job seems frankly unlikely, and would have much the same effect as the above anyway for building Python... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470 From noreply@sourceforge.net Fri Dec 7 15:28:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 07:28:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-417634 ] configuring without C++ compiler name Message-ID: Bugs item #417634, was opened at 2001-04-20 07:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417634&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Michael Hudson (mwh) Summary: configuring without C++ compiler name Initial Comment: If you check out a clean copy of Python 2.1 on a Solaris 5.8 machine, and run: ./configure -with-cxx rather than: ./configure -with-cxx=g++ It generates a makefile with "CXX=yes", so "make" produces: bash-2.03$ make yes -c -g -O2 -Wall -Wstrict-prototypes -I. \ -I./Include -DHAVE_CONFIG_H \ -o Modules/ccpython.o \ ./Modules/ccpython.cc make: yes: Command not found ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 07:28 Message: Logged In: YES user_id=6380 That's about right, Michael. Please check it in and close the bug! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 02:09 Message: Logged In: YES user_id=6656 Yay, it's there now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 02:08 Message: Logged In: YES user_id=6656 Oh good grief, sf is such a *pain* sometimes. Trying again... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 11:38 Message: Logged In: YES user_id=6380 Where's the attached fix? Back to MWH. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-06 09:31 Message: Logged In: YES user_id=6656 Two options: (1) apply the braindead fix I've just attached (2) ignore the problem and close the report. I don't really have an opinion on which is better. An autoconf guru may have a better idea, but it hardly seems worth putting too much effort into. Assigned to Guido for a quick decision -- please don't think too hard about it! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417634&group_id=5470 From noreply@sourceforge.net Fri Dec 7 15:39:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 07:39:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-417634 ] configuring without C++ compiler name Message-ID: Bugs item #417634, was opened at 2001-04-20 07:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417634&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Michael Hudson (mwh) Summary: configuring without C++ compiler name Initial Comment: If you check out a clean copy of Python 2.1 on a Solaris 5.8 machine, and run: ./configure -with-cxx rather than: ./configure -with-cxx=g++ It generates a makefile with "CXX=yes", so "make" produces: bash-2.03$ make yes -c -g -O2 -Wall -Wstrict-prototypes -I. \ -I./Include -DHAVE_CONFIG_H \ -o Modules/ccpython.o \ ./Modules/ccpython.cc make: yes: Command not found ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-07 07:39 Message: Logged In: YES user_id=6656 Done in configure: 1.279 configure.in: 1.288 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 07:28 Message: Logged In: YES user_id=6380 That's about right, Michael. Please check it in and close the bug! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 02:09 Message: Logged In: YES user_id=6656 Yay, it's there now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 02:08 Message: Logged In: YES user_id=6656 Oh good grief, sf is such a *pain* sometimes. Trying again... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 11:38 Message: Logged In: YES user_id=6380 Where's the attached fix? Back to MWH. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-06 09:31 Message: Logged In: YES user_id=6656 Two options: (1) apply the braindead fix I've just attached (2) ignore the problem and close the report. I don't really have an opinion on which is better. An autoconf guru may have a better idea, but it hardly seems worth putting too much effort into. Assigned to Guido for a quick decision -- please don't think too hard about it! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417634&group_id=5470 From noreply@sourceforge.net Fri Dec 7 15:49:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 07:49:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-472881 ] distutils does not deduce dependencies Message-ID: Bugs item #472881, was opened at 2001-10-19 11:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Michael Hudson (mwh) Summary: distutils does not deduce dependencies Initial Comment: I just "cvs up"d my Python tree and executed "make". Nothing much changed, except patchlevel.h. Make got this right and rebuilt everything (patchlevel.h is included from Python.h, so changing patchlevel.h should cause make to rebuild just about everything). Distutils failed to notice this, however, so it didn't rebuild any modules. In this case, I think the failure to rebuild is probably innocuous, but I'm not at all confident it will do the right thing if I modify some other file. For example, I've noticed that it's not sufficient to delete a module's .o file when you want to rebuild it. Distutils still thinks the .so file is okay. If distutils is going to take the place of make I think it's going to need to do a much better job deducing file dependencies or provide a robust way for a person to tell it what those dependencies are. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-07 07:49 Message: Logged In: YES user_id=6656 OK, I'll try to get something concrete done in the next few days. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 06:54 Message: Logged In: YES user_id=6380 It depends on what kind of change you are making to a header file. 99% of the time I find that a change to a header is something innocuous like add a new function, and it still causes a rebuild of the world. That's particularly annoying when I'm experimenting with a new object type and adding things to the header file one at a time -- each time the header gets touched everything gets rebuilt. But it's easy enough to only rebuild the core ("make python") so I'm not sure if I really oppose your simple solution. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:53 Message: Logged In: YES user_id=6656 Eh, I was going to add a os.system("touch last_build") thingy to setup.py. Not aiming for elegance here. Is it really 99% of the time that changes in headers are irrelevant? Then what make does is a bit silly, surely. It would presumably be easy enough to ask the user, but I know I'd find that really annoying (I generally fire a biuld off, do something else for a few minutes and come back. OTOH, I almost always go through a "rm -rfv build && mkdir build && cd build && ../configure --prefix=$HOME && make" ritual anyway so this issue doesn't affect me in the slightest). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 05:40 Message: Logged In: YES user_id=6380 Hm, how do you know when the last build was? Also, since in 99% of the cases this is unnecessary and rebuilding all extensions takes a long time, I'd like this to be optional -- maybe it can ask the user before zapping build? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 04:36 Message: Logged In: YES user_id=6656 Would a "good enough" solution be to check (in setup.py) if pyconfig.h or anything in Include/ has changed since the last build and if so blow away the & build directory? Doing a "proper" job seems frankly unlikely, and would have much the same effect as the above anyway for building Python... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470 From noreply@sourceforge.net Fri Dec 7 15:55:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 07:55:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-490264 ] Portable compiler option specification Message-ID: Bugs item #490264, was opened at 2001-12-07 07:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490264&group_id=5470 Category: Distutils Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Konrad Hinsen (hinsen) Assigned to: A.M. Kuchling (akuchling) Summary: Portable compiler option specification Initial Comment: Distutils should provide a portable way for packagers to specify common compiler options, e.g. "maximum optimization", "debugging symbols" etc. These should be per-module options that can be specified in the setup script. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490264&group_id=5470 From noreply@sourceforge.net Fri Dec 7 16:08:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 08:08:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-475253 ] [OSX]ConfigPython fails 4 non-admin user Message-ID: Bugs item #475253, was opened at 2001-10-26 03:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=475253&group_id=5470 Category: Macintosh Group: Platform-specific >Status: Closed Resolution: None Priority: 5 Submitted By: Ryan Wilcox (ryanwilcox) Assigned to: Jack Jansen (jackjansen) Summary: [OSX]ConfigPython fails 4 non-admin user Initial Comment: ConfigurePythonCarbon fails on users that don't have admin privs. (It tries towrite PythonCore to /Library/ and fails, for obvious reasons). Having this fail means the IDE fails to build, and, well... ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-07 08:08 Message: Logged In: YES user_id=45365 Fixed in CVS. We now continue with ConfigurePython, and we give a better error message too (explaining that we didn't copy PythonCore for system-wide access, and that this means applets have to reside in the main Python folder to be able to run). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=475253&group_id=5470 From noreply@sourceforge.net Fri Dec 7 16:44:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 08:44:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-485150 ] memory leak from marshal.c (test_email) Message-ID: Bugs item #485150, was opened at 2001-11-24 11:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485150&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Guido van Rossum (gvanrossum) Summary: memory leak from marshal.c (test_email) Initial Comment: marshal.c seems to be the culprit in leaking data from running test_email see attached file for details ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 08:44 Message: Logged In: YES user_id=6380 According to mail from Neal, this is fixed -- probably by some other leak fix. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 19:43 Message: Logged In: YES user_id=6380 I can't get any of the test suites from test_email.py to grow when I place them in a loop. Maybe this is another one-time leak? Or maybe the leak is related to import? (Historically, there have often been small one-time leaks in import -- these are hard to find but also relatively unimportant, since one rarely re-imports modules over and over.) If that's the case, maybe it's possible to construct a test case out of a small module that's reloaded over and over? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 14:12 Message: Logged In: YES user_id=6380 It's not marshal's fault -- we see this all the time when a constant loaded from a .pyc file is leaked by some code that gets it passed in as an argument. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:04 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485150&group_id=5470 From noreply@sourceforge.net Fri Dec 7 16:44:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 08:44:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-489670 ] memory leak in test_re Message-ID: Bugs item #489670, was opened at 2001-12-05 18:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489670&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Guido van Rossum (gvanrossum) Summary: memory leak in test_re Initial Comment: leak when running test_descr may be related to bug #485152 "memory leak from marshal.c (test_email)" see attached file for details ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 08:44 Message: Logged In: YES user_id=6380 According to Neal this no longer leaks. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 20:26 Message: Logged In: YES user_id=6380 Neil, can you test this one again? I'm expecting it's fixed by the fix to _sre.c that I checked in to fix the test_sre leak you reported. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 14:10 Message: Logged In: YES user_id=6380 Hard to say what's going on here, and hard to whittle it down (see my comments for the leak in test_sre.py -- they apply here too, since it's almost the same test suite). Again, all that Purify tells us is that the leaked object is a string (this time read from a .pyc file). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489670&group_id=5470 From noreply@sourceforge.net Fri Dec 7 16:46:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 08:46:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-485139 ] mem leak in interpreter from syntax err Message-ID: Bugs item #485139, was opened at 2001-11-24 10:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485139&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Wont Fix Priority: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Guido van Rossum (gvanrossum) Summary: mem leak in interpreter from syntax err Initial Comment: when a syntax error occurs in the interpreter, the interpreter leaks see the attached file for more info ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 08:46 Message: Logged In: YES user_id=6380 Neal writes: --- I tried: for i in range(1000): try: import t2 except SyntaxError: print But that doesn't leak. I think the reason it doesn't leak is because of the try/except. I opened the interpreter and interactively created syntax errors (=, =, ...) and it leaked for each error, not just once 874 bytes, instead of 38 for 1. If there is a way to raise a syntax error without exitting the interpreterr I think it could blow up faster. ----- My comment: if it only leaks when you don't catch it, that doesn't bother me much, since that's the end of the process. :-) So I'm closing this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 19:11 Message: Logged In: YES user_id=6380 Neil, can you provide more evidence? I can't see this leak in a loop, like this: | while 1: | try: compile("/", "", "exec") | except SyntaxError: pass ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:05 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485139&group_id=5470 From noreply@sourceforge.net Fri Dec 7 17:13:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 09:13:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-485139 ] mem leak in interpreter from syntax err Message-ID: Bugs item #485139, was opened at 2001-11-24 10:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485139&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Open Resolution: Wont Fix Priority: 7 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Tim Peters (tim_one) Summary: mem leak in interpreter from syntax err Initial Comment: when a syntax error occurs in the interpreter, the interpreter leaks see the attached file for more info ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-07 09:13 Message: Logged In: YES user_id=31435 Reopened and assigned to me. I don't care about a leak on an uncaught syntax error, but something Neal said reminded me of a problem that's repeatedly wasted my time: "enter something at a debug-mode interactive prompt repeatedly" often exhibits "and lose a refcount each time" behavior. Like so: >>> 1 1 [7026 refs] >>> class C: pass ... [7036 refs] >>> class C: pass ... [7037 refs] >>> class C: pass ... [7038 refs] >>> class C: pass ... [7039 refs] >>> Several times this has fooled me into looking for leaks that don't exist. >>> def f(): pass ... [7056 refs] >>> def f(): pass ... [7057 refs] >>> def f(): pass ... [7058 refs] >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 08:46 Message: Logged In: YES user_id=6380 Neal writes: --- I tried: for i in range(1000): try: import t2 except SyntaxError: print But that doesn't leak. I think the reason it doesn't leak is because of the try/except. I opened the interpreter and interactively created syntax errors (=, =, ...) and it leaked for each error, not just once 874 bytes, instead of 38 for 1. If there is a way to raise a syntax error without exitting the interpreterr I think it could blow up faster. ----- My comment: if it only leaks when you don't catch it, that doesn't bother me much, since that's the end of the process. :-) So I'm closing this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 19:11 Message: Logged In: YES user_id=6380 Neil, can you provide more evidence? I can't see this leak in a loop, like this: | while 1: | try: compile("/", "", "exec") | except SyntaxError: pass ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:05 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485139&group_id=5470 From noreply@sourceforge.net Fri Dec 7 17:43:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 09:43:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-484950 ] docs suggest no cyclic garbage collectio Message-ID: Bugs item #484950, was opened at 2001-11-23 10:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=484950&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: docs suggest no cyclic garbage collectio Initial Comment: http://python.sourceforge.net/devel-docs/ext/refcounts.html Section 1.10 is a bit out of date -- it would lead some readers to believe that Python doesn't collect cyclical garbage. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-07 09:43 Message: Logged In: YES user_id=3066 Added more information about refcounting and the cycle detector in Doc/ext/extending.tex revision 1.9. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2001-11-28 05:52 Message: Logged In: YES user_id=52562 The last paragraph contrasts Python's chosen strategy, reference counting, with the more standard "automatic garbage collection". Most readers will know that reference counting suffers from the problem of not collecting cyclical garbage where garbage collection does not. Thus, seeing the two contrasted like this, and the reason for Python's lack of garbage collection being given as "there isn't a good one available", they may infer that Python doesn't collect cyclical garbage. I suggest to strike the last paragraph and replace it with something like: """ The strategy of reference counting traditionally suffers from the problem that the interpreter doesn't collect "cyclical garbage". Cyclical garbage is a set of objects which have been unlinked so that they are unreachable, but they contain references to each other so that each object's counter is non-zero. As of version 2.0, Python includes a "garbage cycle collector" which recovers the memory from cyclical garbage as well. (Note that there is an important caveat that the cycle collector does not free objects which contain `__del__' methods, although the normal non-cyclic reference counting system will free those objects. Please see XXX for more information.) """ Regards, Zooko ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-27 22:28 Message: Logged In: YES user_id=3066 Oops, that was *pending*, not closed! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-27 22:19 Message: Logged In: YES user_id=3066 I must be missing something; what makes you think this implies cyclical garbage isn't collected? Marked pending awaiting further information. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=484950&group_id=5470 From noreply@sourceforge.net Fri Dec 7 18:03:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 10:03:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-476884 ] Configparser line continuations fail Message-ID: Bugs item #476884, was opened at 2001-10-31 10:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476884&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Configparser line continuations fail Initial Comment: Configparser line continuations fail with a key error when the option is of mixed case. Configparser maps all options to lowercase (presumably for Win compatibility) but it does the mapping through a method call (optionxform) which leaves the option name (optname) untransformed. This causes a dictionary key error when continuation lines are encountered since the untransformed optname is used to build the continued line. There are at least three possible fixes: 1. Make options case sensitive by eliminating the optionxform method. (My workaround is to overload the optionsxform method...) 2. Replace optname by it's lower case equivalent when it is constructed and use the lower case form throughout. 3. Insert calls to optionxform where the continuation lines are built. Messy and inefficient, IMHO. For greatest generality, there ought to be parameters which manage case sensitivity for section names and option names. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-07 10:03 Message: Logged In: YES user_id=3066 This is a duplicate of SF bug #432369; already fixed by the checkin for revision 1.33. This will be included in Python versions 2.1.2 and 2.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-31 13:09 Message: Logged In: YES user_id=6380 Assigned to Fred. Fred, didn't you dabble some in ConfigParser? You might want to have a look at some of the other open ConfigParser bugs too. Or you can pass this off to someone who knows more about it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476884&group_id=5470 From noreply@sourceforge.net Fri Dec 7 21:04:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 13:04:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-490399 ] ConfigParser and nonexistent file Message-ID: Bugs item #490399, was opened at 2001-12-07 13:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490399&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Cowles (mdcowles) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ConfigParser and nonexistent file Initial Comment: If you give ConfigParser's read() method the name of a file that doesn't exist, you get back an empty database. That may be reasonable but since other modules from the standard library generally don't work that way (dbm, netrc), it may be worth emphasizing in the documentation that that's what happens. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490399&group_id=5470 From noreply@sourceforge.net Fri Dec 7 21:39:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 13:39:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-490399 ] ConfigParser and nonexistent file Message-ID: Bugs item #490399, was opened at 2001-12-07 13:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490399&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthew Cowles (mdcowles) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ConfigParser and nonexistent file Initial Comment: If you give ConfigParser's read() method the name of a file that doesn't exist, you get back an empty database. That may be reasonable but since other modules from the standard library generally don't work that way (dbm, netrc), it may be worth emphasizing in the documentation that that's what happens. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-07 13:39 Message: Logged In: YES user_id=3066 No, that's not reasonable at all, but we can't change it this late in the game. ;-( I've added an explanation of this and how it can be used effectively in Doc/lib/libcfgparser.tex revisions 1.21 and 1.16.4.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490399&group_id=5470 From noreply@sourceforge.net Fri Dec 7 22:00:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 14:00:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-490098 ] dumbdbm docs: flag,mode ignored Message-ID: Bugs item #490098, was opened at 2001-12-06 18:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490098&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: dumbdbm docs: flag,mode ignored Initial Comment: The docs for dumbdbm contain references to flags and modes, but don't note that these are utterly ignored by the dumbdbm module. In particular, anyone using the docs and assuming the 'n' flag works as described will find their life getting unpleasant. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-07 14:00 Message: Logged In: YES user_id=3066 Fixed dumbdbm to honor the mode argument (Lib/dumbdbm.py revision 1.15), and documented that it was ignored in older versions; also that the flag argument is ignored (Doc/lib/libanydbm.tex revision 1.20). Revised documentation for Python 2.1.2 to reflect that both are ignored in that version (Doc/lib/libanydbm.tex revision 1.18.12.1). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490098&group_id=5470 From noreply@sourceforge.net Fri Dec 7 23:02:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 15:02:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-490453 ] OpenUNIX 8: No Compile/Run Message-ID: Bugs item #490453, was opened at 2001-12-07 15:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Larry Rosenman (ler) Assigned to: Nobody/Anonymous (nobody) Summary: OpenUNIX 8: No Compile/Run Initial Comment: On OpenUNIX 8, nothing seems to compile. Y''ou seem to use ld instead of cc for building the shared objects, which is wrong. Also, there seems to be other issues with symbol referencing errors. I've given accounts on my box before, and I'm willing to do that again. I believe there are serious issues with this build. (2.1.1 of Python, BTW). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 From noreply@sourceforge.net Fri Dec 7 23:06:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 15:06:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-490453 ] OpenUNIX 8: No Compile/Run Message-ID: Bugs item #490453, was opened at 2001-12-07 15:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Larry Rosenman (ler) Assigned to: Nobody/Anonymous (nobody) Summary: OpenUNIX 8: No Compile/Run Initial Comment: On OpenUNIX 8, nothing seems to compile. Y''ou seem to use ld instead of cc for building the shared objects, which is wrong. Also, there seems to be other issues with symbol referencing errors. I've given accounts on my box before, and I'm willing to do that again. I believe there are serious issues with this build. (2.1.1 of Python, BTW). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 15:06 Message: Logged In: YES user_id=6380 Thanks for the offer. I don't have time to sort this out, but maybe someone else who reads these notes does. (What *IS* OpenUNIX 8???) You can also try to resolve this yourself -- the configure script has a few case statements on the platform where it sets the various compilers and linkers (and their options) used for various actions. A patch would be most appreciated. You might also consider trying Python 2.2b2, which has somewhat improved the build procedure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 From noreply@sourceforge.net Fri Dec 7 23:09:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 15:09:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-490453 ] OpenUNIX 8: No Compile/Run Message-ID: Bugs item #490453, was opened at 2001-12-07 15:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Larry Rosenman (ler) Assigned to: Nobody/Anonymous (nobody) Summary: OpenUNIX 8: No Compile/Run Initial Comment: On OpenUNIX 8, nothing seems to compile. Y''ou seem to use ld instead of cc for building the shared objects, which is wrong. Also, there seems to be other issues with symbol referencing errors. I've given accounts on my box before, and I'm willing to do that again. I believe there are serious issues with this build. (2.1.1 of Python, BTW). ---------------------------------------------------------------------- >Comment By: Larry Rosenman (ler) Date: 2001-12-07 15:09 Message: Logged In: YES user_id=36452 OpenUNIX 8 is the follow- on from SCO UnixWare 7.1.1. It is from Caldera. I' ll try and figure it out, but... I believe loewis has the ID/PW for an account on my box (lerami.lerctr.org [207.158.72.11]), and I'll gladly make more if you folks want. Larry ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 15:06 Message: Logged In: YES user_id=6380 Thanks for the offer. I don't have time to sort this out, but maybe someone else who reads these notes does. (What *IS* OpenUNIX 8???) You can also try to resolve this yourself -- the configure script has a few case statements on the platform where it sets the various compilers and linkers (and their options) used for various actions. A patch would be most appreciated. You might also consider trying Python 2.2b2, which has somewhat improved the build procedure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 From noreply@sourceforge.net Sat Dec 8 01:03:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 17:03:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-487390 ] Modifying type.__module__ behavior Message-ID: Bugs item #487390, was opened at 2001-11-29 21:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487390&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Burton Radons (loth) Assigned to: Guido van Rossum (gvanrossum) Summary: Modifying type.__module__ behavior Initial Comment: A __module__ attribute request on a C type will return __builtin__ if the typeobject.c code cannot find a period in the type name. This is always incorrect for extension libraries, and can be a _very_ confusing error when trying to pickle your types (as the error makes it seem as if you're supposed to register your type in __builtin__). I propose that: A) All builtin Python types have a "__builtin__." prefixed to their type declaration's name. B) If the __module__ code cannot find a period, it raises AttributeError with a somewhat descriptive message. This would be in the place where it returns __builtin__. C) The tp_name comment in Include/object.h describe the special semantics. "/* 'module.typename' */", for example. This is a lot of files to change, I know, but it's only one or two line changes each file. The only code this should affect is code which is written incorrectly; it may not understand the name semantics, or it may actually be registering itself in __builtin__ (as I did before I figured out what it was doing). Otherwise we're golden. ---------------------------------------------------------------------- >Comment By: Burton Radons (loth) Date: 2001-12-07 17:03 Message: Logged In: YES user_id=2441 Sorry about the delay. I've attached a patch doing described and threw in patches to fix Module and Mac type names as well, if it so pleases. If it does not, I can amend. Further complications came in with PyStructSequence_InitType, which sets tp_name to a passed descriptor's field. I merely patched all the places that use the function. "__module__" should now be a guaranteed correct attribute amongst Python and the modules. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 08:41 Message: Logged In: YES user_id=6380 I agree with this in principle, but I don't hve the time to make all the changes. Can you submit a patch? Since, as you say, it's so simple, I wouldn't object against including it in 2.2c1, if it's submitted in time (2.2c1 is planned for December 12 -- give us a couple of days before that). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487390&group_id=5470 From noreply@sourceforge.net Sat Dec 8 02:13:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 18:13:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-477371 ] build_scripts can use wrong #! line Message-ID: Bugs item #477371, was opened at 2001-11-01 19:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477371&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: build_scripts can use wrong #! line Initial Comment: When the build_scripts command is run, it places into build/scripts a copy of the script with the #! line modified to call the python version directly. But if you subsequently call setup.py with a different python version, the script is not updated to use the correct python executable path. ---------------------------------------------------------------------- >Comment By: Matthew Mueller (donut) Date: 2001-12-07 18:13 Message: Logged In: YES user_id=65253 Uh, I guess maybe it doesn't bother you, but it sees an odd inconsistancy that build_ext puts its generated files in version-specific dirs, yet build_scripts makes no attempt to handle it. If you are never supposed to run setup.py with more than one version of python then why does build_ext handle it? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:28 Message: Logged In: YES user_id=6656 So don't do that then? Surely you're going to get problems with various other bits of distutils if you're not consistent about which Python you run setup.py with? Very much inclined to close this... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477371&group_id=5470 From noreply@sourceforge.net Sat Dec 8 02:33:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 18:33:45 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-434329 ] Expose tk_chooseDirectory in tkFileDialo Message-ID: Feature Requests item #434329, was opened at 2001-06-18 18:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=434329&group_id=5470 Category: None Group: None >Status: Closed Priority: 5 Submitted By: Matthew Cowles (mdcowles) Assigned to: Nobody/Anonymous (nobody) Summary: Expose tk_chooseDirectory in tkFileDialo Initial Comment: Tk now provides a directory chooser dialog (tk_chooseDirectory) in addition to the file save and open dialogs. It would be nice to expose it in tkFileDialog. This was suggested in comp.lang.python article <40f7645c.0106070944.4d71d203@posting.google.com> (The article is also the first hit in a Google Usenet search for tkinter directory chooser.) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-07 18:33 Message: Logged In: YES user_id=21627 Implemented in Python 2.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=434329&group_id=5470 From noreply@sourceforge.net Sat Dec 8 05:22:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 21:22:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-487390 ] Modifying type.__module__ behavior Message-ID: Bugs item #487390, was opened at 2001-11-29 21:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487390&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Burton Radons (loth) Assigned to: Guido van Rossum (gvanrossum) Summary: Modifying type.__module__ behavior Initial Comment: A __module__ attribute request on a C type will return __builtin__ if the typeobject.c code cannot find a period in the type name. This is always incorrect for extension libraries, and can be a _very_ confusing error when trying to pickle your types (as the error makes it seem as if you're supposed to register your type in __builtin__). I propose that: A) All builtin Python types have a "__builtin__." prefixed to their type declaration's name. B) If the __module__ code cannot find a period, it raises AttributeError with a somewhat descriptive message. This would be in the place where it returns __builtin__. C) The tp_name comment in Include/object.h describe the special semantics. "/* 'module.typename' */", for example. This is a lot of files to change, I know, but it's only one or two line changes each file. The only code this should affect is code which is written incorrectly; it may not understand the name semantics, or it may actually be registering itself in __builtin__ (as I did before I figured out what it was doing). Otherwise we're golden. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 21:22 Message: Logged In: YES user_id=6380 Thanks. Unfortunately, ten standard tests fail with these patches. I have a set of fixes, but I believe that the set of fixes needed could be much smaller if we did *not* add the "__builtin__." in front of all built-in types. Their __module__ will still have the correct value "__builtin__" because it defaults that way, and various bits of code that print or test tp_name won't suddenly see "__builtin__." where it wasn't before. (The worst case was cPickle, which switches on the first char of tp_name as a speed hack -- this caused mysterious failures in test_cookie and test_sre.) What do you think of this idea? IMO the rest of your patch still implements an important improvement. ---------------------------------------------------------------------- Comment By: Burton Radons (loth) Date: 2001-12-07 17:03 Message: Logged In: YES user_id=2441 Sorry about the delay. I've attached a patch doing described and threw in patches to fix Module and Mac type names as well, if it so pleases. If it does not, I can amend. Further complications came in with PyStructSequence_InitType, which sets tp_name to a passed descriptor's field. I merely patched all the places that use the function. "__module__" should now be a guaranteed correct attribute amongst Python and the modules. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 08:41 Message: Logged In: YES user_id=6380 I agree with this in principle, but I don't hve the time to make all the changes. Can you submit a patch? Since, as you say, it's so simple, I wouldn't object against including it in 2.2c1, if it's submitted in time (2.2c1 is planned for December 12 -- give us a couple of days before that). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487390&group_id=5470 From noreply@sourceforge.net Sat Dec 8 05:51:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 21:51:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-485139 ] mem leak in interpreter from syntax err Message-ID: Bugs item #485139, was opened at 2001-11-24 10:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485139&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: Wont Fix >Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Tim Peters (tim_one) Summary: mem leak in interpreter from syntax err Initial Comment: when a syntax error occurs in the interpreter, the interpreter leaks see the attached file for more info ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-07 21:51 Message: Logged In: YES user_id=31435 Well, this just gets more mysterious the longer I stare at it. I added a routine to compute the sum of all the refcounts in the objects in the refchain, and fiddled PyRun_InteractiveLoopFlags to print that sum after printing _Py_RefTotal. That's the first mystery: C:\Code\python\PCbuild>python_d Adding parser accelerators ... Done. Python 2.2b2+ (#26, Dec 7 2001, 19:25:48) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> [7004 refs] # _Py_RefTotal [6540 sum] # sum of ob_refcnt across refchain objs That is, right off the bat, _Py_RefTotal is 536 larger than the sum of all refcounts in all known objects. I hoped they'd be equal. At least these stay in synch across lots of input expressions: >>> 1 1 [7006 refs] [6542 sum] Both went up by 2 there. >>> [] [] [7011 refs] [6547 sum] And both up by 5. >>> () () [7011 refs] [6547 sum] No change. >>> {} {} [7011 refs] [6547 sum] No change. >>> 2.3 2.2999999999999998 [7011 refs] [6547 sum] No change. Now comes another Mystery: >>> def f(): pass ... [7028 refs] [6562 sum] That is, _Py_RefTotal went up by 17, but the sum of all refcounts only went up by 15. What's up with that? Then both "leak" 1 for each repetition of a function defn: >>> def f(): pass ... [7029 refs] [6563 sum] >>> def f(): pass ... [7030 refs] [6564 sum] >>> def f(): pass ... [7031 refs] [6565 sum] >>> That makes three mysteries. There's no other evidence of an actual leak, though! In particular, >>> import sys [7036 refs] [6570 sum] >>> for i in range(10): ... def f(): pass ... print sys.gettotalrefcount() ... 7075 7075 7075 7075 7075 7075 7075 7075 7075 7075 [7037 refs] [6571 sum] >>> That is, _PyRef_Total is *not* going up by 1 on each "def f (): pass" if the def stmt is inside a loop. Reducing the priority since this is such a pit. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-07 09:13 Message: Logged In: YES user_id=31435 Reopened and assigned to me. I don't care about a leak on an uncaught syntax error, but something Neal said reminded me of a problem that's repeatedly wasted my time: "enter something at a debug-mode interactive prompt repeatedly" often exhibits "and lose a refcount each time" behavior. Like so: >>> 1 1 [7026 refs] >>> class C: pass ... [7036 refs] >>> class C: pass ... [7037 refs] >>> class C: pass ... [7038 refs] >>> class C: pass ... [7039 refs] >>> Several times this has fooled me into looking for leaks that don't exist. >>> def f(): pass ... [7056 refs] >>> def f(): pass ... [7057 refs] >>> def f(): pass ... [7058 refs] >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 08:46 Message: Logged In: YES user_id=6380 Neal writes: --- I tried: for i in range(1000): try: import t2 except SyntaxError: print But that doesn't leak. I think the reason it doesn't leak is because of the try/except. I opened the interpreter and interactively created syntax errors (=, =, ...) and it leaked for each error, not just once 874 bytes, instead of 38 for 1. If there is a way to raise a syntax error without exitting the interpreterr I think it could blow up faster. ----- My comment: if it only leaks when you don't catch it, that doesn't bother me much, since that's the end of the process. :-) So I'm closing this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 19:11 Message: Logged In: YES user_id=6380 Neil, can you provide more evidence? I can't see this leak in a loop, like this: | while 1: | try: compile("/", "", "exec") | except SyntaxError: pass ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:05 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485139&group_id=5470 From noreply@sourceforge.net Sat Dec 8 05:56:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 07 Dec 2001 21:56:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-487390 ] Modifying type.__module__ behavior Message-ID: Bugs item #487390, was opened at 2001-11-29 21:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487390&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Burton Radons (loth) Assigned to: Guido van Rossum (gvanrossum) Summary: Modifying type.__module__ behavior Initial Comment: A __module__ attribute request on a C type will return __builtin__ if the typeobject.c code cannot find a period in the type name. This is always incorrect for extension libraries, and can be a _very_ confusing error when trying to pickle your types (as the error makes it seem as if you're supposed to register your type in __builtin__). I propose that: A) All builtin Python types have a "__builtin__." prefixed to their type declaration's name. B) If the __module__ code cannot find a period, it raises AttributeError with a somewhat descriptive message. This would be in the place where it returns __builtin__. C) The tp_name comment in Include/object.h describe the special semantics. "/* 'module.typename' */", for example. This is a lot of files to change, I know, but it's only one or two line changes each file. The only code this should affect is code which is written incorrectly; it may not understand the name semantics, or it may actually be registering itself in __builtin__ (as I did before I figured out what it was doing). Otherwise we're golden. ---------------------------------------------------------------------- >Comment By: Burton Radons (loth) Date: 2001-12-07 21:56 Message: Logged In: YES user_id=2441 I should have remembered the test suite, sorry. Pickling had the highest chance of messing up with the change, but I didn't even think of trying it with the lovely set of tests available. Go ahead, remove the "__builtin__." part of the patch. I've put up a modified patch that is missing the __builtin__ changes and the change to __module__ behaviour, if you want one; simple hack job. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 21:22 Message: Logged In: YES user_id=6380 Thanks. Unfortunately, ten standard tests fail with these patches. I have a set of fixes, but I believe that the set of fixes needed could be much smaller if we did *not* add the "__builtin__." in front of all built-in types. Their __module__ will still have the correct value "__builtin__" because it defaults that way, and various bits of code that print or test tp_name won't suddenly see "__builtin__." where it wasn't before. (The worst case was cPickle, which switches on the first char of tp_name as a speed hack -- this caused mysterious failures in test_cookie and test_sre.) What do you think of this idea? IMO the rest of your patch still implements an important improvement. ---------------------------------------------------------------------- Comment By: Burton Radons (loth) Date: 2001-12-07 17:03 Message: Logged In: YES user_id=2441 Sorry about the delay. I've attached a patch doing described and threw in patches to fix Module and Mac type names as well, if it so pleases. If it does not, I can amend. Further complications came in with PyStructSequence_InitType, which sets tp_name to a passed descriptor's field. I merely patched all the places that use the function. "__module__" should now be a guaranteed correct attribute amongst Python and the modules. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 08:41 Message: Logged In: YES user_id=6380 I agree with this in principle, but I don't hve the time to make all the changes. Can you submit a patch? Since, as you say, it's so simple, I wouldn't object against including it in 2.2c1, if it's submitted in time (2.2c1 is planned for December 12 -- give us a couple of days before that). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487390&group_id=5470 From noreply@sourceforge.net Sat Dec 8 10:14:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 02:14:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-490558 ] Missing Snd functions Message-ID: Bugs item #490558, was opened at 2001-12-08 02:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490558&group_id=5470 Category: Macintosh Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jason Harper (jasonharper) Assigned to: Jack Jansen (jackjansen) Summary: Missing Snd functions Initial Comment: A few minor omissions in the Carbon.Snd module as of 2.2b2: SndPlay and SndStartFilePlay are exposed only as methods of sound channel objects. However, these are usefully called with a NULL sound channel, in which case a channel is internally allocated for the duration of the call (and the 'async' parameter is ignored). SndRecord is completely missing (as is SndRecordToFile, but that isn't supported in Carbon) - yes, there is SPBRecord, but that's a lower-level routine that doesn't present a user interface for recording. If I'm understanding the bgen process correctly, this is because of a parameter of type ModalFilterUPP, which is blacklisted. However, SndRecord would be useful even if this parameter wasn't supported (required to be None, perhaps): the Sound Manager documentation gives no hint as to why you'd even want to use a filterproc, and the sample code I can find always passes NULL. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490558&group_id=5470 From noreply@sourceforge.net Sat Dec 8 11:15:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 03:15:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-477371 ] build_scripts can use wrong #! line Message-ID: Bugs item #477371, was opened at 2001-11-01 19:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477371&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) >Assigned to: Michael Hudson (mwh) Summary: build_scripts can use wrong #! line Initial Comment: When the build_scripts command is run, it places into build/scripts a copy of the script with the #! line modified to call the python version directly. But if you subsequently call setup.py with a different python version, the script is not updated to use the correct python executable path. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-08 03:15 Message: Logged In: YES user_id=6656 Fair point. Should be fairly easy to fix. I'll have a go next week, but feel free to submit a patch before then . ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2001-12-07 18:13 Message: Logged In: YES user_id=65253 Uh, I guess maybe it doesn't bother you, but it sees an odd inconsistancy that build_ext puts its generated files in version-specific dirs, yet build_scripts makes no attempt to handle it. If you are never supposed to run setup.py with more than one version of python then why does build_ext handle it? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:28 Message: Logged In: YES user_id=6656 So don't do that then? Surely you're going to get problems with various other bits of distutils if you're not consistent about which Python you run setup.py with? Very much inclined to close this... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477371&group_id=5470 From noreply@sourceforge.net Sat Dec 8 11:42:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 03:42:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-490573 ] re.match('^a*?$', 'foo') fails Message-ID: Bugs item #490573, was opened at 2001-12-08 03:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490573&group_id=5470 Category: Regular Expressions Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Ben Escoto (bescoto) Assigned to: Fredrik Lundh (effbot) Summary: re.match('^a*?$', 'foo') fails Initial Comment: I saw some other bugs reported here that may be the same as this one, but I figured I might as well post: >>> import re >>> re.match('^a*?$', 'foo') This seems to be a relative new bug. v2.0c says: >>> re.match('^a*?$', 'foo') >>> ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490573&group_id=5470 From noreply@sourceforge.net Sat Dec 8 16:44:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 08:44:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-490573 ] re.match('^a*?$', 'foo') fails Message-ID: Bugs item #490573, was opened at 2001-12-08 03:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490573&group_id=5470 Category: Regular Expressions Group: Python 2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Ben Escoto (bescoto) Assigned to: Fredrik Lundh (effbot) Summary: re.match('^a*?$', 'foo') fails Initial Comment: I saw some other bugs reported here that may be the same as this one, but I figured I might as well post: >>> import re >>> re.match('^a*?$', 'foo') This seems to be a relative new bug. v2.0c says: >>> re.match('^a*?$', 'foo') >>> ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490573&group_id=5470 From noreply@sourceforge.net Sat Dec 8 17:17:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 09:17:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-490168 ] shutil.copy(path, path) deletes contents Message-ID: Bugs item #490168, was opened at 2001-12-07 01:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490168&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copy(path, path) deletes contents Initial Comment: If source equals destination path the contents of the file is deleted. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:17 Message: Logged In: YES user_id=6380 I know the Unix 'cp' command tests for this condition, but shouldn't this fall in the category of "don't do that, then" in the Python world? How stupid do we expect the programmer to be? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490168&group_id=5470 From noreply@sourceforge.net Sat Dec 8 17:18:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 09:18:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-488730 ] os.popen() seg faults on FreeBSD 5 Message-ID: Bugs item #488730, was opened at 2001-12-03 21:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Marc Culler (marcculler) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen() seg faults on FreeBSD 5 Initial Comment: Here is the crash with Python 2.1.1 on my FreeBSD 5.0-current system: [ace:culler]$ python Python 2.1.1 (#5, Aug 18 2001, 17:41:43) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') Segmentation fault (core dumped) No problem occurs when I do the same thing in Python 2.0, which was compiled under FreeBSD 4, but is running here under FreeBSD 5: [ace:culler]$ python2.0 Python 2.0 (#2, Nov 16 2000, 22:22:48) [GCC 2.95.2 19991024 (release)] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') >>> mypipe.readlines() ['COPYRIGHT\012', 'bin\012', 'boot\012', 'cdrom\012', 'compat\012', 'dev\012', 'dist\012', 'entropy\012', 'etc\012', 'home\012', 'kernel\012', 'kernel.GENERIC\012', 'kernel.old\012', 'kernel.prev\012', 'mnt\012', 'modules\012', 'modules.old\012', 'proc\012', 'root\012', 'sbin\012', 'shared\012', 'stand\012', 'sys\012', 'tmp\012', 'usr\012', 'var\012'] >>> ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:18 Message: Logged In: YES user_id=6380 I can't reproduce this, and I don't have access to a FreeBSD 5 machine. Can you debug this yourself? We'd welcome a patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 From noreply@sourceforge.net Sat Dec 8 17:19:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 09:19:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-488730 ] os.popen() seg faults on FreeBSD 5 Message-ID: Bugs item #488730, was opened at 2001-12-03 21:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 >Category: Extension Modules >Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Marc Culler (marcculler) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen() seg faults on FreeBSD 5 Initial Comment: Here is the crash with Python 2.1.1 on my FreeBSD 5.0-current system: [ace:culler]$ python Python 2.1.1 (#5, Aug 18 2001, 17:41:43) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') Segmentation fault (core dumped) No problem occurs when I do the same thing in Python 2.0, which was compiled under FreeBSD 4, but is running here under FreeBSD 5: [ace:culler]$ python2.0 Python 2.0 (#2, Nov 16 2000, 22:22:48) [GCC 2.95.2 19991024 (release)] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') >>> mypipe.readlines() ['COPYRIGHT\012', 'bin\012', 'boot\012', 'cdrom\012', 'compat\012', 'dev\012', 'dist\012', 'entropy\012', 'etc\012', 'home\012', 'kernel\012', 'kernel.GENERIC\012', 'kernel.old\012', 'kernel.prev\012', 'mnt\012', 'modules\012', 'modules.old\012', 'proc\012', 'root\012', 'sbin\012', 'shared\012', 'stand\012', 'sys\012', 'tmp\012', 'usr\012', 'var\012'] >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:18 Message: Logged In: YES user_id=6380 I can't reproduce this, and I don't have access to a FreeBSD 5 machine. Can you debug this yourself? We'd welcome a patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 From noreply@sourceforge.net Sat Dec 8 18:00:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 10:00:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-487390 ] Modifying type.__module__ behavior Message-ID: Bugs item #487390, was opened at 2001-11-29 21:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487390&group_id=5470 Category: Type/class unification Group: Python 2.2 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Burton Radons (loth) Assigned to: Guido van Rossum (gvanrossum) Summary: Modifying type.__module__ behavior Initial Comment: A __module__ attribute request on a C type will return __builtin__ if the typeobject.c code cannot find a period in the type name. This is always incorrect for extension libraries, and can be a _very_ confusing error when trying to pickle your types (as the error makes it seem as if you're supposed to register your type in __builtin__). I propose that: A) All builtin Python types have a "__builtin__." prefixed to their type declaration's name. B) If the __module__ code cannot find a period, it raises AttributeError with a somewhat descriptive message. This would be in the place where it returns __builtin__. C) The tp_name comment in Include/object.h describe the special semantics. "/* 'module.typename' */", for example. This is a lot of files to change, I know, but it's only one or two line changes each file. The only code this should affect is code which is written incorrectly; it may not understand the name semantics, or it may actually be registering itself in __builtin__ (as I did before I figured out what it was doing). Otherwise we're golden. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 10:00 Message: Logged In: YES user_id=6380 Thanks, I've applied the second version of the patch. I'm closing this because I'm satisfied now. ---------------------------------------------------------------------- Comment By: Burton Radons (loth) Date: 2001-12-07 21:56 Message: Logged In: YES user_id=2441 I should have remembered the test suite, sorry. Pickling had the highest chance of messing up with the change, but I didn't even think of trying it with the lovely set of tests available. Go ahead, remove the "__builtin__." part of the patch. I've put up a modified patch that is missing the __builtin__ changes and the change to __module__ behaviour, if you want one; simple hack job. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 21:22 Message: Logged In: YES user_id=6380 Thanks. Unfortunately, ten standard tests fail with these patches. I have a set of fixes, but I believe that the set of fixes needed could be much smaller if we did *not* add the "__builtin__." in front of all built-in types. Their __module__ will still have the correct value "__builtin__" because it defaults that way, and various bits of code that print or test tp_name won't suddenly see "__builtin__." where it wasn't before. (The worst case was cPickle, which switches on the first char of tp_name as a speed hack -- this caused mysterious failures in test_cookie and test_sre.) What do you think of this idea? IMO the rest of your patch still implements an important improvement. ---------------------------------------------------------------------- Comment By: Burton Radons (loth) Date: 2001-12-07 17:03 Message: Logged In: YES user_id=2441 Sorry about the delay. I've attached a patch doing described and threw in patches to fix Module and Mac type names as well, if it so pleases. If it does not, I can amend. Further complications came in with PyStructSequence_InitType, which sets tp_name to a passed descriptor's field. I merely patched all the places that use the function. "__module__" should now be a guaranteed correct attribute amongst Python and the modules. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 08:41 Message: Logged In: YES user_id=6380 I agree with this in principle, but I don't hve the time to make all the changes. Can you submit a patch? Since, as you say, it's so simple, I wouldn't object against including it in 2.2c1, if it's submitted in time (2.2c1 is planned for December 12 -- give us a couple of days before that). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487390&group_id=5470 From noreply@sourceforge.net Sat Dec 8 22:32:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 14:32:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-485139 ] mem leak in interpreter from syntax err Message-ID: Bugs item #485139, was opened at 2001-11-24 10:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485139&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Tim Peters (tim_one) Summary: mem leak in interpreter from syntax err Initial Comment: when a syntax error occurs in the interpreter, the interpreter leaks see the attached file for more info ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-08 14:32 Message: Logged In: YES user_id=31435 The difference between _Py_RefTotal and the sum of the refcounts of the objects in refchain is at least partly accounted for by that static type objects don't appear in refchain. The two get out of synch already by the time _Py_RefTotal reaches 4, due to the static PyBaseObject_Type showing up in a tuple of base classes (thus adding a count to _Py_RefTotal that's not seen when traversing refchain). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-07 21:51 Message: Logged In: YES user_id=31435 Well, this just gets more mysterious the longer I stare at it. I added a routine to compute the sum of all the refcounts in the objects in the refchain, and fiddled PyRun_InteractiveLoopFlags to print that sum after printing _Py_RefTotal. That's the first mystery: C:\Code\python\PCbuild>python_d Adding parser accelerators ... Done. Python 2.2b2+ (#26, Dec 7 2001, 19:25:48) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> [7004 refs] # _Py_RefTotal [6540 sum] # sum of ob_refcnt across refchain objs That is, right off the bat, _Py_RefTotal is 536 larger than the sum of all refcounts in all known objects. I hoped they'd be equal. At least these stay in synch across lots of input expressions: >>> 1 1 [7006 refs] [6542 sum] Both went up by 2 there. >>> [] [] [7011 refs] [6547 sum] And both up by 5. >>> () () [7011 refs] [6547 sum] No change. >>> {} {} [7011 refs] [6547 sum] No change. >>> 2.3 2.2999999999999998 [7011 refs] [6547 sum] No change. Now comes another Mystery: >>> def f(): pass ... [7028 refs] [6562 sum] That is, _Py_RefTotal went up by 17, but the sum of all refcounts only went up by 15. What's up with that? Then both "leak" 1 for each repetition of a function defn: >>> def f(): pass ... [7029 refs] [6563 sum] >>> def f(): pass ... [7030 refs] [6564 sum] >>> def f(): pass ... [7031 refs] [6565 sum] >>> That makes three mysteries. There's no other evidence of an actual leak, though! In particular, >>> import sys [7036 refs] [6570 sum] >>> for i in range(10): ... def f(): pass ... print sys.gettotalrefcount() ... 7075 7075 7075 7075 7075 7075 7075 7075 7075 7075 [7037 refs] [6571 sum] >>> That is, _PyRef_Total is *not* going up by 1 on each "def f (): pass" if the def stmt is inside a loop. Reducing the priority since this is such a pit. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-07 09:13 Message: Logged In: YES user_id=31435 Reopened and assigned to me. I don't care about a leak on an uncaught syntax error, but something Neal said reminded me of a problem that's repeatedly wasted my time: "enter something at a debug-mode interactive prompt repeatedly" often exhibits "and lose a refcount each time" behavior. Like so: >>> 1 1 [7026 refs] >>> class C: pass ... [7036 refs] >>> class C: pass ... [7037 refs] >>> class C: pass ... [7038 refs] >>> class C: pass ... [7039 refs] >>> Several times this has fooled me into looking for leaks that don't exist. >>> def f(): pass ... [7056 refs] >>> def f(): pass ... [7057 refs] >>> def f(): pass ... [7058 refs] >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 08:46 Message: Logged In: YES user_id=6380 Neal writes: --- I tried: for i in range(1000): try: import t2 except SyntaxError: print But that doesn't leak. I think the reason it doesn't leak is because of the try/except. I opened the interpreter and interactively created syntax errors (=, =, ...) and it leaked for each error, not just once 874 bytes, instead of 38 for 1. If there is a way to raise a syntax error without exitting the interpreterr I think it could blow up faster. ----- My comment: if it only leaks when you don't catch it, that doesn't bother me much, since that's the end of the process. :-) So I'm closing this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 19:11 Message: Logged In: YES user_id=6380 Neil, can you provide more evidence? I can't see this leak in a loop, like this: | while 1: | try: compile("/", "", "exec") | except SyntaxError: pass ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:05 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485139&group_id=5470 From noreply@sourceforge.net Sat Dec 8 23:21:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 15:21:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-485139 ] mem leak in interpreter from syntax err Message-ID: Bugs item #485139, was opened at 2001-11-24 10:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485139&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Tim Peters (tim_one) Summary: mem leak in interpreter from syntax err Initial Comment: when a syntax error occurs in the interpreter, the interpreter leaks see the attached file for more info ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-08 15:21 Message: Logged In: YES user_id=31435 Don't ask how I found this : in the def and class examples, we're "leaking" references to the integer 1(!). C:\Code\python\PCbuild>python_d Adding parser accelerators ... Done. Python 2.2b2+ (#26, Dec 8 2001, 17:33:44) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> def g(): # return the current refcount on 1 ... import sys ... return sys.getrefcount(1) ... [7037 refs] >>> g() # it's 38 now 38 [7040 refs] >>> g() # and it's still 38 38 [7040 refs] >>> def f(): pass # do 3 function defs, and ... ... [7057 refs] >>> def f(): pass ... [7058 refs] >>> def f(): pass ... [7059 refs] >>> g() # ... the refcount on 1 goes up by 3 41 [7060 refs] >>> class C: pass # then do 5 class defs, and ... ... [7070 refs] >>> class C: pass ... [7071 refs] >>> class C: pass ... [7072 refs] >>> class C: pass ... [7073 refs] >>> class C: pass ... [7074 refs] >>> g() # ... the refcount on 1 goes up by 5 46 [7075 refs] >>> Similarly for, e.g., entering "lambda:42" over and over. I don't know *why* we're leaking refs to 1 -- it's bizarre. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-08 14:32 Message: Logged In: YES user_id=31435 The difference between _Py_RefTotal and the sum of the refcounts of the objects in refchain is at least partly accounted for by that static type objects don't appear in refchain. The two get out of synch already by the time _Py_RefTotal reaches 4, due to the static PyBaseObject_Type showing up in a tuple of base classes (thus adding a count to _Py_RefTotal that's not seen when traversing refchain). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-07 21:51 Message: Logged In: YES user_id=31435 Well, this just gets more mysterious the longer I stare at it. I added a routine to compute the sum of all the refcounts in the objects in the refchain, and fiddled PyRun_InteractiveLoopFlags to print that sum after printing _Py_RefTotal. That's the first mystery: C:\Code\python\PCbuild>python_d Adding parser accelerators ... Done. Python 2.2b2+ (#26, Dec 7 2001, 19:25:48) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> [7004 refs] # _Py_RefTotal [6540 sum] # sum of ob_refcnt across refchain objs That is, right off the bat, _Py_RefTotal is 536 larger than the sum of all refcounts in all known objects. I hoped they'd be equal. At least these stay in synch across lots of input expressions: >>> 1 1 [7006 refs] [6542 sum] Both went up by 2 there. >>> [] [] [7011 refs] [6547 sum] And both up by 5. >>> () () [7011 refs] [6547 sum] No change. >>> {} {} [7011 refs] [6547 sum] No change. >>> 2.3 2.2999999999999998 [7011 refs] [6547 sum] No change. Now comes another Mystery: >>> def f(): pass ... [7028 refs] [6562 sum] That is, _Py_RefTotal went up by 17, but the sum of all refcounts only went up by 15. What's up with that? Then both "leak" 1 for each repetition of a function defn: >>> def f(): pass ... [7029 refs] [6563 sum] >>> def f(): pass ... [7030 refs] [6564 sum] >>> def f(): pass ... [7031 refs] [6565 sum] >>> That makes three mysteries. There's no other evidence of an actual leak, though! In particular, >>> import sys [7036 refs] [6570 sum] >>> for i in range(10): ... def f(): pass ... print sys.gettotalrefcount() ... 7075 7075 7075 7075 7075 7075 7075 7075 7075 7075 [7037 refs] [6571 sum] >>> That is, _PyRef_Total is *not* going up by 1 on each "def f (): pass" if the def stmt is inside a loop. Reducing the priority since this is such a pit. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-07 09:13 Message: Logged In: YES user_id=31435 Reopened and assigned to me. I don't care about a leak on an uncaught syntax error, but something Neal said reminded me of a problem that's repeatedly wasted my time: "enter something at a debug-mode interactive prompt repeatedly" often exhibits "and lose a refcount each time" behavior. Like so: >>> 1 1 [7026 refs] >>> class C: pass ... [7036 refs] >>> class C: pass ... [7037 refs] >>> class C: pass ... [7038 refs] >>> class C: pass ... [7039 refs] >>> Several times this has fooled me into looking for leaks that don't exist. >>> def f(): pass ... [7056 refs] >>> def f(): pass ... [7057 refs] >>> def f(): pass ... [7058 refs] >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 08:46 Message: Logged In: YES user_id=6380 Neal writes: --- I tried: for i in range(1000): try: import t2 except SyntaxError: print But that doesn't leak. I think the reason it doesn't leak is because of the try/except. I opened the interpreter and interactively created syntax errors (=, =, ...) and it leaked for each error, not just once 874 bytes, instead of 38 for 1. If there is a way to raise a syntax error without exitting the interpreterr I think it could blow up faster. ----- My comment: if it only leaks when you don't catch it, that doesn't bother me much, since that's the end of the process. :-) So I'm closing this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 19:11 Message: Logged In: YES user_id=6380 Neil, can you provide more evidence? I can't see this leak in a loop, like this: | while 1: | try: compile("/", "", "exec") | except SyntaxError: pass ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:05 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485139&group_id=5470 From noreply@sourceforge.net Sat Dec 8 23:44:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 08 Dec 2001 15:44:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-485139 ] mem leak in interpreter from syntax err Message-ID: Bugs item #485139, was opened at 2001-11-24 10:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485139&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Tim Peters (tim_one) Summary: mem leak in interpreter from syntax err Initial Comment: when a syntax error occurs in the interpreter, the interpreter leaks see the attached file for more info ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-08 15:44 Message: Logged In: YES user_id=31435 The leaking refs to the integer 1 got plugged in Python/symtable.c; new revision: 2.9 Closing this now, as there doesn't appear to be any mystery remaining worth tracking down, and the other mysteries are too hard to fix. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-08 15:21 Message: Logged In: YES user_id=31435 Don't ask how I found this : in the def and class examples, we're "leaking" references to the integer 1(!). C:\Code\python\PCbuild>python_d Adding parser accelerators ... Done. Python 2.2b2+ (#26, Dec 8 2001, 17:33:44) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> def g(): # return the current refcount on 1 ... import sys ... return sys.getrefcount(1) ... [7037 refs] >>> g() # it's 38 now 38 [7040 refs] >>> g() # and it's still 38 38 [7040 refs] >>> def f(): pass # do 3 function defs, and ... ... [7057 refs] >>> def f(): pass ... [7058 refs] >>> def f(): pass ... [7059 refs] >>> g() # ... the refcount on 1 goes up by 3 41 [7060 refs] >>> class C: pass # then do 5 class defs, and ... ... [7070 refs] >>> class C: pass ... [7071 refs] >>> class C: pass ... [7072 refs] >>> class C: pass ... [7073 refs] >>> class C: pass ... [7074 refs] >>> g() # ... the refcount on 1 goes up by 5 46 [7075 refs] >>> Similarly for, e.g., entering "lambda:42" over and over. I don't know *why* we're leaking refs to 1 -- it's bizarre. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-08 14:32 Message: Logged In: YES user_id=31435 The difference between _Py_RefTotal and the sum of the refcounts of the objects in refchain is at least partly accounted for by that static type objects don't appear in refchain. The two get out of synch already by the time _Py_RefTotal reaches 4, due to the static PyBaseObject_Type showing up in a tuple of base classes (thus adding a count to _Py_RefTotal that's not seen when traversing refchain). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-07 21:51 Message: Logged In: YES user_id=31435 Well, this just gets more mysterious the longer I stare at it. I added a routine to compute the sum of all the refcounts in the objects in the refchain, and fiddled PyRun_InteractiveLoopFlags to print that sum after printing _Py_RefTotal. That's the first mystery: C:\Code\python\PCbuild>python_d Adding parser accelerators ... Done. Python 2.2b2+ (#26, Dec 7 2001, 19:25:48) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> [7004 refs] # _Py_RefTotal [6540 sum] # sum of ob_refcnt across refchain objs That is, right off the bat, _Py_RefTotal is 536 larger than the sum of all refcounts in all known objects. I hoped they'd be equal. At least these stay in synch across lots of input expressions: >>> 1 1 [7006 refs] [6542 sum] Both went up by 2 there. >>> [] [] [7011 refs] [6547 sum] And both up by 5. >>> () () [7011 refs] [6547 sum] No change. >>> {} {} [7011 refs] [6547 sum] No change. >>> 2.3 2.2999999999999998 [7011 refs] [6547 sum] No change. Now comes another Mystery: >>> def f(): pass ... [7028 refs] [6562 sum] That is, _Py_RefTotal went up by 17, but the sum of all refcounts only went up by 15. What's up with that? Then both "leak" 1 for each repetition of a function defn: >>> def f(): pass ... [7029 refs] [6563 sum] >>> def f(): pass ... [7030 refs] [6564 sum] >>> def f(): pass ... [7031 refs] [6565 sum] >>> That makes three mysteries. There's no other evidence of an actual leak, though! In particular, >>> import sys [7036 refs] [6570 sum] >>> for i in range(10): ... def f(): pass ... print sys.gettotalrefcount() ... 7075 7075 7075 7075 7075 7075 7075 7075 7075 7075 [7037 refs] [6571 sum] >>> That is, _PyRef_Total is *not* going up by 1 on each "def f (): pass" if the def stmt is inside a loop. Reducing the priority since this is such a pit. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-07 09:13 Message: Logged In: YES user_id=31435 Reopened and assigned to me. I don't care about a leak on an uncaught syntax error, but something Neal said reminded me of a problem that's repeatedly wasted my time: "enter something at a debug-mode interactive prompt repeatedly" often exhibits "and lose a refcount each time" behavior. Like so: >>> 1 1 [7026 refs] >>> class C: pass ... [7036 refs] >>> class C: pass ... [7037 refs] >>> class C: pass ... [7038 refs] >>> class C: pass ... [7039 refs] >>> Several times this has fooled me into looking for leaks that don't exist. >>> def f(): pass ... [7056 refs] >>> def f(): pass ... [7057 refs] >>> def f(): pass ... [7058 refs] >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 08:46 Message: Logged In: YES user_id=6380 Neal writes: --- I tried: for i in range(1000): try: import t2 except SyntaxError: print But that doesn't leak. I think the reason it doesn't leak is because of the try/except. I opened the interpreter and interactively created syntax errors (=, =, ...) and it leaked for each error, not just once 874 bytes, instead of 38 for 1. If there is a way to raise a syntax error without exitting the interpreterr I think it could blow up faster. ----- My comment: if it only leaks when you don't catch it, that doesn't bother me much, since that's the end of the process. :-) So I'm closing this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 19:11 Message: Logged In: YES user_id=6380 Neil, can you provide more evidence? I can't see this leak in a loop, like this: | while 1: | try: compile("/", "", "exec") | except SyntaxError: pass ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 12:05 Message: Logged In: YES user_id=31435 Assigned to Barry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=485139&group_id=5470 From noreply@sourceforge.net Sun Dec 9 13:00:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 05:00:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-490823 ] str.decode() missing. Message-ID: Bugs item #490823, was opened at 2001-12-09 05:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490823&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: str.decode() missing. Initial Comment: The 2.2 .decode() method isn't listed among the string methods in section 2.2.6.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490823&group_id=5470 From noreply@sourceforge.net Sun Dec 9 16:17:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 08:17:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-490573 ] re.match('^a*?$', 'foo') fails Message-ID: Bugs item #490573, was opened at 2001-12-08 03:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490573&group_id=5470 Category: Regular Expressions Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Ben Escoto (bescoto) Assigned to: Fredrik Lundh (effbot) Summary: re.match('^a*?$', 'foo') fails Initial Comment: I saw some other bugs reported here that may be the same as this one, but I figured I might as well post: >>> import re >>> re.match('^a*?$', 'foo') This seems to be a relative new bug. v2.0c says: >>> re.match('^a*?$', 'foo') >>> ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2001-12-09 08:17 Message: Logged In: YES user_id=38376 backed out of broken patch from July 2001. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490573&group_id=5470 From noreply@sourceforge.net Sun Dec 9 16:17:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 08:17:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-483789 ] another *? greedy bug Message-ID: Bugs item #483789, was opened at 2001-11-20 06:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=483789&group_id=5470 Category: Regular Expressions Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Bastian Kleineidam (calvin) Assigned to: Fredrik Lundh (effbot) Summary: another *? greedy bug Initial Comment: Hm, it took me one hour debugging until I reached the regex level of my application :) Python 2.2b2 (#26, Nov 16 2001, 11:44:11) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> re.search(r"a[^>]*?b", "a>b") ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2001-12-09 08:17 Message: Logged In: YES user_id=38376 backed out of broken patch from July 2001. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=483789&group_id=5470 From noreply@sourceforge.net Sun Dec 9 16:18:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 08:18:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-477728 ] .*? matches newlines without DOTALL Message-ID: Bugs item #477728, was opened at 2001-11-02 22:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477728&group_id=5470 Category: Regular Expressions Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Fredrik Lundh (effbot) Summary: .*? matches newlines without DOTALL Initial Comment: ython 2.2b1+ (#25, Oct 30 2001, 22:36:33) [MSC 32 bit (Intel)] on win32 >> text = "one\ntwo\nthree\n" >> import re >> re.match(r'.*?$', text) SRE_Match object at 0x007AD940> >> _.group(0) # oops! one\ntwo\nthree' >> re.match(r'.*$', text) # more like it >> Since . shouldn't match a newline in the absence of re.DOTALL, .*? shouldn't match any newlines, and then minimal match should have failed (as did the maximal match). Found by Bruce Eckel. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2001-12-09 08:18 Message: Logged In: YES user_id=38376 backed out of broken patch from July 2001. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-12-06 14:07 Message: Logged In: YES user_id=38376 A quick fix (which I originally planned to check in tonight) would be to back out of a recent patch that attempts to avoid recursion in some cases. But after a careful code review, I'm beginning to think that I might be able to tweak the patch into something that works also in this case. But I better do that some night when I haven't been out celebrating the PythonWorks 1.3 release... (tomorrow, in other words) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-02 12:28 Message: Logged In: YES user_id=31435 Boosted priority: /F, what's the hangup here? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-02 12:27 Message: Logged In: YES user_id=31435 Boosted priority: /F, what's the hangup here? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477728&group_id=5470 From noreply@sourceforge.net Sun Dec 9 16:34:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 08:34:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-406815 ] python2.1b re bug (.*)? Message-ID: Bugs item #406815, was opened at 2001-03-07 12:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406815&group_id=5470 Category: Regular Expressions Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fredrik Lundh (effbot) Summary: python2.1b re bug (.*)? Initial Comment: The script below works per expectation with python1.5. It fails with python2.1b1 % python2.1 gar Traceback (most recent call last): File "gar", line 9, in ? mob = re.search("== Parameters ==\n(.*)?\s*$", output, re.S) File "/usr/local/lib/python2.1/sre.py", line 55, in search return _compile(pattern, flags).search(string) File "/usr/local/lib/python2.1/sre.py", line 131, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat Move "?" inside the parens and it works. Replace the "*" with a "+" and it works (at least for this example input). import re output = """ Using == Parameters == line1 line2 """ mob = re.search("== Parameters ==\n(.*)?\s*$", output, re.S) print mob.groups() ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2001-12-09 08:34 Message: Logged In: YES user_id=38376 the expression is ambigous, and could mean either "(.+)?" (if you want an undefined group for an empty match) or "(.*)" (if you want the group to contain an empty string). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=406815&group_id=5470 From noreply@sourceforge.net Sun Dec 9 16:42:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 08:42:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-456742 ] Failing test case for .*? Message-ID: Bugs item #456742, was opened at 2001-08-29 20:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456742&group_id=5470 Category: Regular Expressions Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Darrell Gallion (dgallion) Assigned to: Fredrik Lundh (effbot) Summary: Failing test case for .*? Initial Comment: The following error is the result of patch 101612 Which tries to fix recursion limits in sre. >>> s="""a\nb\n1""" >>> re.findall("[^\n]+?\d", s) ['a\nb\n1'] A less than optimal work around makes sure a simple '.' is being searched for. If it has a chance of being accepted, I'll look for a way to remove the recursion for more complex patterns. line 1105 _sre.c /* see if the tail matches */ state->repeat = rp->prev; if (rp->pattern[2] == 65535 && (*(rp- >pattern+3) == SRE_OP_ANY || *(rp->pattern+3) == SRE_OP_ANY_ALL)){ /* unbounded repeat */ for (;;) { ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2001-12-09 08:42 Message: Logged In: YES user_id=38376 I've backed out of the patch. for the work-around, you will also need to make sure that the repeated pattern is only one character long (it's probably better to do this in the compiler). true recursion (based on additional "state" opcodes, to allow the engine to return instead of recurse at points marked with "RECURSIVE") is being worked on, but won't make it into 2.2 final. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456742&group_id=5470 From noreply@sourceforge.net Sun Dec 9 21:32:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 13:32:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-487390 ] Modifying type.__module__ behavior Message-ID: Bugs item #487390, was opened at 2001-11-29 21:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487390&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Burton Radons (loth) Assigned to: Guido van Rossum (gvanrossum) Summary: Modifying type.__module__ behavior Initial Comment: A __module__ attribute request on a C type will return __builtin__ if the typeobject.c code cannot find a period in the type name. This is always incorrect for extension libraries, and can be a _very_ confusing error when trying to pickle your types (as the error makes it seem as if you're supposed to register your type in __builtin__). I propose that: A) All builtin Python types have a "__builtin__." prefixed to their type declaration's name. B) If the __module__ code cannot find a period, it raises AttributeError with a somewhat descriptive message. This would be in the place where it returns __builtin__. C) The tp_name comment in Include/object.h describe the special semantics. "/* 'module.typename' */", for example. This is a lot of files to change, I know, but it's only one or two line changes each file. The only code this should affect is code which is written incorrectly; it may not understand the name semantics, or it may actually be registering itself in __builtin__ (as I did before I figured out what it was doing). Otherwise we're golden. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-09 13:32 Message: Logged In: YES user_id=45365 A question about this patch: is the module name actually used for something? I ask because the Mac toolbox modules have different names, depending on the situation. The Python programmer will always refer to the modules as something like "Carbon.Win". This, however, is a wrapper module (in Python) that imports the _Win module. If you use them under command line Python on OSX _Win will live in Lib/lib-dynload, so the "real" name will indeed be "_Win". If you use them in MacPython, however, _Win will live in the Carbon package, so the "real" name will be "Carbon._Win". Or, I should phrase that differently, if you want to import it afresh you should import it as Carbon._Win (unless you're inside the Carbon package, of course). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 10:00 Message: Logged In: YES user_id=6380 Thanks, I've applied the second version of the patch. I'm closing this because I'm satisfied now. ---------------------------------------------------------------------- Comment By: Burton Radons (loth) Date: 2001-12-07 21:56 Message: Logged In: YES user_id=2441 I should have remembered the test suite, sorry. Pickling had the highest chance of messing up with the change, but I didn't even think of trying it with the lovely set of tests available. Go ahead, remove the "__builtin__." part of the patch. I've put up a modified patch that is missing the __builtin__ changes and the change to __module__ behaviour, if you want one; simple hack job. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 21:22 Message: Logged In: YES user_id=6380 Thanks. Unfortunately, ten standard tests fail with these patches. I have a set of fixes, but I believe that the set of fixes needed could be much smaller if we did *not* add the "__builtin__." in front of all built-in types. Their __module__ will still have the correct value "__builtin__" because it defaults that way, and various bits of code that print or test tp_name won't suddenly see "__builtin__." where it wasn't before. (The worst case was cPickle, which switches on the first char of tp_name as a speed hack -- this caused mysterious failures in test_cookie and test_sre.) What do you think of this idea? IMO the rest of your patch still implements an important improvement. ---------------------------------------------------------------------- Comment By: Burton Radons (loth) Date: 2001-12-07 17:03 Message: Logged In: YES user_id=2441 Sorry about the delay. I've attached a patch doing described and threw in patches to fix Module and Mac type names as well, if it so pleases. If it does not, I can amend. Further complications came in with PyStructSequence_InitType, which sets tp_name to a passed descriptor's field. I merely patched all the places that use the function. "__module__" should now be a guaranteed correct attribute amongst Python and the modules. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 08:41 Message: Logged In: YES user_id=6380 I agree with this in principle, but I don't hve the time to make all the changes. Can you submit a patch? Since, as you say, it's so simple, I wouldn't object against including it in 2.2c1, if it's submitted in time (2.2c1 is planned for December 12 -- give us a couple of days before that). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487390&group_id=5470 From noreply@sourceforge.net Sun Dec 9 22:09:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 14:09:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-490939 ] .join(generator) crash bug Message-ID: Bugs item #490939, was opened at 2001-12-09 14:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490939&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Sami Hangaslammi (shang) Assigned to: Nobody/Anonymous (nobody) Summary: .join(generator) crash bug Initial Comment: Reproduced on Windows XP (Python 2.2b1) and Redhat 7.1 (Python 2.2b1). Bug didn't manifest with Python 2.1 (WinNT4) or Python 2.2a2 (RH7.1). Some generators crash the interpreter when used with .join(generator). The same generators work fine when used with for-loops or with the build-in function list. I couldn't create a more simple generator that would cause the interpreter to crash, so I'll attach the whole script (longish). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490939&group_id=5470 From noreply@sourceforge.net Sun Dec 9 22:16:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 14:16:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-487390 ] Modifying type.__module__ behavior Message-ID: Bugs item #487390, was opened at 2001-11-29 21:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487390&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Burton Radons (loth) Assigned to: Guido van Rossum (gvanrossum) Summary: Modifying type.__module__ behavior Initial Comment: A __module__ attribute request on a C type will return __builtin__ if the typeobject.c code cannot find a period in the type name. This is always incorrect for extension libraries, and can be a _very_ confusing error when trying to pickle your types (as the error makes it seem as if you're supposed to register your type in __builtin__). I propose that: A) All builtin Python types have a "__builtin__." prefixed to their type declaration's name. B) If the __module__ code cannot find a period, it raises AttributeError with a somewhat descriptive message. This would be in the place where it returns __builtin__. C) The tp_name comment in Include/object.h describe the special semantics. "/* 'module.typename' */", for example. This is a lot of files to change, I know, but it's only one or two line changes each file. The only code this should affect is code which is written incorrectly; it may not understand the name semantics, or it may actually be registering itself in __builtin__ (as I did before I figured out what it was doing). Otherwise we're golden. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-09 14:16 Message: Logged In: NO (This is Guido, unable to log in to SF on his laptop.) Answering Jack's question about the utility of the module name: The module name can be retrieved from the type using t.__module__, and is displayed by the repr() of the type. For objects with picklable instances, it is also used to pickle a reference to the type (the pickle module asks for __module__ and __name__ and then checks that importing __name__ from __module__ indeed retrieves the correct type). Additionally, if you don't specify the type, __module__ defaults to __builtin__, which is highly confusing (but can't be helped for various reasons). Alas, I don't know what to do about the different names for the same type. Maybe you can fix it so that there's a "true" name and a "convenience" name? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-09 13:32 Message: Logged In: YES user_id=45365 A question about this patch: is the module name actually used for something? I ask because the Mac toolbox modules have different names, depending on the situation. The Python programmer will always refer to the modules as something like "Carbon.Win". This, however, is a wrapper module (in Python) that imports the _Win module. If you use them under command line Python on OSX _Win will live in Lib/lib-dynload, so the "real" name will indeed be "_Win". If you use them in MacPython, however, _Win will live in the Carbon package, so the "real" name will be "Carbon._Win". Or, I should phrase that differently, if you want to import it afresh you should import it as Carbon._Win (unless you're inside the Carbon package, of course). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 10:00 Message: Logged In: YES user_id=6380 Thanks, I've applied the second version of the patch. I'm closing this because I'm satisfied now. ---------------------------------------------------------------------- Comment By: Burton Radons (loth) Date: 2001-12-07 21:56 Message: Logged In: YES user_id=2441 I should have remembered the test suite, sorry. Pickling had the highest chance of messing up with the change, but I didn't even think of trying it with the lovely set of tests available. Go ahead, remove the "__builtin__." part of the patch. I've put up a modified patch that is missing the __builtin__ changes and the change to __module__ behaviour, if you want one; simple hack job. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 21:22 Message: Logged In: YES user_id=6380 Thanks. Unfortunately, ten standard tests fail with these patches. I have a set of fixes, but I believe that the set of fixes needed could be much smaller if we did *not* add the "__builtin__." in front of all built-in types. Their __module__ will still have the correct value "__builtin__" because it defaults that way, and various bits of code that print or test tp_name won't suddenly see "__builtin__." where it wasn't before. (The worst case was cPickle, which switches on the first char of tp_name as a speed hack -- this caused mysterious failures in test_cookie and test_sre.) What do you think of this idea? IMO the rest of your patch still implements an important improvement. ---------------------------------------------------------------------- Comment By: Burton Radons (loth) Date: 2001-12-07 17:03 Message: Logged In: YES user_id=2441 Sorry about the delay. I've attached a patch doing described and threw in patches to fix Module and Mac type names as well, if it so pleases. If it does not, I can amend. Further complications came in with PyStructSequence_InitType, which sets tp_name to a passed descriptor's field. I merely patched all the places that use the function. "__module__" should now be a guaranteed correct attribute amongst Python and the modules. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 08:41 Message: Logged In: YES user_id=6380 I agree with this in principle, but I don't hve the time to make all the changes. Can you submit a patch? Since, as you say, it's so simple, I wouldn't object against including it in 2.2c1, if it's submitted in time (2.2c1 is planned for December 12 -- give us a couple of days before that). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487390&group_id=5470 From noreply@sourceforge.net Sun Dec 9 22:33:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 14:33:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-490939 ] .join(generator) crash bug Message-ID: Bugs item #490939, was opened at 2001-12-09 14:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490939&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Sami Hangaslammi (shang) >Assigned to: Guido van Rossum (gvanrossum) Summary: .join(generator) crash bug Initial Comment: Reproduced on Windows XP (Python 2.2b1) and Redhat 7.1 (Python 2.2b1). Bug didn't manifest with Python 2.1 (WinNT4) or Python 2.2a2 (RH7.1). Some generators crash the interpreter when used with .join(generator). The same generators work fine when used with for-loops or with the build-in function list. I couldn't create a more simple generator that would cause the interpreter to crash, so I'll attach the whole script (longish). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 14:33 Message: Logged In: YES user_id=6380 I think I *just* fixed this. Can you try a recent CVS? tupleobject.c 2.62. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490939&group_id=5470 From noreply@sourceforge.net Sun Dec 9 22:38:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 14:38:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-490939 ] .join(generator) crash bug Message-ID: Bugs item #490939, was opened at 2001-12-09 14:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490939&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Open Resolution: Fixed Priority: 5 Submitted By: Sami Hangaslammi (shang) >Assigned to: Tim Peters (tim_one) Summary: .join(generator) crash bug Initial Comment: Reproduced on Windows XP (Python 2.2b1) and Redhat 7.1 (Python 2.2b1). Bug didn't manifest with Python 2.1 (WinNT4) or Python 2.2a2 (RH7.1). Some generators crash the interpreter when used with .join(generator). The same generators work fine when used with for-loops or with the build-in function list. I couldn't create a more simple generator that would cause the interpreter to crash, so I'll attach the whole script (longish). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-09 14:38 Message: Logged In: YES user_id=31435 I can reproduce a crash under 2.2b1 and 2.2b2, but not under current CVS Python. This irks me, because I don't know of anything relevant that changed (that is, AFAICT it's "working" by accident now -- or never should have failed). I'll rebuild 2.2b2 from scratch and dig into it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 14:33 Message: Logged In: YES user_id=6380 I think I *just* fixed this. Can you try a recent CVS? tupleobject.c 2.62. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490939&group_id=5470 From noreply@sourceforge.net Sun Dec 9 22:50:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 14:50:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-490939 ] .join(generator) crash bug Message-ID: Bugs item #490939, was opened at 2001-12-09 14:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490939&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: Fixed Priority: 5 Submitted By: Sami Hangaslammi (shang) Assigned to: Tim Peters (tim_one) Summary: .join(generator) crash bug Initial Comment: Reproduced on Windows XP (Python 2.2b1) and Redhat 7.1 (Python 2.2b1). Bug didn't manifest with Python 2.1 (WinNT4) or Python 2.2a2 (RH7.1). Some generators crash the interpreter when used with .join(generator). The same generators work fine when used with for-loops or with the build-in function list. I couldn't create a more simple generator that would cause the interpreter to crash, so I'll attach the whole script (longish). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-09 14:50 Message: Logged In: YES user_id=31435 Hmm (Guido). tuple resizing could be relevant, but reverting to 2.61 of tupleobject.c didn't yield a crash. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-09 14:38 Message: Logged In: YES user_id=31435 I can reproduce a crash under 2.2b1 and 2.2b2, but not under current CVS Python. This irks me, because I don't know of anything relevant that changed (that is, AFAICT it's "working" by accident now -- or never should have failed). I'll rebuild 2.2b2 from scratch and dig into it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 14:33 Message: Logged In: YES user_id=6380 I think I *just* fixed this. Can you try a recent CVS? tupleobject.c 2.62. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490939&group_id=5470 From noreply@sourceforge.net Sun Dec 9 22:57:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 14:57:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-490939 ] .join(generator) crash bug Message-ID: Bugs item #490939, was opened at 2001-12-09 14:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490939&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: Fixed Priority: 5 Submitted By: Sami Hangaslammi (shang) Assigned to: Tim Peters (tim_one) Summary: .join(generator) crash bug Initial Comment: Reproduced on Windows XP (Python 2.2b1) and Redhat 7.1 (Python 2.2b1). Bug didn't manifest with Python 2.1 (WinNT4) or Python 2.2a2 (RH7.1). Some generators crash the interpreter when used with .join(generator). The same generators work fine when used with for-loops or with the build-in function list. I couldn't create a more simple generator that would cause the interpreter to crash, so I'll attach the whole script (longish). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 14:57 Message: Logged In: YES user_id=6380 Tim, for me reverting to tupleobject.c 2.61 *did* yield a crash. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-09 14:50 Message: Logged In: YES user_id=31435 Hmm (Guido). tuple resizing could be relevant, but reverting to 2.61 of tupleobject.c didn't yield a crash. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-09 14:38 Message: Logged In: YES user_id=31435 I can reproduce a crash under 2.2b1 and 2.2b2, but not under current CVS Python. This irks me, because I don't know of anything relevant that changed (that is, AFAICT it's "working" by accident now -- or never should have failed). I'll rebuild 2.2b2 from scratch and dig into it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 14:33 Message: Logged In: YES user_id=6380 I think I *just* fixed this. Can you try a recent CVS? tupleobject.c 2.62. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490939&group_id=5470 From noreply@sourceforge.net Sun Dec 9 22:59:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 14:59:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-490939 ] .join(generator) crash bug Message-ID: Bugs item #490939, was opened at 2001-12-09 14:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490939&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: Fixed Priority: 5 Submitted By: Sami Hangaslammi (shang) Assigned to: Tim Peters (tim_one) Summary: .join(generator) crash bug Initial Comment: Reproduced on Windows XP (Python 2.2b1) and Redhat 7.1 (Python 2.2b1). Bug didn't manifest with Python 2.1 (WinNT4) or Python 2.2a2 (RH7.1). Some generators crash the interpreter when used with .join(generator). The same generators work fine when used with for-loops or with the build-in function list. I couldn't create a more simple generator that would cause the interpreter to crash, so I'll attach the whole script (longish). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 14:59 Message: Logged In: YES user_id=6380 Moreover, Tim, the crash I get is in _PyTuple_Resize(). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 14:57 Message: Logged In: YES user_id=6380 Tim, for me reverting to tupleobject.c 2.61 *did* yield a crash. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-09 14:50 Message: Logged In: YES user_id=31435 Hmm (Guido). tuple resizing could be relevant, but reverting to 2.61 of tupleobject.c didn't yield a crash. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-09 14:38 Message: Logged In: YES user_id=31435 I can reproduce a crash under 2.2b1 and 2.2b2, but not under current CVS Python. This irks me, because I don't know of anything relevant that changed (that is, AFAICT it's "working" by accident now -- or never should have failed). I'll rebuild 2.2b2 from scratch and dig into it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 14:33 Message: Logged In: YES user_id=6380 I think I *just* fixed this. Can you try a recent CVS? tupleobject.c 2.62. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490939&group_id=5470 From noreply@sourceforge.net Sun Dec 9 23:06:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 15:06:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-490939 ] .join(generator) crash bug Message-ID: Bugs item #490939, was opened at 2001-12-09 14:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490939&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Sami Hangaslammi (shang) >Assigned to: Guido van Rossum (gvanrossum) Summary: .join(generator) crash bug Initial Comment: Reproduced on Windows XP (Python 2.2b1) and Redhat 7.1 (Python 2.2b1). Bug didn't manifest with Python 2.1 (WinNT4) or Python 2.2a2 (RH7.1). Some generators crash the interpreter when used with .join(generator). The same generators work fine when used with for-loops or with the build-in function list. I couldn't create a more simple generator that would cause the interpreter to crash, so I'll attach the whole script (longish). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-09 15:06 Message: Logged In: YES user_id=31435 Luck of the draw, I guess. I rebuilt 2.2b2 and the resizing is definitely it -- choking in _PyTuple_Resize will cutting back the result tuple from 20 to 19, on a trash address left over from an earlier _PyTuple_Resize growing the tuple from 10 to 20. Closed again. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 14:59 Message: Logged In: YES user_id=6380 Moreover, Tim, the crash I get is in _PyTuple_Resize(). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 14:57 Message: Logged In: YES user_id=6380 Tim, for me reverting to tupleobject.c 2.61 *did* yield a crash. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-09 14:50 Message: Logged In: YES user_id=31435 Hmm (Guido). tuple resizing could be relevant, but reverting to 2.61 of tupleobject.c didn't yield a crash. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-09 14:38 Message: Logged In: YES user_id=31435 I can reproduce a crash under 2.2b1 and 2.2b2, but not under current CVS Python. This irks me, because I don't know of anything relevant that changed (that is, AFAICT it's "working" by accident now -- or never should have failed). I'll rebuild 2.2b2 from scratch and dig into it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 14:33 Message: Logged In: YES user_id=6380 I think I *just* fixed this. Can you try a recent CVS? tupleobject.c 2.62. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490939&group_id=5470 From noreply@sourceforge.net Sun Dec 9 23:36:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 15:36:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-484994 ] bugs in Tix.py ListNoteBook PanedWindow Message-ID: Bugs item #484994, was opened at 2001-11-23 14:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=484994&group_id=5470 Category: Tkinter Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Robert Roy (rjroy) Assigned to: Nobody/Anonymous (nobody) Summary: bugs in Tix.py ListNoteBook PanedWindow Initial Comment: Python 2.2b2 Tix.py 1) class ListNoteBook, __init__ method calls base class __init__ method with "tixDirList" instead of "tixListNoteBook" 2) class PanedWindow, panes method, does not split the string returned from self.tk.call(self._w, 'panes') patch also adds: access to the paned window in ListNoteBook class dummyPanedWindow to support above paneconfigure methods to PanedWindow pageConfigure methods to NoteBook and ListNoteBook page and pages methods to ListNoteBook I am attaching the pathched file as well as the following diff ################ 1044c1044,1046 < TixWidget.__init__(self, master, 'tixDirList', ['options'], cnf, kw) --- > TixWidget.__init__(self, master, 'tixListNoteBook', ['options'], cnf, kw) > self.subwidget_list['pane'] = _dummyPanedWindow(self, 'pane', > destroy_physically=0) 1048d1049 < 1054a1056,1070 > def page(self, name): > return self.subwidget(name) > > def pages(self): > # Can't call subwidgets_all directly because we don't want .nbframe > names = self.tk.split(self.tk.call (self._w, 'pages')) > ret = [] > for x in names: > ret.append(self.subwidget(x)) > return ret > > def pageconfigure(self, name, **kw): > apply(self.tk.call, > (self._w, 'pageconfigure', name) + self._options(kw)) > 1099a1116,1119 > def pageconfigure(self, name, **kw): > apply(self.tk.call, > (self._w, 'pageconfigure', name) + self._options(kw)) > 1162c1182 < names = self.tk.call(self._w, 'panes') --- > names = self.tk.split(self.tk.call (self._w, 'panes')) 1167a1188,1191 > def paneconfigure(self, name, **kw): > apply(self.tk.call, > (self._w, 'paneconfigure', name) + self._options(kw)) > 1571a1596,1599 > TixSubWidget.__init__(self, master, name, destroy_physically) > > class _dummyPanedWindow(PanedWindow, TixSubWidget): > def __init__(self, master, name, destroy_physically=1): ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-12-09 15:36 Message: Logged In: YES user_id=33229 The first part of the patch was a definite bug, but your diffs are against Tix.py 1.5, and the bug is fixed in the current version 1.6. (I've also submitted a new version (1.7?) to the patch queue). You're right about the splitlist, but the next part of the patch is partly wrong: there is no 'pages' method to the tixPanedWindow. The methods of the class in Tcl Tix are: add delete forget manage panecget paneconfigure panes setsize I appreciate your help on getting the PanedWindow implementation complete. Could I ask you to check the Tcl Tix documentation and code carefully and resubmit this patch against 1.7 when it comes out, perhaps with some of the other missing methods as well? To speed things up for Martin, it could be best to use a context diff diff -c and upload the result as a file. Mike Clarkson ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 08:15 Message: Logged In: YES user_id=3066 I've asked Mike Clarkson (Tix.py guru) to take a look at this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=484994&group_id=5470 From noreply@sourceforge.net Mon Dec 10 02:34:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 18:34:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-484994 ] bugs in Tix.py ListNoteBook PanedWindow Message-ID: Bugs item #484994, was opened at 2001-11-23 14:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=484994&group_id=5470 Category: Tkinter Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Robert Roy (rjroy) Assigned to: Nobody/Anonymous (nobody) Summary: bugs in Tix.py ListNoteBook PanedWindow Initial Comment: Python 2.2b2 Tix.py 1) class ListNoteBook, __init__ method calls base class __init__ method with "tixDirList" instead of "tixListNoteBook" 2) class PanedWindow, panes method, does not split the string returned from self.tk.call(self._w, 'panes') patch also adds: access to the paned window in ListNoteBook class dummyPanedWindow to support above paneconfigure methods to PanedWindow pageConfigure methods to NoteBook and ListNoteBook page and pages methods to ListNoteBook I am attaching the pathched file as well as the following diff ################ 1044c1044,1046 < TixWidget.__init__(self, master, 'tixDirList', ['options'], cnf, kw) --- > TixWidget.__init__(self, master, 'tixListNoteBook', ['options'], cnf, kw) > self.subwidget_list['pane'] = _dummyPanedWindow(self, 'pane', > destroy_physically=0) 1048d1049 < 1054a1056,1070 > def page(self, name): > return self.subwidget(name) > > def pages(self): > # Can't call subwidgets_all directly because we don't want .nbframe > names = self.tk.split(self.tk.call (self._w, 'pages')) > ret = [] > for x in names: > ret.append(self.subwidget(x)) > return ret > > def pageconfigure(self, name, **kw): > apply(self.tk.call, > (self._w, 'pageconfigure', name) + self._options(kw)) > 1099a1116,1119 > def pageconfigure(self, name, **kw): > apply(self.tk.call, > (self._w, 'pageconfigure', name) + self._options(kw)) > 1162c1182 < names = self.tk.call(self._w, 'panes') --- > names = self.tk.split(self.tk.call (self._w, 'panes')) 1167a1188,1191 > def paneconfigure(self, name, **kw): > apply(self.tk.call, > (self._w, 'paneconfigure', name) + self._options(kw)) > 1571a1596,1599 > TixSubWidget.__init__(self, master, name, destroy_physically) > > class _dummyPanedWindow(PanedWindow, TixSubWidget): > def __init__(self, master, name, destroy_physically=1): ---------------------------------------------------------------------- >Comment By: Robert Roy (rjroy) Date: 2001-12-09 18:34 Message: Logged In: YES user_id=352797 Thanks for reviewing my submission. I will make sure to do a context diff next time I submit something. The pages method that I added is applied to the listNoteBook class not the tixPanedWindow class. It is inherited from the vstack base class. Where can I find the later version? Do I have to get them from the source tree? Bob Roy. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2001-12-09 15:36 Message: Logged In: YES user_id=33229 The first part of the patch was a definite bug, but your diffs are against Tix.py 1.5, and the bug is fixed in the current version 1.6. (I've also submitted a new version (1.7?) to the patch queue). You're right about the splitlist, but the next part of the patch is partly wrong: there is no 'pages' method to the tixPanedWindow. The methods of the class in Tcl Tix are: add delete forget manage panecget paneconfigure panes setsize I appreciate your help on getting the PanedWindow implementation complete. Could I ask you to check the Tcl Tix documentation and code carefully and resubmit this patch against 1.7 when it comes out, perhaps with some of the other missing methods as well? To speed things up for Martin, it could be best to use a context diff diff -c and upload the result as a file. Mike Clarkson ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 08:15 Message: Logged In: YES user_id=3066 I've asked Mike Clarkson (Tix.py guru) to take a look at this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=484994&group_id=5470 From noreply@sourceforge.net Mon Dec 10 04:09:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 20:09:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-479568 ] xxsubtype builtin Message-ID: Bugs item #479568, was opened at 2001-11-08 05:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479568&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Gustavo Niemeyer (niemeyer) >Assigned to: Guido van Rossum (gvanrossum) Summary: xxsubtype builtin Initial Comment: Python 2.2b1+ (#1, Nov 6 2001, 21:52:55) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-i386 Type "help", "copyright", "credits" or "license" for more information. >>> import sys sys.builtin_module_names ('__builtin__', '__main__', '_sre', '_symtable', 'exceptions', 'gc', 'imp', 'marshal', 'new', 'posix', 'signal', 'sys', 'thread', 'xxsubtype') >>> Should xxsubtype be a builtin module? The line mentioning it in Setup.dist is uncommented by default. Maybe it's there just for testing purposes? Thanks! ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-09 20:09 Message: Logged In: YES user_id=31435 Guido, we should "do something about this" before 2.2c1. Perhaps rename to __xxsubtype__? It's still valuable for test_descr.py to exercise it. Or perhaps it should be included in _testcapimodule? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479568&group_id=5470 From noreply@sourceforge.net Mon Dec 10 04:13:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 20:13:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-479568 ] xxsubtype builtin Message-ID: Bugs item #479568, was opened at 2001-11-08 05:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479568&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Guido van Rossum (gvanrossum) Summary: xxsubtype builtin Initial Comment: Python 2.2b1+ (#1, Nov 6 2001, 21:52:55) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-i386 Type "help", "copyright", "credits" or "license" for more information. >>> import sys sys.builtin_module_names ('__builtin__', '__main__', '_sre', '_symtable', 'exceptions', 'gc', 'imp', 'marshal', 'new', 'posix', 'signal', 'sys', 'thread', 'xxsubtype') >>> Should xxsubtype be a builtin module? The line mentioning it in Setup.dist is uncommented by default. Maybe it's there just for testing purposes? Thanks! ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 20:13 Message: Logged In: YES user_id=6380 I'd like to close this with a "won't fix". I don't see what's wrong with having this show up; renaming it seems not worth the effort. It's not like we're stepping on an important piece of the user's namespace. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-09 20:09 Message: Logged In: YES user_id=31435 Guido, we should "do something about this" before 2.2c1. Perhaps rename to __xxsubtype__? It's still valuable for test_descr.py to exercise it. Or perhaps it should be included in _testcapimodule? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479568&group_id=5470 From noreply@sourceforge.net Mon Dec 10 05:01:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 21:01:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-479568 ] xxsubtype builtin Message-ID: Bugs item #479568, was opened at 2001-11-08 05:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479568&group_id=5470 Category: Extension Modules Group: Python 2.2 >Status: Closed >Resolution: Wont Fix >Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) >Assigned to: Tim Peters (tim_one) Summary: xxsubtype builtin Initial Comment: Python 2.2b1+ (#1, Nov 6 2001, 21:52:55) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-i386 Type "help", "copyright", "credits" or "license" for more information. >>> import sys sys.builtin_module_names ('__builtin__', '__main__', '_sre', '_symtable', 'exceptions', 'gc', 'imp', 'marshal', 'new', 'posix', 'signal', 'sys', 'thread', 'xxsubtype') >>> Should xxsubtype be a builtin module? The line mentioning it in Setup.dist is uncommented by default. Maybe it's there just for testing purposes? Thanks! ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-09 21:01 Message: Logged In: YES user_id=31435 I agree, and closed as WontFix. Reassigned to me so you don't get yelled at needlessly . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 20:13 Message: Logged In: YES user_id=6380 I'd like to close this with a "won't fix". I don't see what's wrong with having this show up; renaming it seems not worth the effort. It's not like we're stepping on an important piece of the user's namespace. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-09 20:09 Message: Logged In: YES user_id=31435 Guido, we should "do something about this" before 2.2c1. Perhaps rename to __xxsubtype__? It's still valuable for test_descr.py to exercise it. Or perhaps it should be included in _testcapimodule? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479568&group_id=5470 From noreply@sourceforge.net Mon Dec 10 06:00:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 09 Dec 2001 22:00:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-491033 ] asyncore - api doesn't provide doneevent Message-ID: Bugs item #491033, was opened at 2001-12-09 22:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491033&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Joseph Wayne Norton (natsukashi) Assigned to: Nobody/Anonymous (nobody) Summary: asyncore - api doesn't provide doneevent Initial Comment: The asyncore api doesn't provide a way to invoke the "loop" method but to only perform one iteration. Since the loop method does some selection of which poll method to call before entering the while loop, I have to duplicate the same behavior in my own "dooneiteration" method. I would like some functionality similar to the Tk interp model where one can enter the mainloop or simply do one event. regards, - joe n. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491033&group_id=5470 From noreply@sourceforge.net Mon Dec 10 08:04:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 00:04:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-456612 ] SRE fix 133283 (minimizing repeats) bug Message-ID: Bugs item #456612, was opened at 2001-08-29 11:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456612&group_id=5470 Category: Regular Expressions Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Fredrik Lundh (effbot) Summary: SRE fix 133283 (minimizing repeats) bug Initial Comment: The following is from Python 2.2a2: >>> pat = sre.compile(r'"(?:\")*?"') >>> m = pat.search(r'"a"') >>> m.group() '"a"' Clearly, that string should not have matched the pattern (since the pattern should not allow the 'a'). I believe the problem is from the change marked as #133283 in _sre.c. The code in the first ("unbounded repeat") branch of the if statement searches forward through the string until it matches the tail ('"'), but then the code neglects to check if the repeated pattern actually matches the intervening characters. FWIW, it seems to me that the behavior for non- unbounded repeats (which I believe is identical to the pcre behavior) makes more sense. That is, it seems to me that a minimizing repeat should minimize the number of times the repeated pattern is applied, not the number of characters consumed by those applications. (However, I see that Perl (v. 5.5) minimizes characters consumed, so I suppose that's the reason for the change). ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2001-12-10 00:04 Message: Logged In: YES user_id=38376 fixed in 2.2rc1 (patch #133283 was broken) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456612&group_id=5470 From noreply@sourceforge.net Mon Dec 10 08:06:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 00:06:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-420011 ] \u escapes don't work inside ranges Message-ID: Bugs item #420011, was opened at 2001-04-29 14:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420011&group_id=5470 Category: Regular Expressions Group: Feature Request >Status: Closed >Resolution: Wont Fix Priority: 3 Submitted By: Fredrik Lundh (effbot) Assigned to: Fredrik Lundh (effbot) Summary: \u escapes don't work inside ranges Initial Comment: the pattern "[\u0000-\uffff]" should match any unicode character. for some reason, it doesn't seem to do that... ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-04-29 14:18 Message: Logged In: YES user_id=38376 I meant r"[\u0000-\uffff]" and on second thought, I'm not sure it's a bug: SRE doesn't seem to support \u and \U escapes at all. and the pattern u"[\u0000-\uffff]" works as expected. I'll change this to a feature request. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420011&group_id=5470 From noreply@sourceforge.net Mon Dec 10 08:10:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 00:10:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-231204 ] fork()/execv() IDE Crash Message-ID: Bugs item #231204, was opened at 2001-02-05 18:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231204&group_id=5470 Category: IDLE Group: Platform-specific Status: Open Resolution: None Priority: 3 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Nobody/Anonymous (nobody) Summary: fork()/execv() IDE Crash Initial Comment: I'm just learning the fork()/execv() business and i'm sure this code is crappy... but it does crash IDLE on Windows 98 #system test import os MyList = ['127.0.0.1'] while 1: os.execv('C:\Windows\ping', MyList ) os.fork() ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2001-12-10 00:10 Message: Logged In: YES user_id=38376 ponder, ponder... don't have Win98, and no time to spare. maybe an sys.exitfunc hook could be used to trap this? or perhaps we need a sys.execfunc? my advice for the time being is "don't do that". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-02-05 18:51 Message: Assigned to effbot for pondering. On Win98SE, the loop isn't needed, and neither is the fork. os.execv is enough to crash IDLE. It dies in tk83.dll. If I do bin = r'\bin\wc.exe' os.execv(bin, [bin, bin]) then wc does run to completion, so I imagine Tk is mondo confused about Python going away. "Nobody", fork doesn't even exist on Windows: >>> import os >>> os.fork Traceback (most recent call last): File "", line 1, in ? AttributeError: 'os' module has no attribute 'fork' >>> This is stuff is natural only on Unix systems. On Windows, play with the os.spawn* functions instead. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-02-05 18:36 Message: Questions/Comments can be sent to radiohead83@yahoo.com ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231204&group_id=5470 From noreply@sourceforge.net Mon Dec 10 10:42:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 02:42:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-490168 ] shutil.copy(path, path) deletes contents Message-ID: Bugs item #490168, was opened at 2001-12-07 01:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490168&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copy(path, path) deletes contents Initial Comment: If source equals destination path the contents of the file is deleted. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-10 02:42 Message: Logged In: YES user_id=6656 To the OP, if you're paying attention: shutil is pretty useless. You might consider using distutils.file_util instead (though I don't know if that suffers from this "problem"). I wanted to do somthing about this before 2.2, sigh... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:17 Message: Logged In: YES user_id=6380 I know the Unix 'cp' command tests for this condition, but shouldn't this fall in the category of "don't do that, then" in the Python world? How stupid do we expect the programmer to be? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490168&group_id=5470 From noreply@sourceforge.net Mon Dec 10 11:01:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 03:01:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-477371 ] build_scripts can use wrong #! line Message-ID: Bugs item #477371, was opened at 2001-11-01 19:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477371&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Michael Hudson (mwh) Summary: build_scripts can use wrong #! line Initial Comment: When the build_scripts command is run, it places into build/scripts a copy of the script with the #! line modified to call the python version directly. But if you subsequently call setup.py with a different python version, the script is not updated to use the correct python executable path. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-10 03:01 Message: Logged In: YES user_id=6656 Try this. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-08 03:15 Message: Logged In: YES user_id=6656 Fair point. Should be fairly easy to fix. I'll have a go next week, but feel free to submit a patch before then . ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2001-12-07 18:13 Message: Logged In: YES user_id=65253 Uh, I guess maybe it doesn't bother you, but it sees an odd inconsistancy that build_ext puts its generated files in version-specific dirs, yet build_scripts makes no attempt to handle it. If you are never supposed to run setup.py with more than one version of python then why does build_ext handle it? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:28 Message: Logged In: YES user_id=6656 So don't do that then? Surely you're going to get problems with various other bits of distutils if you're not consistent about which Python you run setup.py with? Very much inclined to close this... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477371&group_id=5470 From noreply@sourceforge.net Mon Dec 10 11:06:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 03:06:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-490168 ] shutil.copy(path, path) deletes contents Message-ID: Bugs item #490168, was opened at 2001-12-07 01:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490168&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copy(path, path) deletes contents Initial Comment: If source equals destination path the contents of the file is deleted. ---------------------------------------------------------------------- Comment By: Matthias Kirst (mattkirst) Date: 2001-12-10 03:06 Message: Logged In: YES user_id=397984 That's correct when using the command interactively. But when the command is used in an environment where source and destination path come from user interactions over a GUI for instance the programmer won't check for the source and destination path each time the command is called. In my example I had a relative and an absolute path to compare. So I would have had the relative path tracked programmatically. At the end it seemed clearer to me to read the source file out, create an empty destination (open "w+") and write the dump to this file. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 02:42 Message: Logged In: YES user_id=6656 To the OP, if you're paying attention: shutil is pretty useless. You might consider using distutils.file_util instead (though I don't know if that suffers from this "problem"). I wanted to do somthing about this before 2.2, sigh... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:17 Message: Logged In: YES user_id=6380 I know the Unix 'cp' command tests for this condition, but shouldn't this fall in the category of "don't do that, then" in the Python world? How stupid do we expect the programmer to be? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490168&group_id=5470 From noreply@sourceforge.net Mon Dec 10 11:17:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 03:17:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-479568 ] xxsubtype builtin Message-ID: Bugs item #479568, was opened at 2001-11-08 05:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479568&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Tim Peters (tim_one) Summary: xxsubtype builtin Initial Comment: Python 2.2b1+ (#1, Nov 6 2001, 21:52:55) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-i386 Type "help", "copyright", "credits" or "license" for more information. >>> import sys sys.builtin_module_names ('__builtin__', '__main__', '_sre', '_symtable', 'exceptions', 'gc', 'imp', 'marshal', 'new', 'posix', 'signal', 'sys', 'thread', 'xxsubtype') >>> Should xxsubtype be a builtin module? The line mentioning it in Setup.dist is uncommented by default. Maybe it's there just for testing purposes? Thanks! ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-12-10 03:17 Message: Logged In: YES user_id=7887 I wasn't concerned about the namespace polution. I was really concerned about needless bloatness being included in the interpreter. I don't see any problems with shipping that in a beta version. I just hope this gets removed in the final release. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-09 21:01 Message: Logged In: YES user_id=31435 I agree, and closed as WontFix. Reassigned to me so you don't get yelled at needlessly . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 20:13 Message: Logged In: YES user_id=6380 I'd like to close this with a "won't fix". I don't see what's wrong with having this show up; renaming it seems not worth the effort. It's not like we're stepping on an important piece of the user's namespace. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-09 20:09 Message: Logged In: YES user_id=31435 Guido, we should "do something about this" before 2.2c1. Perhaps rename to __xxsubtype__? It's still valuable for test_descr.py to exercise it. Or perhaps it should be included in _testcapimodule? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479568&group_id=5470 From noreply@sourceforge.net Mon Dec 10 12:02:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 04:02:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-491108 ] 2.2b2 build fail under Cygwin Message-ID: Bugs item #491108, was opened at 2001-12-10 04:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491108&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: kent sin (kentsin) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2b2 build fail under Cygwin Initial Comment: ne.o -L/usr/lib/termcap -L/usr/local/lib -L. - lreadline -lncurses -lpython2.2 -o build/lib.cygwin-1.3.6-i686-2.2/readline.dll WARNING: removing "readline" since importing it failed skipping 'crypt' extension (up-to-date) skipping '_socket' extension (up-to-date) building 'gdbm' extension gcc -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT - I. -I/home/kentsin/Python- 2.2b2/./Include -I/usr/local/include -IInclude/ - c /home/kentsin/Python-2.2b2/Mo dules/gdbmmodule.c -o build/temp.cygwin-1.3.6-i686- 2.2/gdbmmodule.o C:\bin\home\kentsin\Python-2.2b2\python.exe: *** unable to remap C:\bin\bin\cygs sl.dll to same address as parent -- 0x1A5D0000 0 [main] python 1060 sync_with_child: child 1488 (0xF8) died before initial ization with status code 0x1 5375 [main] python 1060 sync_with_child: *** child state child loading dlls error: Resource temporarily unavailable make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491108&group_id=5470 From noreply@sourceforge.net Mon Dec 10 12:16:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 04:16:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-491108 ] 2.2b2 build fail under Cygwin Message-ID: Bugs item #491108, was opened at 2001-12-10 04:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491108&group_id=5470 Category: Build Group: Python 2.2 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: kent sin (kentsin) >Assigned to: Michael Hudson (mwh) Summary: 2.2b2 build fail under Cygwin Initial Comment: ne.o -L/usr/lib/termcap -L/usr/local/lib -L. - lreadline -lncurses -lpython2.2 -o build/lib.cygwin-1.3.6-i686-2.2/readline.dll WARNING: removing "readline" since importing it failed skipping 'crypt' extension (up-to-date) skipping '_socket' extension (up-to-date) building 'gdbm' extension gcc -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT - I. -I/home/kentsin/Python- 2.2b2/./Include -I/usr/local/include -IInclude/ - c /home/kentsin/Python-2.2b2/Mo dules/gdbmmodule.c -o build/temp.cygwin-1.3.6-i686- 2.2/gdbmmodule.o C:\bin\home\kentsin\Python-2.2b2\python.exe: *** unable to remap C:\bin\bin\cygs sl.dll to same address as parent -- 0x1A5D0000 0 [main] python 1060 sync_with_child: child 1488 (0xF8) died before initial ization with status code 0x1 5375 [main] python 1060 sync_with_child: *** child state child loading dlls error: Resource temporarily unavailable make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-10 04:16 Message: Logged In: YES user_id=6656 Duplicate of [ #489709 ] Building Fails under Cygwin (please, at least *try* to see if a bug has already been reported). We think this is cygwin's fault, and people are working on it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491108&group_id=5470 From noreply@sourceforge.net Mon Dec 10 12:39:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 04:39:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-472881 ] distutils does not deduce dependencies Message-ID: Bugs item #472881, was opened at 2001-10-19 11:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Guido van Rossum (gvanrossum) Summary: distutils does not deduce dependencies Initial Comment: I just "cvs up"d my Python tree and executed "make". Nothing much changed, except patchlevel.h. Make got this right and rebuilt everything (patchlevel.h is included from Python.h, so changing patchlevel.h should cause make to rebuild just about everything). Distutils failed to notice this, however, so it didn't rebuild any modules. In this case, I think the failure to rebuild is probably innocuous, but I'm not at all confident it will do the right thing if I modify some other file. For example, I've noticed that it's not sufficient to delete a module's .o file when you want to rebuild it. Distutils still thinks the .so file is okay. If distutils is going to take the place of make I think it's going to need to do a much better job deducing file dependencies or provide a robust way for a person to tell it what those dependencies are. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-10 04:39 Message: Logged In: YES user_id=6656 Here's an attempt. TBH, I'd be a bit nervous about fiddling with the build at this stage, but assigning to Guido to decide. I'd recommend assigning it back to me Pending/Later, and applying something like this early in 2.3. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 07:49 Message: Logged In: YES user_id=6656 OK, I'll try to get something concrete done in the next few days. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 06:54 Message: Logged In: YES user_id=6380 It depends on what kind of change you are making to a header file. 99% of the time I find that a change to a header is something innocuous like add a new function, and it still causes a rebuild of the world. That's particularly annoying when I'm experimenting with a new object type and adding things to the header file one at a time -- each time the header gets touched everything gets rebuilt. But it's easy enough to only rebuild the core ("make python") so I'm not sure if I really oppose your simple solution. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:53 Message: Logged In: YES user_id=6656 Eh, I was going to add a os.system("touch last_build") thingy to setup.py. Not aiming for elegance here. Is it really 99% of the time that changes in headers are irrelevant? Then what make does is a bit silly, surely. It would presumably be easy enough to ask the user, but I know I'd find that really annoying (I generally fire a biuld off, do something else for a few minutes and come back. OTOH, I almost always go through a "rm -rfv build && mkdir build && cd build && ../configure --prefix=$HOME && make" ritual anyway so this issue doesn't affect me in the slightest). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 05:40 Message: Logged In: YES user_id=6380 Hm, how do you know when the last build was? Also, since in 99% of the cases this is unnecessary and rebuilding all extensions takes a long time, I'd like this to be optional -- maybe it can ask the user before zapping build? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 04:36 Message: Logged In: YES user_id=6656 Would a "good enough" solution be to check (in setup.py) if pyconfig.h or anything in Include/ has changed since the last build and if so blow away the & build directory? Doing a "proper" job seems frankly unlikely, and would have much the same effect as the above anyway for building Python... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470 From noreply@sourceforge.net Mon Dec 10 12:41:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 04:41:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-477371 ] build_scripts can use wrong #! line Message-ID: Bugs item #477371, was opened at 2001-11-01 19:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477371&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) >Assigned to: Nobody/Anonymous (nobody) Summary: build_scripts can use wrong #! line Initial Comment: When the build_scripts command is run, it places into build/scripts a copy of the script with the #! line modified to call the python version directly. But if you subsequently call setup.py with a different python version, the script is not updated to use the correct python executable path. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-10 04:41 Message: Logged In: YES user_id=6656 And I'd like someone else to have a look at this before I apply it (if indeed I do), so I'm unassigning it from me. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 03:01 Message: Logged In: YES user_id=6656 Try this. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-08 03:15 Message: Logged In: YES user_id=6656 Fair point. Should be fairly easy to fix. I'll have a go next week, but feel free to submit a patch before then . ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2001-12-07 18:13 Message: Logged In: YES user_id=65253 Uh, I guess maybe it doesn't bother you, but it sees an odd inconsistancy that build_ext puts its generated files in version-specific dirs, yet build_scripts makes no attempt to handle it. If you are never supposed to run setup.py with more than one version of python then why does build_ext handle it? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:28 Message: Logged In: YES user_id=6656 So don't do that then? Surely you're going to get problems with various other bits of distutils if you're not consistent about which Python you run setup.py with? Very much inclined to close this... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477371&group_id=5470 From noreply@sourceforge.net Mon Dec 10 13:13:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 05:13:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-489709 ] Building Fails under Cygwin Message-ID: Bugs item #489709, was opened at 2001-12-05 20:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489709&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Michael Hudson (mwh) Summary: Building Fails under Cygwin Initial Comment: Even after applying the h2py patch, building under Cygwin ends with the following error: building 'gdbm' extension gcc -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT - I. -I/cygdrive/e/Python-2.2b2/./Include - I/usr/local/include -IInclude/ -c /cygdrive/e/Python- 2.2b2/Modules/gdbmmodule.c -o build/temp.cygwin-1.3. 5-i686-2.2/gdbmmodule.o e:\buildpy\python.exe: *** unable to remap C:\cygnus\bin\cygssl.dll to same address as parent -- 0x1A7C0000 0 [main] python 1292 sync_with_child: child 1108 (0xF0) died before initialization with status code 0x1 25901 [main] python 1292 sync_with_child: *** child state child loading dlls error: Resource temporarily unavailable make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-10 05:13 Message: Logged In: YES user_id=6656 (sf keeps logging me out every ten minutes, grr) This is being hashed out on the cygwin list. It's unfortunately not obvious that it will be fixed in the 2.2 timeframe. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-06 07:16 Message: Logged In: YES user_id=6656 Hmm. Seems pretty similar to mine. I'll bug Jason Tishler and see if he knows anything about it. ---------------------------------------------------------------------- Comment By: David Abrahams (david_abrahams) Date: 2001-12-06 07:12 Message: Logged In: YES user_id=52572 I'm using Win2K CYGWIN_NT-5.0 MOREPIE 1.3.5(0.47/3/2) 2001-11-13 23:16 i686 unknown And I've built and installed GCC 3.0.2, thought the Python build seems to use 2.95.x anyway. I am not on the cygwin mailing list, sorry ;-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-06 05:53 Message: Logged In: YES user_id=6656 Just to say that I'm seeing this too. What OS? I'm on NT4 SP6. Which cygwin? I'm [Administrator@MATHS-PC150 QUAKE]$ uname -a CYGWIN_NT-4.0 MATHS-PC150 1.3.6(0.47/3/2) 2001-12-03 15:41 i686 unknown I was actually assuming this was a cygwin bug. Are you on the cygwin mailing list? Maybe you could try raising it there? I would, but I *really* don't need another subscription to a high-volume mailing list right now. PS: can we add jason as a developer? then we can assign bugs to him . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489709&group_id=5470 From noreply@sourceforge.net Mon Dec 10 14:47:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 06:47:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-491033 ] asyncore - api doesn't provide doneevent Message-ID: Bugs item #491033, was opened at 2001-12-09 22:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491033&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Joseph Wayne Norton (natsukashi) Assigned to: Nobody/Anonymous (nobody) Summary: asyncore - api doesn't provide doneevent Initial Comment: The asyncore api doesn't provide a way to invoke the "loop" method but to only perform one iteration. Since the loop method does some selection of which poll method to call before entering the while loop, I have to duplicate the same behavior in my own "dooneiteration" method. I would like some functionality similar to the Tk interp model where one can enter the mainloop or simply do one event. regards, - joe n. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 06:47 Message: Logged In: YES user_id=6380 If you can supply a decent patch, we'd happily apply it to Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491033&group_id=5470 From noreply@sourceforge.net Mon Dec 10 14:56:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 06:56:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-231204 ] fork()/execv() IDE Crash Message-ID: Bugs item #231204, was opened at 2001-02-05 18:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231204&group_id=5470 Category: IDLE Group: Platform-specific >Status: Closed >Resolution: Works For Me Priority: 3 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: fork()/execv() IDE Crash Initial Comment: I'm just learning the fork()/execv() business and i'm sure this code is crappy... but it does crash IDLE on Windows 98 #system test import os MyList = ['127.0.0.1'] while 1: os.execv('C:\Windows\ping', MyList ) os.fork() ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 06:56 Message: Logged In: YES user_id=6380 IMO there's no bug here, just a clueless user. (1) This works for me; I get a ping usage message. (2) MyList[0] should be "ping", MyList[1] should be the address to ping. (3) There's no os.fork() -- fortunately this never gets reached. (4) os.execv() doesn't return, so the loop gets executed a half time. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-12-10 00:10 Message: Logged In: YES user_id=38376 ponder, ponder... don't have Win98, and no time to spare. maybe an sys.exitfunc hook could be used to trap this? or perhaps we need a sys.execfunc? my advice for the time being is "don't do that". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-02-05 18:51 Message: Assigned to effbot for pondering. On Win98SE, the loop isn't needed, and neither is the fork. os.execv is enough to crash IDLE. It dies in tk83.dll. If I do bin = r'\bin\wc.exe' os.execv(bin, [bin, bin]) then wc does run to completion, so I imagine Tk is mondo confused about Python going away. "Nobody", fork doesn't even exist on Windows: >>> import os >>> os.fork Traceback (most recent call last): File "", line 1, in ? AttributeError: 'os' module has no attribute 'fork' >>> This is stuff is natural only on Unix systems. On Windows, play with the os.spawn* functions instead. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-02-05 18:36 Message: Questions/Comments can be sent to radiohead83@yahoo.com ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231204&group_id=5470 From noreply@sourceforge.net Mon Dec 10 15:16:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 07:16:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-472881 ] distutils does not deduce dependencies Message-ID: Bugs item #472881, was opened at 2001-10-19 11:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470 Category: Distutils Group: None Status: Open >Resolution: Postponed Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Michael Hudson (mwh) Summary: distutils does not deduce dependencies Initial Comment: I just "cvs up"d my Python tree and executed "make". Nothing much changed, except patchlevel.h. Make got this right and rebuilt everything (patchlevel.h is included from Python.h, so changing patchlevel.h should cause make to rebuild just about everything). Distutils failed to notice this, however, so it didn't rebuild any modules. In this case, I think the failure to rebuild is probably innocuous, but I'm not at all confident it will do the right thing if I modify some other file. For example, I've noticed that it's not sufficient to delete a module's .o file when you want to rebuild it. Distutils still thinks the .so file is okay. If distutils is going to take the place of make I think it's going to need to do a much better job deducing file dependencies or provide a robust way for a person to tell it what those dependencies are. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:16 Message: Logged In: YES user_id=6380 I agree. Let's put this off until 2.3 (or maybe 2.2.1). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 04:39 Message: Logged In: YES user_id=6656 Here's an attempt. TBH, I'd be a bit nervous about fiddling with the build at this stage, but assigning to Guido to decide. I'd recommend assigning it back to me Pending/Later, and applying something like this early in 2.3. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 07:49 Message: Logged In: YES user_id=6656 OK, I'll try to get something concrete done in the next few days. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 06:54 Message: Logged In: YES user_id=6380 It depends on what kind of change you are making to a header file. 99% of the time I find that a change to a header is something innocuous like add a new function, and it still causes a rebuild of the world. That's particularly annoying when I'm experimenting with a new object type and adding things to the header file one at a time -- each time the header gets touched everything gets rebuilt. But it's easy enough to only rebuild the core ("make python") so I'm not sure if I really oppose your simple solution. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:53 Message: Logged In: YES user_id=6656 Eh, I was going to add a os.system("touch last_build") thingy to setup.py. Not aiming for elegance here. Is it really 99% of the time that changes in headers are irrelevant? Then what make does is a bit silly, surely. It would presumably be easy enough to ask the user, but I know I'd find that really annoying (I generally fire a biuld off, do something else for a few minutes and come back. OTOH, I almost always go through a "rm -rfv build && mkdir build && cd build && ../configure --prefix=$HOME && make" ritual anyway so this issue doesn't affect me in the slightest). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 05:40 Message: Logged In: YES user_id=6380 Hm, how do you know when the last build was? Also, since in 99% of the cases this is unnecessary and rebuilding all extensions takes a long time, I'd like this to be optional -- maybe it can ask the user before zapping build? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 04:36 Message: Logged In: YES user_id=6656 Would a "good enough" solution be to check (in setup.py) if pyconfig.h or anything in Include/ has changed since the last build and if so blow away the & build directory? Doing a "proper" job seems frankly unlikely, and would have much the same effect as the above anyway for building Python... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470 From noreply@sourceforge.net Mon Dec 10 15:21:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 07:21:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-477371 ] build_scripts can use wrong #! line Message-ID: Bugs item #477371, was opened at 2001-11-01 19:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477371&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) >Assigned to: Michael Hudson (mwh) Summary: build_scripts can use wrong #! line Initial Comment: When the build_scripts command is run, it places into build/scripts a copy of the script with the #! line modified to call the python version directly. But if you subsequently call setup.py with a different python version, the script is not updated to use the correct python executable path. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:21 Message: Logged In: YES user_id=6380 Works for me. Back to you. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 04:41 Message: Logged In: YES user_id=6656 And I'd like someone else to have a look at this before I apply it (if indeed I do), so I'm unassigning it from me. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 03:01 Message: Logged In: YES user_id=6656 Try this. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-08 03:15 Message: Logged In: YES user_id=6656 Fair point. Should be fairly easy to fix. I'll have a go next week, but feel free to submit a patch before then . ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2001-12-07 18:13 Message: Logged In: YES user_id=65253 Uh, I guess maybe it doesn't bother you, but it sees an odd inconsistancy that build_ext puts its generated files in version-specific dirs, yet build_scripts makes no attempt to handle it. If you are never supposed to run setup.py with more than one version of python then why does build_ext handle it? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:28 Message: Logged In: YES user_id=6656 So don't do that then? Surely you're going to get problems with various other bits of distutils if you're not consistent about which Python you run setup.py with? Very much inclined to close this... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477371&group_id=5470 From noreply@sourceforge.net Mon Dec 10 15:29:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 07:29:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-477371 ] build_scripts can use wrong #! line Message-ID: Bugs item #477371, was opened at 2001-11-01 19:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477371&group_id=5470 Category: Distutils Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Michael Hudson (mwh) Summary: build_scripts can use wrong #! line Initial Comment: When the build_scripts command is run, it places into build/scripts a copy of the script with the #! line modified to call the python version directly. But if you subsequently call setup.py with a different python version, the script is not updated to use the correct python executable path. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-10 07:29 Message: Logged In: YES user_id=6656 Checked in as revision 1.32 of Lib/distutils/command/build.py. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:21 Message: Logged In: YES user_id=6380 Works for me. Back to you. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 04:41 Message: Logged In: YES user_id=6656 And I'd like someone else to have a look at this before I apply it (if indeed I do), so I'm unassigning it from me. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 03:01 Message: Logged In: YES user_id=6656 Try this. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-08 03:15 Message: Logged In: YES user_id=6656 Fair point. Should be fairly easy to fix. I'll have a go next week, but feel free to submit a patch before then . ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2001-12-07 18:13 Message: Logged In: YES user_id=65253 Uh, I guess maybe it doesn't bother you, but it sees an odd inconsistancy that build_ext puts its generated files in version-specific dirs, yet build_scripts makes no attempt to handle it. If you are never supposed to run setup.py with more than one version of python then why does build_ext handle it? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:28 Message: Logged In: YES user_id=6656 So don't do that then? Surely you're going to get problems with various other bits of distutils if you're not consistent about which Python you run setup.py with? Very much inclined to close this... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477371&group_id=5470 From noreply@sourceforge.net Mon Dec 10 15:31:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 07:31:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-472881 ] distutils does not deduce dependencies Message-ID: Bugs item #472881, was opened at 2001-10-19 11:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470 Category: Distutils Group: None >Status: Pending Resolution: Postponed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Michael Hudson (mwh) Summary: distutils does not deduce dependencies Initial Comment: I just "cvs up"d my Python tree and executed "make". Nothing much changed, except patchlevel.h. Make got this right and rebuilt everything (patchlevel.h is included from Python.h, so changing patchlevel.h should cause make to rebuild just about everything). Distutils failed to notice this, however, so it didn't rebuild any modules. In this case, I think the failure to rebuild is probably innocuous, but I'm not at all confident it will do the right thing if I modify some other file. For example, I've noticed that it's not sufficient to delete a module's .o file when you want to rebuild it. Distutils still thinks the .so file is okay. If distutils is going to take the place of make I think it's going to need to do a much better job deducing file dependencies or provide a robust way for a person to tell it what those dependencies are. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:16 Message: Logged In: YES user_id=6380 I agree. Let's put this off until 2.3 (or maybe 2.2.1). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 04:39 Message: Logged In: YES user_id=6656 Here's an attempt. TBH, I'd be a bit nervous about fiddling with the build at this stage, but assigning to Guido to decide. I'd recommend assigning it back to me Pending/Later, and applying something like this early in 2.3. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 07:49 Message: Logged In: YES user_id=6656 OK, I'll try to get something concrete done in the next few days. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 06:54 Message: Logged In: YES user_id=6380 It depends on what kind of change you are making to a header file. 99% of the time I find that a change to a header is something innocuous like add a new function, and it still causes a rebuild of the world. That's particularly annoying when I'm experimenting with a new object type and adding things to the header file one at a time -- each time the header gets touched everything gets rebuilt. But it's easy enough to only rebuild the core ("make python") so I'm not sure if I really oppose your simple solution. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:53 Message: Logged In: YES user_id=6656 Eh, I was going to add a os.system("touch last_build") thingy to setup.py. Not aiming for elegance here. Is it really 99% of the time that changes in headers are irrelevant? Then what make does is a bit silly, surely. It would presumably be easy enough to ask the user, but I know I'd find that really annoying (I generally fire a biuld off, do something else for a few minutes and come back. OTOH, I almost always go through a "rm -rfv build && mkdir build && cd build && ../configure --prefix=$HOME && make" ritual anyway so this issue doesn't affect me in the slightest). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 05:40 Message: Logged In: YES user_id=6380 Hm, how do you know when the last build was? Also, since in 99% of the cases this is unnecessary and rebuilding all extensions takes a long time, I'd like this to be optional -- maybe it can ask the user before zapping build? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 04:36 Message: Logged In: YES user_id=6656 Would a "good enough" solution be to check (in setup.py) if pyconfig.h or anything in Include/ has changed since the last build and if so blow away the & build directory? Doing a "proper" job seems frankly unlikely, and would have much the same effect as the above anyway for building Python... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470 From noreply@sourceforge.net Mon Dec 10 15:34:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 07:34:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-478428 ] dbm build fails Message-ID: Bugs item #478428, was opened at 2001-11-05 12:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478428&group_id=5470 Category: Macintosh Group: Python 2.2 Status: Closed Resolution: None Priority: 5 Submitted By: John Buell (dadaist) Assigned to: Jack Jansen (jackjansen) Summary: dbm build fails Initial Comment: Trying a build with cvs source downloaded this morning. I've been sure to do the configure --with-suffix=_ on case-insensitive Mac OS X (10.1), but I'm having some problem with the 'dbm' module. Here's a copy of the messages: building 'dbm' extension /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c: In function `dbm_subscript': /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c:104: warning: implicit declaration of function `dbm_error' /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c:105: warning: implicit declaration of function `dbm_clearerr' cc -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -I. -I/Users/jbuell/Documents/Python/python/dist/src/./Include -I/Users/jbuell/Documents/Python/python/dist/src/./Mac/Include -I/usr/local/include -IInclude/ -c /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c -o build/temp.darwin-1.4-Power Macintosh-2.2/dbmmodule.o cc -bundle -flat_namespace -undefined suppress build/temp.darwin-1.4-Power Macintosh-2.2/dbmmodule.o -L/usr/local/lib -o build/lib.darwin-1.4-Power Macintosh-2.2/dbm.so building 'gdbm' extension dyld: ./python_ Undefined symbols: __ashldi3 make: *** [sharedmods] Error 67 Any suggestions? Anything I can change in my settings to get past this? -John ---------------------------------------------------------------------- >Comment By: John Buell (dadaist) Date: 2001-12-10 07:34 Message: Logged In: YES user_id=368337 Well, I thought I'd reinstall the developer tools, but decided no, why not move this gdbm.h from /usr/local/include to /tmp ? That did it. It did the entire make and make install without a hitch. However, shouldn't Python be able to build _with_ a gdbm.h file? Is mine just out of date? I'm going to attach it this time. -John ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-05 15:15 Message: Logged In: YES user_id=45365 John, not so on my iBook (10.1.1, devtools installed), so I'm 99% sure that the gdbm.h you have in /usr/include is also the result of something you installed.... ---------------------------------------------------------------------- Comment By: John Buell (dadaist) Date: 2001-12-05 08:13 Message: Logged In: YES user_id=368337 Okay, further checking shows that the beige G3 does NOT have a gdbm.h ANYWHERE, while the iBook does. No wonder it succeeds on the one and not on the other. [localhost:/Users/jbuell] root# ls -l `find / -name gdbm.h -print` -rw-r--r-- 1 root admin 4744 Oct 1 02:54 /sw/include/gdbm.h -rw-r--r-- 1 root wheel 4744 Feb 27 2001 /usr/local/include/gdbm.h I can include a copy of this gdbm.h if necessary. I'm wondering if it's from an older version that is breaking the python 2.2 build? Where in the build/make trees could I go to comment this out? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-04 03:21 Message: Logged In: YES user_id=45365 The problem isn't with /sw, it's with the gdbm.h that is installed in /usr/local/include. This is what triggers setup.py to try and build gdbm. The other questrion is of course why it doesn't work: if you have gdbm.h and libgdbm there's really no reason why it shouldn't build. ---------------------------------------------------------------------- Comment By: John Buell (dadaist) Date: 2001-12-03 09:29 Message: Logged In: YES user_id=368337 Sorry, I've been busy. I've narrowed it down to being a fink-related problem. My beige G3 without fink can build and install python 2.2 just fine. The iBook WITH fink is what doesn't like the gdbm thing. The odd part is that the fink directories (/sw/*) are NOT part of my path while I'm doing builds, but gdbm seems to be finding the extra files anyway. bash-2.05$ echo $PATH ~/bin/powerpc-apple-darwin:/Users/jbuell/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/X11R6/bin [localhost:/Users/jbuell] root# find / -name libgdbm.a -print /sw/lib/libgdbm.a /usr/local/lib/libgdbm.a [localhost:/Users/jbuell] root# find / -name gdbm.h -print /sw/include/gdbm.h /usr/local/include/gdbm.h Other than uninstalling fink, is there a way to get python's build mechanism to completely ignore /sw and its subdirectories? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-02 14:15 Message: Logged In: YES user_id=45365 As the originator didn't follow up on my previous remark and everything works fine for me I'm closing this bug. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-06 12:45 Message: Logged In: YES user_id=45365 Note that the problem is with gdbm, not with dbm. Dbm seems to build fine (with a warning). I've heard a report of this before. Needless to say, for me there is no problem whatsoever:-) I think that the problem is that setup.py detects files that indicate to it that dbm is available while in fact it is not. Could you check whether you have a libgdbm.a and/or a gdbm.h on your system somewhere? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478428&group_id=5470 From noreply@sourceforge.net Mon Dec 10 15:46:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 07:46:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-478428 ] dbm build fails Message-ID: Bugs item #478428, was opened at 2001-11-05 12:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478428&group_id=5470 Category: Macintosh Group: Python 2.2 Status: Closed Resolution: None Priority: 5 Submitted By: John Buell (dadaist) Assigned to: Jack Jansen (jackjansen) Summary: dbm build fails Initial Comment: Trying a build with cvs source downloaded this morning. I've been sure to do the configure --with-suffix=_ on case-insensitive Mac OS X (10.1), but I'm having some problem with the 'dbm' module. Here's a copy of the messages: building 'dbm' extension /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c: In function `dbm_subscript': /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c:104: warning: implicit declaration of function `dbm_error' /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c:105: warning: implicit declaration of function `dbm_clearerr' cc -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -I. -I/Users/jbuell/Documents/Python/python/dist/src/./Include -I/Users/jbuell/Documents/Python/python/dist/src/./Mac/Include -I/usr/local/include -IInclude/ -c /Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c -o build/temp.darwin-1.4-Power Macintosh-2.2/dbmmodule.o cc -bundle -flat_namespace -undefined suppress build/temp.darwin-1.4-Power Macintosh-2.2/dbmmodule.o -L/usr/local/lib -o build/lib.darwin-1.4-Power Macintosh-2.2/dbm.so building 'gdbm' extension dyld: ./python_ Undefined symbols: __ashldi3 make: *** [sharedmods] Error 67 Any suggestions? Anything I can change in my settings to get past this? -John ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-10 07:46 Message: Logged In: YES user_id=45365 John, sorry but I really don't have the time to pursue this further. Gdbm isn't part of a standard MacOSX installation, and if you want to investigate why it doesn't build: by all means! (And please post a patch here, too!). But I'm simply too busy with 2.2 coming up and having to care for both OSX Python and MacPython. Sorry... ---------------------------------------------------------------------- Comment By: John Buell (dadaist) Date: 2001-12-10 07:34 Message: Logged In: YES user_id=368337 Well, I thought I'd reinstall the developer tools, but decided no, why not move this gdbm.h from /usr/local/include to /tmp ? That did it. It did the entire make and make install without a hitch. However, shouldn't Python be able to build _with_ a gdbm.h file? Is mine just out of date? I'm going to attach it this time. -John ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-05 15:15 Message: Logged In: YES user_id=45365 John, not so on my iBook (10.1.1, devtools installed), so I'm 99% sure that the gdbm.h you have in /usr/include is also the result of something you installed.... ---------------------------------------------------------------------- Comment By: John Buell (dadaist) Date: 2001-12-05 08:13 Message: Logged In: YES user_id=368337 Okay, further checking shows that the beige G3 does NOT have a gdbm.h ANYWHERE, while the iBook does. No wonder it succeeds on the one and not on the other. [localhost:/Users/jbuell] root# ls -l `find / -name gdbm.h -print` -rw-r--r-- 1 root admin 4744 Oct 1 02:54 /sw/include/gdbm.h -rw-r--r-- 1 root wheel 4744 Feb 27 2001 /usr/local/include/gdbm.h I can include a copy of this gdbm.h if necessary. I'm wondering if it's from an older version that is breaking the python 2.2 build? Where in the build/make trees could I go to comment this out? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-04 03:21 Message: Logged In: YES user_id=45365 The problem isn't with /sw, it's with the gdbm.h that is installed in /usr/local/include. This is what triggers setup.py to try and build gdbm. The other questrion is of course why it doesn't work: if you have gdbm.h and libgdbm there's really no reason why it shouldn't build. ---------------------------------------------------------------------- Comment By: John Buell (dadaist) Date: 2001-12-03 09:29 Message: Logged In: YES user_id=368337 Sorry, I've been busy. I've narrowed it down to being a fink-related problem. My beige G3 without fink can build and install python 2.2 just fine. The iBook WITH fink is what doesn't like the gdbm thing. The odd part is that the fink directories (/sw/*) are NOT part of my path while I'm doing builds, but gdbm seems to be finding the extra files anyway. bash-2.05$ echo $PATH ~/bin/powerpc-apple-darwin:/Users/jbuell/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/X11R6/bin [localhost:/Users/jbuell] root# find / -name libgdbm.a -print /sw/lib/libgdbm.a /usr/local/lib/libgdbm.a [localhost:/Users/jbuell] root# find / -name gdbm.h -print /sw/include/gdbm.h /usr/local/include/gdbm.h Other than uninstalling fink, is there a way to get python's build mechanism to completely ignore /sw and its subdirectories? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-02 14:15 Message: Logged In: YES user_id=45365 As the originator didn't follow up on my previous remark and everything works fine for me I'm closing this bug. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-06 12:45 Message: Logged In: YES user_id=45365 Note that the problem is with gdbm, not with dbm. Dbm seems to build fine (with a warning). I've heard a report of this before. Needless to say, for me there is no problem whatsoever:-) I think that the problem is that setup.py detects files that indicate to it that dbm is available while in fact it is not. Could you check whether you have a libgdbm.a and/or a gdbm.h on your system somewhere? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478428&group_id=5470 From noreply@sourceforge.net Mon Dec 10 15:53:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 07:53:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-410878 ] Distutils should have a Setup parser Message-ID: Bugs item #410878, was opened at 2001-03-23 09:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410878&group_id=5470 Category: Distutils Group: Feature Request Status: Open Resolution: None Priority: 9 Submitted By: A.M. Kuchling (akuchling) Assigned to: A.M. Kuchling (akuchling) Summary: Distutils should have a Setup parser Initial Comment: Setup files are handy for allowing user overrides. I do a minimal parse in Python 2.1's setup.py, and Pete Shinners wrote a more complete one for pygame's config.py. Support for parsing Setup files should be added to the Distutils API, so packagers can easily make overrides for C extension compile flags. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:53 Message: Logged In: YES user_id=6380 Andrew, what's the point of setting the priority to 9 if it won't get done before 2.2? We can't release with outstanding bugs of priority 7 or higher, but we're just going to lower the priority of this item... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410878&group_id=5470 From noreply@sourceforge.net Mon Dec 10 16:09:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 08:09:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-409430 ] pydoc install broken Message-ID: Bugs item #409430, was opened at 2001-03-17 10:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409430&group_id=5470 Category: Installation Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Michael Hudson (mwh) Summary: pydoc install broken Initial Comment: I've moaned about this on python-dev but I want to make sure it doesn't get forgotten. I've just built from CVS, installed in /usr/local, and: $ pydoc -g Traceback (most recent call last): File "/usr/local/bin/pydoc", line 3, in ? import pydoc ImportError: No module named pydoc because the /usr/bin/env python thing hits the older python in /usr first. Don't really know how best to implement this, not being a distutils whiz. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 08:09 Message: Logged In: YES user_id=6380 Michael, this patch works for me (after fixing the typo). So consider it accepted, and please check it in! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:54 Message: Logged In: YES user_id=6656 Please consider the obvious typo to be fixed; I've lost the "!" in the "#!", doh. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 05:48 Message: Logged In: YES user_id=6380 Fred, can you have a quick look at this and bounce it back to MWH with a yea or nay? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:08 Message: Logged In: YES user_id=6656 I finally got off my fat butt and had a go at fixing this. I've no idea who to assign this to to get it reviewed, I'm afraid. Someone have a look please! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-11 07:40 Message: Logged In: YES user_id=6656 Oops, not paying attention. Revision 1.9 of Lib/distutils/command/build_scripts.py seemed to be aimed at fixing this; however, I now have a ~/bin/pydoc that starts: #!python which isn't too helpful. This command either needs to do something different when building Python, or a different command needs to be used to install the pydoc script. Or you could wedge the install path into sys.executable in setup.py, I suppose. Assigned to Greg, as I don't think he's had this patch yet. Also bumped priority, as we now seem to be installing decidely broken scripts, and changed summary. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-10 21:56 Message: Logged In: NO I am having similar problems with the win 2.1 ver it seems none of my saved .py files are recognised. Is this simply a case of not configed as an executable or a version clash? (solutions as well as opinions would be nice) I can however import string,sys and other modules if that muddies the water any. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 12:11 Message: Logged In: YES user_id=6380 OK, ping-pong. Ping, do you have any bright ideas? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-04-10 10:57 Message: Logged In: YES user_id=11375 The pydoc script is Ping's, really. Fixing this requires Distutils hackery, and I don't see that this is worth fixing. Leaving it to someone else to make the decision to close it, though. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-17 22:23 Message: Logged In: YES user_id=31435 Assigned to Andrew because I seem to recall he wrote the pydoc script. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409430&group_id=5470 From noreply@sourceforge.net Mon Dec 10 16:16:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 08:16:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-410878 ] Distutils should have a Setup parser Message-ID: Bugs item #410878, was opened at 2001-03-23 09:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410878&group_id=5470 Category: Distutils Group: Feature Request Status: Open Resolution: None >Priority: 1 Submitted By: A.M. Kuchling (akuchling) Assigned to: A.M. Kuchling (akuchling) Summary: Distutils should have a Setup parser Initial Comment: Setup files are handy for allowing user overrides. I do a minimal parse in Python 2.1's setup.py, and Pete Shinners wrote a more complete one for pygame's config.py. Support for parsing Setup files should be added to the Distutils API, so packagers can easily make overrides for C extension compile flags. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-12-10 08:16 Message: Logged In: YES user_id=11375 Because I thought priority 9 was lowest priority, not highest, of course! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:53 Message: Logged In: YES user_id=6380 Andrew, what's the point of setting the priority to 9 if it won't get done before 2.2? We can't release with outstanding bugs of priority 7 or higher, but we're just going to lower the priority of this item... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410878&group_id=5470 From noreply@sourceforge.net Mon Dec 10 16:16:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 08:16:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-409430 ] pydoc install broken Message-ID: Bugs item #409430, was opened at 2001-03-17 10:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409430&group_id=5470 Category: Installation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: pydoc install broken Initial Comment: I've moaned about this on python-dev but I want to make sure it doesn't get forgotten. I've just built from CVS, installed in /usr/local, and: $ pydoc -g Traceback (most recent call last): File "/usr/local/bin/pydoc", line 3, in ? import pydoc ImportError: No module named pydoc because the /usr/bin/env python thing hits the older python in /usr first. Don't really know how best to implement this, not being a distutils whiz. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-10 08:16 Message: Logged In: YES user_id=6656 Done, Lib/distutils/command/build_scripts.py 1.13. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 08:09 Message: Logged In: YES user_id=6380 Michael, this patch works for me (after fixing the typo). So consider it accepted, and please check it in! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:54 Message: Logged In: YES user_id=6656 Please consider the obvious typo to be fixed; I've lost the "!" in the "#!", doh. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 05:48 Message: Logged In: YES user_id=6380 Fred, can you have a quick look at this and bounce it back to MWH with a yea or nay? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:08 Message: Logged In: YES user_id=6656 I finally got off my fat butt and had a go at fixing this. I've no idea who to assign this to to get it reviewed, I'm afraid. Someone have a look please! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-11 07:40 Message: Logged In: YES user_id=6656 Oops, not paying attention. Revision 1.9 of Lib/distutils/command/build_scripts.py seemed to be aimed at fixing this; however, I now have a ~/bin/pydoc that starts: #!python which isn't too helpful. This command either needs to do something different when building Python, or a different command needs to be used to install the pydoc script. Or you could wedge the install path into sys.executable in setup.py, I suppose. Assigned to Greg, as I don't think he's had this patch yet. Also bumped priority, as we now seem to be installing decidely broken scripts, and changed summary. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-10 21:56 Message: Logged In: NO I am having similar problems with the win 2.1 ver it seems none of my saved .py files are recognised. Is this simply a case of not configed as an executable or a version clash? (solutions as well as opinions would be nice) I can however import string,sys and other modules if that muddies the water any. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 12:11 Message: Logged In: YES user_id=6380 OK, ping-pong. Ping, do you have any bright ideas? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-04-10 10:57 Message: Logged In: YES user_id=11375 The pydoc script is Ping's, really. Fixing this requires Distutils hackery, and I don't see that this is worth fixing. Leaving it to someone else to make the decision to close it, though. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-17 22:23 Message: Logged In: YES user_id=31435 Assigned to Andrew because I seem to recall he wrote the pydoc script. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409430&group_id=5470 From noreply@sourceforge.net Mon Dec 10 16:20:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 08:20:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-409430 ] pydoc install broken Message-ID: Bugs item #409430, was opened at 2001-03-17 10:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409430&group_id=5470 Category: Installation Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: pydoc install broken Initial Comment: I've moaned about this on python-dev but I want to make sure it doesn't get forgotten. I've just built from CVS, installed in /usr/local, and: $ pydoc -g Traceback (most recent call last): File "/usr/local/bin/pydoc", line 3, in ? import pydoc ImportError: No module named pydoc because the /usr/bin/env python thing hits the older python in /usr first. Don't really know how best to implement this, not being a distutils whiz. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 08:20 Message: Logged In: YES user_id=6380 Thanks, Michael! Looks like you're *becoming* a distutils whiz... :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 08:16 Message: Logged In: YES user_id=6656 Done, Lib/distutils/command/build_scripts.py 1.13. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 08:09 Message: Logged In: YES user_id=6380 Michael, this patch works for me (after fixing the typo). So consider it accepted, and please check it in! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:54 Message: Logged In: YES user_id=6656 Please consider the obvious typo to be fixed; I've lost the "!" in the "#!", doh. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 05:48 Message: Logged In: YES user_id=6380 Fred, can you have a quick look at this and bounce it back to MWH with a yea or nay? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:08 Message: Logged In: YES user_id=6656 I finally got off my fat butt and had a go at fixing this. I've no idea who to assign this to to get it reviewed, I'm afraid. Someone have a look please! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-11 07:40 Message: Logged In: YES user_id=6656 Oops, not paying attention. Revision 1.9 of Lib/distutils/command/build_scripts.py seemed to be aimed at fixing this; however, I now have a ~/bin/pydoc that starts: #!python which isn't too helpful. This command either needs to do something different when building Python, or a different command needs to be used to install the pydoc script. Or you could wedge the install path into sys.executable in setup.py, I suppose. Assigned to Greg, as I don't think he's had this patch yet. Also bumped priority, as we now seem to be installing decidely broken scripts, and changed summary. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-10 21:56 Message: Logged In: NO I am having similar problems with the win 2.1 ver it seems none of my saved .py files are recognised. Is this simply a case of not configed as an executable or a version clash? (solutions as well as opinions would be nice) I can however import string,sys and other modules if that muddies the water any. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 12:11 Message: Logged In: YES user_id=6380 OK, ping-pong. Ping, do you have any bright ideas? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-04-10 10:57 Message: Logged In: YES user_id=11375 The pydoc script is Ping's, really. Fixing this requires Distutils hackery, and I don't see that this is worth fixing. Leaving it to someone else to make the decision to close it, though. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-17 22:23 Message: Logged In: YES user_id=31435 Assigned to Andrew because I seem to recall he wrote the pydoc script. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409430&group_id=5470 From noreply@sourceforge.net Mon Dec 10 16:21:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 08:21:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-410878 ] Distutils should have a Setup parser Message-ID: Bugs item #410878, was opened at 2001-03-23 09:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410878&group_id=5470 Category: Distutils Group: Feature Request Status: Open Resolution: None Priority: 1 Submitted By: A.M. Kuchling (akuchling) Assigned to: A.M. Kuchling (akuchling) Summary: Distutils should have a Setup parser Initial Comment: Setup files are handy for allowing user overrides. I do a minimal parse in Python 2.1's setup.py, and Pete Shinners wrote a more complete one for pygame's config.py. Support for parsing Setup files should be added to the Distutils API, so packagers can easily make overrides for C extension compile flags. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 08:21 Message: Logged In: YES user_id=6380 ROTFL. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-12-10 08:16 Message: Logged In: YES user_id=11375 Because I thought priority 9 was lowest priority, not highest, of course! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:53 Message: Logged In: YES user_id=6380 Andrew, what's the point of setting the priority to 9 if it won't get done before 2.2? We can't release with outstanding bugs of priority 7 or higher, but we're just going to lower the priority of this item... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410878&group_id=5470 From noreply@sourceforge.net Mon Dec 10 16:27:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 08:27:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-409430 ] pydoc install broken Message-ID: Bugs item #409430, was opened at 2001-03-17 10:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409430&group_id=5470 Category: Installation Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: pydoc install broken Initial Comment: I've moaned about this on python-dev but I want to make sure it doesn't get forgotten. I've just built from CVS, installed in /usr/local, and: $ pydoc -g Traceback (most recent call last): File "/usr/local/bin/pydoc", line 3, in ? import pydoc ImportError: No module named pydoc because the /usr/bin/env python thing hits the older python in /usr first. Don't really know how best to implement this, not being a distutils whiz. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-10 08:27 Message: Logged In: YES user_id=6656 I was afraid of that . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 08:20 Message: Logged In: YES user_id=6380 Thanks, Michael! Looks like you're *becoming* a distutils whiz... :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 08:16 Message: Logged In: YES user_id=6656 Done, Lib/distutils/command/build_scripts.py 1.13. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 08:09 Message: Logged In: YES user_id=6380 Michael, this patch works for me (after fixing the typo). So consider it accepted, and please check it in! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:54 Message: Logged In: YES user_id=6656 Please consider the obvious typo to be fixed; I've lost the "!" in the "#!", doh. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 05:48 Message: Logged In: YES user_id=6380 Fred, can you have a quick look at this and bounce it back to MWH with a yea or nay? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:08 Message: Logged In: YES user_id=6656 I finally got off my fat butt and had a go at fixing this. I've no idea who to assign this to to get it reviewed, I'm afraid. Someone have a look please! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-11 07:40 Message: Logged In: YES user_id=6656 Oops, not paying attention. Revision 1.9 of Lib/distutils/command/build_scripts.py seemed to be aimed at fixing this; however, I now have a ~/bin/pydoc that starts: #!python which isn't too helpful. This command either needs to do something different when building Python, or a different command needs to be used to install the pydoc script. Or you could wedge the install path into sys.executable in setup.py, I suppose. Assigned to Greg, as I don't think he's had this patch yet. Also bumped priority, as we now seem to be installing decidely broken scripts, and changed summary. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-10 21:56 Message: Logged In: NO I am having similar problems with the win 2.1 ver it seems none of my saved .py files are recognised. Is this simply a case of not configed as an executable or a version clash? (solutions as well as opinions would be nice) I can however import string,sys and other modules if that muddies the water any. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 12:11 Message: Logged In: YES user_id=6380 OK, ping-pong. Ping, do you have any bright ideas? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-04-10 10:57 Message: Logged In: YES user_id=11375 The pydoc script is Ping's, really. Fixing this requires Distutils hackery, and I don't see that this is worth fixing. Leaving it to someone else to make the decision to close it, though. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-17 22:23 Message: Logged In: YES user_id=31435 Assigned to Andrew because I seem to recall he wrote the pydoc script. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409430&group_id=5470 From noreply@sourceforge.net Mon Dec 10 16:34:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 08:34:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-491183 ] ScrolledText.grid() doesn't work Message-ID: Bugs item #491183, was opened at 2001-12-10 08:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491183&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) Summary: ScrolledText.grid() doesn't work Initial Comment: Using grid methods on ScrolledText widgets does not work as expected. It either fails to pack a widget, or can even cause Tk to lock up. The problem is that the .grid method is being called on the text widget, not the frame widget. This can lead to the well-known lockup in Tk when a frame's children are managed by both the pack and grid managers. Even if it doesn't lock up, the frame is never placed within the intended widget. Program fragment: >>> import ScrolledText >>> s = ScrolledText.ScrolledText() >>> s.grid(row=0, column=0, rowspan=2) The following patch uses the same hack to copy the 'grid' and 'place' geometry manager methods to the ScrolledText instance as is already used for the 'pack' manager. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491183&group_id=5470 From noreply@sourceforge.net Mon Dec 10 16:43:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 08:43:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-491183 ] ScrolledText.grid() doesn't work Message-ID: Bugs item #491183, was opened at 2001-12-10 08:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491183&group_id=5470 Category: Tkinter Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jeff Epler (jepler) >Assigned to: Guido van Rossum (gvanrossum) Summary: ScrolledText.grid() doesn't work Initial Comment: Using grid methods on ScrolledText widgets does not work as expected. It either fails to pack a widget, or can even cause Tk to lock up. The problem is that the .grid method is being called on the text widget, not the frame widget. This can lead to the well-known lockup in Tk when a frame's children are managed by both the pack and grid managers. Even if it doesn't lock up, the frame is never placed within the intended widget. Program fragment: >>> import ScrolledText >>> s = ScrolledText.ScrolledText() >>> s.grid(row=0, column=0, rowspan=2) The following patch uses the same hack to copy the 'grid' and 'place' geometry manager methods to the ScrolledText instance as is already used for the 'pack' manager. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 08:43 Message: Logged In: YES user_id=6380 Thanks! I see no harm in applying this, so done -- ScrolledText 1.11 it is. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491183&group_id=5470 From noreply@sourceforge.net Mon Dec 10 16:43:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 08:43:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-490823 ] str.decode() missing. Message-ID: Bugs item #490823, was opened at 2001-12-09 05:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490823&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Finn Bock (bckfnn) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: str.decode() missing. Initial Comment: The 2.2 .decode() method isn't listed among the string methods in section 2.2.6.1. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-10 08:43 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/libstdtypes.tex revision 1.80. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490823&group_id=5470 From noreply@sourceforge.net Mon Dec 10 16:58:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 08:58:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-479568 ] xxsubtype builtin Message-ID: Bugs item #479568, was opened at 2001-11-08 05:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479568&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Tim Peters (tim_one) Summary: xxsubtype builtin Initial Comment: Python 2.2b1+ (#1, Nov 6 2001, 21:52:55) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-i386 Type "help", "copyright", "credits" or "license" for more information. >>> import sys sys.builtin_module_names ('__builtin__', '__main__', '_sre', '_symtable', 'exceptions', 'gc', 'imp', 'marshal', 'new', 'posix', 'signal', 'sys', 'thread', 'xxsubtype') >>> Should xxsubtype be a builtin module? The line mentioning it in Setup.dist is uncommented by default. Maybe it's there just for testing purposes? Thanks! ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-10 08:58 Message: Logged In: YES user_id=31435 The bloat is insignificant, and the module must be present for the test suite to complete. Someone who never intends to run the test suite can leave it out. I notice the module doesn't have a docstring, though, making it too hard to discover why it's there -- so my solution will be to increase the bloat by adding a docstring. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-12-10 03:17 Message: Logged In: YES user_id=7887 I wasn't concerned about the namespace polution. I was really concerned about needless bloatness being included in the interpreter. I don't see any problems with shipping that in a beta version. I just hope this gets removed in the final release. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-09 21:01 Message: Logged In: YES user_id=31435 I agree, and closed as WontFix. Reassigned to me so you don't get yelled at needlessly . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-09 20:13 Message: Logged In: YES user_id=6380 I'd like to close this with a "won't fix". I don't see what's wrong with having this show up; renaming it seems not worth the effort. It's not like we're stepping on an important piece of the user's namespace. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-09 20:09 Message: Logged In: YES user_id=31435 Guido, we should "do something about this" before 2.2c1. Perhaps rename to __xxsubtype__? It's still valuable for test_descr.py to exercise it. Or perhaps it should be included in _testcapimodule? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479568&group_id=5470 From noreply@sourceforge.net Mon Dec 10 17:02:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 09:02:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-489709 ] Building Fails under Cygwin Message-ID: Bugs item #489709, was opened at 2001-12-05 20:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489709&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Michael Hudson (mwh) Summary: Building Fails under Cygwin Initial Comment: Even after applying the h2py patch, building under Cygwin ends with the following error: building 'gdbm' extension gcc -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT - I. -I/cygdrive/e/Python-2.2b2/./Include - I/usr/local/include -IInclude/ -c /cygdrive/e/Python- 2.2b2/Modules/gdbmmodule.c -o build/temp.cygwin-1.3. 5-i686-2.2/gdbmmodule.o e:\buildpy\python.exe: *** unable to remap C:\cygnus\bin\cygssl.dll to same address as parent -- 0x1A7C0000 0 [main] python 1292 sync_with_child: child 1108 (0xF0) died before initialization with status code 0x1 25901 [main] python 1292 sync_with_child: *** child state child loading dlls error: Resource temporarily unavailable make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-10 09:02 Message: Logged In: YES user_id=6656 FWIW, it seems building _socket statically solves the problem. This may suffice to for 2.2. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 05:13 Message: Logged In: YES user_id=6656 (sf keeps logging me out every ten minutes, grr) This is being hashed out on the cygwin list. It's unfortunately not obvious that it will be fixed in the 2.2 timeframe. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-06 07:16 Message: Logged In: YES user_id=6656 Hmm. Seems pretty similar to mine. I'll bug Jason Tishler and see if he knows anything about it. ---------------------------------------------------------------------- Comment By: David Abrahams (david_abrahams) Date: 2001-12-06 07:12 Message: Logged In: YES user_id=52572 I'm using Win2K CYGWIN_NT-5.0 MOREPIE 1.3.5(0.47/3/2) 2001-11-13 23:16 i686 unknown And I've built and installed GCC 3.0.2, thought the Python build seems to use 2.95.x anyway. I am not on the cygwin mailing list, sorry ;-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-06 05:53 Message: Logged In: YES user_id=6656 Just to say that I'm seeing this too. What OS? I'm on NT4 SP6. Which cygwin? I'm [Administrator@MATHS-PC150 QUAKE]$ uname -a CYGWIN_NT-4.0 MATHS-PC150 1.3.6(0.47/3/2) 2001-12-03 15:41 i686 unknown I was actually assuming this was a cygwin bug. Are you on the cygwin mailing list? Maybe you could try raising it there? I would, but I *really* don't need another subscription to a high-volume mailing list right now. PS: can we add jason as a developer? then we can assign bugs to him . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489709&group_id=5470 From noreply@sourceforge.net Mon Dec 10 17:15:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 09:15:41 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-491033 ] asyncore - api doesn't provide doneevent Message-ID: Feature Requests item #491033, was opened at 2001-12-09 22:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=491033&group_id=5470 >Category: None >Group: None Status: Open Priority: 5 Submitted By: Joseph Wayne Norton (natsukashi) Assigned to: Nobody/Anonymous (nobody) Summary: asyncore - api doesn't provide doneevent Initial Comment: The asyncore api doesn't provide a way to invoke the "loop" method but to only perform one iteration. Since the loop method does some selection of which poll method to call before entering the while loop, I have to duplicate the same behavior in my own "dooneiteration" method. I would like some functionality similar to the Tk interp model where one can enter the mainloop or simply do one event. regards, - joe n. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-10 09:15 Message: Logged In: YES user_id=31435 Moved to the Feature Request tracker. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 06:47 Message: Logged In: YES user_id=6380 If you can supply a decent patch, we'd happily apply it to Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=491033&group_id=5470 From noreply@sourceforge.net Mon Dec 10 17:19:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 09:19:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-434944 ] setup.py - nonstandard paths Message-ID: Bugs item #434944, was opened at 2001-06-20 15:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434944&group_id=5470 Category: Build Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Robert Minsk (rminsk) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py - nonstandard paths Initial Comment: In my build environment I have to ensure that the same version of each software package is available across many different platforms. To do this I compile code into a directory structure when the root path of /usr/tools/fw. So a tools like flex would result in files /usr/tools/fw/bin/flex, /usr/tools/fw/include/FlexLexer.h, /usr/tools/fw/lib/libfl.a, ... In the Python 2.1 build environment it does not seem that you can pass extra search paths too setup.py. I must either hack setup.py to look in /usr/tools/fw or manually add each module to Modules/Setup. It would be nice for setup.py to be able to take extra search paths. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-10 09:19 Message: Logged In: YES user_id=6656 Don't the -I & -L options to setup.py handle this? As in: ./python $(srcdir)/setup.py -I/usr/tools/fw/include \ -L/usr/tools/fw/lib ? I can't see how to arrange things to do this just by typing "make" -- is that what you're complaining about? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434944&group_id=5470 From noreply@sourceforge.net Mon Dec 10 17:41:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 09:41:02 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-491033 ] asyncore - api doesn't provide doneevent Message-ID: Feature Requests item #491033, was opened at 2001-12-09 22:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=491033&group_id=5470 >Category: Python Library Group: None Status: Open Priority: 5 Submitted By: Joseph Wayne Norton (natsukashi) Assigned to: Nobody/Anonymous (nobody) Summary: asyncore - api doesn't provide doneevent Initial Comment: The asyncore api doesn't provide a way to invoke the "loop" method but to only perform one iteration. Since the loop method does some selection of which poll method to call before entering the while loop, I have to duplicate the same behavior in my own "dooneiteration" method. I would like some functionality similar to the Tk interp model where one can enter the mainloop or simply do one event. regards, - joe n. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-10 09:41 Message: Logged In: YES user_id=31435 The Feature Requests tracker didn't have any Categories defined. I defined the same ones as the Bug tracker has, and purt this report in category "Python Library". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-10 09:15 Message: Logged In: YES user_id=31435 Moved to the Feature Request tracker. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 06:47 Message: Logged In: YES user_id=6380 If you can supply a decent patch, we'd happily apply it to Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=491033&group_id=5470 From noreply@sourceforge.net Mon Dec 10 17:46:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 09:46:29 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-229840 ] IDLE needs to print ! Message-ID: Feature Requests item #229840, was opened at 2001-01-23 10:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=229840&group_id=5470 >Category: IDLE Group: None Status: Open Priority: 1 Submitted By: Charles Doutriaux (cdoutri) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE needs to print ! Initial Comment: It'd be really nice if idle had a print function, all these nice colors got to be printed ! or at least a postscript output would be nice. Thanks, C. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-10 09:46 Message: Logged In: YES user_id=31435 Changed Category to IDLE. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-23 18:40 Message: The kind folks from reportlab.com once contributed a printing function. it was kind of slow though. But maybe it should still be added. I think I have it somewhere still. The problem is the licensing (it's not relesed under the same license as Python itself). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=229840&group_id=5470 From noreply@sourceforge.net Mon Dec 10 17:47:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 09:47:20 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-404444 ] [IDLE] auto indent/parentheses Message-ID: Feature Requests item #404444, was opened at 2001-02-26 15:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=404444&group_id=5470 >Category: IDLE Group: None Status: Open Priority: 5 Submitted By: Charles Doutriaux (cdoutri) Assigned to: Nobody/Anonymous (nobody) Summary: [IDLE] auto indent/parentheses Initial Comment: It'd be really nice to have an automatic indent of a line when using the "TAB" key anywhere on the line, this feature exist in the python emacs mode and is REALLY nice and a total time-saver. Also, having the possibility to see which parentheses/brackets you're closing while typing (as in a lot of editors) would be really nice ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-10 09:47 Message: Logged In: YES user_id=31435 Chagned Category to IDLE. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-18 11:32 Message: Logged In: YES user_id=31435 Hmm. SF threw us another curve ball here: the new "Data Type" value "Feature Requests" has only "None" as a possible value for "Assigned To". The intro text in PEP 42 doesn't know about this either ... ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-03-18 08:32 Message: Logged In: YES user_id=12800 Thomas explained it nicely in a followup to the PEP 42 checkin. Included here for completeness. "The TAB comment is pretty easy to explain: the user wants IDLE to re-indent the *current* line whenever he presses TAB, regardless of where his cursor is at that moment." Indeed, this is how python-mode (and most language editing modes) in Emacs works. You typically have to type ^Q TAB to get a real tab character inserted. Assigning to Guido since he's the most enthusiastic IDLE hacker, but moving it to Feature Requests and re-opening. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-17 11:55 Message: Logged In: YES user_id=31435 Added to PEP 42 and marked Later/Closed. Assigned to Barry in the hopes that he can clarify the TAB business (I don't understand what this is asking for -- doesn't a TAB key act like a TAB key in Emacs? maybe I always rebound it in my Emacs days). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=404444&group_id=5470 From noreply@sourceforge.net Mon Dec 10 18:38:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 10:38:48 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-433029 ] SRE: posix classes aren't supported Message-ID: Feature Requests item #433029, was opened at 2001-06-14 01:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433029&group_id=5470 >Category: None >Group: None Status: Open Priority: 3 Submitted By: Fredrik Lundh (effbot) >Assigned to: Nobody/Anonymous (nobody) Summary: SRE: posix classes aren't supported Initial Comment: from the jeffrey friedl report: Posix class stuff aren't supported. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433029&group_id=5470 From noreply@sourceforge.net Mon Dec 10 18:39:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 10:39:29 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-433029 ] SRE: posix classes aren't supported Message-ID: Feature Requests item #433029, was opened at 2001-06-14 01:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433029&group_id=5470 >Category: Regular Expressions Group: None Status: Open Priority: 3 Submitted By: Fredrik Lundh (effbot) >Assigned to: Fredrik Lundh (effbot) Summary: SRE: posix classes aren't supported Initial Comment: from the jeffrey friedl report: Posix class stuff aren't supported. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433029&group_id=5470 From noreply@sourceforge.net Mon Dec 10 18:39:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 10:39:48 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-433028 ] SRE: (?flag:...) is not supported Message-ID: Feature Requests item #433028, was opened at 2001-06-14 01:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433028&group_id=5470 >Category: None >Group: None Status: Open Priority: 3 Submitted By: Fredrik Lundh (effbot) >Assigned to: Nobody/Anonymous (nobody) Summary: SRE: (?flag:...) is not supported Initial Comment: from the jeffrey friedl report: (?flag:...) and (?-flag:...) are not supported. They'd be nice. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433028&group_id=5470 From noreply@sourceforge.net Mon Dec 10 18:40:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 10:40:26 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-433028 ] SRE: (?flag:...) is not supported Message-ID: Feature Requests item #433028, was opened at 2001-06-14 01:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433028&group_id=5470 >Category: Regular Expressions Group: None Status: Open Priority: 3 Submitted By: Fredrik Lundh (effbot) >Assigned to: Fredrik Lundh (effbot) Summary: SRE: (?flag:...) is not supported Initial Comment: from the jeffrey friedl report: (?flag:...) and (?-flag:...) are not supported. They'd be nice. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433028&group_id=5470 From noreply@sourceforge.net Mon Dec 10 18:41:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 10:41:06 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-433031 ] SRE: x++ isn't supported Message-ID: Feature Requests item #433031, was opened at 2001-06-14 01:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433031&group_id=5470 >Category: None >Group: None Status: Open Priority: 3 Submitted By: Fredrik Lundh (effbot) >Assigned to: Nobody/Anonymous (nobody) Summary: SRE: x++ isn't supported Initial Comment: from jeffrey friedl: [perl has] added some interesting things that you might want to consider. In particular, posessive quantifiers X++ (which acts exactly like (?>X+), but is much easier to grok). Very nice. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433031&group_id=5470 From noreply@sourceforge.net Mon Dec 10 18:44:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 10:44:06 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-433030 ] SRE: (?>...) is not supported Message-ID: Feature Requests item #433030, was opened at 2001-06-14 01:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433030&group_id=5470 >Category: None >Group: None Status: Open Priority: 3 Submitted By: Fredrik Lundh (effbot) >Assigned to: Nobody/Anonymous (nobody) Summary: SRE: (?>...) is not supported Initial Comment: from the jeffrey friedl report: (?>...) is not supported [this is a "stand-alone pattern". the engine has code for this, but the parser doesn't recognize this yet. shouldn't be too hard to fix; I just need a couple of good test cases before I start /F] ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433030&group_id=5470 From noreply@sourceforge.net Mon Dec 10 18:44:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 10:44:44 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-433030 ] SRE: (?>...) is not supported Message-ID: Feature Requests item #433030, was opened at 2001-06-14 01:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433030&group_id=5470 >Category: Regular Expressions Group: None Status: Open Priority: 3 Submitted By: Fredrik Lundh (effbot) >Assigned to: Fredrik Lundh (effbot) Summary: SRE: (?>...) is not supported Initial Comment: from the jeffrey friedl report: (?>...) is not supported [this is a "stand-alone pattern". the engine has code for this, but the parser doesn't recognize this yet. shouldn't be too hard to fix; I just need a couple of good test cases before I start /F] ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433030&group_id=5470 From noreply@sourceforge.net Mon Dec 10 18:45:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 10:45:05 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-433024 ] SRE: (?flag) isn't properly scoped Message-ID: Feature Requests item #433024, was opened at 2001-06-14 01:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433024&group_id=5470 >Category: None >Group: None Status: Open Priority: 3 Submitted By: Fredrik Lundh (effbot) >Assigned to: Nobody/Anonymous (nobody) Summary: SRE: (?flag) isn't properly scoped Initial Comment: from the jeffrey friedl report: The way (?i) works now is that if it appears anywhere in the regex, it turns on case-insensative matching for the entire regex. This is different (and less useful) than how Perl or Sun's Java package does it [I'm pretty sure SRE does it this way to exactly match the version of PCRE used in 1.5.2, but maybe it's time to move forward... /F] ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433024&group_id=5470 From noreply@sourceforge.net Mon Dec 10 18:45:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 10:45:22 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-433027 ] SRE: (?-flag) is not supported. Message-ID: Feature Requests item #433027, was opened at 2001-06-14 01:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433027&group_id=5470 >Category: None >Group: None Status: Open Priority: 3 Submitted By: Fredrik Lundh (effbot) >Assigned to: Nobody/Anonymous (nobody) Summary: SRE: (?-flag) is not supported. Initial Comment: from the jeffrey friedl report: (?-i) is not supported. It'd be nice to have ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433027&group_id=5470 From noreply@sourceforge.net Mon Dec 10 18:45:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 10:45:48 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-433031 ] SRE: x++ isn't supported Message-ID: Feature Requests item #433031, was opened at 2001-06-14 01:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433031&group_id=5470 >Category: Regular Expressions Group: None Status: Open Priority: 3 Submitted By: Fredrik Lundh (effbot) >Assigned to: Fredrik Lundh (effbot) Summary: SRE: x++ isn't supported Initial Comment: from jeffrey friedl: [perl has] added some interesting things that you might want to consider. In particular, posessive quantifiers X++ (which acts exactly like (?>X+), but is much easier to grok). Very nice. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433031&group_id=5470 From noreply@sourceforge.net Mon Dec 10 18:46:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 10:46:13 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-433024 ] SRE: (?flag) isn't properly scoped Message-ID: Feature Requests item #433024, was opened at 2001-06-14 01:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433024&group_id=5470 >Category: Regular Expressions Group: None Status: Open Priority: 3 Submitted By: Fredrik Lundh (effbot) >Assigned to: Fredrik Lundh (effbot) Summary: SRE: (?flag) isn't properly scoped Initial Comment: from the jeffrey friedl report: The way (?i) works now is that if it appears anywhere in the regex, it turns on case-insensative matching for the entire regex. This is different (and less useful) than how Perl or Sun's Java package does it [I'm pretty sure SRE does it this way to exactly match the version of PCRE used in 1.5.2, but maybe it's time to move forward... /F] ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433024&group_id=5470 From noreply@sourceforge.net Mon Dec 10 18:46:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 10:46:39 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-433027 ] SRE: (?-flag) is not supported. Message-ID: Feature Requests item #433027, was opened at 2001-06-14 01:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433027&group_id=5470 >Category: Regular Expressions Group: None Status: Open Priority: 3 Submitted By: Fredrik Lundh (effbot) >Assigned to: Fredrik Lundh (effbot) Summary: SRE: (?-flag) is not supported. Initial Comment: from the jeffrey friedl report: (?-i) is not supported. It'd be nice to have ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=433027&group_id=5470 From noreply@sourceforge.net Mon Dec 10 18:47:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 10:47:34 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-416670 ] MatchObjects not deepcopy()able Message-ID: Feature Requests item #416670, was opened at 2001-04-17 05:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=416670&group_id=5470 >Category: None >Group: None Status: Open Priority: 5 Submitted By: Henning Thielemann (amigalemming) >Assigned to: Nobody/Anonymous (nobody) Summary: MatchObjects not deepcopy()able Initial Comment: In the re-Module which come with Python version 2.0 (Nov 28 11:10 re.py) the created MatchObjects cannot be copied with a deepcopy(). Switching back to the old "pre.py" as proposed in "re.py" makes everything work ok. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-04-28 01:53 Message: Logged In: YES user_id=38376 On the other hand, it looks like we've found a rather elegant way to solve this. I'll leave this one open (as a feature request). ---------------------------------------------------------------------- Comment By: Henning Thielemann (amigalemming) Date: 2001-04-27 03:03 Message: Logged In: YES user_id=197994 You are right, m.groupdict() and m.groups() are surely the better choice. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-04-26 14:50 Message: Logged In: YES user_id=38376 I'm not sure this is a bug -- imo, you're relying on an implementation artifact in the original PCRE port. And making this work under SRE isn't as easy as it may appear (the proposed patch may work in your specific case, but it isn't a general solution). But before I make up my mind here, maybe you could tell me why you think it's a good idea to use deepcopy on match objects. Why not just store "m.groups()" or "m.regs" instead? Cheers /F ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-26 01:01 Message: Logged In: YES user_id=21627 A patch for that problem is in http://sourceforge.net/tracker/index.php?func=detail&aid=419070&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=416670&group_id=5470 From noreply@sourceforge.net Mon Dec 10 18:50:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 10:50:32 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-416670 ] MatchObjects not deepcopy()able Message-ID: Feature Requests item #416670, was opened at 2001-04-17 05:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=416670&group_id=5470 >Category: Regular Expressions Group: None Status: Open >Priority: 3 Submitted By: Henning Thielemann (amigalemming) >Assigned to: Fredrik Lundh (effbot) Summary: MatchObjects not deepcopy()able Initial Comment: In the re-Module which come with Python version 2.0 (Nov 28 11:10 re.py) the created MatchObjects cannot be copied with a deepcopy(). Switching back to the old "pre.py" as proposed in "re.py" makes everything work ok. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-04-28 01:53 Message: Logged In: YES user_id=38376 On the other hand, it looks like we've found a rather elegant way to solve this. I'll leave this one open (as a feature request). ---------------------------------------------------------------------- Comment By: Henning Thielemann (amigalemming) Date: 2001-04-27 03:03 Message: Logged In: YES user_id=197994 You are right, m.groupdict() and m.groups() are surely the better choice. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-04-26 14:50 Message: Logged In: YES user_id=38376 I'm not sure this is a bug -- imo, you're relying on an implementation artifact in the original PCRE port. And making this work under SRE isn't as easy as it may appear (the proposed patch may work in your specific case, but it isn't a general solution). But before I make up my mind here, maybe you could tell me why you think it's a good idea to use deepcopy on match objects. Why not just store "m.groups()" or "m.regs" instead? Cheers /F ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-26 01:01 Message: Logged In: YES user_id=21627 A patch for that problem is in http://sourceforge.net/tracker/index.php?func=detail&aid=419070&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=416670&group_id=5470 From noreply@sourceforge.net Mon Dec 10 18:51:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 10:51:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-491246 ] problem with imports in an if-statement Message-ID: Bugs item #491246, was opened at 2001-12-10 10:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491246&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: kevin davidson (ked) Assigned to: Nobody/Anonymous (nobody) Summary: problem with imports in an if-statement Initial Comment: I'm not sure if this has been submitted already or not. I searched for it, but I don't have the time needed to check all the results. The problem is with importing modules inside of an if statement. The attached file should be self explanatory. I might add that this only seems to be a problem when the code is inside a function. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491246&group_id=5470 From noreply@sourceforge.net Mon Dec 10 19:24:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 11:24:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-491246 ] problem with imports in an if-statement Message-ID: Bugs item #491246, was opened at 2001-12-10 10:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491246&group_id=5470 Category: None >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: kevin davidson (ked) >Assigned to: Tim Peters (tim_one) Summary: problem with imports in an if-statement Initial Comment: I'm not sure if this has been submitted already or not. I searched for it, but I don't have the time needed to check all the results. The problem is with importing modules inside of an if statement. The attached file should be self explanatory. I might add that this only seems to be a problem when the code is inside a function. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-10 11:24 Message: Logged In: YES user_id=31435 Not a bug: an import is a binding statement, and the appearance of "import x" *anywhere* in a scope makes the name "x" a local vrbl throughout the entire scope. So this is the same as x = 4 def bug(): . if 1: . y = x . else: . x = 100 . y = x In the "if 1:" branch, the local name "x" is referenced before it's been assigned a value (the global name "x" is a a different beast). Exactly the same thing accounts for way you get an UnboundLocalError on the name "string". Putting your imports at the tops of your functions-- or at module level --is an easy way to avoid this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491246&group_id=5470 From noreply@sourceforge.net Mon Dec 10 19:56:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 11:56:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-490453 ] OpenUNIX 8: No Compile/Run Message-ID: Bugs item #490453, was opened at 2001-12-07 15:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Larry Rosenman (ler) Assigned to: Nobody/Anonymous (nobody) Summary: OpenUNIX 8: No Compile/Run Initial Comment: On OpenUNIX 8, nothing seems to compile. Y''ou seem to use ld instead of cc for building the shared objects, which is wrong. Also, there seems to be other issues with symbol referencing errors. I've given accounts on my box before, and I'm willing to do that again. I believe there are serious issues with this build. (2.1.1 of Python, BTW). ---------------------------------------------------------------------- >Comment By: Larry Rosenman (ler) Date: 2001-12-10 11:56 Message: Logged In: YES user_id=36452 Ok, 2.2b2 is *MUCH* better on this platform. the _socket extension doesn't compile. (EAI_MAX is not defined, and some other issues). I am not sure where this is supposed to be defined. I am *STILL* willing to allow a python developer (or developers) access to my box. LER ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-07 15:09 Message: Logged In: YES user_id=36452 OpenUNIX 8 is the follow- on from SCO UnixWare 7.1.1. It is from Caldera. I' ll try and figure it out, but... I believe loewis has the ID/PW for an account on my box (lerami.lerctr.org [207.158.72.11]), and I'll gladly make more if you folks want. Larry ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 15:06 Message: Logged In: YES user_id=6380 Thanks for the offer. I don't have time to sort this out, but maybe someone else who reads these notes does. (What *IS* OpenUNIX 8???) You can also try to resolve this yourself -- the configure script has a few case statements on the platform where it sets the various compilers and linkers (and their options) used for various actions. A patch would be most appreciated. You might also consider trying Python 2.2b2, which has somewhat improved the build procedure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 From noreply@sourceforge.net Mon Dec 10 20:04:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 12:04:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-490453 ] OpenUNIX 8: No Compile/Run Message-ID: Bugs item #490453, was opened at 2001-12-07 15:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Larry Rosenman (ler) Assigned to: Nobody/Anonymous (nobody) Summary: OpenUNIX 8: No Compile/Run Initial Comment: On OpenUNIX 8, nothing seems to compile. Y''ou seem to use ld instead of cc for building the shared objects, which is wrong. Also, there seems to be other issues with symbol referencing errors. I've given accounts on my box before, and I'm willing to do that again. I believe there are serious issues with this build. (2.1.1 of Python, BTW). ---------------------------------------------------------------------- >Comment By: Larry Rosenman (ler) Date: 2001-12-10 12:04 Message: Logged In: YES user_id=36452 Here is a make.out from a ./configure --with-cxx=CC --with-threads --disable- ipv6 ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 11:56 Message: Logged In: YES user_id=36452 Ok, 2.2b2 is *MUCH* better on this platform. the _socket extension doesn't compile. (EAI_MAX is not defined, and some other issues). I am not sure where this is supposed to be defined. I am *STILL* willing to allow a python developer (or developers) access to my box. LER ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-07 15:09 Message: Logged In: YES user_id=36452 OpenUNIX 8 is the follow- on from SCO UnixWare 7.1.1. It is from Caldera. I' ll try and figure it out, but... I believe loewis has the ID/PW for an account on my box (lerami.lerctr.org [207.158.72.11]), and I'll gladly make more if you folks want. Larry ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 15:06 Message: Logged In: YES user_id=6380 Thanks for the offer. I don't have time to sort this out, but maybe someone else who reads these notes does. (What *IS* OpenUNIX 8???) You can also try to resolve this yourself -- the configure script has a few case statements on the platform where it sets the various compilers and linkers (and their options) used for various actions. A patch would be most appreciated. You might also consider trying Python 2.2b2, which has somewhat improved the build procedure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 From noreply@sourceforge.net Mon Dec 10 20:06:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 12:06:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-490453 ] OpenUNIX 8: No Compile/Run Message-ID: Bugs item #490453, was opened at 2001-12-07 15:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Larry Rosenman (ler) Assigned to: Nobody/Anonymous (nobody) Summary: OpenUNIX 8: No Compile/Run Initial Comment: On OpenUNIX 8, nothing seems to compile. Y''ou seem to use ld instead of cc for building the shared objects, which is wrong. Also, there seems to be other issues with symbol referencing errors. I've given accounts on my box before, and I'm willing to do that again. I believe there are serious issues with this build. (2.1.1 of Python, BTW). ---------------------------------------------------------------------- >Comment By: Larry Rosenman (ler) Date: 2001-12-10 12:06 Message: Logged In: YES user_id=36452 Here is the file ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 12:04 Message: Logged In: YES user_id=36452 Here is a make.out from a ./configure --with-cxx=CC --with-threads --disable- ipv6 ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 11:56 Message: Logged In: YES user_id=36452 Ok, 2.2b2 is *MUCH* better on this platform. the _socket extension doesn't compile. (EAI_MAX is not defined, and some other issues). I am not sure where this is supposed to be defined. I am *STILL* willing to allow a python developer (or developers) access to my box. LER ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-07 15:09 Message: Logged In: YES user_id=36452 OpenUNIX 8 is the follow- on from SCO UnixWare 7.1.1. It is from Caldera. I' ll try and figure it out, but... I believe loewis has the ID/PW for an account on my box (lerami.lerctr.org [207.158.72.11]), and I'll gladly make more if you folks want. Larry ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 15:06 Message: Logged In: YES user_id=6380 Thanks for the offer. I don't have time to sort this out, but maybe someone else who reads these notes does. (What *IS* OpenUNIX 8???) You can also try to resolve this yourself -- the configure script has a few case statements on the platform where it sets the various compilers and linkers (and their options) used for various actions. A patch would be most appreciated. You might also consider trying Python 2.2b2, which has somewhat improved the build procedure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 From noreply@sourceforge.net Mon Dec 10 20:22:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 12:22:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-478534 ] SystemError with WeakKeyDictionary Message-ID: Bugs item #478534, was opened at 2001-11-05 19:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478534&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: Works For Me Priority: 5 Submitted By: Sverker Nilsson (svenil) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: SystemError with WeakKeyDictionary Initial Comment: SystemError with WeakKeyDictionary A SystemError is generated when trying to iterate over a function returned from a function that stored it in a WeakKeyDictionary. The expected error was TypeError. Sverker Nilsson Examples: This program gives a SystemError: import weakref ref = weakref.WeakKeyDictionary() def encapsulate(): f = lambda : () ref[f] = None return f for x in encapsulate(): print x Python 2.2b1 (#5, Oct 20 2001, 03:03:53) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. ... Traceback (most recent call last): File "", line 1, in ? File "/tmp/pythona04442", line 9, in ? for x in encapsulate(): SystemError: error return without exception set >>> A variation of it, with a temporary variable, gives the expected TypeError: import weakref ref = weakref.WeakKeyDictionary() def encapsulate(): f = lambda : () ref[f] = None return f g = encapsulate() for x in g: print x Traceback (most recent call last): File "", line 1, in ? File "/tmp/pythona04442", line 10, in ? for x in g: TypeError: iteration over non-sequence >>> ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-10 12:22 Message: Logged In: YES user_id=3066 This is a really vicious bug. I've simplified the test case some more, but I'm still not sure what needs to be done to fix this. I'm not sure that I can make the test case smaller; raising the exception is still required. I expect this is still a matter of an exception not being properly detected and cleared at some point. ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:55 Message: Logged In: YES user_id=356603 Seems the files didnt make it, sorry for the fuzz.. trying again. S. ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:50 Message: Logged In: YES user_id=356603 wrbug4.gdb-transcript contains a raw gdb transcript, in case it can be of some use / Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:47 Message: Logged In: YES user_id=356603 I couldnt figure out how to upload several files with the same comment. Well, this is to tell you that wrbug4.mail contains some more info. /Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:42 Message: Logged In: YES user_id=356603 I have got the cvs version now. It also gives the error or segmentation fault. Either compiled with Py_Debug enabled in configuration, or with another version of my test program. (The Py_Debug definition changes what Python does in eval_frame so the error is revealed in the original test. ) See attached files: wrbug4.py, new test program. wrbug4.mail, some info. wrbug4.gdb-transcript, a raw gdb transcript... /Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-06 11:07 Message: Logged In: YES user_id=356603 Ooops, in the example I sent you I hadnt removed the self parameter after all. I mixed up something. But when I did remove the self parameter it went as I said. Actually, I get a segmentation fault running it directly from the shell. (When running it from Emacs mode or importing it I get SystemError.) Sverker Shell transcript: nicosys [228] python defenvbug3.py first add ok Segmentation fault nicosys [229] cat defenvbug3.py import weakref ref = weakref.WeakKeyDictionary() class MyError(Exception): pass def add(x): raise MyError def encapsulate(): f = lambda : () ref[f] = None return f try: add(encapsulate()) except MyError: pass print 'first add ok' add(encapsulate()) # Here we would like to get Exception but gets SystemError instead. nicosys [230] python Python 2.2b1 (#5, Oct 20 2001, 03:03:53) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import defenvbug3.py first add ok Traceback (most recent call last): File "", line 1, in ? SystemError: NULL result without error in PyObject_Call >>> nicosys [231] whence python /usr/local/bin/python is actually /hda7/local/bin/python /usr/local/bin/python: ELF 32-bit LSB executable i386 (386 and up) Version 1 nicosys [232] ldd /hda7/local/bin/python libdl.so.2 => /lib/libdl.so.2 (0x40018000) libpthread.so.0 => /lib/libpthread.so.0 (0x4001d000) libutil.so.1 => /lib/libutil.so.1 (0x40030000) libm.so.6 => /lib/libm.so.6 (0x40033000) libc.so.6 => /lib/libc.so.6 (0x40052000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) nicosys [233] ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-06 10:47 Message: Logged In: YES user_id=356603 To answer your question, I am using 2.2b1, from the tarball not from CVS. In the second example, I get SystemError from the first call to add actually. I thought it was from the second one, but since I changed from my own exception class to Exception it became hidden. When I remove the uninteded self parameter of add, I get SystemError in the second call, as I thought I was getting. But you get TypeError.. hmmm.. I suppose I should download the CVS then?.. Or maybe wait for 2.2b2.. Sverker ps. Here's my updated second example, anyway.. import weakref ref = weakref.WeakKeyDictionary() class MyError(Exception): pass def add(self, x): raise MyError def encapsulate(): f = lambda : () ref[f] = None return f try: add(encapsulate()) except MyError: pass print 'first add ok' add(encapsulate()) # Here we would like to get Exception but gets SystemError instead. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-06 08:33 Message: Logged In: YES user_id=3066 I cannot reproduce this using either code snippet. Note that the second example should (and does for me) raise TypeError when calling add() -- you left in a "self" that appears to be unintended. Are you using 2.2b1 or CVS python? ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-05 23:17 Message: Logged In: YES user_id=356603 The same problem now occured in another situation. I am enclosing the condensed program. /Sverker ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478534&group_id=5470 From noreply@sourceforge.net Mon Dec 10 20:34:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 12:34:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-478534 ] SystemError with WeakKeyDictionary Message-ID: Bugs item #478534, was opened at 2001-11-05 19:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478534&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: Works For Me Priority: 5 Submitted By: Sverker Nilsson (svenil) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: SystemError with WeakKeyDictionary Initial Comment: SystemError with WeakKeyDictionary A SystemError is generated when trying to iterate over a function returned from a function that stored it in a WeakKeyDictionary. The expected error was TypeError. Sverker Nilsson Examples: This program gives a SystemError: import weakref ref = weakref.WeakKeyDictionary() def encapsulate(): f = lambda : () ref[f] = None return f for x in encapsulate(): print x Python 2.2b1 (#5, Oct 20 2001, 03:03:53) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. ... Traceback (most recent call last): File "", line 1, in ? File "/tmp/pythona04442", line 9, in ? for x in encapsulate(): SystemError: error return without exception set >>> A variation of it, with a temporary variable, gives the expected TypeError: import weakref ref = weakref.WeakKeyDictionary() def encapsulate(): f = lambda : () ref[f] = None return f g = encapsulate() for x in g: print x Traceback (most recent call last): File "", line 1, in ? File "/tmp/pythona04442", line 10, in ? for x in g: TypeError: iteration over non-sequence >>> ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 12:34 Message: Logged In: YES user_id=6380 Fred, do you need help looking at this? If this needs to be fixed before the release, please raise priority to 7 or higher. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-10 12:22 Message: Logged In: YES user_id=3066 This is a really vicious bug. I've simplified the test case some more, but I'm still not sure what needs to be done to fix this. I'm not sure that I can make the test case smaller; raising the exception is still required. I expect this is still a matter of an exception not being properly detected and cleared at some point. ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:55 Message: Logged In: YES user_id=356603 Seems the files didnt make it, sorry for the fuzz.. trying again. S. ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:50 Message: Logged In: YES user_id=356603 wrbug4.gdb-transcript contains a raw gdb transcript, in case it can be of some use / Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:47 Message: Logged In: YES user_id=356603 I couldnt figure out how to upload several files with the same comment. Well, this is to tell you that wrbug4.mail contains some more info. /Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:42 Message: Logged In: YES user_id=356603 I have got the cvs version now. It also gives the error or segmentation fault. Either compiled with Py_Debug enabled in configuration, or with another version of my test program. (The Py_Debug definition changes what Python does in eval_frame so the error is revealed in the original test. ) See attached files: wrbug4.py, new test program. wrbug4.mail, some info. wrbug4.gdb-transcript, a raw gdb transcript... /Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-06 11:07 Message: Logged In: YES user_id=356603 Ooops, in the example I sent you I hadnt removed the self parameter after all. I mixed up something. But when I did remove the self parameter it went as I said. Actually, I get a segmentation fault running it directly from the shell. (When running it from Emacs mode or importing it I get SystemError.) Sverker Shell transcript: nicosys [228] python defenvbug3.py first add ok Segmentation fault nicosys [229] cat defenvbug3.py import weakref ref = weakref.WeakKeyDictionary() class MyError(Exception): pass def add(x): raise MyError def encapsulate(): f = lambda : () ref[f] = None return f try: add(encapsulate()) except MyError: pass print 'first add ok' add(encapsulate()) # Here we would like to get Exception but gets SystemError instead. nicosys [230] python Python 2.2b1 (#5, Oct 20 2001, 03:03:53) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import defenvbug3.py first add ok Traceback (most recent call last): File "", line 1, in ? SystemError: NULL result without error in PyObject_Call >>> nicosys [231] whence python /usr/local/bin/python is actually /hda7/local/bin/python /usr/local/bin/python: ELF 32-bit LSB executable i386 (386 and up) Version 1 nicosys [232] ldd /hda7/local/bin/python libdl.so.2 => /lib/libdl.so.2 (0x40018000) libpthread.so.0 => /lib/libpthread.so.0 (0x4001d000) libutil.so.1 => /lib/libutil.so.1 (0x40030000) libm.so.6 => /lib/libm.so.6 (0x40033000) libc.so.6 => /lib/libc.so.6 (0x40052000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) nicosys [233] ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-06 10:47 Message: Logged In: YES user_id=356603 To answer your question, I am using 2.2b1, from the tarball not from CVS. In the second example, I get SystemError from the first call to add actually. I thought it was from the second one, but since I changed from my own exception class to Exception it became hidden. When I remove the uninteded self parameter of add, I get SystemError in the second call, as I thought I was getting. But you get TypeError.. hmmm.. I suppose I should download the CVS then?.. Or maybe wait for 2.2b2.. Sverker ps. Here's my updated second example, anyway.. import weakref ref = weakref.WeakKeyDictionary() class MyError(Exception): pass def add(self, x): raise MyError def encapsulate(): f = lambda : () ref[f] = None return f try: add(encapsulate()) except MyError: pass print 'first add ok' add(encapsulate()) # Here we would like to get Exception but gets SystemError instead. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-06 08:33 Message: Logged In: YES user_id=3066 I cannot reproduce this using either code snippet. Note that the second example should (and does for me) raise TypeError when calling add() -- you left in a "self" that appears to be unintended. Are you using 2.2b1 or CVS python? ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-05 23:17 Message: Logged In: YES user_id=356603 The same problem now occured in another situation. I am enclosing the condensed program. /Sverker ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478534&group_id=5470 From noreply@sourceforge.net Mon Dec 10 20:48:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 12:48:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-491301 ] a bad tuple comparison Message-ID: Bugs item #491301, was opened at 2001-12-10 12:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491301&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Ortmann (dortmann) Assigned to: Nobody/Anonymous (nobody) Summary: a bad tuple comparison Initial Comment: A slice of sys.version_info does not compare as a tuple. #!/usr/local/bin/python import sys a = (2,2) b = (sys.version_info[0:1]) c = (sys.version_info[0], sys.version_info[1]) assert a == b, "kaBOOM! assertion failed: a == b" assert a == c, "kaBOOM! assertion failed: a == c" print "everything is okey dokey! :-)" Comment out the first assert and everything works fine. (I am new to python, but this seems to be an error; it was, at the very least, unexpected and counter intuitive.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491301&group_id=5470 From noreply@sourceforge.net Mon Dec 10 21:21:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 13:21:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-491301 ] a bad tuple comparison Message-ID: Bugs item #491301, was opened at 2001-12-10 12:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491301&group_id=5470 Category: None >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Daniel Ortmann (dortmann) Assigned to: Nobody/Anonymous (nobody) Summary: a bad tuple comparison Initial Comment: A slice of sys.version_info does not compare as a tuple. #!/usr/local/bin/python import sys a = (2,2) b = (sys.version_info[0:1]) c = (sys.version_info[0], sys.version_info[1]) assert a == b, "kaBOOM! assertion failed: a == b" assert a == c, "kaBOOM! assertion failed: a == c" print "everything is okey dokey! :-)" Comment out the first assert and everything works fine. (I am new to python, but this seems to be an error; it was, at the very least, unexpected and counter intuitive.) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-10 13:21 Message: Logged In: YES user_id=31435 Not a bug. Review the docs on sequence slicing: s[i:j] contains j-i elements, not j-i+1. Try printing sys.version [0:1], then try printing sys.version[:2]. Repeat until the light bulb goes off . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491301&group_id=5470 From noreply@sourceforge.net Mon Dec 10 21:31:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 13:31:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-478534 ] SystemError with WeakKeyDictionary Message-ID: Bugs item #478534, was opened at 2001-11-05 19:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478534&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: Works For Me >Priority: 6 Submitted By: Sverker Nilsson (svenil) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: SystemError with WeakKeyDictionary Initial Comment: SystemError with WeakKeyDictionary A SystemError is generated when trying to iterate over a function returned from a function that stored it in a WeakKeyDictionary. The expected error was TypeError. Sverker Nilsson Examples: This program gives a SystemError: import weakref ref = weakref.WeakKeyDictionary() def encapsulate(): f = lambda : () ref[f] = None return f for x in encapsulate(): print x Python 2.2b1 (#5, Oct 20 2001, 03:03:53) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. ... Traceback (most recent call last): File "", line 1, in ? File "/tmp/pythona04442", line 9, in ? for x in encapsulate(): SystemError: error return without exception set >>> A variation of it, with a temporary variable, gives the expected TypeError: import weakref ref = weakref.WeakKeyDictionary() def encapsulate(): f = lambda : () ref[f] = None return f g = encapsulate() for x in g: print x Traceback (most recent call last): File "", line 1, in ? File "/tmp/pythona04442", line 10, in ? for x in g: TypeError: iteration over non-sequence >>> ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-10 13:31 Message: Logged In: YES user_id=3066 Let me try to explain (part of) what is happening in a debug build: 1. Object F is referenced only in the locals of a function; there is a weakref with a callback function for F. 2. An exception gets raised while that frame is still around. 3. When the locals of that frame are DECREF'd, PyObject_ClearWeakRefs() is called for F. 4. PyObject_ClearWeakRefs() calls the callback function. 5. eval_frame() detects that an exception was raised without a NULL return, and turns it into a real exception. 6. frame_dealloc() removes the locals, which causes PyObject_ClearWeakRefs() to be called for F. 7. PyObject_ClearWeakRefs() sees the NULL return and calls PyErr_WriteUnraisable(), which (eventually) clears the exception. 8. PyObject_ClearWeakRefs() returns, and the frame which contained the reference to F continues to act as if there were an exception. Well, I don't think this should end up dumping core, but clearly things are pretty messed up at this point. Essentially, deallocators (even those in C) should not be entered as long as an exception is set, and this is a case where it can happen. I can add code to protect against this for callbacks triggered by the weakref code, but that doesn't solve the general problem of which this is a specific case. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 12:34 Message: Logged In: YES user_id=6380 Fred, do you need help looking at this? If this needs to be fixed before the release, please raise priority to 7 or higher. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-10 12:22 Message: Logged In: YES user_id=3066 This is a really vicious bug. I've simplified the test case some more, but I'm still not sure what needs to be done to fix this. I'm not sure that I can make the test case smaller; raising the exception is still required. I expect this is still a matter of an exception not being properly detected and cleared at some point. ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:55 Message: Logged In: YES user_id=356603 Seems the files didnt make it, sorry for the fuzz.. trying again. S. ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:50 Message: Logged In: YES user_id=356603 wrbug4.gdb-transcript contains a raw gdb transcript, in case it can be of some use / Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:47 Message: Logged In: YES user_id=356603 I couldnt figure out how to upload several files with the same comment. Well, this is to tell you that wrbug4.mail contains some more info. /Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:42 Message: Logged In: YES user_id=356603 I have got the cvs version now. It also gives the error or segmentation fault. Either compiled with Py_Debug enabled in configuration, or with another version of my test program. (The Py_Debug definition changes what Python does in eval_frame so the error is revealed in the original test. ) See attached files: wrbug4.py, new test program. wrbug4.mail, some info. wrbug4.gdb-transcript, a raw gdb transcript... /Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-06 11:07 Message: Logged In: YES user_id=356603 Ooops, in the example I sent you I hadnt removed the self parameter after all. I mixed up something. But when I did remove the self parameter it went as I said. Actually, I get a segmentation fault running it directly from the shell. (When running it from Emacs mode or importing it I get SystemError.) Sverker Shell transcript: nicosys [228] python defenvbug3.py first add ok Segmentation fault nicosys [229] cat defenvbug3.py import weakref ref = weakref.WeakKeyDictionary() class MyError(Exception): pass def add(x): raise MyError def encapsulate(): f = lambda : () ref[f] = None return f try: add(encapsulate()) except MyError: pass print 'first add ok' add(encapsulate()) # Here we would like to get Exception but gets SystemError instead. nicosys [230] python Python 2.2b1 (#5, Oct 20 2001, 03:03:53) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import defenvbug3.py first add ok Traceback (most recent call last): File "", line 1, in ? SystemError: NULL result without error in PyObject_Call >>> nicosys [231] whence python /usr/local/bin/python is actually /hda7/local/bin/python /usr/local/bin/python: ELF 32-bit LSB executable i386 (386 and up) Version 1 nicosys [232] ldd /hda7/local/bin/python libdl.so.2 => /lib/libdl.so.2 (0x40018000) libpthread.so.0 => /lib/libpthread.so.0 (0x4001d000) libutil.so.1 => /lib/libutil.so.1 (0x40030000) libm.so.6 => /lib/libm.so.6 (0x40033000) libc.so.6 => /lib/libc.so.6 (0x40052000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) nicosys [233] ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-06 10:47 Message: Logged In: YES user_id=356603 To answer your question, I am using 2.2b1, from the tarball not from CVS. In the second example, I get SystemError from the first call to add actually. I thought it was from the second one, but since I changed from my own exception class to Exception it became hidden. When I remove the uninteded self parameter of add, I get SystemError in the second call, as I thought I was getting. But you get TypeError.. hmmm.. I suppose I should download the CVS then?.. Or maybe wait for 2.2b2.. Sverker ps. Here's my updated second example, anyway.. import weakref ref = weakref.WeakKeyDictionary() class MyError(Exception): pass def add(self, x): raise MyError def encapsulate(): f = lambda : () ref[f] = None return f try: add(encapsulate()) except MyError: pass print 'first add ok' add(encapsulate()) # Here we would like to get Exception but gets SystemError instead. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-06 08:33 Message: Logged In: YES user_id=3066 I cannot reproduce this using either code snippet. Note that the second example should (and does for me) raise TypeError when calling add() -- you left in a "self" that appears to be unintended. Are you using 2.2b1 or CVS python? ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-05 23:17 Message: Logged In: YES user_id=356603 The same problem now occured in another situation. I am enclosing the condensed program. /Sverker ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478534&group_id=5470 From noreply@sourceforge.net Mon Dec 10 22:03:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 14:03:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-478534 ] SystemError with WeakKeyDictionary Message-ID: Bugs item #478534, was opened at 2001-11-05 19:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478534&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: Works For Me Priority: 6 Submitted By: Sverker Nilsson (svenil) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: SystemError with WeakKeyDictionary Initial Comment: SystemError with WeakKeyDictionary A SystemError is generated when trying to iterate over a function returned from a function that stored it in a WeakKeyDictionary. The expected error was TypeError. Sverker Nilsson Examples: This program gives a SystemError: import weakref ref = weakref.WeakKeyDictionary() def encapsulate(): f = lambda : () ref[f] = None return f for x in encapsulate(): print x Python 2.2b1 (#5, Oct 20 2001, 03:03:53) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. ... Traceback (most recent call last): File "", line 1, in ? File "/tmp/pythona04442", line 9, in ? for x in encapsulate(): SystemError: error return without exception set >>> A variation of it, with a temporary variable, gives the expected TypeError: import weakref ref = weakref.WeakKeyDictionary() def encapsulate(): f = lambda : () ref[f] = None return f g = encapsulate() for x in g: print x Traceback (most recent call last): File "", line 1, in ? File "/tmp/pythona04442", line 10, in ? for x in g: TypeError: iteration over non-sequence >>> ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 14:03 Message: Logged In: YES user_id=6380 [Fred] > Essentially, deallocators (even those in C) should not be > entered as long as an exception is set, and this is a case > where it can happen. Not true, IMO. If by deallocator you mean the function in the tp_dealloc field of a type object, that gets called by the Py_DECREF() macro, and Py_DECREF() gets called all the time with a pending exception (lots of code does cleanup involving Py_DECREF() before passing an exception on to its caller). The correct rule is that if a deallocator calls into Python, it must save and restore any pending exception condition using PyErr_Fetch() and PyErr_Restore(). This is how __del__ finalizers get called. I suppose you could put such a call around each of the PyObject_CallFunction(callback, ...) call in PyObject_ClearWeakRefs(), or you could puy it around most of that function's body (since there are several calls). Or you might have a flag variable that tells you whether you have already called PyErr_Fetch(), and only call PyErr_Restore() at the function exit when the flag is set. Personally, this function looks ripe for refactoring... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-10 13:31 Message: Logged In: YES user_id=3066 Let me try to explain (part of) what is happening in a debug build: 1. Object F is referenced only in the locals of a function; there is a weakref with a callback function for F. 2. An exception gets raised while that frame is still around. 3. When the locals of that frame are DECREF'd, PyObject_ClearWeakRefs() is called for F. 4. PyObject_ClearWeakRefs() calls the callback function. 5. eval_frame() detects that an exception was raised without a NULL return, and turns it into a real exception. 6. frame_dealloc() removes the locals, which causes PyObject_ClearWeakRefs() to be called for F. 7. PyObject_ClearWeakRefs() sees the NULL return and calls PyErr_WriteUnraisable(), which (eventually) clears the exception. 8. PyObject_ClearWeakRefs() returns, and the frame which contained the reference to F continues to act as if there were an exception. Well, I don't think this should end up dumping core, but clearly things are pretty messed up at this point. Essentially, deallocators (even those in C) should not be entered as long as an exception is set, and this is a case where it can happen. I can add code to protect against this for callbacks triggered by the weakref code, but that doesn't solve the general problem of which this is a specific case. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 12:34 Message: Logged In: YES user_id=6380 Fred, do you need help looking at this? If this needs to be fixed before the release, please raise priority to 7 or higher. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-10 12:22 Message: Logged In: YES user_id=3066 This is a really vicious bug. I've simplified the test case some more, but I'm still not sure what needs to be done to fix this. I'm not sure that I can make the test case smaller; raising the exception is still required. I expect this is still a matter of an exception not being properly detected and cleared at some point. ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:55 Message: Logged In: YES user_id=356603 Seems the files didnt make it, sorry for the fuzz.. trying again. S. ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:50 Message: Logged In: YES user_id=356603 wrbug4.gdb-transcript contains a raw gdb transcript, in case it can be of some use / Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:47 Message: Logged In: YES user_id=356603 I couldnt figure out how to upload several files with the same comment. Well, this is to tell you that wrbug4.mail contains some more info. /Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:42 Message: Logged In: YES user_id=356603 I have got the cvs version now. It also gives the error or segmentation fault. Either compiled with Py_Debug enabled in configuration, or with another version of my test program. (The Py_Debug definition changes what Python does in eval_frame so the error is revealed in the original test. ) See attached files: wrbug4.py, new test program. wrbug4.mail, some info. wrbug4.gdb-transcript, a raw gdb transcript... /Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-06 11:07 Message: Logged In: YES user_id=356603 Ooops, in the example I sent you I hadnt removed the self parameter after all. I mixed up something. But when I did remove the self parameter it went as I said. Actually, I get a segmentation fault running it directly from the shell. (When running it from Emacs mode or importing it I get SystemError.) Sverker Shell transcript: nicosys [228] python defenvbug3.py first add ok Segmentation fault nicosys [229] cat defenvbug3.py import weakref ref = weakref.WeakKeyDictionary() class MyError(Exception): pass def add(x): raise MyError def encapsulate(): f = lambda : () ref[f] = None return f try: add(encapsulate()) except MyError: pass print 'first add ok' add(encapsulate()) # Here we would like to get Exception but gets SystemError instead. nicosys [230] python Python 2.2b1 (#5, Oct 20 2001, 03:03:53) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import defenvbug3.py first add ok Traceback (most recent call last): File "", line 1, in ? SystemError: NULL result without error in PyObject_Call >>> nicosys [231] whence python /usr/local/bin/python is actually /hda7/local/bin/python /usr/local/bin/python: ELF 32-bit LSB executable i386 (386 and up) Version 1 nicosys [232] ldd /hda7/local/bin/python libdl.so.2 => /lib/libdl.so.2 (0x40018000) libpthread.so.0 => /lib/libpthread.so.0 (0x4001d000) libutil.so.1 => /lib/libutil.so.1 (0x40030000) libm.so.6 => /lib/libm.so.6 (0x40033000) libc.so.6 => /lib/libc.so.6 (0x40052000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) nicosys [233] ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-06 10:47 Message: Logged In: YES user_id=356603 To answer your question, I am using 2.2b1, from the tarball not from CVS. In the second example, I get SystemError from the first call to add actually. I thought it was from the second one, but since I changed from my own exception class to Exception it became hidden. When I remove the uninteded self parameter of add, I get SystemError in the second call, as I thought I was getting. But you get TypeError.. hmmm.. I suppose I should download the CVS then?.. Or maybe wait for 2.2b2.. Sverker ps. Here's my updated second example, anyway.. import weakref ref = weakref.WeakKeyDictionary() class MyError(Exception): pass def add(self, x): raise MyError def encapsulate(): f = lambda : () ref[f] = None return f try: add(encapsulate()) except MyError: pass print 'first add ok' add(encapsulate()) # Here we would like to get Exception but gets SystemError instead. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-06 08:33 Message: Logged In: YES user_id=3066 I cannot reproduce this using either code snippet. Note that the second example should (and does for me) raise TypeError when calling add() -- you left in a "self" that appears to be unintended. Are you using 2.2b1 or CVS python? ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-05 23:17 Message: Logged In: YES user_id=356603 The same problem now occured in another situation. I am enclosing the condensed program. /Sverker ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478534&group_id=5470 From noreply@sourceforge.net Mon Dec 10 22:12:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 14:12:28 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-491331 ] request sys.required_version Message-ID: Feature Requests item #491331, was opened at 2001-12-10 14:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=491331&group_id=5470 Category: Python Library Group: None Status: Open Priority: 5 Submitted By: Daniel Ortmann (dortmann) Assigned to: Nobody/Anonymous (nobody) Summary: request sys.required_version Initial Comment: In Perl, "require 5.04" conveniently specifies the minimum level of Perl required to run the script. I expected to find something similar in the Python sys module, but this is as close as I can come: import sys assert (2,2) <= sys.version_info[:2], "python version is too old!" It seems to me that I should be able to say something like: import sys sys.required_version(2,2,0) Thank you! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=491331&group_id=5470 From noreply@sourceforge.net Mon Dec 10 22:20:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 14:20:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-490453 ] OpenUNIX 8: No Compile/Run Message-ID: Bugs item #490453, was opened at 2001-12-07 15:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Larry Rosenman (ler) Assigned to: Nobody/Anonymous (nobody) Summary: OpenUNIX 8: No Compile/Run Initial Comment: On OpenUNIX 8, nothing seems to compile. Y''ou seem to use ld instead of cc for building the shared objects, which is wrong. Also, there seems to be other issues with symbol referencing errors. I've given accounts on my box before, and I'm willing to do that again. I believe there are serious issues with this build. (2.1.1 of Python, BTW). ---------------------------------------------------------------------- >Comment By: Larry Rosenman (ler) Date: 2001-12-10 14:20 Message: Logged In: YES user_id=36452 More information: the getaddrinfo configure test doesn't take into account ---disable--ipv6. This causes the program to fail, which causes us to NOT believe we have getaddrinfo (which we DO). If I force HAVE_GETADDRINFO in pyconfig.h, we compile the socket code just fine. we still coredump on a make test (I haven't figured that out yet). What can I do to help this situation? LER ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 12:06 Message: Logged In: YES user_id=36452 Here is the file ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 12:04 Message: Logged In: YES user_id=36452 Here is a make.out from a ./configure --with-cxx=CC --with-threads --disable- ipv6 ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 11:56 Message: Logged In: YES user_id=36452 Ok, 2.2b2 is *MUCH* better on this platform. the _socket extension doesn't compile. (EAI_MAX is not defined, and some other issues). I am not sure where this is supposed to be defined. I am *STILL* willing to allow a python developer (or developers) access to my box. LER ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-07 15:09 Message: Logged In: YES user_id=36452 OpenUNIX 8 is the follow- on from SCO UnixWare 7.1.1. It is from Caldera. I' ll try and figure it out, but... I believe loewis has the ID/PW for an account on my box (lerami.lerctr.org [207.158.72.11]), and I'll gladly make more if you folks want. Larry ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 15:06 Message: Logged In: YES user_id=6380 Thanks for the offer. I don't have time to sort this out, but maybe someone else who reads these notes does. (What *IS* OpenUNIX 8???) You can also try to resolve this yourself -- the configure script has a few case statements on the platform where it sets the various compilers and linkers (and their options) used for various actions. A patch would be most appreciated. You might also consider trying Python 2.2b2, which has somewhat improved the build procedure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 From noreply@sourceforge.net Mon Dec 10 22:25:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 14:25:43 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-491331 ] request sys.required_version Message-ID: Feature Requests item #491331, was opened at 2001-12-10 14:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=491331&group_id=5470 Category: Python Library Group: None Status: Open Priority: 5 Submitted By: Daniel Ortmann (dortmann) Assigned to: Nobody/Anonymous (nobody) Summary: request sys.required_version Initial Comment: In Perl, "require 5.04" conveniently specifies the minimum level of Perl required to run the script. I expected to find something similar in the Python sys module, but this is as close as I can come: import sys assert (2,2) <= sys.version_info[:2], "python version is too old!" It seems to me that I should be able to say something like: import sys sys.required_version(2,2,0) Thank you! ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-10 14:25 Message: Logged In: YES user_id=31435 Because Python has a full-blown exception system, it's generally better to test for the feature you need than to compare mysterious little integers. For example, suppose you need list comprehensions. You have no idea which version of Python first introduced them, and once you think you've got it figured out, readers of your code are going to have no idea that you *meant* "list comprehensions" when you compare sys.version_info against (2, 0). So clearer all around is: try: . eval("[i for i in range(2)]") except SyntaxError: . raise ImportError, "I require list comprehensions" ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=491331&group_id=5470 From noreply@sourceforge.net Mon Dec 10 22:27:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 14:27:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-487390 ] Modifying type.__module__ behavior Message-ID: Bugs item #487390, was opened at 2001-11-29 21:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487390&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Burton Radons (loth) Assigned to: Guido van Rossum (gvanrossum) Summary: Modifying type.__module__ behavior Initial Comment: A __module__ attribute request on a C type will return __builtin__ if the typeobject.c code cannot find a period in the type name. This is always incorrect for extension libraries, and can be a _very_ confusing error when trying to pickle your types (as the error makes it seem as if you're supposed to register your type in __builtin__). I propose that: A) All builtin Python types have a "__builtin__." prefixed to their type declaration's name. B) If the __module__ code cannot find a period, it raises AttributeError with a somewhat descriptive message. This would be in the place where it returns __builtin__. C) The tp_name comment in Include/object.h describe the special semantics. "/* 'module.typename' */", for example. This is a lot of files to change, I know, but it's only one or two line changes each file. The only code this should affect is code which is written incorrectly; it may not understand the name semantics, or it may actually be registering itself in __builtin__ (as I did before I figured out what it was doing). Otherwise we're golden. ---------------------------------------------------------------------- >Comment By: Burton Radons (loth) Date: 2001-12-10 14:27 Message: Logged In: YES user_id=2441 I have the bad feeling that there's going to be plenty of hidden caveats if we start getting tricky about where a type is. If it can be made so that __import__ ("_Win") will always yield the exact same type (or "as if"), that would be far better than hacking around in here. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-09 14:16 Message: Logged In: NO (This is Guido, unable to log in to SF on his laptop.) Answering Jack's question about the utility of the module name: The module name can be retrieved from the type using t.__module__, and is displayed by the repr() of the type. For objects with picklable instances, it is also used to pickle a reference to the type (the pickle module asks for __module__ and __name__ and then checks that importing __name__ from __module__ indeed retrieves the correct type). Additionally, if you don't specify the type, __module__ defaults to __builtin__, which is highly confusing (but can't be helped for various reasons). Alas, I don't know what to do about the different names for the same type. Maybe you can fix it so that there's a "true" name and a "convenience" name? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-09 13:32 Message: Logged In: YES user_id=45365 A question about this patch: is the module name actually used for something? I ask because the Mac toolbox modules have different names, depending on the situation. The Python programmer will always refer to the modules as something like "Carbon.Win". This, however, is a wrapper module (in Python) that imports the _Win module. If you use them under command line Python on OSX _Win will live in Lib/lib-dynload, so the "real" name will indeed be "_Win". If you use them in MacPython, however, _Win will live in the Carbon package, so the "real" name will be "Carbon._Win". Or, I should phrase that differently, if you want to import it afresh you should import it as Carbon._Win (unless you're inside the Carbon package, of course). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 10:00 Message: Logged In: YES user_id=6380 Thanks, I've applied the second version of the patch. I'm closing this because I'm satisfied now. ---------------------------------------------------------------------- Comment By: Burton Radons (loth) Date: 2001-12-07 21:56 Message: Logged In: YES user_id=2441 I should have remembered the test suite, sorry. Pickling had the highest chance of messing up with the change, but I didn't even think of trying it with the lovely set of tests available. Go ahead, remove the "__builtin__." part of the patch. I've put up a modified patch that is missing the __builtin__ changes and the change to __module__ behaviour, if you want one; simple hack job. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 21:22 Message: Logged In: YES user_id=6380 Thanks. Unfortunately, ten standard tests fail with these patches. I have a set of fixes, but I believe that the set of fixes needed could be much smaller if we did *not* add the "__builtin__." in front of all built-in types. Their __module__ will still have the correct value "__builtin__" because it defaults that way, and various bits of code that print or test tp_name won't suddenly see "__builtin__." where it wasn't before. (The worst case was cPickle, which switches on the first char of tp_name as a speed hack -- this caused mysterious failures in test_cookie and test_sre.) What do you think of this idea? IMO the rest of your patch still implements an important improvement. ---------------------------------------------------------------------- Comment By: Burton Radons (loth) Date: 2001-12-07 17:03 Message: Logged In: YES user_id=2441 Sorry about the delay. I've attached a patch doing described and threw in patches to fix Module and Mac type names as well, if it so pleases. If it does not, I can amend. Further complications came in with PyStructSequence_InitType, which sets tp_name to a passed descriptor's field. I merely patched all the places that use the function. "__module__" should now be a guaranteed correct attribute amongst Python and the modules. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 08:41 Message: Logged In: YES user_id=6380 I agree with this in principle, but I don't hve the time to make all the changes. Can you submit a patch? Since, as you say, it's so simple, I wouldn't object against including it in 2.2c1, if it's submitted in time (2.2c1 is planned for December 12 -- give us a couple of days before that). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487390&group_id=5470 From noreply@sourceforge.net Mon Dec 10 22:37:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 14:37:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-490453 ] OpenUNIX 8: No Compile/Run Message-ID: Bugs item #490453, was opened at 2001-12-07 15:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Larry Rosenman (ler) >Assigned to: Martin v. Löwis (loewis) Summary: OpenUNIX 8: No Compile/Run Initial Comment: On OpenUNIX 8, nothing seems to compile. Y''ou seem to use ld instead of cc for building the shared objects, which is wrong. Also, there seems to be other issues with symbol referencing errors. I've given accounts on my box before, and I'm willing to do that again. I believe there are serious issues with this build. (2.1.1 of Python, BTW). ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 14:20 Message: Logged In: YES user_id=36452 More information: the getaddrinfo configure test doesn't take into account ---disable--ipv6. This causes the program to fail, which causes us to NOT believe we have getaddrinfo (which we DO). If I force HAVE_GETADDRINFO in pyconfig.h, we compile the socket code just fine. we still coredump on a make test (I haven't figured that out yet). What can I do to help this situation? LER ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 12:06 Message: Logged In: YES user_id=36452 Here is the file ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 12:04 Message: Logged In: YES user_id=36452 Here is a make.out from a ./configure --with-cxx=CC --with-threads --disable- ipv6 ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 11:56 Message: Logged In: YES user_id=36452 Ok, 2.2b2 is *MUCH* better on this platform. the _socket extension doesn't compile. (EAI_MAX is not defined, and some other issues). I am not sure where this is supposed to be defined. I am *STILL* willing to allow a python developer (or developers) access to my box. LER ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-07 15:09 Message: Logged In: YES user_id=36452 OpenUNIX 8 is the follow- on from SCO UnixWare 7.1.1. It is from Caldera. I' ll try and figure it out, but... I believe loewis has the ID/PW for an account on my box (lerami.lerctr.org [207.158.72.11]), and I'll gladly make more if you folks want. Larry ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 15:06 Message: Logged In: YES user_id=6380 Thanks for the offer. I don't have time to sort this out, but maybe someone else who reads these notes does. (What *IS* OpenUNIX 8???) You can also try to resolve this yourself -- the configure script has a few case statements on the platform where it sets the various compilers and linkers (and their options) used for various actions. A patch would be most appreciated. You might also consider trying Python 2.2b2, which has somewhat improved the build procedure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 From noreply@sourceforge.net Mon Dec 10 23:28:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 15:28:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-478534 ] SystemError with WeakKeyDictionary Message-ID: Bugs item #478534, was opened at 2001-11-05 19:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478534&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: Works For Me Priority: 6 Submitted By: Sverker Nilsson (svenil) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: SystemError with WeakKeyDictionary Initial Comment: SystemError with WeakKeyDictionary A SystemError is generated when trying to iterate over a function returned from a function that stored it in a WeakKeyDictionary. The expected error was TypeError. Sverker Nilsson Examples: This program gives a SystemError: import weakref ref = weakref.WeakKeyDictionary() def encapsulate(): f = lambda : () ref[f] = None return f for x in encapsulate(): print x Python 2.2b1 (#5, Oct 20 2001, 03:03:53) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. ... Traceback (most recent call last): File "", line 1, in ? File "/tmp/pythona04442", line 9, in ? for x in encapsulate(): SystemError: error return without exception set >>> A variation of it, with a temporary variable, gives the expected TypeError: import weakref ref = weakref.WeakKeyDictionary() def encapsulate(): f = lambda : () ref[f] = None return f g = encapsulate() for x in g: print x Traceback (most recent call last): File "", line 1, in ? File "/tmp/pythona04442", line 10, in ? for x in g: TypeError: iteration over non-sequence >>> ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-10 15:28 Message: Logged In: YES user_id=31435 Guido sez: """ The correct rule is that if a deallocator calls into Python, it must save and restore any pending exception condition using PyErr_Fetch() and PyErr_Restore(). """ I don't think it's that easy: as bug 485153 pointed out, you can get into trouble just calling C API functions with a stale exception set. The deallocator may call a C API function whose internals use Py_ErrOccurred() to detect whether what the latter calls raised an error. But if an error is set upon entry to the deallocator, Py_ErrOccurred () will trigger in the callees whether or not the error is fresh. It's like leaving a stale non-zero errno value set when calling a function that checks errno after a call but doesn't clear errno before the call. So I expect a more correct rule is: If a deallocator makes any C API calls, then before making the first it must save any pending exception condition using PyErr_Fetch(), clear the exception before making the C API call, and restore the pending exception via PyErr_Restore() after the last C API call -- unless it can prove the C API call can't be fooled by a pending exception (which it can't in theory, but is often true nevertheless in practice). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 14:03 Message: Logged In: YES user_id=6380 [Fred] > Essentially, deallocators (even those in C) should not be > entered as long as an exception is set, and this is a case > where it can happen. Not true, IMO. If by deallocator you mean the function in the tp_dealloc field of a type object, that gets called by the Py_DECREF() macro, and Py_DECREF() gets called all the time with a pending exception (lots of code does cleanup involving Py_DECREF() before passing an exception on to its caller). The correct rule is that if a deallocator calls into Python, it must save and restore any pending exception condition using PyErr_Fetch() and PyErr_Restore(). This is how __del__ finalizers get called. I suppose you could put such a call around each of the PyObject_CallFunction(callback, ...) call in PyObject_ClearWeakRefs(), or you could puy it around most of that function's body (since there are several calls). Or you might have a flag variable that tells you whether you have already called PyErr_Fetch(), and only call PyErr_Restore() at the function exit when the flag is set. Personally, this function looks ripe for refactoring... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-10 13:31 Message: Logged In: YES user_id=3066 Let me try to explain (part of) what is happening in a debug build: 1. Object F is referenced only in the locals of a function; there is a weakref with a callback function for F. 2. An exception gets raised while that frame is still around. 3. When the locals of that frame are DECREF'd, PyObject_ClearWeakRefs() is called for F. 4. PyObject_ClearWeakRefs() calls the callback function. 5. eval_frame() detects that an exception was raised without a NULL return, and turns it into a real exception. 6. frame_dealloc() removes the locals, which causes PyObject_ClearWeakRefs() to be called for F. 7. PyObject_ClearWeakRefs() sees the NULL return and calls PyErr_WriteUnraisable(), which (eventually) clears the exception. 8. PyObject_ClearWeakRefs() returns, and the frame which contained the reference to F continues to act as if there were an exception. Well, I don't think this should end up dumping core, but clearly things are pretty messed up at this point. Essentially, deallocators (even those in C) should not be entered as long as an exception is set, and this is a case where it can happen. I can add code to protect against this for callbacks triggered by the weakref code, but that doesn't solve the general problem of which this is a specific case. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 12:34 Message: Logged In: YES user_id=6380 Fred, do you need help looking at this? If this needs to be fixed before the release, please raise priority to 7 or higher. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-10 12:22 Message: Logged In: YES user_id=3066 This is a really vicious bug. I've simplified the test case some more, but I'm still not sure what needs to be done to fix this. I'm not sure that I can make the test case smaller; raising the exception is still required. I expect this is still a matter of an exception not being properly detected and cleared at some point. ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:55 Message: Logged In: YES user_id=356603 Seems the files didnt make it, sorry for the fuzz.. trying again. S. ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:50 Message: Logged In: YES user_id=356603 wrbug4.gdb-transcript contains a raw gdb transcript, in case it can be of some use / Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:47 Message: Logged In: YES user_id=356603 I couldnt figure out how to upload several files with the same comment. Well, this is to tell you that wrbug4.mail contains some more info. /Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:42 Message: Logged In: YES user_id=356603 I have got the cvs version now. It also gives the error or segmentation fault. Either compiled with Py_Debug enabled in configuration, or with another version of my test program. (The Py_Debug definition changes what Python does in eval_frame so the error is revealed in the original test. ) See attached files: wrbug4.py, new test program. wrbug4.mail, some info. wrbug4.gdb-transcript, a raw gdb transcript... /Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-06 11:07 Message: Logged In: YES user_id=356603 Ooops, in the example I sent you I hadnt removed the self parameter after all. I mixed up something. But when I did remove the self parameter it went as I said. Actually, I get a segmentation fault running it directly from the shell. (When running it from Emacs mode or importing it I get SystemError.) Sverker Shell transcript: nicosys [228] python defenvbug3.py first add ok Segmentation fault nicosys [229] cat defenvbug3.py import weakref ref = weakref.WeakKeyDictionary() class MyError(Exception): pass def add(x): raise MyError def encapsulate(): f = lambda : () ref[f] = None return f try: add(encapsulate()) except MyError: pass print 'first add ok' add(encapsulate()) # Here we would like to get Exception but gets SystemError instead. nicosys [230] python Python 2.2b1 (#5, Oct 20 2001, 03:03:53) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import defenvbug3.py first add ok Traceback (most recent call last): File "", line 1, in ? SystemError: NULL result without error in PyObject_Call >>> nicosys [231] whence python /usr/local/bin/python is actually /hda7/local/bin/python /usr/local/bin/python: ELF 32-bit LSB executable i386 (386 and up) Version 1 nicosys [232] ldd /hda7/local/bin/python libdl.so.2 => /lib/libdl.so.2 (0x40018000) libpthread.so.0 => /lib/libpthread.so.0 (0x4001d000) libutil.so.1 => /lib/libutil.so.1 (0x40030000) libm.so.6 => /lib/libm.so.6 (0x40033000) libc.so.6 => /lib/libc.so.6 (0x40052000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) nicosys [233] ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-06 10:47 Message: Logged In: YES user_id=356603 To answer your question, I am using 2.2b1, from the tarball not from CVS. In the second example, I get SystemError from the first call to add actually. I thought it was from the second one, but since I changed from my own exception class to Exception it became hidden. When I remove the uninteded self parameter of add, I get SystemError in the second call, as I thought I was getting. But you get TypeError.. hmmm.. I suppose I should download the CVS then?.. Or maybe wait for 2.2b2.. Sverker ps. Here's my updated second example, anyway.. import weakref ref = weakref.WeakKeyDictionary() class MyError(Exception): pass def add(self, x): raise MyError def encapsulate(): f = lambda : () ref[f] = None return f try: add(encapsulate()) except MyError: pass print 'first add ok' add(encapsulate()) # Here we would like to get Exception but gets SystemError instead. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-06 08:33 Message: Logged In: YES user_id=3066 I cannot reproduce this using either code snippet. Note that the second example should (and does for me) raise TypeError when calling add() -- you left in a "self" that appears to be unintended. Are you using 2.2b1 or CVS python? ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-05 23:17 Message: Logged In: YES user_id=356603 The same problem now occured in another situation. I am enclosing the condensed program. /Sverker ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478534&group_id=5470 From noreply@sourceforge.net Mon Dec 10 23:48:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 15:48:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-478534 ] SystemError with WeakKeyDictionary Message-ID: Bugs item #478534, was opened at 2001-11-05 19:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478534&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Sverker Nilsson (svenil) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: SystemError with WeakKeyDictionary Initial Comment: SystemError with WeakKeyDictionary A SystemError is generated when trying to iterate over a function returned from a function that stored it in a WeakKeyDictionary. The expected error was TypeError. Sverker Nilsson Examples: This program gives a SystemError: import weakref ref = weakref.WeakKeyDictionary() def encapsulate(): f = lambda : () ref[f] = None return f for x in encapsulate(): print x Python 2.2b1 (#5, Oct 20 2001, 03:03:53) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. ... Traceback (most recent call last): File "", line 1, in ? File "/tmp/pythona04442", line 9, in ? for x in encapsulate(): SystemError: error return without exception set >>> A variation of it, with a temporary variable, gives the expected TypeError: import weakref ref = weakref.WeakKeyDictionary() def encapsulate(): f = lambda : () ref[f] = None return f g = encapsulate() for x in g: print x Traceback (most recent call last): File "", line 1, in ? File "/tmp/pythona04442", line 10, in ? for x in g: TypeError: iteration over non-sequence >>> ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-10 15:48 Message: Logged In: YES user_id=3066 Fixed according to Guido's thinking in Objects/weakrefobject.c revision 1.7. The more basic issue of whether this is the right approach to outstanding exceptions and deallocators needs to be addressed separately, but probably not for Python 2.2. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-10 15:28 Message: Logged In: YES user_id=31435 Guido sez: """ The correct rule is that if a deallocator calls into Python, it must save and restore any pending exception condition using PyErr_Fetch() and PyErr_Restore(). """ I don't think it's that easy: as bug 485153 pointed out, you can get into trouble just calling C API functions with a stale exception set. The deallocator may call a C API function whose internals use Py_ErrOccurred() to detect whether what the latter calls raised an error. But if an error is set upon entry to the deallocator, Py_ErrOccurred () will trigger in the callees whether or not the error is fresh. It's like leaving a stale non-zero errno value set when calling a function that checks errno after a call but doesn't clear errno before the call. So I expect a more correct rule is: If a deallocator makes any C API calls, then before making the first it must save any pending exception condition using PyErr_Fetch(), clear the exception before making the C API call, and restore the pending exception via PyErr_Restore() after the last C API call -- unless it can prove the C API call can't be fooled by a pending exception (which it can't in theory, but is often true nevertheless in practice). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 14:03 Message: Logged In: YES user_id=6380 [Fred] > Essentially, deallocators (even those in C) should not be > entered as long as an exception is set, and this is a case > where it can happen. Not true, IMO. If by deallocator you mean the function in the tp_dealloc field of a type object, that gets called by the Py_DECREF() macro, and Py_DECREF() gets called all the time with a pending exception (lots of code does cleanup involving Py_DECREF() before passing an exception on to its caller). The correct rule is that if a deallocator calls into Python, it must save and restore any pending exception condition using PyErr_Fetch() and PyErr_Restore(). This is how __del__ finalizers get called. I suppose you could put such a call around each of the PyObject_CallFunction(callback, ...) call in PyObject_ClearWeakRefs(), or you could puy it around most of that function's body (since there are several calls). Or you might have a flag variable that tells you whether you have already called PyErr_Fetch(), and only call PyErr_Restore() at the function exit when the flag is set. Personally, this function looks ripe for refactoring... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-10 13:31 Message: Logged In: YES user_id=3066 Let me try to explain (part of) what is happening in a debug build: 1. Object F is referenced only in the locals of a function; there is a weakref with a callback function for F. 2. An exception gets raised while that frame is still around. 3. When the locals of that frame are DECREF'd, PyObject_ClearWeakRefs() is called for F. 4. PyObject_ClearWeakRefs() calls the callback function. 5. eval_frame() detects that an exception was raised without a NULL return, and turns it into a real exception. 6. frame_dealloc() removes the locals, which causes PyObject_ClearWeakRefs() to be called for F. 7. PyObject_ClearWeakRefs() sees the NULL return and calls PyErr_WriteUnraisable(), which (eventually) clears the exception. 8. PyObject_ClearWeakRefs() returns, and the frame which contained the reference to F continues to act as if there were an exception. Well, I don't think this should end up dumping core, but clearly things are pretty messed up at this point. Essentially, deallocators (even those in C) should not be entered as long as an exception is set, and this is a case where it can happen. I can add code to protect against this for callbacks triggered by the weakref code, but that doesn't solve the general problem of which this is a specific case. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 12:34 Message: Logged In: YES user_id=6380 Fred, do you need help looking at this? If this needs to be fixed before the release, please raise priority to 7 or higher. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-10 12:22 Message: Logged In: YES user_id=3066 This is a really vicious bug. I've simplified the test case some more, but I'm still not sure what needs to be done to fix this. I'm not sure that I can make the test case smaller; raising the exception is still required. I expect this is still a matter of an exception not being properly detected and cleared at some point. ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:55 Message: Logged In: YES user_id=356603 Seems the files didnt make it, sorry for the fuzz.. trying again. S. ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:50 Message: Logged In: YES user_id=356603 wrbug4.gdb-transcript contains a raw gdb transcript, in case it can be of some use / Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:47 Message: Logged In: YES user_id=356603 I couldnt figure out how to upload several files with the same comment. Well, this is to tell you that wrbug4.mail contains some more info. /Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:42 Message: Logged In: YES user_id=356603 I have got the cvs version now. It also gives the error or segmentation fault. Either compiled with Py_Debug enabled in configuration, or with another version of my test program. (The Py_Debug definition changes what Python does in eval_frame so the error is revealed in the original test. ) See attached files: wrbug4.py, new test program. wrbug4.mail, some info. wrbug4.gdb-transcript, a raw gdb transcript... /Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-06 11:07 Message: Logged In: YES user_id=356603 Ooops, in the example I sent you I hadnt removed the self parameter after all. I mixed up something. But when I did remove the self parameter it went as I said. Actually, I get a segmentation fault running it directly from the shell. (When running it from Emacs mode or importing it I get SystemError.) Sverker Shell transcript: nicosys [228] python defenvbug3.py first add ok Segmentation fault nicosys [229] cat defenvbug3.py import weakref ref = weakref.WeakKeyDictionary() class MyError(Exception): pass def add(x): raise MyError def encapsulate(): f = lambda : () ref[f] = None return f try: add(encapsulate()) except MyError: pass print 'first add ok' add(encapsulate()) # Here we would like to get Exception but gets SystemError instead. nicosys [230] python Python 2.2b1 (#5, Oct 20 2001, 03:03:53) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import defenvbug3.py first add ok Traceback (most recent call last): File "", line 1, in ? SystemError: NULL result without error in PyObject_Call >>> nicosys [231] whence python /usr/local/bin/python is actually /hda7/local/bin/python /usr/local/bin/python: ELF 32-bit LSB executable i386 (386 and up) Version 1 nicosys [232] ldd /hda7/local/bin/python libdl.so.2 => /lib/libdl.so.2 (0x40018000) libpthread.so.0 => /lib/libpthread.so.0 (0x4001d000) libutil.so.1 => /lib/libutil.so.1 (0x40030000) libm.so.6 => /lib/libm.so.6 (0x40033000) libc.so.6 => /lib/libc.so.6 (0x40052000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) nicosys [233] ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-06 10:47 Message: Logged In: YES user_id=356603 To answer your question, I am using 2.2b1, from the tarball not from CVS. In the second example, I get SystemError from the first call to add actually. I thought it was from the second one, but since I changed from my own exception class to Exception it became hidden. When I remove the uninteded self parameter of add, I get SystemError in the second call, as I thought I was getting. But you get TypeError.. hmmm.. I suppose I should download the CVS then?.. Or maybe wait for 2.2b2.. Sverker ps. Here's my updated second example, anyway.. import weakref ref = weakref.WeakKeyDictionary() class MyError(Exception): pass def add(self, x): raise MyError def encapsulate(): f = lambda : () ref[f] = None return f try: add(encapsulate()) except MyError: pass print 'first add ok' add(encapsulate()) # Here we would like to get Exception but gets SystemError instead. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-06 08:33 Message: Logged In: YES user_id=3066 I cannot reproduce this using either code snippet. Note that the second example should (and does for me) raise TypeError when calling add() -- you left in a "self" that appears to be unintended. Are you using 2.2b1 or CVS python? ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-05 23:17 Message: Logged In: YES user_id=356603 The same problem now occured in another situation. I am enclosing the condensed program. /Sverker ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478534&group_id=5470 From noreply@sourceforge.net Tue Dec 11 00:05:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 16:05:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-490453 ] OpenUNIX 8: No Compile/Run Message-ID: Bugs item #490453, was opened at 2001-12-07 15:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Larry Rosenman (ler) Assigned to: Martin v. Löwis (loewis) Summary: OpenUNIX 8: No Compile/Run Initial Comment: On OpenUNIX 8, nothing seems to compile. Y''ou seem to use ld instead of cc for building the shared objects, which is wrong. Also, there seems to be other issues with symbol referencing errors. I've given accounts on my box before, and I'm willing to do that again. I believe there are serious issues with this build. (2.1.1 of Python, BTW). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-10 16:05 Message: Logged In: YES user_id=21627 In 2.1, it is not surprising that OpenUNIX uses ld to link, since the system is unknown to configure - if vendors rename their system, they cannot expect that everything continues to work. Support for OpenUNIX* was added before 2.2b1. On getaddrinfo, it appears that the implementation has a bug: Compiling http://sourceforge.net/tracker/download.php?group_id=5470&atid=105470&file_id=13988&aid=486099 produces an error message "fail 11", which indicates that the getnameinfo does return "::" for AI_PASSIVE, but fails to return "::1" (i.e. localhost) without AI_PASSIVE. The test above is the test that tells Python not to use the system getaddrinfo. The EAI_MAX problem is the same that was reported in #490453 (since BSDI shows the same getaddrinfo bug), and has been fixed in the CVS. The coredump is produced by test_largefile, when it tries to write a byte into a large file offset. It uses write(2) to do so, and receives the signal SIGXFSZ (RLIMIT_FSIZE exceeded), which causes a core dump. I think that can be worked-around by ignoring SIGXFSZ where available; the system call will in turn return EFBIG, which in turn will raise an IOError, which will lead test_largefile to think that large files are not supported. In addition, test_unicodefile fails, since the system encoding is not known; this is not a serious problem. ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 14:20 Message: Logged In: YES user_id=36452 More information: the getaddrinfo configure test doesn't take into account ---disable--ipv6. This causes the program to fail, which causes us to NOT believe we have getaddrinfo (which we DO). If I force HAVE_GETADDRINFO in pyconfig.h, we compile the socket code just fine. we still coredump on a make test (I haven't figured that out yet). What can I do to help this situation? LER ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 12:06 Message: Logged In: YES user_id=36452 Here is the file ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 12:04 Message: Logged In: YES user_id=36452 Here is a make.out from a ./configure --with-cxx=CC --with-threads --disable- ipv6 ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 11:56 Message: Logged In: YES user_id=36452 Ok, 2.2b2 is *MUCH* better on this platform. the _socket extension doesn't compile. (EAI_MAX is not defined, and some other issues). I am not sure where this is supposed to be defined. I am *STILL* willing to allow a python developer (or developers) access to my box. LER ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-07 15:09 Message: Logged In: YES user_id=36452 OpenUNIX 8 is the follow- on from SCO UnixWare 7.1.1. It is from Caldera. I' ll try and figure it out, but... I believe loewis has the ID/PW for an account on my box (lerami.lerctr.org [207.158.72.11]), and I'll gladly make more if you folks want. Larry ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 15:06 Message: Logged In: YES user_id=6380 Thanks for the offer. I don't have time to sort this out, but maybe someone else who reads these notes does. (What *IS* OpenUNIX 8???) You can also try to resolve this yourself -- the configure script has a few case statements on the platform where it sets the various compilers and linkers (and their options) used for various actions. A patch would be most appreciated. You might also consider trying Python 2.2b2, which has somewhat improved the build procedure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 From noreply@sourceforge.net Tue Dec 11 01:23:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 17:23:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-478534 ] SystemError with WeakKeyDictionary Message-ID: Bugs item #478534, was opened at 2001-11-05 19:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478534&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Closed Resolution: Fixed Priority: 6 Submitted By: Sverker Nilsson (svenil) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: SystemError with WeakKeyDictionary Initial Comment: SystemError with WeakKeyDictionary A SystemError is generated when trying to iterate over a function returned from a function that stored it in a WeakKeyDictionary. The expected error was TypeError. Sverker Nilsson Examples: This program gives a SystemError: import weakref ref = weakref.WeakKeyDictionary() def encapsulate(): f = lambda : () ref[f] = None return f for x in encapsulate(): print x Python 2.2b1 (#5, Oct 20 2001, 03:03:53) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. ... Traceback (most recent call last): File "", line 1, in ? File "/tmp/pythona04442", line 9, in ? for x in encapsulate(): SystemError: error return without exception set >>> A variation of it, with a temporary variable, gives the expected TypeError: import weakref ref = weakref.WeakKeyDictionary() def encapsulate(): f = lambda : () ref[f] = None return f g = encapsulate() for x in g: print x Traceback (most recent call last): File "", line 1, in ? File "/tmp/pythona04442", line 10, in ? for x in g: TypeError: iteration over non-sequence >>> ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 17:23 Message: Logged In: YES user_id=6380 Tim: of course you're right. Note that my rule didn't say anything about what happens if a deallocator calls some other API function. :-) In practice, most API functions do *not* call PyErr_Occurred(), either directly or indirectly, precisely for this reason: there are too many places where a pending exception must be carried around. Alas, there are enough exceptions that this isn't a very reliable guideline, plus, things change. Ideally, this should be added to the API docs, as yet another invariant that a call may or may not maintain (like the refcount invariants). Fred: I'm not sure what you mean. It has always been a requirement for deallocators to leave pending exceptions absolutely untouched -- that's why the machinery for calling __del__ is so cumbersome. What exactly were you thinking of changing? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-10 15:48 Message: Logged In: YES user_id=3066 Fixed according to Guido's thinking in Objects/weakrefobject.c revision 1.7. The more basic issue of whether this is the right approach to outstanding exceptions and deallocators needs to be addressed separately, but probably not for Python 2.2. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-10 15:28 Message: Logged In: YES user_id=31435 Guido sez: """ The correct rule is that if a deallocator calls into Python, it must save and restore any pending exception condition using PyErr_Fetch() and PyErr_Restore(). """ I don't think it's that easy: as bug 485153 pointed out, you can get into trouble just calling C API functions with a stale exception set. The deallocator may call a C API function whose internals use Py_ErrOccurred() to detect whether what the latter calls raised an error. But if an error is set upon entry to the deallocator, Py_ErrOccurred () will trigger in the callees whether or not the error is fresh. It's like leaving a stale non-zero errno value set when calling a function that checks errno after a call but doesn't clear errno before the call. So I expect a more correct rule is: If a deallocator makes any C API calls, then before making the first it must save any pending exception condition using PyErr_Fetch(), clear the exception before making the C API call, and restore the pending exception via PyErr_Restore() after the last C API call -- unless it can prove the C API call can't be fooled by a pending exception (which it can't in theory, but is often true nevertheless in practice). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 14:03 Message: Logged In: YES user_id=6380 [Fred] > Essentially, deallocators (even those in C) should not be > entered as long as an exception is set, and this is a case > where it can happen. Not true, IMO. If by deallocator you mean the function in the tp_dealloc field of a type object, that gets called by the Py_DECREF() macro, and Py_DECREF() gets called all the time with a pending exception (lots of code does cleanup involving Py_DECREF() before passing an exception on to its caller). The correct rule is that if a deallocator calls into Python, it must save and restore any pending exception condition using PyErr_Fetch() and PyErr_Restore(). This is how __del__ finalizers get called. I suppose you could put such a call around each of the PyObject_CallFunction(callback, ...) call in PyObject_ClearWeakRefs(), or you could puy it around most of that function's body (since there are several calls). Or you might have a flag variable that tells you whether you have already called PyErr_Fetch(), and only call PyErr_Restore() at the function exit when the flag is set. Personally, this function looks ripe for refactoring... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-10 13:31 Message: Logged In: YES user_id=3066 Let me try to explain (part of) what is happening in a debug build: 1. Object F is referenced only in the locals of a function; there is a weakref with a callback function for F. 2. An exception gets raised while that frame is still around. 3. When the locals of that frame are DECREF'd, PyObject_ClearWeakRefs() is called for F. 4. PyObject_ClearWeakRefs() calls the callback function. 5. eval_frame() detects that an exception was raised without a NULL return, and turns it into a real exception. 6. frame_dealloc() removes the locals, which causes PyObject_ClearWeakRefs() to be called for F. 7. PyObject_ClearWeakRefs() sees the NULL return and calls PyErr_WriteUnraisable(), which (eventually) clears the exception. 8. PyObject_ClearWeakRefs() returns, and the frame which contained the reference to F continues to act as if there were an exception. Well, I don't think this should end up dumping core, but clearly things are pretty messed up at this point. Essentially, deallocators (even those in C) should not be entered as long as an exception is set, and this is a case where it can happen. I can add code to protect against this for callbacks triggered by the weakref code, but that doesn't solve the general problem of which this is a specific case. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 12:34 Message: Logged In: YES user_id=6380 Fred, do you need help looking at this? If this needs to be fixed before the release, please raise priority to 7 or higher. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-10 12:22 Message: Logged In: YES user_id=3066 This is a really vicious bug. I've simplified the test case some more, but I'm still not sure what needs to be done to fix this. I'm not sure that I can make the test case smaller; raising the exception is still required. I expect this is still a matter of an exception not being properly detected and cleared at some point. ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:55 Message: Logged In: YES user_id=356603 Seems the files didnt make it, sorry for the fuzz.. trying again. S. ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:50 Message: Logged In: YES user_id=356603 wrbug4.gdb-transcript contains a raw gdb transcript, in case it can be of some use / Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:47 Message: Logged In: YES user_id=356603 I couldnt figure out how to upload several files with the same comment. Well, this is to tell you that wrbug4.mail contains some more info. /Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:42 Message: Logged In: YES user_id=356603 I have got the cvs version now. It also gives the error or segmentation fault. Either compiled with Py_Debug enabled in configuration, or with another version of my test program. (The Py_Debug definition changes what Python does in eval_frame so the error is revealed in the original test. ) See attached files: wrbug4.py, new test program. wrbug4.mail, some info. wrbug4.gdb-transcript, a raw gdb transcript... /Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-06 11:07 Message: Logged In: YES user_id=356603 Ooops, in the example I sent you I hadnt removed the self parameter after all. I mixed up something. But when I did remove the self parameter it went as I said. Actually, I get a segmentation fault running it directly from the shell. (When running it from Emacs mode or importing it I get SystemError.) Sverker Shell transcript: nicosys [228] python defenvbug3.py first add ok Segmentation fault nicosys [229] cat defenvbug3.py import weakref ref = weakref.WeakKeyDictionary() class MyError(Exception): pass def add(x): raise MyError def encapsulate(): f = lambda : () ref[f] = None return f try: add(encapsulate()) except MyError: pass print 'first add ok' add(encapsulate()) # Here we would like to get Exception but gets SystemError instead. nicosys [230] python Python 2.2b1 (#5, Oct 20 2001, 03:03:53) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import defenvbug3.py first add ok Traceback (most recent call last): File "", line 1, in ? SystemError: NULL result without error in PyObject_Call >>> nicosys [231] whence python /usr/local/bin/python is actually /hda7/local/bin/python /usr/local/bin/python: ELF 32-bit LSB executable i386 (386 and up) Version 1 nicosys [232] ldd /hda7/local/bin/python libdl.so.2 => /lib/libdl.so.2 (0x40018000) libpthread.so.0 => /lib/libpthread.so.0 (0x4001d000) libutil.so.1 => /lib/libutil.so.1 (0x40030000) libm.so.6 => /lib/libm.so.6 (0x40033000) libc.so.6 => /lib/libc.so.6 (0x40052000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) nicosys [233] ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-06 10:47 Message: Logged In: YES user_id=356603 To answer your question, I am using 2.2b1, from the tarball not from CVS. In the second example, I get SystemError from the first call to add actually. I thought it was from the second one, but since I changed from my own exception class to Exception it became hidden. When I remove the uninteded self parameter of add, I get SystemError in the second call, as I thought I was getting. But you get TypeError.. hmmm.. I suppose I should download the CVS then?.. Or maybe wait for 2.2b2.. Sverker ps. Here's my updated second example, anyway.. import weakref ref = weakref.WeakKeyDictionary() class MyError(Exception): pass def add(self, x): raise MyError def encapsulate(): f = lambda : () ref[f] = None return f try: add(encapsulate()) except MyError: pass print 'first add ok' add(encapsulate()) # Here we would like to get Exception but gets SystemError instead. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-06 08:33 Message: Logged In: YES user_id=3066 I cannot reproduce this using either code snippet. Note that the second example should (and does for me) raise TypeError when calling add() -- you left in a "self" that appears to be unintended. Are you using 2.2b1 or CVS python? ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-05 23:17 Message: Logged In: YES user_id=356603 The same problem now occured in another situation. I am enclosing the condensed program. /Sverker ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478534&group_id=5470 From noreply@sourceforge.net Tue Dec 11 01:57:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 17:57:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-490453 ] OpenUNIX 8: No Compile/Run Message-ID: Bugs item #490453, was opened at 2001-12-07 15:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Larry Rosenman (ler) Assigned to: Martin v. Löwis (loewis) Summary: OpenUNIX 8: No Compile/Run Initial Comment: On OpenUNIX 8, nothing seems to compile. Y''ou seem to use ld instead of cc for building the shared objects, which is wrong. Also, there seems to be other issues with symbol referencing errors. I've given accounts on my box before, and I'm willing to do that again. I believe there are serious issues with this build. (2.1.1 of Python, BTW). ---------------------------------------------------------------------- >Comment By: Larry Rosenman (ler) Date: 2001-12-10 17:57 Message: Logged In: YES user_id=36452 I verified that if I enable largefile support we don't coredump any more (I'll leave largfiles enabled on /home). as to the getaddrinfo issue, should I report this to caldera? Thanks for looking at it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-10 16:05 Message: Logged In: YES user_id=21627 In 2.1, it is not surprising that OpenUNIX uses ld to link, since the system is unknown to configure - if vendors rename their system, they cannot expect that everything continues to work. Support for OpenUNIX* was added before 2.2b1. On getaddrinfo, it appears that the implementation has a bug: Compiling http://sourceforge.net/tracker/download.php?group_id=5470&atid=105470&file_id=13988&aid=486099 produces an error message "fail 11", which indicates that the getnameinfo does return "::" for AI_PASSIVE, but fails to return "::1" (i.e. localhost) without AI_PASSIVE. The test above is the test that tells Python not to use the system getaddrinfo. The EAI_MAX problem is the same that was reported in #490453 (since BSDI shows the same getaddrinfo bug), and has been fixed in the CVS. The coredump is produced by test_largefile, when it tries to write a byte into a large file offset. It uses write(2) to do so, and receives the signal SIGXFSZ (RLIMIT_FSIZE exceeded), which causes a core dump. I think that can be worked-around by ignoring SIGXFSZ where available; the system call will in turn return EFBIG, which in turn will raise an IOError, which will lead test_largefile to think that large files are not supported. In addition, test_unicodefile fails, since the system encoding is not known; this is not a serious problem. ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 14:20 Message: Logged In: YES user_id=36452 More information: the getaddrinfo configure test doesn't take into account ---disable--ipv6. This causes the program to fail, which causes us to NOT believe we have getaddrinfo (which we DO). If I force HAVE_GETADDRINFO in pyconfig.h, we compile the socket code just fine. we still coredump on a make test (I haven't figured that out yet). What can I do to help this situation? LER ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 12:06 Message: Logged In: YES user_id=36452 Here is the file ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 12:04 Message: Logged In: YES user_id=36452 Here is a make.out from a ./configure --with-cxx=CC --with-threads --disable- ipv6 ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 11:56 Message: Logged In: YES user_id=36452 Ok, 2.2b2 is *MUCH* better on this platform. the _socket extension doesn't compile. (EAI_MAX is not defined, and some other issues). I am not sure where this is supposed to be defined. I am *STILL* willing to allow a python developer (or developers) access to my box. LER ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-07 15:09 Message: Logged In: YES user_id=36452 OpenUNIX 8 is the follow- on from SCO UnixWare 7.1.1. It is from Caldera. I' ll try and figure it out, but... I believe loewis has the ID/PW for an account on my box (lerami.lerctr.org [207.158.72.11]), and I'll gladly make more if you folks want. Larry ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 15:06 Message: Logged In: YES user_id=6380 Thanks for the offer. I don't have time to sort this out, but maybe someone else who reads these notes does. (What *IS* OpenUNIX 8???) You can also try to resolve this yourself -- the configure script has a few case statements on the platform where it sets the various compilers and linkers (and their options) used for various actions. A patch would be most appreciated. You might also consider trying Python 2.2b2, which has somewhat improved the build procedure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 From noreply@sourceforge.net Tue Dec 11 02:17:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 18:17:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-491398 ] Sliced list subclass has wrong type Message-ID: Bugs item #491398, was opened at 2001-12-10 18:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491398&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Sliced list subclass has wrong type Initial Comment: In Python2.2b2, there is a change in behavior between a sub-class of list and a sub-class of UserList. The library code for UserList.Py in Python 2.1.1 shows an intent to maintain the class as an invariant by coercing the object being sliced. def __getslice__(self, i, j): i = max(i, 0); j = max(j, 0) return self.__class__(self.data[i:j]) In the Python2.2b2, this behavior changes and the slice is returned as a list rather than the class of the object being sliced. Example code showing the difference: import UserList class L(UserList.UserList): pass p = L(['a','b','c','d']) print p.__class__ # Original object is of class L print p[1:].__class__ # Sliced object is also class L class M(list): pass q = M(['a','b','c','d']) print q.__class__ # Original object is of class M print q[1:].__class__ # Sliced object in NOT of # class M, but becomes a list! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491398&group_id=5470 From noreply@sourceforge.net Tue Dec 11 03:16:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 19:16:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-491415 ] PyDict_UpdateFromSeq2() unused Message-ID: Bugs item #491415, was opened at 2001-12-10 19:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491415&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: PyDict_UpdateFromSeq2() unused Initial Comment: static int PyDict_UpdateFromSeq2() in Objects/dictobject.c is not used. Should it be used or removed? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491415&group_id=5470 From noreply@sourceforge.net Tue Dec 11 03:26:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 19:26:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-491415 ] PyDict_UpdateFromSeq2() unused Message-ID: Bugs item #491415, was opened at 2001-12-10 19:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491415&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Tim Peters (tim_one) Summary: PyDict_UpdateFromSeq2() unused Initial Comment: static int PyDict_UpdateFromSeq2() in Objects/dictobject.c is not used. Should it be used or removed? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 19:26 Message: Logged In: YES user_id=6380 Tim? It's static but the name looks public??? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491415&group_id=5470 From noreply@sourceforge.net Tue Dec 11 03:37:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 19:37:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-491398 ] Sliced list subclass has wrong type Message-ID: Bugs item #491398, was opened at 2001-12-10 18:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491398&group_id=5470 >Category: Type/class unification Group: Python 2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Guido van Rossum (gvanrossum) Summary: Sliced list subclass has wrong type Initial Comment: In Python2.2b2, there is a change in behavior between a sub-class of list and a sub-class of UserList. The library code for UserList.Py in Python 2.1.1 shows an intent to maintain the class as an invariant by coercing the object being sliced. def __getslice__(self, i, j): i = max(i, 0); j = max(j, 0) return self.__class__(self.data[i:j]) In the Python2.2b2, this behavior changes and the slice is returned as a list rather than the class of the object being sliced. Example code showing the difference: import UserList class L(UserList.UserList): pass p = L(['a','b','c','d']) print p.__class__ # Original object is of class L print p[1:].__class__ # Sliced object is also class L class M(list): pass q = M(['a','b','c','d']) print q.__class__ # Original object is of class M print q[1:].__class__ # Sliced object in NOT of # class M, but becomes a list! ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 19:37 Message: Logged In: YES user_id=6380 Subclassing list will never completely replace subclassing UserList -- they serve different purposes. What UserList does is a bit against the rules, IMO: it makes a requirement on the constructor of the subclass which may be inconvenient. But if you want that behavior, you can override __getslice__ yourself. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491398&group_id=5470 From noreply@sourceforge.net Tue Dec 11 03:55:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 19:55:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-491415 ] PyDict_UpdateFromSeq2() unused Message-ID: Bugs item #491415, was opened at 2001-12-10 19:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491415&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Guido van Rossum (gvanrossum) Summary: PyDict_UpdateFromSeq2() unused Initial Comment: static int PyDict_UpdateFromSeq2() in Objects/dictobject.c is not used. Should it be used or removed? ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-10 19:55 Message: Logged In: YES user_id=31435 PyDict_{Update,Merge}FromSeq2 are parallel to PyDict_ {Update,Merge}, taking a sequence of 2-sequences instead of a dict. The former are both static, and unadvertised in the header file, just because it wasn't clear to me at the time whether we wanted to bloat the public API with them, and I wanted to move on to the next bug. If you care to pronounce that they're not public API material, happy to rename merge2 and nuke update2 (or, if they are, to make them extern and advertise them). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 19:26 Message: Logged In: YES user_id=6380 Tim? It's static but the name looks public??? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491415&group_id=5470 From noreply@sourceforge.net Tue Dec 11 04:10:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 20:10:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-491415 ] PyDict_UpdateFromSeq2() unused Message-ID: Bugs item #491415, was opened at 2001-12-10 19:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491415&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Guido van Rossum (gvanrossum) Summary: PyDict_UpdateFromSeq2() unused Initial Comment: static int PyDict_UpdateFromSeq2() in Objects/dictobject.c is not used. Should it be used or removed? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 20:10 Message: Logged In: YES user_id=6380 let's talk tomorrow. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-10 19:55 Message: Logged In: YES user_id=31435 PyDict_{Update,Merge}FromSeq2 are parallel to PyDict_ {Update,Merge}, taking a sequence of 2-sequences instead of a dict. The former are both static, and unadvertised in the header file, just because it wasn't clear to me at the time whether we wanted to bloat the public API with them, and I wanted to move on to the next bug. If you care to pronounce that they're not public API material, happy to rename merge2 and nuke update2 (or, if they are, to make them extern and advertise them). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 19:26 Message: Logged In: YES user_id=6380 Tim? It's static but the name looks public??? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491415&group_id=5470 From noreply@sourceforge.net Tue Dec 11 04:10:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 20:10:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-491415 ] PyDict_UpdateFromSeq2() unused Message-ID: Bugs item #491415, was opened at 2001-12-10 19:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491415&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Guido van Rossum (gvanrossum) Summary: PyDict_UpdateFromSeq2() unused Initial Comment: static int PyDict_UpdateFromSeq2() in Objects/dictobject.c is not used. Should it be used or removed? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 20:10 Message: Logged In: YES user_id=6380 let's talk tomorrow. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-10 19:55 Message: Logged In: YES user_id=31435 PyDict_{Update,Merge}FromSeq2 are parallel to PyDict_ {Update,Merge}, taking a sequence of 2-sequences instead of a dict. The former are both static, and unadvertised in the header file, just because it wasn't clear to me at the time whether we wanted to bloat the public API with them, and I wanted to move on to the next bug. If you care to pronounce that they're not public API material, happy to rename merge2 and nuke update2 (or, if they are, to make them extern and advertise them). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 19:26 Message: Logged In: YES user_id=6380 Tim? It's static but the name looks public??? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491415&group_id=5470 From noreply@sourceforge.net Tue Dec 11 05:06:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 10 Dec 2001 21:06:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-445902 ] runtime_library_dirs and gcc don't mix Message-ID: Bugs item #445902, was opened at 2001-07-30 03:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445902&group_id=5470 Category: Distutils Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Gary Capell (gcapell) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: runtime_library_dirs and gcc don't mix Initial Comment: providing runtime_library_dirs =["/foo"], setup.py build does: gcc -shared -R/foo ... whereas it requires gcc -shared -Wl,-R/foo to get the option through to the linker. My configuration: python2.1.1, gcc 2.9.6, binutils 2.10.91.0.2, redhat 7.1, intel Please let me know if I'm just doing something stupid. Thanks heaps for the distutils stuff, it makes playing with extensions way easier. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-10 21:06 Message: Logged In: YES user_id=3066 Fixed in Lib/distutils/unixccompiler.py revision 1.38. (Bugfix candidate.) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-07 02:21 Message: Logged In: YES user_id=21627 It is hackish, but it looks acceptable to me. When I applying this patch, I recommend to add a comment indicating what problem this fragment solves. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 13:57 Message: Logged In: YES user_id=3066 I've attached a proposed patch, but it's way too hackish, and doesn't generalize at all. But it probably solves the most common case. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-08-11 00:53 Message: Logged In: YES user_id=21627 It somewhat depends on the platform; on Solaris, gcc will accept -R. On Linux, it doesn't, so this is really distutils fault, not yours. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445902&group_id=5470 From noreply@sourceforge.net Tue Dec 11 09:45:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 01:45:49 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-487331 ] time mod's timezone doesn't honor TZ var Message-ID: Feature Requests item #487331, was opened at 2001-11-29 18:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=487331&group_id=5470 >Category: None >Group: None Status: Open Priority: 3 Submitted By: Jason R. Mastaler (jasonrm) >Assigned to: Nobody/Anonymous (nobody) Summary: time mod's timezone doesn't honor TZ var Initial Comment: Python's time module seems to get the timezone name when it's first imported, but it doesn't change it if the TZ environment variable is later set. On the other hand, the time of day DOES change accordingly. Thus, setting TZ after the time module is imported results in a completely broken rfc2822 date - time in the new TZ, but with a bogus UTC offset and timezone (neither the old nor new). Here is the problem illustrated. You will see that after setting TZ, altzone, timezone, and tzname don't change, while asctime does. $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import time,os >>> print time.asctime() Thu Nov 29 18:47:39 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print time.asctime() Fri Nov 30 14:47:52 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') Here is an example of why this is a problem in practice. One of my applications sets the TZ environment variable based on a "TIMEZONE" setting in the user's configuration file. It later uses the `email' module to create a "Date:" header for outgoing mail messages. Because of this bug, the resulting "Date:" is bogus. e.g, $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import email,os >>> print email.Utils.formatdate(localtime=1) Thu, 29 Nov 2001 18:52:34 -0700 >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print email.Utils.formatdate(localtime=1) Fri, 30 Nov 2001 14:52:41 -0600 The `-0600' should be `+1300', and `-0600' isn't correct even for the original timezone! You might say: "Work around this by setting TZ before the time module is first imported." -- No, that is too fragile, and too difficult to do with complex applications. Many other modules in turn import time, etc. I suggest instead that the TZ environment variable be consulted each time the timezone is accessed. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-05 16:34 Message: Logged In: YES user_id=85984 Marc-André, I apologize for previously misspelling your name a bunch of times. Oops. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-05 15:58 Message: Logged In: YES user_id=85984 Mark, To answer your question from a couple days ago, my exact requirements are: The ability to produce an rfc2822 compliant "Date" string that corresponds to the current value of 'TZ' in the environment. I'm currently using email.Utils.formatdate() to produce the Date, but this breaks as soon as I set 'TZ' within my application. Setting 'TZ' from within Python is necessary. I don't currently know of a way to get around this problem as the breakage is in the lower level time module. Again, mxDateTime is NOT an option. Whether it integrates nicely with Python and runs on many platforms is not relevant. I'm sure both of these facts are true, but I don't want my application to depend on any external packages. This complicates the installation procedure unnecessarily. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-05 01:37 Message: Logged In: YES user_id=38388 Agreed. Let's continue to talk about this after Python 2.2 is out. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 08:11 Message: Logged In: YES user_id=12800 Rightt, all I was thinking about was an object/function to encapsulate the numeric timezone values, daylight, timezone, and altzone, without sucking in all fo the timezone names and abbreviations. As for mxDateTime, yeah putting that into Python would probably mean some compromise on the projmgt side of things. OTOH, it would be damn handy! :) Oh well, plenty of time to think about this for Python 2.3! ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-04 07:48 Message: Logged In: YES user_id=38388 Well, this may sound easy, but once you get into timezones things start to become one big can of worms, e.g. just have a look at how daylight savings time is handled in different countries of the world or how time zone names sometimes map to multiple different zones. OTOH, numeric timezones are easy to handle and all that is needed is some simple code to convert a ticks value plus an offset to a nice ISO string representation an vice-versa. That should be easy to add to the time module... About adding mxDateTime to the core: I suppose it's simply too big. Also, I have a slightly different way of maintaining the mx tools than what is considered the Python way -- I usually happily add new features and modules without much fuzz; wouldn't want to have to write a PEP to enhance my own stuff ;-) As compromise, I could add some ISO date/time parsing and formatting code from mxDateTime to Python 2.3. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 07:04 Message: Logged In: YES user_id=12800 BTW, one way to possibly handle this would be to add something to time module that created a "timezone object", encapsulating daylight, timezone, and altzone for arbitrary timezones. Then date producing code like email.Utils.formatdate() could take optional timezone objects to produce dates relative to the given zone. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 07:03 Message: Logged In: YES user_id=12800 OT, but what about adding mxDateTime to core Python <2.3 wink>? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-04 01:36 Message: Logged In: YES user_id=38388 Jason, as I already mentioned in my other reply, exposing tzset() to Python would cause more trouble than do any good because of the side-effects it has. Rather then provide ways to write buggy code in Python, I suggest to look into solving the problem you seem to have using the available tools, e.g. mxDateTime runs on many different platforms and integrates nicely with Python. If the email package is the only one you need fixed, I suggest to write a small helper or patch which implements the needed modifications for this package. BTW, what are you exact requirements ? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-03 13:56 Message: Logged In: YES user_id=85984 I'm fairly ignorant of the gory details behind the scenes of the time module, but I still contend this is buggy behavior. That is, setting os.environ['TZ'] in the application totally breaks higher level methods such as email.Utils.formatdate(). Barry had a suggestion which Mark doesn't think is a good idea. Mark, are you sure there isn't anything that can be done? If think that if you disregard this issue, it will come back to haunt the Python community. With regards to your suggestion of mxDateTime: I really can't consider this as I don't want to rely on any external modules or packages. One of my application's strengths is that it "just works" out of the box with Python, so it's very easy to install. I'd like to keep it that way unless it's absolutely necessary to do otherwise. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 12:53 Message: Logged In: YES user_id=38388 I don't know whether this is such a good idea -- after all it's fairly easy to manage timezones in the application rather than trying to fiddle the C libs routines into producing the output you intend. Also note that tzset() is *not* thread safe. BTW, Jason, you may want to have a look at mxDateTime -- perhaps it already has what you are looking for. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-11-30 12:11 Message: Logged In: YES user_id=12800 Perhaps we should expose tzset() to Python? We'd also have to reset timezone, altzone, daylight, and tzname in the module after calling tzset(). It's a bit of work, and adds a feature so it can't go into Python 2.2, but if you think this is a viable approach, re-assign this bug to me and I'll deal with it for Python 2.3. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 11:01 Message: Logged In: YES user_id=38388 The time module is a very thin layer on top of the C lib time APIs. There's nothing much Python can do about errors in those APIs, e.g. not recognizing changes to TZ. Also note that the tzset() API which inits the time APIs w/r to the TZ environment variable is only called at time module import time. To expose the dynamic changes you are looking for, it would have to call tzset() prior to all calls to asctime() et al. -- much too time consuming ! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=487331&group_id=5470 From noreply@sourceforge.net Tue Dec 11 09:48:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 01:48:17 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-487331 ] time mod's timezone doesn't honor TZ var Message-ID: Feature Requests item #487331, was opened at 2001-11-29 18:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=487331&group_id=5470 >Category: Python Library Group: None Status: Open Priority: 3 Submitted By: Jason R. Mastaler (jasonrm) >Assigned to: M.-A. Lemburg (lemburg) Summary: time mod's timezone doesn't honor TZ var Initial Comment: Python's time module seems to get the timezone name when it's first imported, but it doesn't change it if the TZ environment variable is later set. On the other hand, the time of day DOES change accordingly. Thus, setting TZ after the time module is imported results in a completely broken rfc2822 date - time in the new TZ, but with a bogus UTC offset and timezone (neither the old nor new). Here is the problem illustrated. You will see that after setting TZ, altzone, timezone, and tzname don't change, while asctime does. $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import time,os >>> print time.asctime() Thu Nov 29 18:47:39 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print time.asctime() Fri Nov 30 14:47:52 2001 >>> print time.altzone,time.timezone,time.tzname 21600 25200 ('MST', 'MDT') Here is an example of why this is a problem in practice. One of my applications sets the TZ environment variable based on a "TIMEZONE" setting in the user's configuration file. It later uses the `email' module to create a "Date:" header for outgoing mail messages. Because of this bug, the resulting "Date:" is bogus. e.g, $ python2.2 Python 2.2b2 (#1, Nov 18 2001, 18:20:32) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import email,os >>> print email.Utils.formatdate(localtime=1) Thu, 29 Nov 2001 18:52:34 -0700 >>> >>> os.environ['TZ'] = "Pacific/Auckland" >>> print email.Utils.formatdate(localtime=1) Fri, 30 Nov 2001 14:52:41 -0600 The `-0600' should be `+1300', and `-0600' isn't correct even for the original timezone! You might say: "Work around this by setting TZ before the time module is first imported." -- No, that is too fragile, and too difficult to do with complex applications. Many other modules in turn import time, etc. I suggest instead that the TZ environment variable be consulted each time the timezone is accessed. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-05 16:34 Message: Logged In: YES user_id=85984 Marc-André, I apologize for previously misspelling your name a bunch of times. Oops. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-05 15:58 Message: Logged In: YES user_id=85984 Mark, To answer your question from a couple days ago, my exact requirements are: The ability to produce an rfc2822 compliant "Date" string that corresponds to the current value of 'TZ' in the environment. I'm currently using email.Utils.formatdate() to produce the Date, but this breaks as soon as I set 'TZ' within my application. Setting 'TZ' from within Python is necessary. I don't currently know of a way to get around this problem as the breakage is in the lower level time module. Again, mxDateTime is NOT an option. Whether it integrates nicely with Python and runs on many platforms is not relevant. I'm sure both of these facts are true, but I don't want my application to depend on any external packages. This complicates the installation procedure unnecessarily. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-05 01:37 Message: Logged In: YES user_id=38388 Agreed. Let's continue to talk about this after Python 2.2 is out. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 08:11 Message: Logged In: YES user_id=12800 Rightt, all I was thinking about was an object/function to encapsulate the numeric timezone values, daylight, timezone, and altzone, without sucking in all fo the timezone names and abbreviations. As for mxDateTime, yeah putting that into Python would probably mean some compromise on the projmgt side of things. OTOH, it would be damn handy! :) Oh well, plenty of time to think about this for Python 2.3! ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-04 07:48 Message: Logged In: YES user_id=38388 Well, this may sound easy, but once you get into timezones things start to become one big can of worms, e.g. just have a look at how daylight savings time is handled in different countries of the world or how time zone names sometimes map to multiple different zones. OTOH, numeric timezones are easy to handle and all that is needed is some simple code to convert a ticks value plus an offset to a nice ISO string representation an vice-versa. That should be easy to add to the time module... About adding mxDateTime to the core: I suppose it's simply too big. Also, I have a slightly different way of maintaining the mx tools than what is considered the Python way -- I usually happily add new features and modules without much fuzz; wouldn't want to have to write a PEP to enhance my own stuff ;-) As compromise, I could add some ISO date/time parsing and formatting code from mxDateTime to Python 2.3. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 07:04 Message: Logged In: YES user_id=12800 BTW, one way to possibly handle this would be to add something to time module that created a "timezone object", encapsulating daylight, timezone, and altzone for arbitrary timezones. Then date producing code like email.Utils.formatdate() could take optional timezone objects to produce dates relative to the given zone. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-04 07:03 Message: Logged In: YES user_id=12800 OT, but what about adding mxDateTime to core Python <2.3 wink>? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-04 01:36 Message: Logged In: YES user_id=38388 Jason, as I already mentioned in my other reply, exposing tzset() to Python would cause more trouble than do any good because of the side-effects it has. Rather then provide ways to write buggy code in Python, I suggest to look into solving the problem you seem to have using the available tools, e.g. mxDateTime runs on many different platforms and integrates nicely with Python. If the email package is the only one you need fixed, I suggest to write a small helper or patch which implements the needed modifications for this package. BTW, what are you exact requirements ? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-03 13:56 Message: Logged In: YES user_id=85984 I'm fairly ignorant of the gory details behind the scenes of the time module, but I still contend this is buggy behavior. That is, setting os.environ['TZ'] in the application totally breaks higher level methods such as email.Utils.formatdate(). Barry had a suggestion which Mark doesn't think is a good idea. Mark, are you sure there isn't anything that can be done? If think that if you disregard this issue, it will come back to haunt the Python community. With regards to your suggestion of mxDateTime: I really can't consider this as I don't want to rely on any external modules or packages. One of my application's strengths is that it "just works" out of the box with Python, so it's very easy to install. I'd like to keep it that way unless it's absolutely necessary to do otherwise. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 12:53 Message: Logged In: YES user_id=38388 I don't know whether this is such a good idea -- after all it's fairly easy to manage timezones in the application rather than trying to fiddle the C libs routines into producing the output you intend. Also note that tzset() is *not* thread safe. BTW, Jason, you may want to have a look at mxDateTime -- perhaps it already has what you are looking for. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-11-30 12:11 Message: Logged In: YES user_id=12800 Perhaps we should expose tzset() to Python? We'd also have to reset timezone, altzone, daylight, and tzname in the module after calling tzset(). It's a bit of work, and adds a feature so it can't go into Python 2.2, but if you think this is a viable approach, re-assign this bug to me and I'll deal with it for Python 2.3. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 11:01 Message: Logged In: YES user_id=38388 The time module is a very thin layer on top of the C lib time APIs. There's nothing much Python can do about errors in those APIs, e.g. not recognizing changes to TZ. Also note that the tzset() API which inits the time APIs w/r to the TZ environment variable is only called at time module import time. To expose the dynamic changes you are looking for, it would have to call tzset() prior to all calls to asctime() et al. -- much too time consuming ! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=487331&group_id=5470 From noreply@sourceforge.net Tue Dec 11 10:01:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 02:01:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-488184 ] import with undefineds can crash python Message-ID: Bugs item #488184, was opened at 2001-12-02 14:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488184&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: import with undefineds can crash python Initial Comment: Importing a module which references undefined externals, or which references libraries that fail initialization, can crash the interpreter. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-11 02:01 Message: Logged In: YES user_id=45365 Apple was already aware of this bug, their bug number for it is #2806458. There is no workaround known, so we'll have to wait until it is fixed. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-06 14:56 Message: Logged In: YES user_id=45365 Unfortunately the fix I had in mind, adding the "return on error" flag to NSLinkModule(), is not good enough. Python crashes while the initialization routine for the dynamic library is running, and NSLinkModule also never gets control back, it seems. I now think this is definitely an Apple bug. Lowering the priority because of that, not because it's not important. I did find an easy way to reproduce the bug, though: "su" to someone else (not root, someone who can't access your window server) and import _Win or something similar. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488184&group_id=5470 From noreply@sourceforge.net Tue Dec 11 13:44:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 05:44:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-481218 ] popen4 fails if cmd is unicode. Message-ID: Bugs item #481218, was opened at 2001-11-13 00:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=481218&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Michael Hudson (mwh) Summary: popen4 fails if cmd is unicode. Initial Comment: In popen2.py there is a class Popen3. It contains a method _run_child(). ------- def _run_child(self, cmd): if type(cmd) == type(''): cmd = ['/bin/sh', '-c', cmd] ------- I think that this test is attempting to find if the "cmd" is not a list. Unfortunately does not get turned into a list. A better test may be: ----- def _run_child(self, cmd): if repr(type(cmd)) != "" cmd = ['/bin/sh', '-c', cmd] ----- This problem shows up when creating commands from XML files read by "xml.sax". Beta 2.2b1 still has this code. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-11 05:44 Message: Logged In: YES user_id=6656 This would seem to have been fixed in revision 1.20 in CVS; the check-in comment was: Patch #487784: Support Unicode commands in popen3/4 handling on UNIX. Bugs that are already fixed are the easiest to close... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=481218&group_id=5470 From noreply@sourceforge.net Tue Dec 11 14:04:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 06:04:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-227470 ] Memory leak in bdb Message-ID: Bugs item #227470, was opened at 2001-01-03 17:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=227470&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tessa Lau (tlau) >Assigned to: Michael Hudson (mwh) Summary: Memory leak in bdb Initial Comment: This program quickly grows to upwards of 70M on Linux with Python 2.0: import bdb for memory_leak in xrange(10000000): b = bdb.Bdb() b.run('i=0', {}, {}) Yet factoring the bdb.Bdb() instantiation outside the loop removes the memory leak. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-11 06:04 Message: Logged In: YES user_id=6656 This no longer leaks, so I guess the recent round of purifying nailed it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-03 18:31 Message: Perhaps something in the trace code? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=227470&group_id=5470 From noreply@sourceforge.net Tue Dec 11 14:08:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 06:08:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-430753 ] Python 2.1 build fails on hp-ux 11 Message-ID: Bugs item #430753, was opened at 2001-06-06 10:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=430753&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.1 build fails on hp-ux 11 Initial Comment: I'm building on HP-UX 11.00 with HP C B.11.02.02. I've tried it on both Series 700 and 800 hardware. I've attached the make logfile. There are problems with: build.py not adding +z when compiling modules termios.c - may be fixed according to another bug report _cursesmodule.c Please send any fixes to joshua.weage@arup.com Thanks ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-11 06:08 Message: Logged In: YES user_id=6656 Eh, aren't we reasonably sure Python 2.2 will build on HP-UX 11.00? Are we going to try to get 2.1 to work there, or should we just close this and say "use 2.2!"? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-08-30 13:41 Message: Logged In: YES user_id=31392 The attached make output shows a lot of problems compiling the curses support. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=430753&group_id=5470 From noreply@sourceforge.net Tue Dec 11 14:10:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 06:10:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-479981 ] test_socket fails when compiled with threads (HP-UX) Message-ID: Bugs item #479981, was opened at 2001-11-09 05:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479981&group_id=5470 Category: Threads Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: test_socket fails when compiled with threads (HP-UX) Initial Comment: Operating System HP-UX 11.0 (64 Bit) I tried to compile Python 2.1.1 this thread support. Doing so, the tests test_socket and test_asynchat both failed with "(9, 'Bad file number')" The test_socket succeds if I compiled python without threads, so I think it's an thread-problem. The thread-test istself succeeds. I think also, that python is correctly linked against libpthread. The same Problem occurs this Python 2.2.b1. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-11 06:10 Message: Logged In: YES user_id=6656 Chaned summary. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-15 08:15 Message: Logged In: NO 1. As expected, there is no change whether to lock gethostbyname or not. 2. gethostbyname is said to be threadsafe at least with HPUX 11.00 and should it be on further releases. HPUX 10.X don't support native Threads anyway 3. Python 2.1 run's on 32 Bit HP-UX-Machines 4. On 64 Bit HP-UX Machines I have found that some Patches are nessesary. I don't know what exact Patch is required but have some experiences with HP-UX General-Release Patch-Bundles: September 2000 - python failed June 2001 or later - python works maybe this helps someone ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-14 06:43 Message: Logged In: YES user_id=21627 Python puts a lock around gethostbyname if gethostbyname_r is not available. I don't think that should cause a problem even if gethostbyname is thread-safe. If you want to further analyse this, you could try to put an && !defined(__hpux) around the line #define USE_GETHOSTBYNAME_LOCK If you do, please report whether it works. In that case, it would be good to know whether gethostbyname is thread-safe on *all* HP-UX versions, or just on some. Furthermore, since this wasn't reported before: Is it specific to your installation, or reproducable on all installations? Is it perhaps specific to 64-bit mode? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-12 02:12 Message: Logged In: NO Maybe the failure has to do with gethostbyname-stuff. according the hpux-manpages theese reentrant interfaces are obsolete: int gethostent_r(struct hostent *result, struct hostent_data *buffer); int gethostbyname_r(const char *name, struct hostent *result, struct hostent_data *buffer); int gethostbyaddr_r(const char *addr, int len, int type, struct hostent *result, struct hostent_data *buffer); int sethostent_r(int stayopen, struct hostent_data *buffer); int endhostent_r(struct hostent_data *buffer); The configure-script has correctly found, that there is only a gethostbyname, but no gethostbyname_r. according to the man-pages the call to gethostbyname IS thread-save: struct hostent *gethostent(void); struct hostent *gethostbyname(const char *name); struct hostent *gethostbyaddr(const char *addr, int len, int type); ... MULTITHREAD USAGE Thread Safe: Yes Cancel Safe: Yes Async-cancel Safe: No Async-signal Safe: No Is it a failure to expect the gethostbyname to be not thread-save ? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-12 01:29 Message: Logged In: NO the complete compiler line used to link together the python binary: gcc -Wl,-E -Wl,+s -Wl,+b/mosquito/python/lib/python2.1/lib- dynload -o python \ Modules/python.o \ libpython2.1.a -lnsl -ldld -lpthread -lm The compiler I used is gcc 3.01. I tried it out with the cc from HP - the same effect After installing the Kernelpatch PHKL_25475, wich supersedes both PHKL_23842 and PHKL_20942 the failure remains the same ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-09 16:13 Message: Logged In: YES user_id=21627 Can you please also check whether the patches PHKL_23842 (or equivalent) and/or PHKL_20942. The patch titles are PHKL_23842 s700_800 11.00 signal,threads,spinlock,scheduler,IDS,q3p PHKL_20942 s700_800 11.00 signal, nanosleep, spinlock, scheduler It appears that HP-UX has a number of bugs where signals, forking, and other aspects of the operating functionality stop working in the presence of threads. If you don't have these patches, it would be good if you could try to install them, and report back whether it changes anything. Notice that HP apparently has a number of patches with these titles; they seem to be intended for different machines. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-09 15:51 Message: Logged In: YES user_id=21627 What compiler are you using? Can you please report the complete compiler line used to link together the python binary? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479981&group_id=5470 From noreply@sourceforge.net Tue Dec 11 14:16:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 06:16:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-481218 ] popen4 fails if cmd is unicode. Message-ID: Bugs item #481218, was opened at 2001-11-13 00:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=481218&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Michael Hudson (mwh) Summary: popen4 fails if cmd is unicode. Initial Comment: In popen2.py there is a class Popen3. It contains a method _run_child(). ------- def _run_child(self, cmd): if type(cmd) == type(''): cmd = ['/bin/sh', '-c', cmd] ------- I think that this test is attempting to find if the "cmd" is not a list. Unfortunately does not get turned into a list. A better test may be: ----- def _run_child(self, cmd): if repr(type(cmd)) != "" cmd = ['/bin/sh', '-c', cmd] ----- This problem shows up when creating commands from XML files read by "xml.sax". Beta 2.2b1 still has this code. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 06:16 Message: Logged In: YES user_id=6380 Ain't a time machine handy? :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-11 05:44 Message: Logged In: YES user_id=6656 This would seem to have been fixed in revision 1.20 in CVS; the check-in comment was: Patch #487784: Support Unicode commands in popen3/4 handling on UNIX. Bugs that are already fixed are the easiest to close... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=481218&group_id=5470 From noreply@sourceforge.net Tue Dec 11 14:22:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 06:22:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-430753 ] Python 2.1 build fails on hp-ux 11 Message-ID: Bugs item #430753, was opened at 2001-06-06 10:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=430753&group_id=5470 Category: Build Group: Platform-specific >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Guido van Rossum (gvanrossum) Summary: Python 2.1 build fails on hp-ux 11 Initial Comment: I'm building on HP-UX 11.00 with HP C B.11.02.02. I've tried it on both Series 700 and 800 hardware. I've attached the make logfile. There are problems with: build.py not adding +z when compiling modules termios.c - may be fixed according to another bug report _cursesmodule.c Please send any fixes to joshua.weage@arup.com Thanks ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 06:22 Message: Logged In: YES user_id=6380 Please use Python 2.2 for HP-UX. If it doesn't work, please submit a new bug report. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-11 06:08 Message: Logged In: YES user_id=6656 Eh, aren't we reasonably sure Python 2.2 will build on HP-UX 11.00? Are we going to try to get 2.1 to work there, or should we just close this and say "use 2.2!"? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-08-30 13:41 Message: Logged In: YES user_id=31392 The attached make output shows a lot of problems compiling the curses support. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=430753&group_id=5470 From noreply@sourceforge.net Tue Dec 11 14:24:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 06:24:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-479981 ] test_socket fails when compiled with threads (HP-UX) Message-ID: Bugs item #479981, was opened at 2001-11-09 05:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479981&group_id=5470 Category: Threads >Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: test_socket fails when compiled with threads (HP-UX) Initial Comment: Operating System HP-UX 11.0 (64 Bit) I tried to compile Python 2.1.1 this thread support. Doing so, the tests test_socket and test_asynchat both failed with "(9, 'Bad file number')" The test_socket succeds if I compiled python without threads, so I think it's an thread-problem. The thread-test istself succeeds. I think also, that python is correctly linked against libpthread. The same Problem occurs this Python 2.2.b1. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 06:24 Message: Logged In: YES user_id=6380 But how are we ever going to find out what to do about this? I'm tempted to close this -- what good is keeping it open going to do it? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-11 06:10 Message: Logged In: YES user_id=6656 Chaned summary. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-15 08:15 Message: Logged In: NO 1. As expected, there is no change whether to lock gethostbyname or not. 2. gethostbyname is said to be threadsafe at least with HPUX 11.00 and should it be on further releases. HPUX 10.X don't support native Threads anyway 3. Python 2.1 run's on 32 Bit HP-UX-Machines 4. On 64 Bit HP-UX Machines I have found that some Patches are nessesary. I don't know what exact Patch is required but have some experiences with HP-UX General-Release Patch-Bundles: September 2000 - python failed June 2001 or later - python works maybe this helps someone ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-14 06:43 Message: Logged In: YES user_id=21627 Python puts a lock around gethostbyname if gethostbyname_r is not available. I don't think that should cause a problem even if gethostbyname is thread-safe. If you want to further analyse this, you could try to put an && !defined(__hpux) around the line #define USE_GETHOSTBYNAME_LOCK If you do, please report whether it works. In that case, it would be good to know whether gethostbyname is thread-safe on *all* HP-UX versions, or just on some. Furthermore, since this wasn't reported before: Is it specific to your installation, or reproducable on all installations? Is it perhaps specific to 64-bit mode? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-12 02:12 Message: Logged In: NO Maybe the failure has to do with gethostbyname-stuff. according the hpux-manpages theese reentrant interfaces are obsolete: int gethostent_r(struct hostent *result, struct hostent_data *buffer); int gethostbyname_r(const char *name, struct hostent *result, struct hostent_data *buffer); int gethostbyaddr_r(const char *addr, int len, int type, struct hostent *result, struct hostent_data *buffer); int sethostent_r(int stayopen, struct hostent_data *buffer); int endhostent_r(struct hostent_data *buffer); The configure-script has correctly found, that there is only a gethostbyname, but no gethostbyname_r. according to the man-pages the call to gethostbyname IS thread-save: struct hostent *gethostent(void); struct hostent *gethostbyname(const char *name); struct hostent *gethostbyaddr(const char *addr, int len, int type); ... MULTITHREAD USAGE Thread Safe: Yes Cancel Safe: Yes Async-cancel Safe: No Async-signal Safe: No Is it a failure to expect the gethostbyname to be not thread-save ? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-12 01:29 Message: Logged In: NO the complete compiler line used to link together the python binary: gcc -Wl,-E -Wl,+s -Wl,+b/mosquito/python/lib/python2.1/lib- dynload -o python \ Modules/python.o \ libpython2.1.a -lnsl -ldld -lpthread -lm The compiler I used is gcc 3.01. I tried it out with the cc from HP - the same effect After installing the Kernelpatch PHKL_25475, wich supersedes both PHKL_23842 and PHKL_20942 the failure remains the same ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-09 16:13 Message: Logged In: YES user_id=21627 Can you please also check whether the patches PHKL_23842 (or equivalent) and/or PHKL_20942. The patch titles are PHKL_23842 s700_800 11.00 signal,threads,spinlock,scheduler,IDS,q3p PHKL_20942 s700_800 11.00 signal, nanosleep, spinlock, scheduler It appears that HP-UX has a number of bugs where signals, forking, and other aspects of the operating functionality stop working in the presence of threads. If you don't have these patches, it would be good if you could try to install them, and report back whether it changes anything. Notice that HP apparently has a number of patches with these titles; they seem to be intended for different machines. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-09 15:51 Message: Logged In: YES user_id=21627 What compiler are you using? Can you please report the complete compiler line used to link together the python binary? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479981&group_id=5470 From noreply@sourceforge.net Tue Dec 11 14:49:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 06:49:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-491567 ] *a and **k in call arglist undocumented? Message-ID: Bugs item #491567, was opened at 2001-12-11 06:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491567&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: *a and **k in call arglist undocumented? Initial Comment: I can't find where in the reference manual the argument forms *args and **kwds are documented. In section 5.3.4 there is no trace of them in the grammar. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491567&group_id=5470 From noreply@sourceforge.net Tue Dec 11 15:06:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 07:06:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-491567 ] *a and **k in call arglist undocumented? Message-ID: Bugs item #491567, was opened at 2001-12-11 06:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491567&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: *a and **k in call arglist undocumented? Initial Comment: I can't find where in the reference manual the argument forms *args and **kwds are documented. In section 5.3.4 there is no trace of them in the grammar. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-11 07:06 Message: Logged In: YES user_id=3066 This is a duplicate of #429329. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491567&group_id=5470 From noreply@sourceforge.net Tue Dec 11 16:16:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 08:16:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-429329 ] actual-parameters *arg, **kws not doc'd Message-ID: Bugs item #429329, was opened at 2001-06-01 08:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429329&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: actual-parameters *arg, **kws not doc'd Initial Comment: 5.3.4 in the language reference should document the forms *args and **kwds for actual parameters, but it makes no mention of them and does not allow for them in the syntax productions. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-11 08:16 Message: Logged In: YES user_id=6656 Here's an attempt. I haven't tried compiling it, as I haven't got that setup on this machine yet, but I think it should be OK. Fred may want to fix some markup. It does elevate some implementation accidents in the interaction of *args and keyword arguments to documented fact, which may or may not be what's wanted. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-06-06 15:46 Message: Logged In: YES user_id=31392 I made a little progress on this pre-parenthood. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-06-01 08:38 Message: Logged In: YES user_id=3066 Assigned to Jeremy, since he shepharded the patch into the Python release. Changes should be integrated with the 2.1.1 and head branches. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429329&group_id=5470 From noreply@sourceforge.net Tue Dec 11 16:17:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 08:17:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-429329 ] actual-parameters *arg, **kws not doc'd Message-ID: Bugs item #429329, was opened at 2001-06-01 08:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429329&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: actual-parameters *arg, **kws not doc'd Initial Comment: 5.3.4 in the language reference should document the forms *args and **kwds for actual parameters, but it makes no mention of them and does not allow for them in the syntax productions. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-11 08:17 Message: Logged In: YES user_id=6656 Here's an attempt. I haven't tried compiling it, as I haven't got that setup on this machine yet, but I think it should be OK. Fred may want to fix some markup. It does elevate some implementation accidents in the interaction of *args and keyword arguments to documented fact, which may or may not be what's wanted. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-11 08:16 Message: Logged In: YES user_id=6656 Here's an attempt. I haven't tried compiling it, as I haven't got that setup on this machine yet, but I think it should be OK. Fred may want to fix some markup. It does elevate some implementation accidents in the interaction of *args and keyword arguments to documented fact, which may or may not be what's wanted. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-06-06 15:46 Message: Logged In: YES user_id=31392 I made a little progress on this pre-parenthood. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-06-01 08:38 Message: Logged In: YES user_id=3066 Assigned to Jeremy, since he shepharded the patch into the Python release. Changes should be integrated with the 2.1.1 and head branches. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429329&group_id=5470 From noreply@sourceforge.net Tue Dec 11 16:17:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 08:17:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-429329 ] actual-parameters *arg, **kws not doc'd Message-ID: Bugs item #429329, was opened at 2001-06-01 08:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429329&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: actual-parameters *arg, **kws not doc'd Initial Comment: 5.3.4 in the language reference should document the forms *args and **kwds for actual parameters, but it makes no mention of them and does not allow for them in the syntax productions. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-11 08:17 Message: Logged In: YES user_id=6656 Oh, sod sf, I'll email it to python-docs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-11 08:17 Message: Logged In: YES user_id=6656 Here's an attempt. I haven't tried compiling it, as I haven't got that setup on this machine yet, but I think it should be OK. Fred may want to fix some markup. It does elevate some implementation accidents in the interaction of *args and keyword arguments to documented fact, which may or may not be what's wanted. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-11 08:16 Message: Logged In: YES user_id=6656 Here's an attempt. I haven't tried compiling it, as I haven't got that setup on this machine yet, but I think it should be OK. Fred may want to fix some markup. It does elevate some implementation accidents in the interaction of *args and keyword arguments to documented fact, which may or may not be what's wanted. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-06-06 15:46 Message: Logged In: YES user_id=31392 I made a little progress on this pre-parenthood. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-06-01 08:38 Message: Logged In: YES user_id=3066 Assigned to Jeremy, since he shepharded the patch into the Python release. Changes should be integrated with the 2.1.1 and head branches. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429329&group_id=5470 From noreply@sourceforge.net Tue Dec 11 16:42:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 08:42:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-491415 ] PyDict_UpdateFromSeq2() unused Message-ID: Bugs item #491415, was opened at 2001-12-10 19:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491415&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None >Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Tim Peters (tim_one) Summary: PyDict_UpdateFromSeq2() unused Initial Comment: static int PyDict_UpdateFromSeq2() in Objects/dictobject.c is not used. Should it be used or removed? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 08:42 Message: Logged In: YES user_id=6380 OK, let's make PyDict_MergeFromSeq2 public, and nuke PyDict_UpdateFromSeq2. (If I had to do it over again, I wouldn't make PyDict_Update public, but only PyDict_Merge -- but that's too late.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 20:10 Message: Logged In: YES user_id=6380 let's talk tomorrow. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-10 19:55 Message: Logged In: YES user_id=31435 PyDict_{Update,Merge}FromSeq2 are parallel to PyDict_ {Update,Merge}, taking a sequence of 2-sequences instead of a dict. The former are both static, and unadvertised in the header file, just because it wasn't clear to me at the time whether we wanted to bloat the public API with them, and I wanted to move on to the next bug. If you care to pronounce that they're not public API material, happy to rename merge2 and nuke update2 (or, if they are, to make them extern and advertise them). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 19:26 Message: Logged In: YES user_id=6380 Tim? It's static but the name looks public??? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491415&group_id=5470 From noreply@sourceforge.net Tue Dec 11 16:53:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 08:53:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-457633 ] _cursesmodules.c does not build on MacOSX Message-ID: Bugs item #457633, was opened at 2001-09-01 16:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457633&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: Remind Priority: 7 Submitted By: Jack Jansen (jackjansen) >Assigned to: Jack Jansen (jackjansen) Summary: _cursesmodules.c does not build on MacOSX Initial Comment: _cursesmodule.c suddenly stopped build on MacOSX. (this is from the CVS repository). The first error is on "chtype" on line 187, and you don't want the know the amount of errors it causes after that. I guess that some optional feature of curses was added without an appropriate ifdef or something. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 08:53 Message: Logged In: YES user_id=6380 I'm reassigning this to Jack because Andrew is shedding load. Jack, is this still a problem? If you can't fix it, can you lower the priority? It's not going to hold up the 2.2 release... ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-09-04 12:38 Message: Logged In: YES user_id=11375 >(are there no other platforms that have this problem?) Probably not, as most systems are SYSV-based these days. It wouldn't work on, say, SunOS 4.1, but who uses such an old version? I'm surprised MacOS X has such an old version of curses, since current *BSDs don't have a problem. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-04 08:03 Message: Logged In: YES user_id=6380 Reopening, hoping for a better way to fix this. This should really check for a magic string that occurs in all recent curses.h files, or one that only occurs in ancient (unusable) cursees.h files, to distinguish between a good and a bad curses. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-09-04 02:07 Message: Logged In: YES user_id=45365 It turns out that the curses on MacOSX is a really old (1994?) Berkeley curses, not good enough for _cursesmodule.c. I've "manually" disabled it in setup.py (are there no other platforms that have this problem?). I have no idea why the problem only showed up recently, there appear to have been no changes around this area in setup.py... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-01 19:15 Message: Logged In: YES user_id=6380 When did it last build for you without problems? The last change was from 19 July, and unless MacOS X defines either sgi or __sgi, I don't see how that could cause lots of errors. The 'chtype' typedef isn't affected by the last two checkins. Maybe something changed in some header included y Python.h or pyport.h? Maybe something you changed yourself? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457633&group_id=5470 From noreply@sourceforge.net Tue Dec 11 17:35:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 09:35:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-429329 ] actual-parameters *arg, **kws not doc'd Message-ID: Bugs item #429329, was opened at 2001-06-01 08:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429329&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: actual-parameters *arg, **kws not doc'd Initial Comment: 5.3.4 in the language reference should document the forms *args and **kwds for actual parameters, but it makes no mention of them and does not allow for them in the syntax productions. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-11 09:35 Message: Logged In: YES user_id=6656 Ah! sf's error message for trying to attach an empty file (doh) could be more informative than "invalid filename"... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-11 08:17 Message: Logged In: YES user_id=6656 Oh, sod sf, I'll email it to python-docs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-11 08:17 Message: Logged In: YES user_id=6656 Here's an attempt. I haven't tried compiling it, as I haven't got that setup on this machine yet, but I think it should be OK. Fred may want to fix some markup. It does elevate some implementation accidents in the interaction of *args and keyword arguments to documented fact, which may or may not be what's wanted. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-11 08:16 Message: Logged In: YES user_id=6656 Here's an attempt. I haven't tried compiling it, as I haven't got that setup on this machine yet, but I think it should be OK. Fred may want to fix some markup. It does elevate some implementation accidents in the interaction of *args and keyword arguments to documented fact, which may or may not be what's wanted. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-06-06 15:46 Message: Logged In: YES user_id=31392 I made a little progress on this pre-parenthood. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-06-01 08:38 Message: Logged In: YES user_id=3066 Assigned to Jeremy, since he shepharded the patch into the Python release. Changes should be integrated with the 2.1.1 and head branches. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429329&group_id=5470 From noreply@sourceforge.net Tue Dec 11 18:18:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 10:18:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-490453 ] OpenUNIX 8: No Compile/Run Message-ID: Bugs item #490453, was opened at 2001-12-07 15:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Larry Rosenman (ler) Assigned to: Martin v. Löwis (loewis) Summary: OpenUNIX 8: No Compile/Run Initial Comment: On OpenUNIX 8, nothing seems to compile. Y''ou seem to use ld instead of cc for building the shared objects, which is wrong. Also, there seems to be other issues with symbol referencing errors. I've given accounts on my box before, and I'm willing to do that again. I believe there are serious issues with this build. (2.1.1 of Python, BTW). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 10:18 Message: Logged In: YES user_id=21627 The largefile problem was fixed with test_largefile.py 1.12; I can't test it since it won't send the signal anymore (but I think it should work now - or, rather, the test will fail instead of dumping core). The test_unicodefile also seems to be due to a bug in OpenUNIX: nl_langinfo(CODESET) returns an empty string in the "C" locale. I believe it should return the name of the charset in the C locale, e.g. "US-ASCII" (Solaris returns "646", Linux 'ansi_x3.4_1968'). On the getaddrinfo issue, please do report this to Caldera: the test was authored by Jun-ichiro "itojun" Hagino, who is an IPv6 guru - so I'm pretty certain the test is right and the system is wrong. However, if Caldera analyses this as a bug on our side, please let us know. With that, I think all issues have been addressed, so I'm closing this report. If you find any further problems, please open a new one. ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 17:57 Message: Logged In: YES user_id=36452 I verified that if I enable largefile support we don't coredump any more (I'll leave largfiles enabled on /home). as to the getaddrinfo issue, should I report this to caldera? Thanks for looking at it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-10 16:05 Message: Logged In: YES user_id=21627 In 2.1, it is not surprising that OpenUNIX uses ld to link, since the system is unknown to configure - if vendors rename their system, they cannot expect that everything continues to work. Support for OpenUNIX* was added before 2.2b1. On getaddrinfo, it appears that the implementation has a bug: Compiling http://sourceforge.net/tracker/download.php?group_id=5470&atid=105470&file_id=13988&aid=486099 produces an error message "fail 11", which indicates that the getnameinfo does return "::" for AI_PASSIVE, but fails to return "::1" (i.e. localhost) without AI_PASSIVE. The test above is the test that tells Python not to use the system getaddrinfo. The EAI_MAX problem is the same that was reported in #490453 (since BSDI shows the same getaddrinfo bug), and has been fixed in the CVS. The coredump is produced by test_largefile, when it tries to write a byte into a large file offset. It uses write(2) to do so, and receives the signal SIGXFSZ (RLIMIT_FSIZE exceeded), which causes a core dump. I think that can be worked-around by ignoring SIGXFSZ where available; the system call will in turn return EFBIG, which in turn will raise an IOError, which will lead test_largefile to think that large files are not supported. In addition, test_unicodefile fails, since the system encoding is not known; this is not a serious problem. ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 14:20 Message: Logged In: YES user_id=36452 More information: the getaddrinfo configure test doesn't take into account ---disable--ipv6. This causes the program to fail, which causes us to NOT believe we have getaddrinfo (which we DO). If I force HAVE_GETADDRINFO in pyconfig.h, we compile the socket code just fine. we still coredump on a make test (I haven't figured that out yet). What can I do to help this situation? LER ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 12:06 Message: Logged In: YES user_id=36452 Here is the file ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 12:04 Message: Logged In: YES user_id=36452 Here is a make.out from a ./configure --with-cxx=CC --with-threads --disable- ipv6 ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 11:56 Message: Logged In: YES user_id=36452 Ok, 2.2b2 is *MUCH* better on this platform. the _socket extension doesn't compile. (EAI_MAX is not defined, and some other issues). I am not sure where this is supposed to be defined. I am *STILL* willing to allow a python developer (or developers) access to my box. LER ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-07 15:09 Message: Logged In: YES user_id=36452 OpenUNIX 8 is the follow- on from SCO UnixWare 7.1.1. It is from Caldera. I' ll try and figure it out, but... I believe loewis has the ID/PW for an account on my box (lerami.lerctr.org [207.158.72.11]), and I'll gladly make more if you folks want. Larry ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 15:06 Message: Logged In: YES user_id=6380 Thanks for the offer. I don't have time to sort this out, but maybe someone else who reads these notes does. (What *IS* OpenUNIX 8???) You can also try to resolve this yourself -- the configure script has a few case statements on the platform where it sets the various compilers and linkers (and their options) used for various actions. A patch would be most appreciated. You might also consider trying Python 2.2b2, which has somewhat improved the build procedure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 From noreply@sourceforge.net Tue Dec 11 18:52:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 10:52:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-491415 ] PyDict_UpdateFromSeq2() unused Message-ID: Bugs item #491415, was opened at 2001-12-10 19:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491415&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Tim Peters (tim_one) Summary: PyDict_UpdateFromSeq2() unused Initial Comment: static int PyDict_UpdateFromSeq2() in Objects/dictobject.c is not used. Should it be used or removed? ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-11 10:52 Message: Logged In: YES user_id=31435 Closed by Doc/api/concrete.tex; new revision: 1.5 Include/dictobject.h; new revision: 2.23 Misc/NEWS; new revision: 1.332 Objects/dictobject.c; new revision: 2.119 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 08:42 Message: Logged In: YES user_id=6380 OK, let's make PyDict_MergeFromSeq2 public, and nuke PyDict_UpdateFromSeq2. (If I had to do it over again, I wouldn't make PyDict_Update public, but only PyDict_Merge -- but that's too late.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 20:10 Message: Logged In: YES user_id=6380 let's talk tomorrow. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-10 19:55 Message: Logged In: YES user_id=31435 PyDict_{Update,Merge}FromSeq2 are parallel to PyDict_ {Update,Merge}, taking a sequence of 2-sequences instead of a dict. The former are both static, and unadvertised in the header file, just because it wasn't clear to me at the time whether we wanted to bloat the public API with them, and I wanted to move on to the next bug. If you care to pronounce that they're not public API material, happy to rename merge2 and nuke update2 (or, if they are, to make them extern and advertise them). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 19:26 Message: Logged In: YES user_id=6380 Tim? It's static but the name looks public??? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491415&group_id=5470 From noreply@sourceforge.net Tue Dec 11 18:49:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 10:49:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-490453 ] OpenUNIX 8: No Compile/Run Message-ID: Bugs item #490453, was opened at 2001-12-07 15:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 Category: Build Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Larry Rosenman (ler) Assigned to: Martin v. Löwis (loewis) Summary: OpenUNIX 8: No Compile/Run Initial Comment: On OpenUNIX 8, nothing seems to compile. Y''ou seem to use ld instead of cc for building the shared objects, which is wrong. Also, there seems to be other issues with symbol referencing errors. I've given accounts on my box before, and I'm willing to do that again. I believe there are serious issues with this build. (2.1.1 of Python, BTW). ---------------------------------------------------------------------- >Comment By: Larry Rosenman (ler) Date: 2001-12-11 10:49 Message: Logged In: YES user_id=36452 I turned off largefile support, and the test works. test_largefile test test_largefile skipped -- filesystem does not have largefile support I also reported both OU8 bugs to caldera. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 10:18 Message: Logged In: YES user_id=21627 The largefile problem was fixed with test_largefile.py 1.12; I can't test it since it won't send the signal anymore (but I think it should work now - or, rather, the test will fail instead of dumping core). The test_unicodefile also seems to be due to a bug in OpenUNIX: nl_langinfo(CODESET) returns an empty string in the "C" locale. I believe it should return the name of the charset in the C locale, e.g. "US-ASCII" (Solaris returns "646", Linux 'ansi_x3.4_1968'). On the getaddrinfo issue, please do report this to Caldera: the test was authored by Jun-ichiro "itojun" Hagino, who is an IPv6 guru - so I'm pretty certain the test is right and the system is wrong. However, if Caldera analyses this as a bug on our side, please let us know. With that, I think all issues have been addressed, so I'm closing this report. If you find any further problems, please open a new one. ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 17:57 Message: Logged In: YES user_id=36452 I verified that if I enable largefile support we don't coredump any more (I'll leave largfiles enabled on /home). as to the getaddrinfo issue, should I report this to caldera? Thanks for looking at it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-10 16:05 Message: Logged In: YES user_id=21627 In 2.1, it is not surprising that OpenUNIX uses ld to link, since the system is unknown to configure - if vendors rename their system, they cannot expect that everything continues to work. Support for OpenUNIX* was added before 2.2b1. On getaddrinfo, it appears that the implementation has a bug: Compiling http://sourceforge.net/tracker/download.php?group_id=5470&atid=105470&file_id=13988&aid=486099 produces an error message "fail 11", which indicates that the getnameinfo does return "::" for AI_PASSIVE, but fails to return "::1" (i.e. localhost) without AI_PASSIVE. The test above is the test that tells Python not to use the system getaddrinfo. The EAI_MAX problem is the same that was reported in #490453 (since BSDI shows the same getaddrinfo bug), and has been fixed in the CVS. The coredump is produced by test_largefile, when it tries to write a byte into a large file offset. It uses write(2) to do so, and receives the signal SIGXFSZ (RLIMIT_FSIZE exceeded), which causes a core dump. I think that can be worked-around by ignoring SIGXFSZ where available; the system call will in turn return EFBIG, which in turn will raise an IOError, which will lead test_largefile to think that large files are not supported. In addition, test_unicodefile fails, since the system encoding is not known; this is not a serious problem. ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 14:20 Message: Logged In: YES user_id=36452 More information: the getaddrinfo configure test doesn't take into account ---disable--ipv6. This causes the program to fail, which causes us to NOT believe we have getaddrinfo (which we DO). If I force HAVE_GETADDRINFO in pyconfig.h, we compile the socket code just fine. we still coredump on a make test (I haven't figured that out yet). What can I do to help this situation? LER ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 12:06 Message: Logged In: YES user_id=36452 Here is the file ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 12:04 Message: Logged In: YES user_id=36452 Here is a make.out from a ./configure --with-cxx=CC --with-threads --disable- ipv6 ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-10 11:56 Message: Logged In: YES user_id=36452 Ok, 2.2b2 is *MUCH* better on this platform. the _socket extension doesn't compile. (EAI_MAX is not defined, and some other issues). I am not sure where this is supposed to be defined. I am *STILL* willing to allow a python developer (or developers) access to my box. LER ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-12-07 15:09 Message: Logged In: YES user_id=36452 OpenUNIX 8 is the follow- on from SCO UnixWare 7.1.1. It is from Caldera. I' ll try and figure it out, but... I believe loewis has the ID/PW for an account on my box (lerami.lerctr.org [207.158.72.11]), and I'll gladly make more if you folks want. Larry ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 15:06 Message: Logged In: YES user_id=6380 Thanks for the offer. I don't have time to sort this out, but maybe someone else who reads these notes does. (What *IS* OpenUNIX 8???) You can also try to resolve this yourself -- the configure script has a few case statements on the platform where it sets the various compilers and linkers (and their options) used for various actions. A patch would be most appreciated. You might also consider trying Python 2.2b2, which has somewhat improved the build procedure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=490453&group_id=5470 From noreply@sourceforge.net Tue Dec 11 19:29:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 11:29:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-478534 ] SystemError with WeakKeyDictionary Message-ID: Bugs item #478534, was opened at 2001-11-05 19:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478534&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Closed Resolution: Fixed Priority: 6 Submitted By: Sverker Nilsson (svenil) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: SystemError with WeakKeyDictionary Initial Comment: SystemError with WeakKeyDictionary A SystemError is generated when trying to iterate over a function returned from a function that stored it in a WeakKeyDictionary. The expected error was TypeError. Sverker Nilsson Examples: This program gives a SystemError: import weakref ref = weakref.WeakKeyDictionary() def encapsulate(): f = lambda : () ref[f] = None return f for x in encapsulate(): print x Python 2.2b1 (#5, Oct 20 2001, 03:03:53) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. ... Traceback (most recent call last): File "", line 1, in ? File "/tmp/pythona04442", line 9, in ? for x in encapsulate(): SystemError: error return without exception set >>> A variation of it, with a temporary variable, gives the expected TypeError: import weakref ref = weakref.WeakKeyDictionary() def encapsulate(): f = lambda : () ref[f] = None return f g = encapsulate() for x in g: print x Traceback (most recent call last): File "", line 1, in ? File "/tmp/pythona04442", line 10, in ? for x in g: TypeError: iteration over non-sequence >>> ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-11 11:29 Message: Logged In: YES user_id=3066 Added a discussion about protecting against exceptions in a deallocator, with an example, in the Extending & Embedding manual as Doc/ext/newtypes.tex revision 1.6. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 17:23 Message: Logged In: YES user_id=6380 Tim: of course you're right. Note that my rule didn't say anything about what happens if a deallocator calls some other API function. :-) In practice, most API functions do *not* call PyErr_Occurred(), either directly or indirectly, precisely for this reason: there are too many places where a pending exception must be carried around. Alas, there are enough exceptions that this isn't a very reliable guideline, plus, things change. Ideally, this should be added to the API docs, as yet another invariant that a call may or may not maintain (like the refcount invariants). Fred: I'm not sure what you mean. It has always been a requirement for deallocators to leave pending exceptions absolutely untouched -- that's why the machinery for calling __del__ is so cumbersome. What exactly were you thinking of changing? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-10 15:48 Message: Logged In: YES user_id=3066 Fixed according to Guido's thinking in Objects/weakrefobject.c revision 1.7. The more basic issue of whether this is the right approach to outstanding exceptions and deallocators needs to be addressed separately, but probably not for Python 2.2. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-10 15:28 Message: Logged In: YES user_id=31435 Guido sez: """ The correct rule is that if a deallocator calls into Python, it must save and restore any pending exception condition using PyErr_Fetch() and PyErr_Restore(). """ I don't think it's that easy: as bug 485153 pointed out, you can get into trouble just calling C API functions with a stale exception set. The deallocator may call a C API function whose internals use Py_ErrOccurred() to detect whether what the latter calls raised an error. But if an error is set upon entry to the deallocator, Py_ErrOccurred () will trigger in the callees whether or not the error is fresh. It's like leaving a stale non-zero errno value set when calling a function that checks errno after a call but doesn't clear errno before the call. So I expect a more correct rule is: If a deallocator makes any C API calls, then before making the first it must save any pending exception condition using PyErr_Fetch(), clear the exception before making the C API call, and restore the pending exception via PyErr_Restore() after the last C API call -- unless it can prove the C API call can't be fooled by a pending exception (which it can't in theory, but is often true nevertheless in practice). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 14:03 Message: Logged In: YES user_id=6380 [Fred] > Essentially, deallocators (even those in C) should not be > entered as long as an exception is set, and this is a case > where it can happen. Not true, IMO. If by deallocator you mean the function in the tp_dealloc field of a type object, that gets called by the Py_DECREF() macro, and Py_DECREF() gets called all the time with a pending exception (lots of code does cleanup involving Py_DECREF() before passing an exception on to its caller). The correct rule is that if a deallocator calls into Python, it must save and restore any pending exception condition using PyErr_Fetch() and PyErr_Restore(). This is how __del__ finalizers get called. I suppose you could put such a call around each of the PyObject_CallFunction(callback, ...) call in PyObject_ClearWeakRefs(), or you could puy it around most of that function's body (since there are several calls). Or you might have a flag variable that tells you whether you have already called PyErr_Fetch(), and only call PyErr_Restore() at the function exit when the flag is set. Personally, this function looks ripe for refactoring... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-10 13:31 Message: Logged In: YES user_id=3066 Let me try to explain (part of) what is happening in a debug build: 1. Object F is referenced only in the locals of a function; there is a weakref with a callback function for F. 2. An exception gets raised while that frame is still around. 3. When the locals of that frame are DECREF'd, PyObject_ClearWeakRefs() is called for F. 4. PyObject_ClearWeakRefs() calls the callback function. 5. eval_frame() detects that an exception was raised without a NULL return, and turns it into a real exception. 6. frame_dealloc() removes the locals, which causes PyObject_ClearWeakRefs() to be called for F. 7. PyObject_ClearWeakRefs() sees the NULL return and calls PyErr_WriteUnraisable(), which (eventually) clears the exception. 8. PyObject_ClearWeakRefs() returns, and the frame which contained the reference to F continues to act as if there were an exception. Well, I don't think this should end up dumping core, but clearly things are pretty messed up at this point. Essentially, deallocators (even those in C) should not be entered as long as an exception is set, and this is a case where it can happen. I can add code to protect against this for callbacks triggered by the weakref code, but that doesn't solve the general problem of which this is a specific case. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 12:34 Message: Logged In: YES user_id=6380 Fred, do you need help looking at this? If this needs to be fixed before the release, please raise priority to 7 or higher. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-10 12:22 Message: Logged In: YES user_id=3066 This is a really vicious bug. I've simplified the test case some more, but I'm still not sure what needs to be done to fix this. I'm not sure that I can make the test case smaller; raising the exception is still required. I expect this is still a matter of an exception not being properly detected and cleared at some point. ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:55 Message: Logged In: YES user_id=356603 Seems the files didnt make it, sorry for the fuzz.. trying again. S. ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:50 Message: Logged In: YES user_id=356603 wrbug4.gdb-transcript contains a raw gdb transcript, in case it can be of some use / Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:47 Message: Logged In: YES user_id=356603 I couldnt figure out how to upload several files with the same comment. Well, this is to tell you that wrbug4.mail contains some more info. /Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-07 09:42 Message: Logged In: YES user_id=356603 I have got the cvs version now. It also gives the error or segmentation fault. Either compiled with Py_Debug enabled in configuration, or with another version of my test program. (The Py_Debug definition changes what Python does in eval_frame so the error is revealed in the original test. ) See attached files: wrbug4.py, new test program. wrbug4.mail, some info. wrbug4.gdb-transcript, a raw gdb transcript... /Sverker ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-06 11:07 Message: Logged In: YES user_id=356603 Ooops, in the example I sent you I hadnt removed the self parameter after all. I mixed up something. But when I did remove the self parameter it went as I said. Actually, I get a segmentation fault running it directly from the shell. (When running it from Emacs mode or importing it I get SystemError.) Sverker Shell transcript: nicosys [228] python defenvbug3.py first add ok Segmentation fault nicosys [229] cat defenvbug3.py import weakref ref = weakref.WeakKeyDictionary() class MyError(Exception): pass def add(x): raise MyError def encapsulate(): f = lambda : () ref[f] = None return f try: add(encapsulate()) except MyError: pass print 'first add ok' add(encapsulate()) # Here we would like to get Exception but gets SystemError instead. nicosys [230] python Python 2.2b1 (#5, Oct 20 2001, 03:03:53) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import defenvbug3.py first add ok Traceback (most recent call last): File "", line 1, in ? SystemError: NULL result without error in PyObject_Call >>> nicosys [231] whence python /usr/local/bin/python is actually /hda7/local/bin/python /usr/local/bin/python: ELF 32-bit LSB executable i386 (386 and up) Version 1 nicosys [232] ldd /hda7/local/bin/python libdl.so.2 => /lib/libdl.so.2 (0x40018000) libpthread.so.0 => /lib/libpthread.so.0 (0x4001d000) libutil.so.1 => /lib/libutil.so.1 (0x40030000) libm.so.6 => /lib/libm.so.6 (0x40033000) libc.so.6 => /lib/libc.so.6 (0x40052000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) nicosys [233] ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-06 10:47 Message: Logged In: YES user_id=356603 To answer your question, I am using 2.2b1, from the tarball not from CVS. In the second example, I get SystemError from the first call to add actually. I thought it was from the second one, but since I changed from my own exception class to Exception it became hidden. When I remove the uninteded self parameter of add, I get SystemError in the second call, as I thought I was getting. But you get TypeError.. hmmm.. I suppose I should download the CVS then?.. Or maybe wait for 2.2b2.. Sverker ps. Here's my updated second example, anyway.. import weakref ref = weakref.WeakKeyDictionary() class MyError(Exception): pass def add(self, x): raise MyError def encapsulate(): f = lambda : () ref[f] = None return f try: add(encapsulate()) except MyError: pass print 'first add ok' add(encapsulate()) # Here we would like to get Exception but gets SystemError instead. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-06 08:33 Message: Logged In: YES user_id=3066 I cannot reproduce this using either code snippet. Note that the second example should (and does for me) raise TypeError when calling add() -- you left in a "self" that appears to be unintended. Are you using 2.2b1 or CVS python? ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2001-11-05 23:17 Message: Logged In: YES user_id=356603 The same problem now occured in another situation. I am enclosing the condensed program. /Sverker ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478534&group_id=5470 From noreply@sourceforge.net Tue Dec 11 20:24:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 12:24:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-429329 ] actual-parameters *arg, **kws not doc'd Message-ID: Bugs item #429329, was opened at 2001-06-01 08:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429329&group_id=5470 Category: Documentation Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Alex Martelli (aleax) >Assigned to: Michael Hudson (mwh) Summary: actual-parameters *arg, **kws not doc'd Initial Comment: 5.3.4 in the language reference should document the forms *args and **kwds for actual parameters, but it makes no mention of them and does not allow for them in the syntax productions. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-11 12:24 Message: Logged In: YES user_id=3066 Michael, this is good. Please check this in and close this report. I really appreciate the help! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-11 09:35 Message: Logged In: YES user_id=6656 Ah! sf's error message for trying to attach an empty file (doh) could be more informative than "invalid filename"... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-11 08:17 Message: Logged In: YES user_id=6656 Oh, sod sf, I'll email it to python-docs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-11 08:17 Message: Logged In: YES user_id=6656 Here's an attempt. I haven't tried compiling it, as I haven't got that setup on this machine yet, but I think it should be OK. Fred may want to fix some markup. It does elevate some implementation accidents in the interaction of *args and keyword arguments to documented fact, which may or may not be what's wanted. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-11 08:16 Message: Logged In: YES user_id=6656 Here's an attempt. I haven't tried compiling it, as I haven't got that setup on this machine yet, but I think it should be OK. Fred may want to fix some markup. It does elevate some implementation accidents in the interaction of *args and keyword arguments to documented fact, which may or may not be what's wanted. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-06-06 15:46 Message: Logged In: YES user_id=31392 I made a little progress on this pre-parenthood. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-06-01 08:38 Message: Logged In: YES user_id=3066 Assigned to Jeremy, since he shepharded the patch into the Python release. Changes should be integrated with the 2.1.1 and head branches. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429329&group_id=5470 From noreply@sourceforge.net Tue Dec 11 20:42:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 12:42:10 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-490264 ] Portable compiler option specification Message-ID: Feature Requests item #490264, was opened at 2001-12-07 07:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=490264&group_id=5470 >Category: None >Group: None Status: Open Priority: 5 Submitted By: Konrad Hinsen (hinsen) >Assigned to: Nobody/Anonymous (nobody) Summary: Portable compiler option specification Initial Comment: Distutils should provide a portable way for packagers to specify common compiler options, e.g. "maximum optimization", "debugging symbols" etc. These should be per-module options that can be specified in the setup script. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=490264&group_id=5470 From noreply@sourceforge.net Tue Dec 11 20:45:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 12:45:00 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-490264 ] Portable compiler option specification Message-ID: Feature Requests item #490264, was opened at 2001-12-07 07:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=490264&group_id=5470 >Category: Distutils Group: None Status: Open Priority: 5 Submitted By: Konrad Hinsen (hinsen) Assigned to: Nobody/Anonymous (nobody) Summary: Portable compiler option specification Initial Comment: Distutils should provide a portable way for packagers to specify common compiler options, e.g. "maximum optimization", "debugging symbols" etc. These should be per-module options that can be specified in the setup script. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=490264&group_id=5470 From noreply@sourceforge.net Tue Dec 11 20:58:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 12:58:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-488730 ] os.popen() seg faults on FreeBSD 5 Message-ID: Bugs item #488730, was opened at 2001-12-03 21:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Marc Culler (marcculler) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen() seg faults on FreeBSD 5 Initial Comment: Here is the crash with Python 2.1.1 on my FreeBSD 5.0-current system: [ace:culler]$ python Python 2.1.1 (#5, Aug 18 2001, 17:41:43) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') Segmentation fault (core dumped) No problem occurs when I do the same thing in Python 2.0, which was compiled under FreeBSD 4, but is running here under FreeBSD 5: [ace:culler]$ python2.0 Python 2.0 (#2, Nov 16 2000, 22:22:48) [GCC 2.95.2 19991024 (release)] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') >>> mypipe.readlines() ['COPYRIGHT\012', 'bin\012', 'boot\012', 'cdrom\012', 'compat\012', 'dev\012', 'dist\012', 'entropy\012', 'etc\012', 'home\012', 'kernel\012', 'kernel.GENERIC\012', 'kernel.old\012', 'kernel.prev\012', 'mnt\012', 'modules\012', 'modules.old\012', 'proc\012', 'root\012', 'sbin\012', 'shared\012', 'stand\012', 'sys\012', 'tmp\012', 'usr\012', 'var\012'] >>> ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 12:58 Message: Logged In: YES user_id=21627 Can't reproduce this on FreeBSD 4.4, either, using the current CVS. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:18 Message: Logged In: YES user_id=6380 I can't reproduce this, and I don't have access to a FreeBSD 5 machine. Can you debug this yourself? We'd welcome a patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 From noreply@sourceforge.net Tue Dec 11 22:14:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 14:14:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-488730 ] os.popen() seg faults on FreeBSD 5 Message-ID: Bugs item #488730, was opened at 2001-12-03 21:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Marc Culler (marcculler) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen() seg faults on FreeBSD 5 Initial Comment: Here is the crash with Python 2.1.1 on my FreeBSD 5.0-current system: [ace:culler]$ python Python 2.1.1 (#5, Aug 18 2001, 17:41:43) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') Segmentation fault (core dumped) No problem occurs when I do the same thing in Python 2.0, which was compiled under FreeBSD 4, but is running here under FreeBSD 5: [ace:culler]$ python2.0 Python 2.0 (#2, Nov 16 2000, 22:22:48) [GCC 2.95.2 19991024 (release)] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') >>> mypipe.readlines() ['COPYRIGHT\012', 'bin\012', 'boot\012', 'cdrom\012', 'compat\012', 'dev\012', 'dist\012', 'entropy\012', 'etc\012', 'home\012', 'kernel\012', 'kernel.GENERIC\012', 'kernel.old\012', 'kernel.prev\012', 'mnt\012', 'modules\012', 'modules.old\012', 'proc\012', 'root\012', 'sbin\012', 'shared\012', 'stand\012', 'sys\012', 'tmp\012', 'usr\012', 'var\012'] >>> ---------------------------------------------------------------------- >Comment By: Marc Culler (marcculler) Date: 2001-12-11 14:14 Message: Logged In: YES user_id=392704 All I know so far is that, according to the stack trace, the crash seems to occur in _fcntl in libc_r.so: (gdb) run Starting program: /usr/local/src/Python211/python Python 2.1.1 (#14, Dec 11 2001, 15:55:41) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> x = os.popen('ls /') Program received signal SIGSEGV, Segmentation fault. 0x280e32ee in _fcntl () from /usr/lib/libc_r.so.5 (gdb) backtrace #0 0x280e32ee in _fcntl () from /usr/lib/libc_r.so.5 #1 0x28391c99 in fdopen () from /usr/lib/libc.so.5 #2 0x2834bf30 in popen () from /usr/lib/libc.so.5 #3 0x80735b1 in posix_popen (self=0x0, args=0x80f488c) at ./Modules/posixmodule.c:2936 #4 0x805921e in call_cfunction (func=0x80d0820, arg=0x80f488c, kw=0x0) at Python/ceval.c:2845 #5 0x8057cb1 in eval_code2 (co=0x8159ac0, globals=0x80e0ccc, locals=0x80e0ccc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:1948 #6 0x8055171 in PyEval_EvalCode (co=0x8159ac0, globals=0x80e0ccc, locals=0x80e0ccc) at Python/ceval.c:341 #7 0x806ca8f in run_node (n=0x8158280, filename=0x80a202d "", globals=0x80e0ccc, locals=0x80e0ccc, flags=0xbfbff70c) at Python/pythonrun.c:1045 #8 0x806bc86 in PyRun_InteractiveOneFlags (fp=0x80c93a0, filename=0x80a202d "", flags=0xbfbff70c) at Python/pythonrun.c:570 #9 0x806bae6 in PyRun_InteractiveLoopFlags (fp=0x80c93a0, filename=0x80a202d "", flags=0xbfbff70c) at Python/pythonrun.c:510 #10 0x806b9db in PyRun_AnyFileExFlags (fp=0x80c93a0, filename=0x80a202d "", closeit=0, flags=0xbfbff70c) at Python/pythonrun.c:473 #11 0x805222c in Py_Main (argc=0, argv=0xbfbff784) at Modules/main.c:320 #12 0x8051d04 in main (argc=1, argv=0xbfbff784) at Modules/python.c:10 #13 0x8051c35 in _start () ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 12:58 Message: Logged In: YES user_id=21627 Can't reproduce this on FreeBSD 4.4, either, using the current CVS. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:18 Message: Logged In: YES user_id=6380 I can't reproduce this, and I don't have access to a FreeBSD 5 machine. Can you debug this yourself? We'd welcome a patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 From noreply@sourceforge.net Tue Dec 11 22:28:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 14:28:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-488730 ] os.popen() seg faults on FreeBSD 5 Message-ID: Bugs item #488730, was opened at 2001-12-03 21:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Marc Culler (marcculler) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen() seg faults on FreeBSD 5 Initial Comment: Here is the crash with Python 2.1.1 on my FreeBSD 5.0-current system: [ace:culler]$ python Python 2.1.1 (#5, Aug 18 2001, 17:41:43) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') Segmentation fault (core dumped) No problem occurs when I do the same thing in Python 2.0, which was compiled under FreeBSD 4, but is running here under FreeBSD 5: [ace:culler]$ python2.0 Python 2.0 (#2, Nov 16 2000, 22:22:48) [GCC 2.95.2 19991024 (release)] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') >>> mypipe.readlines() ['COPYRIGHT\012', 'bin\012', 'boot\012', 'cdrom\012', 'compat\012', 'dev\012', 'dist\012', 'entropy\012', 'etc\012', 'home\012', 'kernel\012', 'kernel.GENERIC\012', 'kernel.old\012', 'kernel.prev\012', 'mnt\012', 'modules\012', 'modules.old\012', 'proc\012', 'root\012', 'sbin\012', 'shared\012', 'stand\012', 'sys\012', 'tmp\012', 'usr\012', 'var\012'] >>> ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 14:28 Message: Logged In: YES user_id=6380 Marc, the Python popen code (if you can see through the #ifdefs for non-Unix platforms :-) is a pretty straightforward call of the C library popen(). The crash you receive suggests that it has nothing to do with Python. Can you try a C program containing the same call? Something like #include main() { popen("ls -l", "r"); } Does this crash in the same way? If so, you may close this bug report and report it to the FreeBSD folks instead... ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-11 14:14 Message: Logged In: YES user_id=392704 All I know so far is that, according to the stack trace, the crash seems to occur in _fcntl in libc_r.so: (gdb) run Starting program: /usr/local/src/Python211/python Python 2.1.1 (#14, Dec 11 2001, 15:55:41) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> x = os.popen('ls /') Program received signal SIGSEGV, Segmentation fault. 0x280e32ee in _fcntl () from /usr/lib/libc_r.so.5 (gdb) backtrace #0 0x280e32ee in _fcntl () from /usr/lib/libc_r.so.5 #1 0x28391c99 in fdopen () from /usr/lib/libc.so.5 #2 0x2834bf30 in popen () from /usr/lib/libc.so.5 #3 0x80735b1 in posix_popen (self=0x0, args=0x80f488c) at ./Modules/posixmodule.c:2936 #4 0x805921e in call_cfunction (func=0x80d0820, arg=0x80f488c, kw=0x0) at Python/ceval.c:2845 #5 0x8057cb1 in eval_code2 (co=0x8159ac0, globals=0x80e0ccc, locals=0x80e0ccc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:1948 #6 0x8055171 in PyEval_EvalCode (co=0x8159ac0, globals=0x80e0ccc, locals=0x80e0ccc) at Python/ceval.c:341 #7 0x806ca8f in run_node (n=0x8158280, filename=0x80a202d "", globals=0x80e0ccc, locals=0x80e0ccc, flags=0xbfbff70c) at Python/pythonrun.c:1045 #8 0x806bc86 in PyRun_InteractiveOneFlags (fp=0x80c93a0, filename=0x80a202d "", flags=0xbfbff70c) at Python/pythonrun.c:570 #9 0x806bae6 in PyRun_InteractiveLoopFlags (fp=0x80c93a0, filename=0x80a202d "", flags=0xbfbff70c) at Python/pythonrun.c:510 #10 0x806b9db in PyRun_AnyFileExFlags (fp=0x80c93a0, filename=0x80a202d "", closeit=0, flags=0xbfbff70c) at Python/pythonrun.c:473 #11 0x805222c in Py_Main (argc=0, argv=0xbfbff784) at Modules/main.c:320 #12 0x8051d04 in main (argc=1, argv=0xbfbff784) at Modules/python.c:10 #13 0x8051c35 in _start () ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 12:58 Message: Logged In: YES user_id=21627 Can't reproduce this on FreeBSD 4.4, either, using the current CVS. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:18 Message: Logged In: YES user_id=6380 I can't reproduce this, and I don't have access to a FreeBSD 5 machine. Can you debug this yourself? We'd welcome a patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 From noreply@sourceforge.net Tue Dec 11 22:41:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 14:41:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-482171 ] webchecker dies on file: URLs w/o robots Message-ID: Bugs item #482171, was opened at 2001-11-15 09:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482171&group_id=5470 Category: Demos and Tools Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: Guido van Rossum (gvanrossum) Summary: webchecker dies on file: URLs w/o robots Initial Comment: When webchecker is run on local documents using a file: URL, it dies if there is not a robots.txt in the root directory: cj42289-a(.../python/Doc); python ../Tools/webchecker/webchecker.py file:`pwd`/html/api/ webchecker version 1.24 Traceback (most recent call last): File "../Tools/webchecker/webchecker.py", line 858, in ? main() File "../Tools/webchecker/webchecker.py", line 205, in main c.addroot(arg) File "../Tools/webchecker/webchecker.py", line 324, in addroot self.addrobot(root) File "../Tools/webchecker/webchecker.py", line 337, in addrobot rp.read() File "/usr/local/lib/python2.2/robotparser.py", line 43, in read f = opener.open(self.url) File "/usr/local/lib/python2.2/urllib.py", line 178, in open return getattr(self, name)(url) File "/usr/local/lib/python2.2/urllib.py", line 405, in open_file return self.open_local_file(url) File "/usr/local/lib/python2.2/urllib.py", line 412, in open_local_file stats = os.stat(localname) OSError: [Errno 2] No such file or directory: '/robots.txt' ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 14:41 Message: Logged In: YES user_id=6380 Fixed in webchecker.py rev. 1.25. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482171&group_id=5470 From noreply@sourceforge.net Tue Dec 11 22:46:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 14:46:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-445815 ] urllib doesn't handle proxy exceptions Message-ID: Bugs item #445815, was opened at 2001-07-29 19:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445815&group_id=5470 >Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dylan Jay (djsq) Assigned to: Nobody/Anonymous (nobody) Summary: urllib doesn't handle proxy exceptions Initial Comment: When using urllib in a firewall environment when a proxy is set, the proxy will be used for all connections regardless of if the host is located inside or outside the firewall. Localhost is a good example of this. Under a windows environment the registry contains a proxy exception list which contains patterns which match hosts that should not be directed through the proxy. This should be used. Under other environments perhaps an environment variable be used to determine the exceptions eg http_proxy_expceptions = "*.mydomain.com;*.myotherdomain.com" Localhost should never be directed through a proxy. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 14:46 Message: Logged In: YES user_id=6380 I think there's code in urllib.py that tries to do exactly wht you're saying. It's towards the end of urllib.py, after "elif os.name == 'nt':". Can you perhaps instrument that code with a few print statements to see why it doesn't do what you expect? I can't debug this because we don't have a proxy set up here, and I have no idea how to configure this information on Windows. It might help if you explained is which Windows version (95, 98, 2K, ME, XT?), of if you have experienced this on multiple Windows versions. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445815&group_id=5470 From noreply@sourceforge.net Tue Dec 11 22:47:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 14:47:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-476858 ] Assignment to () should be legal Message-ID: Bugs item #476858, was opened at 2001-10-31 10:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476858&group_id=5470 Category: Parser/Compiler Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Guido van Rossum (gvanrossum) >Assigned to: Guido van Rossum (gvanrossum) Summary: Assignment to () should be legal Initial Comment: >From c.l.py: Currently, () = x gives a compile-time error. This should really be allowed (and require that x is an empty sequence, of course) as an end case of (a,b,c) = x # x must be a 3-sequence (a,b) = x # x must be a 2-sequence (a,) = x # x must be a 1-sequence () = x # why can't x be z 0-sequence? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 14:47 Message: Logged In: YES user_id=6380 I takeit back. Let's not do this. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 15:08 Message: Logged In: YES user_id=3066 Ugh. Sounds terrible, tastes like soap. Let's not allow this. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-10-31 12:39 Message: Logged In: YES user_id=44345 I won't try and counter Tim's vote (besides, he's already got Guido's 51% vote to contend with), but just provide an example used in c.l.py. You might have a function that can return a possibly-empty tuple as part of a larger sequence, e.g.: def contrived(a, *args): return (len(args), args*a) (foo, (bar,)) = contrived(1,2,3) (foo, ()) = contrived(0,1,2) Some folks view this as useful. I reserve judgement on that. ;-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-31 10:37 Message: Logged In: YES user_id=31435 -1. "Assignment statements are used to (re)bind names to values and to modify attributes or items of mutable objects" (from the Ref Man). Since the degenerate cases (don't forget "[] = x" too) don't do that, they're not "assignment statements" in a meanignful sense; they would just be a surprising way to spell if tuple(x): raise ValueError That isn't a frequent enough need to deserve special syntax. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476858&group_id=5470 From noreply@sourceforge.net Tue Dec 11 22:50:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 14:50:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-487277 ] Different behavior of readline() Message-ID: Bugs item #487277, was opened at 2001-11-29 14:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487277&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Nobody/Anonymous (nobody) Summary: Different behavior of readline() Initial Comment: The behavior of readline() has changed on 2.2. This should be documented. Example: Python 2.1 (#1, Jun 22 2001, 17:13:13) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-i386 Type "copyright", "credits" or "license" for more information. >>> open("/etc").readline() '' Python 2.2b2+ (#1, Nov 27 2001, 21:39:35) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-ppc Type "help", "copyright", "credits" or "license" for more information. >>> open("/etc").readline() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 14:50 Message: Logged In: YES user_id=6380 Are we even sure that open("/") should be disallowed? What if it is used as an existence test? What is allowed by open() should be the realm of the stdio fopen() function, and we shouldn't second-guess it. If fopen() allows us to open directories, why shouldn't we? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-03 06:22 Message: Logged In: YES user_id=21627 Yes, changing it later is fine. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-03 05:03 Message: Logged In: YES user_id=6380 I take it that this needn't be included in 2.2? Who knows what it would break. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-03 01:02 Message: Logged In: YES user_id=21627 I agree that Python should not allow to open a directory. Attached is a patch that implements this check; it is somewhat more involved since it must also check file object that are created through PyFile_FromFile etc. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-02 12:18 Message: Logged In: YES user_id=31435 Well, my question isn't really about libc but about Python: since Python doesn't expose getdents(2) or readdir (2), how could it be anything but a mistake for a Python user on Linux to try to __builtin__.open() a directory? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 05:16 Message: Logged In: YES user_id=21627 Opening a directory is the only way, on Unix, to get its contents. The file descriptor returned is then passed to getdents(2) or readdir(2) (depending on the OS version). __builtins__.open doesn't fail because it calls fopen right away, which doesn't fail because it calls open(2) with just O_RDONLY and O_LARGEFILE, not with O_DIRECTORY. open(2) will then only return EISDIR if the directory is opened for writing. Since this is the behaviour documented in Posix, it is unlikely that Linux glibc will change. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 14:44 Message: Logged In: YES user_id=38388 For the record, this is what I get with Python 2.2b2 on Linux: >>> f = open('/home/lemburg/') >>> f.read() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory >>> f.readline() '' >>> f.readlines() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory >>> Reading the man-page for open(), it seems that directories play some role (though it's not clear which...): open() options: ... O_DIRECTORY If pathname is not a directory, cause the open to fail. This flag is Linux-specific, and was added in kernel version 2.1.126, to avoid denial-of-ser­ vice problems if opendir(3) is called on a FIFO or tape device, but should not be used outside of the implementation of opendir. errno values: ... EISDIR pathname refers to a directory and the access requested involved writing. EACCES The requested access to the file is not allowed, or one of the directories in pathname did not allow search (execute) permission, or the file did not exist yet and write access to the parent directory is not allowed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-30 14:26 Message: Logged In: YES user_id=31435 Does anyone know why opening a directory for reading doesn't complain on Linux? It has always complained on Windows. If readline() is doomed to fail, why do we allow opening a directory for reading at all? OTOH, if it's not insane to open a directory for reading on Linux, why does readline() complain on Linux? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 08:07 Message: Logged In: YES user_id=21627 No. I think very few of the changes will ever cause problems in real software - including this one. I wouldn't be surprised if this remains the only reported incidence of that change. I *am* saying that for every change that has been made, one could construct an application that breaks under this change. This theoretical potential for breakage shouldn't cause prominent appearance in documentation; everybody who really wants to see documentation for all changes should consult the CVS logs. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-11-30 06:15 Message: Logged In: YES user_id=7887 I beg your pardon. Are you saying that there are many changes in Python 2.2 that will blow up code written in Python 2.1!? Why do we have __future__ than!? Why are we concerned about being careful with division upgrade when we have lots of small stuff breaking up *valid* code written one release ago? And, if this was not enough, these changes won't even be documented!?! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 04:21 Message: Logged In: YES user_id=21627 Well, I wouldn't object to anybody documenting this particular change (even though I won't do that myself, either). I'm just pointing out that there are many more changes of this kind, and that it would be an illusion that you could ever produce a complete list. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 01:36 Message: Logged In: YES user_id=38388 I disagree: any change which could potentially blow up existing programs should at least be mentioned somewhere in the docs, be it the NEWS file, the release page on python.org or (thanks to the great work of Andrew Kuchling) the "What's new in Python x.x" docs. This is simply needed due to the very dynamic way Python works: there's no way to test all paths through a program if you want to port it from one Python version to the next, so we'll have to be very careful about these changes even if they are clearly bug fixes. In the mentioned case, I'd say that the programmer was at fault, though: it's so much easier to test a path for being a directory than to rely on some obscure method return value and also much safer ! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 01:19 Message: Logged In: YES user_id=21627 Any change is user-visible: for any change, I can construct a program that behaves differently with the change. Otherwise, the change would be useless (except that it may add commentary or some such). In fact, the change *is* documented, namely in the CVS log. Extracting all those fragments into a single document would be time-consuming and pointless: nobody can read through hundreds of changes. Your program would have blown up even if there was such a document. If a change has severe effects on many existing programs, it should be implemented differently. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-11-29 16:10 Message: Logged In: YES user_id=7887 I think *any* change visible at user space should be documented. I discovered this change because a program I have never read in my life (in fact, I didn't even know it was written in python) has blown up in my hands. It was reading files and safely ignoring directories by testing readline()'s output. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-29 15:53 Message: Logged In: YES user_id=21627 I don't think this needs to be documented. The change is a bug fix, reading from a directory was never supposed to work (whether in lines or not). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487277&group_id=5470 From noreply@sourceforge.net Tue Dec 11 22:51:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 14:51:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-487703 ] Replace strcat, strcpy Message-ID: Bugs item #487703, was opened at 2001-11-30 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487703&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Replace strcat, strcpy Initial Comment: Alex Martelli sent this URL for a paper describing the safer strlcat and strlcpy functions: >http://www.usenix.org/events/usenix99/full_papers/mill ert/millert_html/> ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 14:51 Message: Logged In: YES user_id=6380 Strictly speaking, binary Python distributions would be required to contain a copy of the entire license for that file. I don't like that. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-03 10:59 Message: Logged In: YES user_id=31435 I'm attaching a patch from Alex Martelli; haven't reviewed it, and don't expect to before 2.2 final is released. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-03 02:47 Message: Logged In: YES user_id=38388 Time for PyOS_strlcat() and PyOS_strlcpy() ? Looking at the web-site it seems that we could simply copy the code into the Python distro. I'd then suggest to bundle all the string helpers into a new file: e.g. mystrapis.c. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487703&group_id=5470 From noreply@sourceforge.net Tue Dec 11 22:52:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 14:52:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-227699 ] Memory leaks using imp.load_module Message-ID: Bugs item #227699, was opened at 2001-01-05 12:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=227699&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Charles G Waldman (cgw) >Assigned to: Nobody/Anonymous (nobody) Summary: Memory leaks using imp.load_module Initial Comment: #!/usr/bin/env python import os import sys import imp print os.getpid() sys.path.append("/tmp") count = 0 while (count<1000): modname = "testmod%s" % count count = count + 1 filename = '/tmp/' + modname + '.py' f = open(filename, 'w') for x in range(10000): f.write('x%s=%s\n'%(x,x)) f.close() modinfo = imp.find_module(modname) print 'loading', modname m = apply(imp.load_module, ('testmod',) + modinfo) ## run "watch -n 1 ps up ## where is the pid printed out by this program ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 17:42 Message: Logged In: YES user_id=6380 Using the PYTHONDUMPREFS=1 environment variable and the debug version of Python, I don't see this leaking objects except that all the file names ('/tmp/testmod0.py' etc.) seem to be saved as interned strings, which eternalizes them of course. Hm, I wonder why the filename is interned? (I ran it twice, with different counts (100 and 1000), and 1000 instead of 10,000 variables, saving the PYTHONDUMPREFS output to two different files; then diffed the output files.) So if it's leaking beyond this, it's not in the form of objects. And note that Insure++ (or any leak detection tool worth the name) doesn't consider interned strings leaks -- they are reachable via a global variable. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 16:28 Message: Logged In: YES user_id=6380 Barry, note that he's cheating with the module name passed to load_module(): the module name is always set to 'testmod', so he's in fact overwriting the module on each load. (This acts the same way as reload(), so it's not creating new module objects -- it's loading the code in the same namespace over and over.) I see the process size grow very quickly to 15M, probably on account of the huge parse tree for those 10,000 assignment statements (much less for the 10,000 actual variables created). After that it gradually grows -- after 100 loads it's up to 27 M. Maybe Insure doesn't see this because the data is actually kept alive somewhere? ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-10-18 15:30 Message: Logged In: YES user_id=12800 I'm having a hard time tracking down the leak. I don't believe it's at the C layer since preliminary Insure runs don't indicate any leaked blocks (there are plenty of inuse blocks, but those generally don't count). I will note that if you comment out the imp.load_module call the memory usage remains constant. Loading each module though is going to naturally consume more memory, right? And those loaded modules aren't ever going to get freed, at least without mucking about in sys.modules. The memory consumption with ps is pretty meager, so I suspect we don't have a valid leak here, but just normal memory consumption due to importation of 10k modules. I'm running a more detailed insure run right now just to be sure, but I'm skeptical that there's really a bug here. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-02-23 11:53 Message: I can verify that memory grows with this process. I will run it under insure to get more information. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-18 19:43 Message: Barry...?!?! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-01-07 15:32 Message: Assigned to Barry since he's the memory leak expert (& has the right tools). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=227699&group_id=5470 From noreply@sourceforge.net Tue Dec 11 22:53:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 14:53:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-472642 ] interpreter crash when import .so fails w/ Purify Message-ID: Bugs item #472642, was opened at 2001-10-18 20:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472642&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None >Priority: 3 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: interpreter crash when import .so fails w/ Purify Initial Comment: The python interpreter crashes when import _socket fails (.so). This only happens when running purify (on solaris 2.8). The problem is that dlerror() returns NULL, which is then passed to strlen(). Attached is a file with the stack trace which caused the problem, and a patch to fix the problem. Neal ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-19 06:49 Message: Logged In: YES user_id=6380 Note that Neal mentions Purify as a condition. I've added that to the subject. Could Purify somehow be screwing dlerror()? Not much we can do about that... On the one hand it seems wrong that PyErr_SetString() should be patched; on the other hand there's nothing wrong with making that function a bit more robust. I give the patch a +0. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 23:33 Message: Logged In: YES user_id=21627 I find it surprising that dlerror returns NULL. According to dlerror(3DL), it will only return NULL if there was no error since the last call to dlerror. Since handle is NULL, there certainly was an error very recently (in the dlopen), and I cannot see any dlerror call in-between. In any case, your patch seems to be wrong: the bug is that dlerror returns NULL when it shouldn't. If we really need to work around this bug (which I'm not convinced that we should), then the work-around is to pass a non-null constant string to PyErr_SetString if dlerror returned null. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472642&group_id=5470 From noreply@sourceforge.net Tue Dec 11 23:04:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 15:04:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-453523 ] list.sort crasher Message-ID: Bugs item #453523, was opened at 2001-08-20 15:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453523&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None >Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Nobody/Anonymous (nobody) Summary: list.sort crasher Initial Comment: The marshal module is on the default list of ok builtin modules, but it can be used to crash the interpreter. The new module, on the other hand, is not allowed. To me the only obvious reason for this is that it provides a way to make new code objects, which can then crash the interpreter. But marshal also gives this ability. Example is attached as a file. Having imported marshal, I use marshal.loads() on a carefully constructed string to get a corrupt code object. To work out this string: (in unrestricted mode) def f(): pass import marshal badstring=marshal.dumps(f.func_code).replace('(\x01\x00\x00\x00N', '(\x00\x00\x00\x00') which when loaded gives a code object with co_consts = (). Possible fixes: Easy: remove marshal from the list of approved modules for restricted execution. Hard: Fix marshal (and perhaps new) by adding checks on code objects before returning them. Probably no way to do this exhaustively. Lateral thinking: prohibit exec in restricted mode? (Currently eval() also allows execution of code objects, so that would have to be changed too.) I think this is a nice complement to the existing features of restricted execution mode, which prevent the attachment of a new code object to a function. On the other hand, there's not much point fixing this unless other methods of crashing the interpreter are also hunted down... >>> class C: ... def __cmp__(self, other): ... pop(0) ... return 1 ... >>> gl = [C() for i in '1'*20] >>> pop=gl.pop >>> gl.sort() Segmentation fault (core dumped) (should I submit this as a separate bug report?) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 15:04 Message: Logged In: YES user_id=6380 Sigh. I wished I'd picked this up earlier, but I haven't. After 2.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-04 11:43 Message: Logged In: YES user_id=6380 I'm not so interested in the list.sort crasher, so I'm lowering the priority and unassigning it. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-30 07:51 Message: Logged In: YES user_id=6656 OK, done, in: marshal.c version 1.67 Changed summary. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-30 05:48 Message: Logged In: YES user_id=6380 Michael's patch is fine -- the code-loading is not done in restricted mode (but the execution is, because the restricted globals are passed). Michael, can you check it in? The list issue could be fixed by adding a PyList_Check() call to each list method implementation (or at least to the mutating ones). But is it sufficient? I believe there are plenty of other ways to cause a crash -- stack overflow is one, and I think marshal itself can also crash on corrupt input. Greg's bug report points out that rexec is far from sufficient to deter a real hacker. Imagine that this was used in a popular email program... :-( If we can't deprecate rexec, perhaps we should add very big warnings to the documentation that it can't be trusted against truly hostile users. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-29 23:45 Message: Logged In: YES user_id=31435 Reassigning to Guido. The patch stops marshal from loading a code object when in restricted mode, but I have no feel for whether that's going to be a serious limitation for restricted mode (which I've never used for real). For example, wouldn't this also stop regular old imports from .pyc files? I'd hate for restricted users to be barred from importing tabnanny . The list-crasher is a different issue, but I went over *my* limit for caring about trying to foil hostile users when we added the immutable list type. That trick doesn't help here (the mutating mutable-list method is captured in a bound method object before the sort is invoked). I suppose we could instead check that the list base address and length haven't changed after every compare -- but with N*log(N) compares, that's a significant expense the immutable list trick was trying to get away from. Not worth it to me, but my native interest in competing with hostile users is admittedly undetectable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-25 00:25 Message: Logged In: YES user_id=6656 I think a reasonable approach to the first problem is to not let marshal load code objects when in restricted execution mode. The second crasher you mention is much more worrying, to me. I think it blows the "immutable list trick" out of the water. I'll attach a patch to marshal (from another machine) and assign to Tim to think about the list nagery. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453523&group_id=5470 From noreply@sourceforge.net Tue Dec 11 23:11:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 15:11:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-488730 ] os.popen() seg faults on FreeBSD 5 Message-ID: Bugs item #488730, was opened at 2001-12-03 21:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Marc Culler (marcculler) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen() seg faults on FreeBSD 5 Initial Comment: Here is the crash with Python 2.1.1 on my FreeBSD 5.0-current system: [ace:culler]$ python Python 2.1.1 (#5, Aug 18 2001, 17:41:43) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') Segmentation fault (core dumped) No problem occurs when I do the same thing in Python 2.0, which was compiled under FreeBSD 4, but is running here under FreeBSD 5: [ace:culler]$ python2.0 Python 2.0 (#2, Nov 16 2000, 22:22:48) [GCC 2.95.2 19991024 (release)] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') >>> mypipe.readlines() ['COPYRIGHT\012', 'bin\012', 'boot\012', 'cdrom\012', 'compat\012', 'dev\012', 'dist\012', 'entropy\012', 'etc\012', 'home\012', 'kernel\012', 'kernel.GENERIC\012', 'kernel.old\012', 'kernel.prev\012', 'mnt\012', 'modules\012', 'modules.old\012', 'proc\012', 'root\012', 'sbin\012', 'shared\012', 'stand\012', 'sys\012', 'tmp\012', 'usr\012', 'var\012'] >>> ---------------------------------------------------------------------- >Comment By: Marc Culler (marcculler) Date: 2001-12-11 15:11 Message: Logged In: YES user_id=392704 Yes, I thought it looked like it was a FreeBSD bug too. Unfortunately, though, my little test program produced a nice listing of my / directory. I still think it is FreeBSD's problem, but it is at least a little bit subtle. I suppose I should build the latest FreeBSD sources before proceeding any further with this. #include int main(){ int c; FILE *fp; fp = popen("ls /", "r"); if (fp == NULL) { fprintf(stderr, "popen returned NULL\n"); exit(-1); } while ((c = getc(fp)) != EOF) { putchar(c); } printf("\nDone\n"); exit(0); } ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 14:28 Message: Logged In: YES user_id=6380 Marc, the Python popen code (if you can see through the #ifdefs for non-Unix platforms :-) is a pretty straightforward call of the C library popen(). The crash you receive suggests that it has nothing to do with Python. Can you try a C program containing the same call? Something like #include main() { popen("ls -l", "r"); } Does this crash in the same way? If so, you may close this bug report and report it to the FreeBSD folks instead... ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-11 14:14 Message: Logged In: YES user_id=392704 All I know so far is that, according to the stack trace, the crash seems to occur in _fcntl in libc_r.so: (gdb) run Starting program: /usr/local/src/Python211/python Python 2.1.1 (#14, Dec 11 2001, 15:55:41) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> x = os.popen('ls /') Program received signal SIGSEGV, Segmentation fault. 0x280e32ee in _fcntl () from /usr/lib/libc_r.so.5 (gdb) backtrace #0 0x280e32ee in _fcntl () from /usr/lib/libc_r.so.5 #1 0x28391c99 in fdopen () from /usr/lib/libc.so.5 #2 0x2834bf30 in popen () from /usr/lib/libc.so.5 #3 0x80735b1 in posix_popen (self=0x0, args=0x80f488c) at ./Modules/posixmodule.c:2936 #4 0x805921e in call_cfunction (func=0x80d0820, arg=0x80f488c, kw=0x0) at Python/ceval.c:2845 #5 0x8057cb1 in eval_code2 (co=0x8159ac0, globals=0x80e0ccc, locals=0x80e0ccc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:1948 #6 0x8055171 in PyEval_EvalCode (co=0x8159ac0, globals=0x80e0ccc, locals=0x80e0ccc) at Python/ceval.c:341 #7 0x806ca8f in run_node (n=0x8158280, filename=0x80a202d "", globals=0x80e0ccc, locals=0x80e0ccc, flags=0xbfbff70c) at Python/pythonrun.c:1045 #8 0x806bc86 in PyRun_InteractiveOneFlags (fp=0x80c93a0, filename=0x80a202d "", flags=0xbfbff70c) at Python/pythonrun.c:570 #9 0x806bae6 in PyRun_InteractiveLoopFlags (fp=0x80c93a0, filename=0x80a202d "", flags=0xbfbff70c) at Python/pythonrun.c:510 #10 0x806b9db in PyRun_AnyFileExFlags (fp=0x80c93a0, filename=0x80a202d "", closeit=0, flags=0xbfbff70c) at Python/pythonrun.c:473 #11 0x805222c in Py_Main (argc=0, argv=0xbfbff784) at Modules/main.c:320 #12 0x8051d04 in main (argc=1, argv=0xbfbff784) at Modules/python.c:10 #13 0x8051c35 in _start () ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 12:58 Message: Logged In: YES user_id=21627 Can't reproduce this on FreeBSD 4.4, either, using the current CVS. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:18 Message: Logged In: YES user_id=6380 I can't reproduce this, and I don't have access to a FreeBSD 5 machine. Can you debug this yourself? We'd welcome a patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 From noreply@sourceforge.net Tue Dec 11 23:11:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 15:11:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-445815 ] urllib doesn't handle proxy exceptions Message-ID: Bugs item #445815, was opened at 2001-07-29 19:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445815&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dylan Jay (djsq) Assigned to: Nobody/Anonymous (nobody) Summary: urllib doesn't handle proxy exceptions Initial Comment: When using urllib in a firewall environment when a proxy is set, the proxy will be used for all connections regardless of if the host is located inside or outside the firewall. Localhost is a good example of this. Under a windows environment the registry contains a proxy exception list which contains patterns which match hosts that should not be directed through the proxy. This should be used. Under other environments perhaps an environment variable be used to determine the exceptions eg http_proxy_expceptions = "*.mydomain.com;*.myotherdomain.com" Localhost should never be directed through a proxy. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-11 15:11 Message: Logged In: NO ok, there are really two problems here 1. If I have a proxy set and I go say print urllib.urlopen("http://localhost").read() I go to localhost.com outside the firewall. This is because urllib is not recognizing 'localhost' as a special case. 2. There is no way to override the default behaviour of always using a proxy when it is available. At least under windows, if urllib can find the registry entries for the proxy it will use them whether you want to or not. The solutions I can see are as follows 1. I think the special case handling for 'localhost' is broken. localhost should always resolve to the local computer regardless of presence of a proxy. 2. There are a couple of options here. - extra arguments on url calls - setting modes on urllib - or being able to set up internal link patterns (as suggested in my orginal post). The latter is what windows internet explorer does (I think netscape too). You specify a simple pattern that if the domain matches, will result in the url call being made locally without the use of the proxy. This information is already in the windows registery so that would be the ideal place to get this information on the windows platform. On other platforms I would suggest an evornonment variable. PS. The code you reference just gets the normal proxy information. Not the proxy exception information. PPS. I tested this behaviour on win2k, python 2.1 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 14:46 Message: Logged In: YES user_id=6380 I think there's code in urllib.py that tries to do exactly wht you're saying. It's towards the end of urllib.py, after "elif os.name == 'nt':". Can you perhaps instrument that code with a few print statements to see why it doesn't do what you expect? I can't debug this because we don't have a proxy set up here, and I have no idea how to configure this information on Windows. It might help if you explained is which Windows version (95, 98, 2K, ME, XT?), of if you have experienced this on multiple Windows versions. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445815&group_id=5470 From noreply@sourceforge.net Tue Dec 11 23:43:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 15:43:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-488730 ] os.popen() seg faults on FreeBSD 5 Message-ID: Bugs item #488730, was opened at 2001-12-03 21:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Marc Culler (marcculler) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen() seg faults on FreeBSD 5 Initial Comment: Here is the crash with Python 2.1.1 on my FreeBSD 5.0-current system: [ace:culler]$ python Python 2.1.1 (#5, Aug 18 2001, 17:41:43) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') Segmentation fault (core dumped) No problem occurs when I do the same thing in Python 2.0, which was compiled under FreeBSD 4, but is running here under FreeBSD 5: [ace:culler]$ python2.0 Python 2.0 (#2, Nov 16 2000, 22:22:48) [GCC 2.95.2 19991024 (release)] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') >>> mypipe.readlines() ['COPYRIGHT\012', 'bin\012', 'boot\012', 'cdrom\012', 'compat\012', 'dev\012', 'dist\012', 'entropy\012', 'etc\012', 'home\012', 'kernel\012', 'kernel.GENERIC\012', 'kernel.old\012', 'kernel.prev\012', 'mnt\012', 'modules\012', 'modules.old\012', 'proc\012', 'root\012', 'sbin\012', 'shared\012', 'stand\012', 'sys\012', 'tmp\012', 'usr\012', 'var\012'] >>> ---------------------------------------------------------------------- >Comment By: Marc Culler (marcculler) Date: 2001-12-11 15:43 Message: Logged In: YES user_id=392704 As to the subtlety of this bug, I meant to point out that Python 2.0, which presumably has a nearly identical posix module, has a working os.popen(). On the other hand, Python2.0 loads libc_r.so.4 rather than libc_r.so.5. So maybe that is where the secret lies. Interestingly, the size of that library has gone from 664784 to 108988. That suggests that there were some rather major changes there, doesn't it? ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-11 15:11 Message: Logged In: YES user_id=392704 Yes, I thought it looked like it was a FreeBSD bug too. Unfortunately, though, my little test program produced a nice listing of my / directory. I still think it is FreeBSD's problem, but it is at least a little bit subtle. I suppose I should build the latest FreeBSD sources before proceeding any further with this. #include int main(){ int c; FILE *fp; fp = popen("ls /", "r"); if (fp == NULL) { fprintf(stderr, "popen returned NULL\n"); exit(-1); } while ((c = getc(fp)) != EOF) { putchar(c); } printf("\nDone\n"); exit(0); } ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 14:28 Message: Logged In: YES user_id=6380 Marc, the Python popen code (if you can see through the #ifdefs for non-Unix platforms :-) is a pretty straightforward call of the C library popen(). The crash you receive suggests that it has nothing to do with Python. Can you try a C program containing the same call? Something like #include main() { popen("ls -l", "r"); } Does this crash in the same way? If so, you may close this bug report and report it to the FreeBSD folks instead... ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-11 14:14 Message: Logged In: YES user_id=392704 All I know so far is that, according to the stack trace, the crash seems to occur in _fcntl in libc_r.so: (gdb) run Starting program: /usr/local/src/Python211/python Python 2.1.1 (#14, Dec 11 2001, 15:55:41) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> x = os.popen('ls /') Program received signal SIGSEGV, Segmentation fault. 0x280e32ee in _fcntl () from /usr/lib/libc_r.so.5 (gdb) backtrace #0 0x280e32ee in _fcntl () from /usr/lib/libc_r.so.5 #1 0x28391c99 in fdopen () from /usr/lib/libc.so.5 #2 0x2834bf30 in popen () from /usr/lib/libc.so.5 #3 0x80735b1 in posix_popen (self=0x0, args=0x80f488c) at ./Modules/posixmodule.c:2936 #4 0x805921e in call_cfunction (func=0x80d0820, arg=0x80f488c, kw=0x0) at Python/ceval.c:2845 #5 0x8057cb1 in eval_code2 (co=0x8159ac0, globals=0x80e0ccc, locals=0x80e0ccc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:1948 #6 0x8055171 in PyEval_EvalCode (co=0x8159ac0, globals=0x80e0ccc, locals=0x80e0ccc) at Python/ceval.c:341 #7 0x806ca8f in run_node (n=0x8158280, filename=0x80a202d "", globals=0x80e0ccc, locals=0x80e0ccc, flags=0xbfbff70c) at Python/pythonrun.c:1045 #8 0x806bc86 in PyRun_InteractiveOneFlags (fp=0x80c93a0, filename=0x80a202d "", flags=0xbfbff70c) at Python/pythonrun.c:570 #9 0x806bae6 in PyRun_InteractiveLoopFlags (fp=0x80c93a0, filename=0x80a202d "", flags=0xbfbff70c) at Python/pythonrun.c:510 #10 0x806b9db in PyRun_AnyFileExFlags (fp=0x80c93a0, filename=0x80a202d "", closeit=0, flags=0xbfbff70c) at Python/pythonrun.c:473 #11 0x805222c in Py_Main (argc=0, argv=0xbfbff784) at Modules/main.c:320 #12 0x8051d04 in main (argc=1, argv=0xbfbff784) at Modules/python.c:10 #13 0x8051c35 in _start () ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 12:58 Message: Logged In: YES user_id=21627 Can't reproduce this on FreeBSD 4.4, either, using the current CVS. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:18 Message: Logged In: YES user_id=6380 I can't reproduce this, and I don't have access to a FreeBSD 5 machine. Can you debug this yourself? We'd welcome a patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 From noreply@sourceforge.net Tue Dec 11 23:52:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 15:52:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-491820 ] asynchat.async_chat missing methods Message-ID: Bugs item #491820, was opened at 2001-12-11 15:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491820&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat.async_chat missing methods Initial Comment: asynchat.ascync_chat is an abstract class. To use it you have to subclass it and define (at least) collect_incoming_data and found_terminator. These methods are both called from other asynchat_chat methods. They should probably be defined to raise NotImplementedError. This shuts up a couple pychecker errors, but more importantly, makes it obvious to people reading the source code or running pydoc that they are part of the formal interface. I can't check anything in right now, but here are a couple methods that I think should work. def collect_incoming_data(self, data): raise NotImplementedError, "must be implemented in subclass" def found_terminator(self): raise NotImplementedError, "must be implemented in subclass" ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491820&group_id=5470 From noreply@sourceforge.net Wed Dec 12 02:37:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 18:37:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-471942 ] python2.1.1 SEGV in GC on Solaris 2.7 Message-ID: Bugs item #471942, was opened at 2001-10-16 19:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Anthony Baxter (anthonybaxter) Summary: python2.1.1 SEGV in GC on Solaris 2.7 Initial Comment: I've got a Zope installation where python2.1.1 is segfaulting on Solaris2.7 - it's running a largish ZEO server. The tail of the gdb output is: #128 0x26164 in PyEval_CallObjectWithKeywords () #129 0x264c0 in PyEval_CallObjectWithKeywords () #130 0x26140 in PyEval_CallObjectWithKeywords () #131 0x25fc0 in PyEval_CallObjectWithKeywords () #132 0x517bc in PyInstance_New () #133 0x261a4 in PyEval_CallObjectWithKeywords () #134 0x25fc0 in PyEval_CallObjectWithKeywords () #135 0x42c90 in initgc () It's built with $ gcc -v Reading specs from /opt/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs gcc version 2.95.2 19991024 (release) which is a bit old. I'm going to rebuild with gcc3.0 and also try turning off the GC. Unfortunately I can't get this to happen on a smaller test system - it's only under load that it plows into the ground. I'll also leave symbols in this time... :/ ---------------------------------------------------------------------- Comment By: Joseph Wayne Norton (natsukashi) Date: 2001-12-11 18:37 Message: Logged In: YES user_id=358486 Do you have any updates on this issue? I'm facing the same trouble on the following solaris platform: SunOS i04sv2008 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-80 regards, - j ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-04 23:38 Message: Logged In: YES user_id=29957 Nah, this is a separate one to the frame bug. I'm still seeing it on a regular regular basis, but haven't narrowed it done to what's causing it. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-04 08:48 Message: Logged In: YES user_id=31392 This was the bug that was tracked down to a problem in try/except/finally, wasn't it? If this is fixed, can you close the bug report? If not, can you provide an udpate on its current status? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-07 14:13 Message: Logged In: YES user_id=21627 Any news on this report: did the problem disappear after backporting changes? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 04:32 Message: Logged In: YES user_id=21627 Looking at the changes since 2.1.1, I can see one bugfix that might explain strange behaviour, namely ceval.c 2.277. If you want to try it out, you can get the change here http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Python/ceval.c.diff?r1=2.276&r2=2.277 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 03:59 Message: Logged In: YES user_id=29957 What's the appropriate way to ask this? drop a line to python-dev? purify's showing a UMR in strop_expandtabs (from memory - don't have it on screen right now) when python starts up. Yeah, the realloc bug concerns me - I have to wonder if something's a little bit/lot screwy. I just don't know where. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 03:46 Message: Logged In: YES user_id=21627 This is something to ask the pythonlabs folks; I believe Python has been purified once in a while - perhaps even with Zope extensions. I'd still suspect a bug in the Zope extensions instead of a Python bug, though: if malloc crashes, chances are high that somebody was overwriting free memory. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 03:31 Message: Logged In: YES user_id=29957 It's not a GC object. I'm positive all the extension objects are correct - I just recompiled, without the 1.5/2.0 headers around. It's a different pointer each time round, unfortunately. It also takes anything from 5 minutes to 2 hours to reproduce. I've got about 4 copies of it running now, and I've got a bunch of different core files. I've grabbed purify and an eval license, and I'm feeding it the binary. The printf approach is probably not going to work - these are busy busy Zope servers. Instead, my plan, assuming that purify doesn't immediately spot a problem, is to change the code so that if it gets a dud GC object, it will just bust it out of the tree and let it leak, and print a message saying so. Then I can quit the program, and purify will tell me 'hey, you leaked!' and also tell me where it was allocated. More concerning, about half the segfaults are not from the GC at all, but from realloc in PyFrame_New (line 161 of frameobject). These are the only two I'm getting - it's split 50-50 amongst the 10 coredumps I have now. I'm not sure whether to open a seperate bug for this. Has python2.1.1 been purified? With Zope and zope's extensions? Wow - it's amazing how this SF bug thing is so painful for conversations :) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 03:11 Message: Logged In: YES user_id=21627 There are two options: a) the object isn't really a GC object, i.e. has no GC header. In gdb, you can try to cast gc to PyObject*, then see if the resulting pointer has a better ob_type (this is unlikely, though, since the logic entering the object was already using fromgc/togc) b) somebody has cleared the ob_type field. Can you guarantee that all extension modules have been compiled with the 2.1.1 header files? Is the problem repeatable in the sense that gc will have the same pointer value on each crash? If so, it is relatively easy to track down: just set a gdb change watchpoint on the address on the ob_type field of that address (note that setting watchpoints is not possible until there is really mapped memory on that address). If you can't analyse it through change breakpoints, I recommend to annotate the interpreter in the following way: in pyobject_init, put a printf that prints the address and the tp_name of the type. In subtract_refs, if the ob_type slot is null, print the address of the object and abort. Then analyse the log to see whether a object really has been allocated on that address, and what its type was (make sure you consider the possibility that address are off by the delta that FROM_GC adds). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-17 21:58 Message: Logged In: YES user_id=29957 Ok, I have an intact core file, and a matching binary, no optimisations, nothing. This crash is showing the crash at line 166 of gcmodule.c traverse = PyObject_FROM_GC(gc)->ob_type->tp_traverse; PyObject_FROM_GC(gc)->ob_type in this case is $24 = {ob_refcnt = 1, ob_type = 0x0} To check my logic, I checked gc_next and gc_prev using the same GDB magic, and they correctly show up as a tuple and an instance method. Some fiddling around seems to rule out stack space as the problem, as well. We're going to try and see if purify helps here, but the problem looks to be a junk object - I have no idea how to track this down further. Help? Would taking the horrible horrible hack of removing the object from the gc linked list if ob_type is null help? Well, it'd stop the crashes, anyway. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-17 13:44 Message: Logged In: YES user_id=21627 It would be interesting what the value of "gc" is at the time of the crash. It looks like you got an object that claims to support GC but has a null tp_traverse. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-17 06:08 Message: Logged In: YES user_id=29957 I'm a doofus who read the gdb trace from the wrong end - too much python lately :) Nonetheless, the other end of the trace failed in gc as well - and building without GC enabled worked. Here's the trace with debugging enabled: #0 0xff00 in ?? () #1 0x402f0 in collect (young=0x9b538, old=0x9b544) at ./Modules/gcmodule.c:379 #2 0x405a8 in collect_generations () at ./Modules/gcmodule.c:484 #3 0x40624 in _PyGC_Insert (op=0xbc1f24) at ./Modules/gcmodule.c:507 #4 0x5a224 in PyList_New (size=0) at Objects/listobject.c:61 #5 0x21bc8 in eval_code2 (co=0x1cb370, globals=0x21bc0, locals=0x67, args=0x0, argcount=1, kws=0xf89b24, kwcount=0, defs=0x0, defcount=0, closure=0xbc1f24) at Python/ceval.c:1741 Next trick is to rebuild without any optimisation (sigh) as I suspect that it's inlined subtract_refs(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 From noreply@sourceforge.net Wed Dec 12 03:22:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 19:22:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-491888 ] whichdb lies about db type Message-ID: Bugs item #491888, was opened at 2001-12-11 19:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491888&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: whichdb lies about db type Initial Comment: >>> import dbm >>> d = dbm.open('foo', 'n') >>> d['a'] = 'b' >>> d.close() >>> import whichdb >>> whichdb.whichdb('foo.db') 'dbhash' I'm currently testing for the existence of "foo.db" instead of "foo" and hard-code my routines to use dbm if there is a "foo.db" file (since all other db modules that I've tested do no append ".db") Might it also be possible to have anydbm perform a whichdb check in its open function, so that older databases are usable with newer, more feature-full installations that might include "better" dbm backends? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491888&group_id=5470 From noreply@sourceforge.net Wed Dec 12 04:28:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 20:28:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-491888 ] whichdb lies about db type Message-ID: Bugs item #491888, was opened at 2001-12-11 19:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491888&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: whichdb lies about db type Initial Comment: >>> import dbm >>> d = dbm.open('foo', 'n') >>> d['a'] = 'b' >>> d.close() >>> import whichdb >>> whichdb.whichdb('foo.db') 'dbhash' I'm currently testing for the existence of "foo.db" instead of "foo" and hard-code my routines to use dbm if there is a "foo.db" file (since all other db modules that I've tested do no append ".db") Might it also be possible to have anydbm perform a whichdb check in its open function, so that older databases are usable with newer, more feature-full installations that might include "better" dbm backends? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 20:28 Message: Logged In: YES user_id=6380 Hm. anydmb *does* use whichdb. The problem seems to be that the dbm file really *does* look like a BSD hash -- the Unix file(1) command has the same problem. But I'm not sure I understand your question. Do you have a particular patch in mind? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491888&group_id=5470 From noreply@sourceforge.net Wed Dec 12 04:51:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 20:51:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-445815 ] urllib doesn't handle proxy exceptions Message-ID: Bugs item #445815, was opened at 2001-07-29 19:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445815&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dylan Jay (djsq) Assigned to: Nobody/Anonymous (nobody) Summary: urllib doesn't handle proxy exceptions Initial Comment: When using urllib in a firewall environment when a proxy is set, the proxy will be used for all connections regardless of if the host is located inside or outside the firewall. Localhost is a good example of this. Under a windows environment the registry contains a proxy exception list which contains patterns which match hosts that should not be directed through the proxy. This should be used. Under other environments perhaps an environment variable be used to determine the exceptions eg http_proxy_expceptions = "*.mydomain.com;*.myotherdomain.com" Localhost should never be directed through a proxy. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 20:51 Message: Logged In: YES user_id=6380 Look at the urllib.py in Python 2.2b2. Does that do what you want? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-11 15:11 Message: Logged In: NO ok, there are really two problems here 1. If I have a proxy set and I go say print urllib.urlopen("http://localhost").read() I go to localhost.com outside the firewall. This is because urllib is not recognizing 'localhost' as a special case. 2. There is no way to override the default behaviour of always using a proxy when it is available. At least under windows, if urllib can find the registry entries for the proxy it will use them whether you want to or not. The solutions I can see are as follows 1. I think the special case handling for 'localhost' is broken. localhost should always resolve to the local computer regardless of presence of a proxy. 2. There are a couple of options here. - extra arguments on url calls - setting modes on urllib - or being able to set up internal link patterns (as suggested in my orginal post). The latter is what windows internet explorer does (I think netscape too). You specify a simple pattern that if the domain matches, will result in the url call being made locally without the use of the proxy. This information is already in the windows registery so that would be the ideal place to get this information on the windows platform. On other platforms I would suggest an evornonment variable. PS. The code you reference just gets the normal proxy information. Not the proxy exception information. PPS. I tested this behaviour on win2k, python 2.1 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 14:46 Message: Logged In: YES user_id=6380 I think there's code in urllib.py that tries to do exactly wht you're saying. It's towards the end of urllib.py, after "elif os.name == 'nt':". Can you perhaps instrument that code with a few print statements to see why it doesn't do what you expect? I can't debug this because we don't have a proxy set up here, and I have no idea how to configure this information on Windows. It might help if you explained is which Windows version (95, 98, 2K, ME, XT?), of if you have experienced this on multiple Windows versions. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445815&group_id=5470 From noreply@sourceforge.net Wed Dec 12 05:03:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 21:03:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-445815 ] urllib doesn't handle proxy exceptions Message-ID: Bugs item #445815, was opened at 2001-07-29 19:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445815&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dylan Jay (djsq) Assigned to: Nobody/Anonymous (nobody) Summary: urllib doesn't handle proxy exceptions Initial Comment: When using urllib in a firewall environment when a proxy is set, the proxy will be used for all connections regardless of if the host is located inside or outside the firewall. Localhost is a good example of this. Under a windows environment the registry contains a proxy exception list which contains patterns which match hosts that should not be directed through the proxy. This should be used. Under other environments perhaps an environment variable be used to determine the exceptions eg http_proxy_expceptions = "*.mydomain.com;*.myotherdomain.com" Localhost should never be directed through a proxy. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-11 21:03 Message: Logged In: NO opps, yes, it appears to work perfectly in 2.2b2 on w2k. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 20:51 Message: Logged In: YES user_id=6380 Look at the urllib.py in Python 2.2b2. Does that do what you want? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-11 15:11 Message: Logged In: NO ok, there are really two problems here 1. If I have a proxy set and I go say print urllib.urlopen("http://localhost").read() I go to localhost.com outside the firewall. This is because urllib is not recognizing 'localhost' as a special case. 2. There is no way to override the default behaviour of always using a proxy when it is available. At least under windows, if urllib can find the registry entries for the proxy it will use them whether you want to or not. The solutions I can see are as follows 1. I think the special case handling for 'localhost' is broken. localhost should always resolve to the local computer regardless of presence of a proxy. 2. There are a couple of options here. - extra arguments on url calls - setting modes on urllib - or being able to set up internal link patterns (as suggested in my orginal post). The latter is what windows internet explorer does (I think netscape too). You specify a simple pattern that if the domain matches, will result in the url call being made locally without the use of the proxy. This information is already in the windows registery so that would be the ideal place to get this information on the windows platform. On other platforms I would suggest an evornonment variable. PS. The code you reference just gets the normal proxy information. Not the proxy exception information. PPS. I tested this behaviour on win2k, python 2.1 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 14:46 Message: Logged In: YES user_id=6380 I think there's code in urllib.py that tries to do exactly wht you're saying. It's towards the end of urllib.py, after "elif os.name == 'nt':". Can you perhaps instrument that code with a few print statements to see why it doesn't do what you expect? I can't debug this because we don't have a proxy set up here, and I have no idea how to configure this information on Windows. It might help if you explained is which Windows version (95, 98, 2K, ME, XT?), of if you have experienced this on multiple Windows versions. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445815&group_id=5470 From noreply@sourceforge.net Wed Dec 12 05:10:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 21:10:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-445815 ] urllib doesn't handle proxy exceptions Message-ID: Bugs item #445815, was opened at 2001-07-29 19:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445815&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Dylan Jay (djsq) Assigned to: Nobody/Anonymous (nobody) Summary: urllib doesn't handle proxy exceptions Initial Comment: When using urllib in a firewall environment when a proxy is set, the proxy will be used for all connections regardless of if the host is located inside or outside the firewall. Localhost is a good example of this. Under a windows environment the registry contains a proxy exception list which contains patterns which match hosts that should not be directed through the proxy. This should be used. Under other environments perhaps an environment variable be used to determine the exceptions eg http_proxy_expceptions = "*.mydomain.com;*.myotherdomain.com" Localhost should never be directed through a proxy. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 21:10 Message: Logged In: YES user_id=6380 OK, then I'll close this as duplicate. I was looking at the 2.2b2 version all the time and you were looking at the 2.1 version. What confuses me is that the group is set to Python 2.2 -- did you do that when you submitted? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-11 21:03 Message: Logged In: NO opps, yes, it appears to work perfectly in 2.2b2 on w2k. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 20:51 Message: Logged In: YES user_id=6380 Look at the urllib.py in Python 2.2b2. Does that do what you want? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-11 15:11 Message: Logged In: NO ok, there are really two problems here 1. If I have a proxy set and I go say print urllib.urlopen("http://localhost").read() I go to localhost.com outside the firewall. This is because urllib is not recognizing 'localhost' as a special case. 2. There is no way to override the default behaviour of always using a proxy when it is available. At least under windows, if urllib can find the registry entries for the proxy it will use them whether you want to or not. The solutions I can see are as follows 1. I think the special case handling for 'localhost' is broken. localhost should always resolve to the local computer regardless of presence of a proxy. 2. There are a couple of options here. - extra arguments on url calls - setting modes on urllib - or being able to set up internal link patterns (as suggested in my orginal post). The latter is what windows internet explorer does (I think netscape too). You specify a simple pattern that if the domain matches, will result in the url call being made locally without the use of the proxy. This information is already in the windows registery so that would be the ideal place to get this information on the windows platform. On other platforms I would suggest an evornonment variable. PS. The code you reference just gets the normal proxy information. Not the proxy exception information. PPS. I tested this behaviour on win2k, python 2.1 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 14:46 Message: Logged In: YES user_id=6380 I think there's code in urllib.py that tries to do exactly wht you're saying. It's towards the end of urllib.py, after "elif os.name == 'nt':". Can you perhaps instrument that code with a few print statements to see why it doesn't do what you expect? I can't debug this because we don't have a proxy set up here, and I have no idea how to configure this information on Windows. It might help if you explained is which Windows version (95, 98, 2K, ME, XT?), of if you have experienced this on multiple Windows versions. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445815&group_id=5470 From noreply@sourceforge.net Wed Dec 12 05:14:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 21:14:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-445815 ] urllib doesn't handle proxy exceptions Message-ID: Bugs item #445815, was opened at 2001-07-29 19:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445815&group_id=5470 Category: Python Library Group: Python 2.2 Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Dylan Jay (djsq) Assigned to: Nobody/Anonymous (nobody) Summary: urllib doesn't handle proxy exceptions Initial Comment: When using urllib in a firewall environment when a proxy is set, the proxy will be used for all connections regardless of if the host is located inside or outside the firewall. Localhost is a good example of this. Under a windows environment the registry contains a proxy exception list which contains patterns which match hosts that should not be directed through the proxy. This should be used. Under other environments perhaps an environment variable be used to determine the exceptions eg http_proxy_expceptions = "*.mydomain.com;*.myotherdomain.com" Localhost should never be directed through a proxy. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-11 21:14 Message: Logged In: NO not to my knowledge. I submitted this over 6 months ago so I can't really remember but I'm pretty sure I would have been using 2.1 so I don't know why I would have said it was a 2.2 bug ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 21:10 Message: Logged In: YES user_id=6380 OK, then I'll close this as duplicate. I was looking at the 2.2b2 version all the time and you were looking at the 2.1 version. What confuses me is that the group is set to Python 2.2 -- did you do that when you submitted? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-11 21:03 Message: Logged In: NO opps, yes, it appears to work perfectly in 2.2b2 on w2k. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 20:51 Message: Logged In: YES user_id=6380 Look at the urllib.py in Python 2.2b2. Does that do what you want? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-11 15:11 Message: Logged In: NO ok, there are really two problems here 1. If I have a proxy set and I go say print urllib.urlopen("http://localhost").read() I go to localhost.com outside the firewall. This is because urllib is not recognizing 'localhost' as a special case. 2. There is no way to override the default behaviour of always using a proxy when it is available. At least under windows, if urllib can find the registry entries for the proxy it will use them whether you want to or not. The solutions I can see are as follows 1. I think the special case handling for 'localhost' is broken. localhost should always resolve to the local computer regardless of presence of a proxy. 2. There are a couple of options here. - extra arguments on url calls - setting modes on urllib - or being able to set up internal link patterns (as suggested in my orginal post). The latter is what windows internet explorer does (I think netscape too). You specify a simple pattern that if the domain matches, will result in the url call being made locally without the use of the proxy. This information is already in the windows registery so that would be the ideal place to get this information on the windows platform. On other platforms I would suggest an evornonment variable. PS. The code you reference just gets the normal proxy information. Not the proxy exception information. PPS. I tested this behaviour on win2k, python 2.1 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 14:46 Message: Logged In: YES user_id=6380 I think there's code in urllib.py that tries to do exactly wht you're saying. It's towards the end of urllib.py, after "elif os.name == 'nt':". Can you perhaps instrument that code with a few print statements to see why it doesn't do what you expect? I can't debug this because we don't have a proxy set up here, and I have no idea how to configure this information on Windows. It might help if you explained is which Windows version (95, 98, 2K, ME, XT?), of if you have experienced this on multiple Windows versions. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445815&group_id=5470 From noreply@sourceforge.net Wed Dec 12 05:28:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 21:28:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-227699 ] Memory leaks using imp.load_module Message-ID: Bugs item #227699, was opened at 2001-01-05 12:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=227699&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Charles G Waldman (cgw) >Assigned to: Guido van Rossum (gvanrossum) Summary: Memory leaks using imp.load_module Initial Comment: #!/usr/bin/env python import os import sys import imp print os.getpid() sys.path.append("/tmp") count = 0 while (count<1000): modname = "testmod%s" % count count = count + 1 filename = '/tmp/' + modname + '.py' f = open(filename, 'w') for x in range(10000): f.write('x%s=%s\n'%(x,x)) f.close() modinfo = imp.find_module(modname) print 'loading', modname m = apply(imp.load_module, ('testmod',) + modinfo) ## run "watch -n 1 ps up ## where is the pid printed out by this program ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 21:28 Message: Logged In: YES user_id=6380 Closing. The code base has changed so much that this is most likely irrelevant. Also, very recently Neal Norwitz ran Purify on the entire test suite and declared it leak-free. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 17:42 Message: Logged In: YES user_id=6380 Using the PYTHONDUMPREFS=1 environment variable and the debug version of Python, I don't see this leaking objects except that all the file names ('/tmp/testmod0.py' etc.) seem to be saved as interned strings, which eternalizes them of course. Hm, I wonder why the filename is interned? (I ran it twice, with different counts (100 and 1000), and 1000 instead of 10,000 variables, saving the PYTHONDUMPREFS output to two different files; then diffed the output files.) So if it's leaking beyond this, it's not in the form of objects. And note that Insure++ (or any leak detection tool worth the name) doesn't consider interned strings leaks -- they are reachable via a global variable. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-18 16:28 Message: Logged In: YES user_id=6380 Barry, note that he's cheating with the module name passed to load_module(): the module name is always set to 'testmod', so he's in fact overwriting the module on each load. (This acts the same way as reload(), so it's not creating new module objects -- it's loading the code in the same namespace over and over.) I see the process size grow very quickly to 15M, probably on account of the huge parse tree for those 10,000 assignment statements (much less for the 10,000 actual variables created). After that it gradually grows -- after 100 loads it's up to 27 M. Maybe Insure doesn't see this because the data is actually kept alive somewhere? ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-10-18 15:30 Message: Logged In: YES user_id=12800 I'm having a hard time tracking down the leak. I don't believe it's at the C layer since preliminary Insure runs don't indicate any leaked blocks (there are plenty of inuse blocks, but those generally don't count). I will note that if you comment out the imp.load_module call the memory usage remains constant. Loading each module though is going to naturally consume more memory, right? And those loaded modules aren't ever going to get freed, at least without mucking about in sys.modules. The memory consumption with ps is pretty meager, so I suspect we don't have a valid leak here, but just normal memory consumption due to importation of 10k modules. I'm running a more detailed insure run right now just to be sure, but I'm skeptical that there's really a bug here. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-02-23 11:53 Message: I can verify that memory grows with this process. I will run it under insure to get more information. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-18 19:43 Message: Barry...?!?! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-01-07 15:32 Message: Assigned to Barry since he's the memory leak expert (& has the right tools). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=227699&group_id=5470 From noreply@sourceforge.net Wed Dec 12 05:29:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 21:29:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-443866 ] Evaluating func_code causing core dump Message-ID: Bugs item #443866, was opened at 2001-07-23 10:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443866&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: Later Priority: 3 Submitted By: Jonathan Hogg (jhogg) Assigned to: Jeremy Hylton (jhylton) Summary: Evaluating func_code causing core dump Initial Comment: Python 2.2a1 (#1, Jul 19 2001, 18:18:51) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on linux2 The intepreter dies hard if you directly evaluate the func_code of a function that has a closure. E.g.: ----- def func1(): return lambda: 4 + y f = func1() print "Ugly test 1:", eval( f.func_code, {'y': 38} ) def func2(x): return lambda: x + y f = func2(4) print "Ugly test 2:", eval( f.func_code, {'y': 38} ) ----- The second eval will cause a core dump on UNIX. The offending code is in PyEval_EvalCodeEx() of ceval.c line 2466. This loop attempts to match free vars against the closure, but the closure is NULL if the function is called with eval. I know this is very broken usage of the interpreter, but it should die more cleanly than a core dump ;-) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 21:29 Message: Logged In: YES user_id=6380 Jeremy, since you claimed this to be fixed, is there a reason to keep this bug report open? If you want a feature, please open a (new, please!) feature request. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-07-30 14:53 Message: Logged In: YES user_id=31392 It might be useful to extend eval() with a means to specify bindings from free variables. It's not at all clear how to do this under the current implementation, which refers to free variables using integer indexes assigned at compile time. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-07-30 14:51 Message: Logged In: YES user_id=31392 Fixed in rev 2.219 of bltinmodule.c ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 15:35 Message: Logged In: YES user_id=31435 Assigned to Jeremy in the hopes this will speed his return to us . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443866&group_id=5470 From noreply@sourceforge.net Wed Dec 12 05:31:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 21:31:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-431000 ] PyMapping_DelItem[String]() is broken Message-ID: Bugs item #431000, was opened at 2001-06-07 04:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=431000&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Duplicate Priority: 3 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: PyMapping_DelItem[String]() is broken Initial Comment: Somehow nobody ever noticed this, so I doubt this is a big problem in practice. But it's a bug nevertheless. In abstract.h, the abstract APIs PyMapping_DelItem() is equivalenced to PyDict_DelItem(); likewise for ...DelItemString(). This is broken because the PyMapping_ family of functions should work for any mapping type, not just for dictionaries! ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 21:31 Message: Logged In: YES user_id=6380 Closed - this is a dup of #476852, which was fixed in abstract.h rev. 2.42. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=431000&group_id=5470 From noreply@sourceforge.net Wed Dec 12 05:32:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 21:32:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-472642 ] interpreter crash when import .so fails w/ Purify Message-ID: Bugs item #472642, was opened at 2001-10-18 20:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472642&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Wont Fix Priority: 3 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Guido van Rossum (gvanrossum) Summary: interpreter crash when import .so fails w/ Purify Initial Comment: The python interpreter crashes when import _socket fails (.so). This only happens when running purify (on solaris 2.8). The problem is that dlerror() returns NULL, which is then passed to strlen(). Attached is a file with the stack trace which caused the problem, and a patch to fix the problem. Neal ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 21:32 Message: Logged In: YES user_id=6380 Closing as "won't fix". Nobody seems to care. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-19 06:49 Message: Logged In: YES user_id=6380 Note that Neal mentions Purify as a condition. I've added that to the subject. Could Purify somehow be screwing dlerror()? Not much we can do about that... On the one hand it seems wrong that PyErr_SetString() should be patched; on the other hand there's nothing wrong with making that function a bit more robust. I give the patch a +0. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 23:33 Message: Logged In: YES user_id=21627 I find it surprising that dlerror returns NULL. According to dlerror(3DL), it will only return NULL if there was no error since the last call to dlerror. Since handle is NULL, there certainly was an error very recently (in the dlopen), and I cannot see any dlerror call in-between. In any case, your patch seems to be wrong: the bug is that dlerror returns NULL when it shouldn't. If we really need to work around this bug (which I'm not convinced that we should), then the work-around is to pass a non-null constant string to PyErr_SetString if dlerror returned null. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472642&group_id=5470 From noreply@sourceforge.net Wed Dec 12 05:33:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 21:33:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-456738 ] Support for smoother debugging of C exts Message-ID: Bugs item #456738, was opened at 2001-08-29 19:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456738&group_id=5470 Category: Python Interpreter Core Group: Feature Request >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Support for smoother debugging of C exts Initial Comment: With every new Python release, the first thing that I do is modify Modules/main.c to add an empty function called void Py_DebugTrap(void) { return; } The purpose of this function is to give me a handy place to set a breakpoint so that I can debug my C/C++ extension modules. It occured to me that this handy trick might be more generally useful and worthy of inclusion in the standard distributions. Thoughts? -- Michael Aivazis (aivazis@caltech.edu) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 21:33 Message: Logged In: YES user_id=6380 Nothing happened in three months. Closing for lack of interest. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-05 23:59 Message: Logged In: YES user_id=21627 In a private conversation, Michael volunteered to contribute a patch for that, including documentation, wrapper macros, and whatever else he considers necessary. So I propose not to act on that report for a few weeks, to see whether we get a contribution of a fix. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 10:55 Message: Logged In: YES user_id=6380 I don't see why Barry should do this (he doesn't seem interested), so unassigning, on the theory that Jeremy randomly assigned it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-09-04 02:44 Message: Logged In: YES user_id=45365 I think I would like this feature. Actually, I think it would even be nice to export it to Python (through sys?). There's something similar in MacPython (the MacOS DebugStr() routine) and I use it a lot. The advantage of a separate routine (as opposed to setting a breakpoint) is that you can put complex conditions in your code for when you want to call the routine. This could conceivably be done with conditional breakpoints too, but it tends to be much more of a hassle. Especially going from Python code to the C debugger at a specific point is pretty difficult. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-03 14:36 Message: Logged In: YES user_id=21627 I don't think this is universally useful. It seems that, at a minimum, you have to add calls to Py_DebugTrap into the module to make it useful, right? Then why can't you just set breakpoints on the lines that you want to call Py_DebugTrap? If the problem is that you cannot set a breakpoint on code that is not yet loaded, I can give you a number of alternatives: - any advanced debugger should offer to break when a shared library is loaded. gdb does. - you can set a breakpoint on Py_InitModule4 (or whatever your extension module calls) - you can set a breakpoint on dlsym (or whatever your shared library system uses to find the address of the init function) - you can statically link your extension module into the Python interpreter, and avoid DLL problems altogether. If these suggestions don't address your problem, please explain in more detail what your problem is. Otherwise, I propose to close this report as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456738&group_id=5470 From noreply@sourceforge.net Wed Dec 12 05:34:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 21:34:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-439992 ] [win32] KeyboardInterrupt Not Caught Message-ID: Bugs item #439992, was opened at 2001-07-10 02:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439992&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Tim Peters (tim_one) Summary: [win32] KeyboardInterrupt Not Caught Initial Comment: The following program, run under unix (FreeBSD 4.3) and Windows 2000 SP2 with the command line: python test.py In both cases, running python 2.1. The program works as expected under unix and IDLE on Windows 2000, but it does *not* catch the interrupt in the command line version of Win32 python... i.e., The traceback message appears rather than my "Leaving Dodge..." message. while 1: try: x = raw_input().upper() print x except KeyboardInterrupt: print "Leaving Dodge...\n" break ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 21:34 Message: Logged In: YES user_id=6380 Shall we close this as Won't Fix? Is there a point in keeping it open while we know we can't fix it? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-07 08:51 Message: Logged In: YES user_id=31435 For posterity, a delightfully confused section of MS's "signal" docs: """ Note SIGINT is not supported for any Win32 application including Windows NT and Windows 95. When a CTRL+C interrupt occurs, Win32 operating systems generate a new thread to specifically handle that interrupt. This can cause a single-thread application such as UNIX, to become multithreaded, resulting in unexpected behavior. """ I kid you not. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-07 06:59 Message: Logged In: YES user_id=6380 Yes, I'm afraid signal handling doesn't always work on Windows. I don't know Windows enough to understand how to fix this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439992&group_id=5470 From noreply@sourceforge.net Wed Dec 12 05:49:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 21:49:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-221671 ] bad link David Ascher's compile.py script Message-ID: Bugs item #221671, was opened at 2000-11-05 08:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=221671&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Mark Phillips (mphillips) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: bad link David Ascher's compile.py script Initial Comment: The document "Extending and Embedding the Python Interpreter, October 16, 2000, Release 2.0", at http://www.python.org/doc/current/ext/win-cookbook.html contains a bad link to bad link David Ascher's compile.py script; the link is to http://starship.python.net/crew/da/compile/ but this URL doesn't work (it redirects to one that refuses connections). It'd be great if someone could put compile.py someplace accessible and fix this link! --Mark ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-11 21:49 Message: Logged In: YES user_id=3066 This keeps coming back to bite users. I've looked around to see whether I have all the information I need to update this (I think I do), so I'm raising the priority to make sure I get this done. I should be able to have this done for 2.2rc1. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-04 21:49 Message: Logged In: YES user_id=3066 The entire section that links to this script is seriously in need of updating. I'll try to look at this tomorrow. Bumping the priority up, but not so much as to block the release. ---------------------------------------------------------------------- Comment By: David Ascher (david_ascher) Date: 2001-09-05 22:37 Message: Logged In: YES user_id=6114 I'll gladly provide the script, but I've lost any energy keeping a permanent website up. I haven't touched the script in ages. I agree that distutils is probably the way to go at this point. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-11-08 22:38 Message: This is a known problem. I have a copy of the script, but I need someone to test it to make sure it works with Python 2.0. Another possibility is to push the Distutils tools; that may be a better option at this point. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=221671&group_id=5470 From noreply@sourceforge.net Wed Dec 12 05:53:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 21:53:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-225003 ] Extension manual: Windows extension info needs update Message-ID: Bugs item #225003, was opened at 2000-12-08 07:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=225003&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Extension manual: Windows extension info needs update Initial Comment: The section on building extensions on Windows needs to be updated. A single section, shared for Unix & Windows, needs to point out the distutils approach and point to the appropriate manual. Information about linking, DLLs/shared libraries, and use of C++ needs to be reviewed and updated. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-11 21:53 Message: Logged In: YES user_id=3066 This is closely related to SF bug #221671. Bumping the priority to match. I'll plan to get this done for 2.2rc1; Alex, I'll expect you to review the updated material once the release candidate is out so I can get your comments before the final release. ;-) ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2001-08-17 00:52 Message: Logged In: YES user_id=60314 Yes, I fully agree -- the information in the manual at http://python.sourceforge.net/devel-docs/ext/win- cookbook.html is positively wrong, and one of the major causes of help requests in my experience -- people look for inexistent http://starship.python.net/crew/da/compile/, download the sources to get a pyconfig.h they don't need and look for a PC\pyconfig.h that doesn't exist, and get tied into knots writing a Setup file. Seems a very serious situation to me. While we wait to do it 'just right', couldn't at least the present erroneous text be replaced with some temporary pointer e.g. to some of the various posts on the subject (cfr http://groups.google.com/groups? as_q=setup.py&as_uauthors=alex%20martelli for many examples, or my apparently popular recipe at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/6650 9, or...?) -- I'll be happy to write/rewrite this stuff with whatever mods you require, Fred, except that I can't seem to use the 'official' way to write Python docs (LaTex etc etc -- I thought a Linux box would make it easy but i'm still having problems setting it up, sigh). Let me know if I can be of help in any way, but I think that, particularly now with the nice new material in chapter 2, it's a positive ill to leave chapter 4 as it is now...:-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=225003&group_id=5470 From noreply@sourceforge.net Wed Dec 12 05:55:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 21:55:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-484603 ] SAX Attribute/AttributesNS class missing Message-ID: Bugs item #484603, was opened at 2001-11-22 08:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=484603&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Alexandre Fayolle (afayolle) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: SAX Attribute/AttributesNS class missing Initial Comment: In the SAX ContentHandler documentation (html-doc/lib/content-handler-objects.html), references are made to classes that are not described elsewhere, Attributes and AttributesNS. Alexandre ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-11 21:55 Message: Logged In: YES user_id=3066 Bumping priority slightly since this is more important than many of the current omissions, but not so much that it should block the release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=484603&group_id=5470 From noreply@sourceforge.net Wed Dec 12 06:07:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 22:07:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-488264 ] Generators should be in the document Message-ID: Bugs item #488264, was opened at 2001-12-02 20:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488264&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Generators should be in the document Initial Comment: The yield statement should appear in the list of statements, and generators should be described either there or in the futuress section of the document. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-11 22:07 Message: Logged In: YES user_id=3066 Documentation added in time for Python 2.2rc1 (several checkins). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488264&group_id=5470 From noreply@sourceforge.net Wed Dec 12 06:08:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 22:08:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-439992 ] [win32] KeyboardInterrupt Not Caught Message-ID: Bugs item #439992, was opened at 2001-07-10 02:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439992&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Mark Hammond (mhammond) Summary: [win32] KeyboardInterrupt Not Caught Initial Comment: The following program, run under unix (FreeBSD 4.3) and Windows 2000 SP2 with the command line: python test.py In both cases, running python 2.1. The program works as expected under unix and IDLE on Windows 2000, but it does *not* catch the interrupt in the command line version of Win32 python... i.e., The traceback message appears rather than my "Leaving Dodge..." message. while 1: try: x = raw_input().upper() print x except KeyboardInterrupt: print "Leaving Dodge...\n" break ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-11 22:08 Message: Logged In: YES user_id=31435 Umm, I have no idea whether it can be fixed. Who was this assigned to? Assigning to MarkH in case he has an idea. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 21:34 Message: Logged In: YES user_id=6380 Shall we close this as Won't Fix? Is there a point in keeping it open while we know we can't fix it? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-07 08:51 Message: Logged In: YES user_id=31435 For posterity, a delightfully confused section of MS's "signal" docs: """ Note SIGINT is not supported for any Win32 application including Windows NT and Windows 95. When a CTRL+C interrupt occurs, Win32 operating systems generate a new thread to specifically handle that interrupt. This can cause a single-thread application such as UNIX, to become multithreaded, resulting in unexpected behavior. """ I kid you not. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-07 06:59 Message: Logged In: YES user_id=6380 Yes, I'm afraid signal handling doesn't always work on Windows. I don't know Windows enough to understand how to fix this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439992&group_id=5470 From noreply@sourceforge.net Wed Dec 12 07:57:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 11 Dec 2001 23:57:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-488730 ] os.popen() seg faults on FreeBSD 5 Message-ID: Bugs item #488730, was opened at 2001-12-03 21:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Marc Culler (marcculler) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen() seg faults on FreeBSD 5 Initial Comment: Here is the crash with Python 2.1.1 on my FreeBSD 5.0-current system: [ace:culler]$ python Python 2.1.1 (#5, Aug 18 2001, 17:41:43) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') Segmentation fault (core dumped) No problem occurs when I do the same thing in Python 2.0, which was compiled under FreeBSD 4, but is running here under FreeBSD 5: [ace:culler]$ python2.0 Python 2.0 (#2, Nov 16 2000, 22:22:48) [GCC 2.95.2 19991024 (release)] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') >>> mypipe.readlines() ['COPYRIGHT\012', 'bin\012', 'boot\012', 'cdrom\012', 'compat\012', 'dev\012', 'dist\012', 'entropy\012', 'etc\012', 'home\012', 'kernel\012', 'kernel.GENERIC\012', 'kernel.old\012', 'kernel.prev\012', 'mnt\012', 'modules\012', 'modules.old\012', 'proc\012', 'root\012', 'sbin\012', 'shared\012', 'stand\012', 'sys\012', 'tmp\012', 'usr\012', 'var\012'] >>> ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 23:57 Message: Logged In: YES user_id=21627 Could that be one of those "it's BSD, never mix threading and non-threading C libraries" bugs? I find it surprising that it crashes inside the C library; the only known causes (besides genuine bugs) are: - memory management got corrupted. Without seeing the source of _fcntl, I think this is unlikely. - caller and callee have different ideas of how structures are layed out, due to being compiled with different definitions of those structures. Are you sure it is correct to link with both libc and libc_r simultaneously? Are there additional variants of the C library which only work in certain combinations? Is this documented anywhere? ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-11 15:43 Message: Logged In: YES user_id=392704 As to the subtlety of this bug, I meant to point out that Python 2.0, which presumably has a nearly identical posix module, has a working os.popen(). On the other hand, Python2.0 loads libc_r.so.4 rather than libc_r.so.5. So maybe that is where the secret lies. Interestingly, the size of that library has gone from 664784 to 108988. That suggests that there were some rather major changes there, doesn't it? ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-11 15:11 Message: Logged In: YES user_id=392704 Yes, I thought it looked like it was a FreeBSD bug too. Unfortunately, though, my little test program produced a nice listing of my / directory. I still think it is FreeBSD's problem, but it is at least a little bit subtle. I suppose I should build the latest FreeBSD sources before proceeding any further with this. #include int main(){ int c; FILE *fp; fp = popen("ls /", "r"); if (fp == NULL) { fprintf(stderr, "popen returned NULL\n"); exit(-1); } while ((c = getc(fp)) != EOF) { putchar(c); } printf("\nDone\n"); exit(0); } ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 14:28 Message: Logged In: YES user_id=6380 Marc, the Python popen code (if you can see through the #ifdefs for non-Unix platforms :-) is a pretty straightforward call of the C library popen(). The crash you receive suggests that it has nothing to do with Python. Can you try a C program containing the same call? Something like #include main() { popen("ls -l", "r"); } Does this crash in the same way? If so, you may close this bug report and report it to the FreeBSD folks instead... ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-11 14:14 Message: Logged In: YES user_id=392704 All I know so far is that, according to the stack trace, the crash seems to occur in _fcntl in libc_r.so: (gdb) run Starting program: /usr/local/src/Python211/python Python 2.1.1 (#14, Dec 11 2001, 15:55:41) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> x = os.popen('ls /') Program received signal SIGSEGV, Segmentation fault. 0x280e32ee in _fcntl () from /usr/lib/libc_r.so.5 (gdb) backtrace #0 0x280e32ee in _fcntl () from /usr/lib/libc_r.so.5 #1 0x28391c99 in fdopen () from /usr/lib/libc.so.5 #2 0x2834bf30 in popen () from /usr/lib/libc.so.5 #3 0x80735b1 in posix_popen (self=0x0, args=0x80f488c) at ./Modules/posixmodule.c:2936 #4 0x805921e in call_cfunction (func=0x80d0820, arg=0x80f488c, kw=0x0) at Python/ceval.c:2845 #5 0x8057cb1 in eval_code2 (co=0x8159ac0, globals=0x80e0ccc, locals=0x80e0ccc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:1948 #6 0x8055171 in PyEval_EvalCode (co=0x8159ac0, globals=0x80e0ccc, locals=0x80e0ccc) at Python/ceval.c:341 #7 0x806ca8f in run_node (n=0x8158280, filename=0x80a202d "", globals=0x80e0ccc, locals=0x80e0ccc, flags=0xbfbff70c) at Python/pythonrun.c:1045 #8 0x806bc86 in PyRun_InteractiveOneFlags (fp=0x80c93a0, filename=0x80a202d "", flags=0xbfbff70c) at Python/pythonrun.c:570 #9 0x806bae6 in PyRun_InteractiveLoopFlags (fp=0x80c93a0, filename=0x80a202d "", flags=0xbfbff70c) at Python/pythonrun.c:510 #10 0x806b9db in PyRun_AnyFileExFlags (fp=0x80c93a0, filename=0x80a202d "", closeit=0, flags=0xbfbff70c) at Python/pythonrun.c:473 #11 0x805222c in Py_Main (argc=0, argv=0xbfbff784) at Modules/main.c:320 #12 0x8051d04 in main (argc=1, argv=0xbfbff784) at Modules/python.c:10 #13 0x8051c35 in _start () ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 12:58 Message: Logged In: YES user_id=21627 Can't reproduce this on FreeBSD 4.4, either, using the current CVS. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:18 Message: Logged In: YES user_id=6380 I can't reproduce this, and I don't have access to a FreeBSD 5 machine. Can you debug this yourself? We'd welcome a patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 From noreply@sourceforge.net Wed Dec 12 08:06:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 00:06:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-487277 ] Different behavior of readline() Message-ID: Bugs item #487277, was opened at 2001-11-29 14:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487277&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Nobody/Anonymous (nobody) Summary: Different behavior of readline() Initial Comment: The behavior of readline() has changed on 2.2. This should be documented. Example: Python 2.1 (#1, Jun 22 2001, 17:13:13) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-i386 Type "copyright", "credits" or "license" for more information. >>> open("/etc").readline() '' Python 2.2b2+ (#1, Nov 27 2001, 21:39:35) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-ppc Type "help", "copyright", "credits" or "license" for more information. >>> open("/etc").readline() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-12 00:06 Message: Logged In: YES user_id=21627 Tim was arguing that open("/") fails on some systems, anyway, since the C library will refuse to open a directory. So it would be for uniformity's sake that makes it fail on Posix, as well. I think that fopen() allows to open a directory is by a similar rationale: if open(2) allows to open it, fopen(3) should do so as well. That rationale is already broken: open(2) is needed to read a directory, but you cannot read a directory if you have a FILE*. The "used for existence test" argument isn't very convincing; use access or stat for that (specifically, os.exists). Of course, changing it might break existing code, just as changing .readline did. It is clear that posix.open should forward directly to the system call, instead of performing checks. It is not so clear that file() should do the same thing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 14:50 Message: Logged In: YES user_id=6380 Are we even sure that open("/") should be disallowed? What if it is used as an existence test? What is allowed by open() should be the realm of the stdio fopen() function, and we shouldn't second-guess it. If fopen() allows us to open directories, why shouldn't we? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-03 06:22 Message: Logged In: YES user_id=21627 Yes, changing it later is fine. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-03 05:03 Message: Logged In: YES user_id=6380 I take it that this needn't be included in 2.2? Who knows what it would break. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-03 01:02 Message: Logged In: YES user_id=21627 I agree that Python should not allow to open a directory. Attached is a patch that implements this check; it is somewhat more involved since it must also check file object that are created through PyFile_FromFile etc. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-02 12:18 Message: Logged In: YES user_id=31435 Well, my question isn't really about libc but about Python: since Python doesn't expose getdents(2) or readdir (2), how could it be anything but a mistake for a Python user on Linux to try to __builtin__.open() a directory? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 05:16 Message: Logged In: YES user_id=21627 Opening a directory is the only way, on Unix, to get its contents. The file descriptor returned is then passed to getdents(2) or readdir(2) (depending on the OS version). __builtins__.open doesn't fail because it calls fopen right away, which doesn't fail because it calls open(2) with just O_RDONLY and O_LARGEFILE, not with O_DIRECTORY. open(2) will then only return EISDIR if the directory is opened for writing. Since this is the behaviour documented in Posix, it is unlikely that Linux glibc will change. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 14:44 Message: Logged In: YES user_id=38388 For the record, this is what I get with Python 2.2b2 on Linux: >>> f = open('/home/lemburg/') >>> f.read() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory >>> f.readline() '' >>> f.readlines() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory >>> Reading the man-page for open(), it seems that directories play some role (though it's not clear which...): open() options: ... O_DIRECTORY If pathname is not a directory, cause the open to fail. This flag is Linux-specific, and was added in kernel version 2.1.126, to avoid denial-of-ser­ vice problems if opendir(3) is called on a FIFO or tape device, but should not be used outside of the implementation of opendir. errno values: ... EISDIR pathname refers to a directory and the access requested involved writing. EACCES The requested access to the file is not allowed, or one of the directories in pathname did not allow search (execute) permission, or the file did not exist yet and write access to the parent directory is not allowed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-30 14:26 Message: Logged In: YES user_id=31435 Does anyone know why opening a directory for reading doesn't complain on Linux? It has always complained on Windows. If readline() is doomed to fail, why do we allow opening a directory for reading at all? OTOH, if it's not insane to open a directory for reading on Linux, why does readline() complain on Linux? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 08:07 Message: Logged In: YES user_id=21627 No. I think very few of the changes will ever cause problems in real software - including this one. I wouldn't be surprised if this remains the only reported incidence of that change. I *am* saying that for every change that has been made, one could construct an application that breaks under this change. This theoretical potential for breakage shouldn't cause prominent appearance in documentation; everybody who really wants to see documentation for all changes should consult the CVS logs. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-11-30 06:15 Message: Logged In: YES user_id=7887 I beg your pardon. Are you saying that there are many changes in Python 2.2 that will blow up code written in Python 2.1!? Why do we have __future__ than!? Why are we concerned about being careful with division upgrade when we have lots of small stuff breaking up *valid* code written one release ago? And, if this was not enough, these changes won't even be documented!?! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 04:21 Message: Logged In: YES user_id=21627 Well, I wouldn't object to anybody documenting this particular change (even though I won't do that myself, either). I'm just pointing out that there are many more changes of this kind, and that it would be an illusion that you could ever produce a complete list. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 01:36 Message: Logged In: YES user_id=38388 I disagree: any change which could potentially blow up existing programs should at least be mentioned somewhere in the docs, be it the NEWS file, the release page on python.org or (thanks to the great work of Andrew Kuchling) the "What's new in Python x.x" docs. This is simply needed due to the very dynamic way Python works: there's no way to test all paths through a program if you want to port it from one Python version to the next, so we'll have to be very careful about these changes even if they are clearly bug fixes. In the mentioned case, I'd say that the programmer was at fault, though: it's so much easier to test a path for being a directory than to rely on some obscure method return value and also much safer ! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 01:19 Message: Logged In: YES user_id=21627 Any change is user-visible: for any change, I can construct a program that behaves differently with the change. Otherwise, the change would be useless (except that it may add commentary or some such). In fact, the change *is* documented, namely in the CVS log. Extracting all those fragments into a single document would be time-consuming and pointless: nobody can read through hundreds of changes. Your program would have blown up even if there was such a document. If a change has severe effects on many existing programs, it should be implemented differently. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-11-29 16:10 Message: Logged In: YES user_id=7887 I think *any* change visible at user space should be documented. I discovered this change because a program I have never read in my life (in fact, I didn't even know it was written in python) has blown up in my hands. It was reading files and safely ignoring directories by testing readline()'s output. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-29 15:53 Message: Logged In: YES user_id=21627 I don't think this needs to be documented. The change is a bug fix, reading from a directory was never supposed to work (whether in lines or not). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487277&group_id=5470 From noreply@sourceforge.net Wed Dec 12 09:41:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 01:41:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-491953 ] ScrolledText.py has TabError Message-ID: Bugs item #491953, was opened at 2001-12-12 01:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491953&group_id=5470 Category: Tkinter Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) Summary: ScrolledText.py has TabError Initial Comment: [dalke@pw600a lib-tk]$ pwd /home/dalke/cvses/python/dist/src/Lib/lib-tk [dalke@pw600a lib-tk]$ date Wed Dec 12 04:32:25 EST 2001 [dalke@pw600a lib-tk]$ rm ScrolledText.py [dalke@pw600a lib-tk]$ cvs update ScrolledText.py U ScrolledText.py [dalke@pw600a lib-tk]$ python -tt ScrolledText.py File "", line 37 methods = Pack.__dict__.keys() ^ TabError: inconsistent use of tabs and spaces in indentation The fix is obvious - no need for a patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491953&group_id=5470 From noreply@sourceforge.net Wed Dec 12 11:57:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 03:57:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-429329 ] actual-parameters *arg, **kws not doc'd Message-ID: Bugs item #429329, was opened at 2001-06-01 08:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429329&group_id=5470 Category: Documentation Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Michael Hudson (mwh) Summary: actual-parameters *arg, **kws not doc'd Initial Comment: 5.3.4 in the language reference should document the forms *args and **kwds for actual parameters, but it makes no mention of them and does not allow for them in the syntax productions. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-12 03:57 Message: Logged In: YES user_id=6656 Checked in as revision 1.52 of Doc/ref/ref5.tex. Glad to be of assistance! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-11 12:24 Message: Logged In: YES user_id=3066 Michael, this is good. Please check this in and close this report. I really appreciate the help! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-11 09:35 Message: Logged In: YES user_id=6656 Ah! sf's error message for trying to attach an empty file (doh) could be more informative than "invalid filename"... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-11 08:17 Message: Logged In: YES user_id=6656 Oh, sod sf, I'll email it to python-docs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-11 08:17 Message: Logged In: YES user_id=6656 Here's an attempt. I haven't tried compiling it, as I haven't got that setup on this machine yet, but I think it should be OK. Fred may want to fix some markup. It does elevate some implementation accidents in the interaction of *args and keyword arguments to documented fact, which may or may not be what's wanted. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-11 08:16 Message: Logged In: YES user_id=6656 Here's an attempt. I haven't tried compiling it, as I haven't got that setup on this machine yet, but I think it should be OK. Fred may want to fix some markup. It does elevate some implementation accidents in the interaction of *args and keyword arguments to documented fact, which may or may not be what's wanted. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-06-06 15:46 Message: Logged In: YES user_id=31392 I made a little progress on this pre-parenthood. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-06-01 08:38 Message: Logged In: YES user_id=3066 Assigned to Jeremy, since he shepharded the patch into the Python release. Changes should be integrated with the 2.1.1 and head branches. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429329&group_id=5470 From noreply@sourceforge.net Wed Dec 12 12:43:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 04:43:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-488730 ] os.popen() seg faults on FreeBSD 5 Message-ID: Bugs item #488730, was opened at 2001-12-03 21:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Marc Culler (marcculler) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen() seg faults on FreeBSD 5 Initial Comment: Here is the crash with Python 2.1.1 on my FreeBSD 5.0-current system: [ace:culler]$ python Python 2.1.1 (#5, Aug 18 2001, 17:41:43) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') Segmentation fault (core dumped) No problem occurs when I do the same thing in Python 2.0, which was compiled under FreeBSD 4, but is running here under FreeBSD 5: [ace:culler]$ python2.0 Python 2.0 (#2, Nov 16 2000, 22:22:48) [GCC 2.95.2 19991024 (release)] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') >>> mypipe.readlines() ['COPYRIGHT\012', 'bin\012', 'boot\012', 'cdrom\012', 'compat\012', 'dev\012', 'dist\012', 'entropy\012', 'etc\012', 'home\012', 'kernel\012', 'kernel.GENERIC\012', 'kernel.old\012', 'kernel.prev\012', 'mnt\012', 'modules\012', 'modules.old\012', 'proc\012', 'root\012', 'sbin\012', 'shared\012', 'stand\012', 'sys\012', 'tmp\012', 'usr\012', 'var\012'] >>> ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-12 04:43 Message: Logged In: YES user_id=6380 Good point. The experiment with a little C program should be repeated, compiling and linking it with exactly the same flags as Python is compiled and linked. (Statically, since the posix module is statically linked into Python.) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 23:57 Message: Logged In: YES user_id=21627 Could that be one of those "it's BSD, never mix threading and non-threading C libraries" bugs? I find it surprising that it crashes inside the C library; the only known causes (besides genuine bugs) are: - memory management got corrupted. Without seeing the source of _fcntl, I think this is unlikely. - caller and callee have different ideas of how structures are layed out, due to being compiled with different definitions of those structures. Are you sure it is correct to link with both libc and libc_r simultaneously? Are there additional variants of the C library which only work in certain combinations? Is this documented anywhere? ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-11 15:43 Message: Logged In: YES user_id=392704 As to the subtlety of this bug, I meant to point out that Python 2.0, which presumably has a nearly identical posix module, has a working os.popen(). On the other hand, Python2.0 loads libc_r.so.4 rather than libc_r.so.5. So maybe that is where the secret lies. Interestingly, the size of that library has gone from 664784 to 108988. That suggests that there were some rather major changes there, doesn't it? ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-11 15:11 Message: Logged In: YES user_id=392704 Yes, I thought it looked like it was a FreeBSD bug too. Unfortunately, though, my little test program produced a nice listing of my / directory. I still think it is FreeBSD's problem, but it is at least a little bit subtle. I suppose I should build the latest FreeBSD sources before proceeding any further with this. #include int main(){ int c; FILE *fp; fp = popen("ls /", "r"); if (fp == NULL) { fprintf(stderr, "popen returned NULL\n"); exit(-1); } while ((c = getc(fp)) != EOF) { putchar(c); } printf("\nDone\n"); exit(0); } ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 14:28 Message: Logged In: YES user_id=6380 Marc, the Python popen code (if you can see through the #ifdefs for non-Unix platforms :-) is a pretty straightforward call of the C library popen(). The crash you receive suggests that it has nothing to do with Python. Can you try a C program containing the same call? Something like #include main() { popen("ls -l", "r"); } Does this crash in the same way? If so, you may close this bug report and report it to the FreeBSD folks instead... ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-11 14:14 Message: Logged In: YES user_id=392704 All I know so far is that, according to the stack trace, the crash seems to occur in _fcntl in libc_r.so: (gdb) run Starting program: /usr/local/src/Python211/python Python 2.1.1 (#14, Dec 11 2001, 15:55:41) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> x = os.popen('ls /') Program received signal SIGSEGV, Segmentation fault. 0x280e32ee in _fcntl () from /usr/lib/libc_r.so.5 (gdb) backtrace #0 0x280e32ee in _fcntl () from /usr/lib/libc_r.so.5 #1 0x28391c99 in fdopen () from /usr/lib/libc.so.5 #2 0x2834bf30 in popen () from /usr/lib/libc.so.5 #3 0x80735b1 in posix_popen (self=0x0, args=0x80f488c) at ./Modules/posixmodule.c:2936 #4 0x805921e in call_cfunction (func=0x80d0820, arg=0x80f488c, kw=0x0) at Python/ceval.c:2845 #5 0x8057cb1 in eval_code2 (co=0x8159ac0, globals=0x80e0ccc, locals=0x80e0ccc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:1948 #6 0x8055171 in PyEval_EvalCode (co=0x8159ac0, globals=0x80e0ccc, locals=0x80e0ccc) at Python/ceval.c:341 #7 0x806ca8f in run_node (n=0x8158280, filename=0x80a202d "", globals=0x80e0ccc, locals=0x80e0ccc, flags=0xbfbff70c) at Python/pythonrun.c:1045 #8 0x806bc86 in PyRun_InteractiveOneFlags (fp=0x80c93a0, filename=0x80a202d "", flags=0xbfbff70c) at Python/pythonrun.c:570 #9 0x806bae6 in PyRun_InteractiveLoopFlags (fp=0x80c93a0, filename=0x80a202d "", flags=0xbfbff70c) at Python/pythonrun.c:510 #10 0x806b9db in PyRun_AnyFileExFlags (fp=0x80c93a0, filename=0x80a202d "", closeit=0, flags=0xbfbff70c) at Python/pythonrun.c:473 #11 0x805222c in Py_Main (argc=0, argv=0xbfbff784) at Modules/main.c:320 #12 0x8051d04 in main (argc=1, argv=0xbfbff784) at Modules/python.c:10 #13 0x8051c35 in _start () ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 12:58 Message: Logged In: YES user_id=21627 Can't reproduce this on FreeBSD 4.4, either, using the current CVS. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:18 Message: Logged In: YES user_id=6380 I can't reproduce this, and I don't have access to a FreeBSD 5 machine. Can you debug this yourself? We'd welcome a patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 From noreply@sourceforge.net Wed Dec 12 12:46:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 04:46:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-487277 ] Different behavior of readline() Message-ID: Bugs item #487277, was opened at 2001-11-29 14:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487277&group_id=5470 Category: Python Interpreter Core >Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Nobody/Anonymous (nobody) Summary: Different behavior of readline() Initial Comment: The behavior of readline() has changed on 2.2. This should be documented. Example: Python 2.1 (#1, Jun 22 2001, 17:13:13) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-i386 Type "copyright", "credits" or "license" for more information. >>> open("/etc").readline() '' Python 2.2b2+ (#1, Nov 27 2001, 21:39:35) [GCC 2.95.3 20010315 (release) (conectiva)] on linux-ppc Type "help", "copyright", "credits" or "license" for more information. >>> open("/etc").readline() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-12 04:46 Message: Logged In: YES user_id=6380 OK,. I buy that argument. I'll take a patch after 2.2. We really need a "2.3" group here -- for now I've set the group to feathre request. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-12 00:06 Message: Logged In: YES user_id=21627 Tim was arguing that open("/") fails on some systems, anyway, since the C library will refuse to open a directory. So it would be for uniformity's sake that makes it fail on Posix, as well. I think that fopen() allows to open a directory is by a similar rationale: if open(2) allows to open it, fopen(3) should do so as well. That rationale is already broken: open(2) is needed to read a directory, but you cannot read a directory if you have a FILE*. The "used for existence test" argument isn't very convincing; use access or stat for that (specifically, os.exists). Of course, changing it might break existing code, just as changing .readline did. It is clear that posix.open should forward directly to the system call, instead of performing checks. It is not so clear that file() should do the same thing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 14:50 Message: Logged In: YES user_id=6380 Are we even sure that open("/") should be disallowed? What if it is used as an existence test? What is allowed by open() should be the realm of the stdio fopen() function, and we shouldn't second-guess it. If fopen() allows us to open directories, why shouldn't we? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-03 06:22 Message: Logged In: YES user_id=21627 Yes, changing it later is fine. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-03 05:03 Message: Logged In: YES user_id=6380 I take it that this needn't be included in 2.2? Who knows what it would break. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-03 01:02 Message: Logged In: YES user_id=21627 I agree that Python should not allow to open a directory. Attached is a patch that implements this check; it is somewhat more involved since it must also check file object that are created through PyFile_FromFile etc. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-02 12:18 Message: Logged In: YES user_id=31435 Well, my question isn't really about libc but about Python: since Python doesn't expose getdents(2) or readdir (2), how could it be anything but a mistake for a Python user on Linux to try to __builtin__.open() a directory? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 05:16 Message: Logged In: YES user_id=21627 Opening a directory is the only way, on Unix, to get its contents. The file descriptor returned is then passed to getdents(2) or readdir(2) (depending on the OS version). __builtins__.open doesn't fail because it calls fopen right away, which doesn't fail because it calls open(2) with just O_RDONLY and O_LARGEFILE, not with O_DIRECTORY. open(2) will then only return EISDIR if the directory is opened for writing. Since this is the behaviour documented in Posix, it is unlikely that Linux glibc will change. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 14:44 Message: Logged In: YES user_id=38388 For the record, this is what I get with Python 2.2b2 on Linux: >>> f = open('/home/lemburg/') >>> f.read() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory >>> f.readline() '' >>> f.readlines() Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory >>> Reading the man-page for open(), it seems that directories play some role (though it's not clear which...): open() options: ... O_DIRECTORY If pathname is not a directory, cause the open to fail. This flag is Linux-specific, and was added in kernel version 2.1.126, to avoid denial-of-ser­ vice problems if opendir(3) is called on a FIFO or tape device, but should not be used outside of the implementation of opendir. errno values: ... EISDIR pathname refers to a directory and the access requested involved writing. EACCES The requested access to the file is not allowed, or one of the directories in pathname did not allow search (execute) permission, or the file did not exist yet and write access to the parent directory is not allowed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-30 14:26 Message: Logged In: YES user_id=31435 Does anyone know why opening a directory for reading doesn't complain on Linux? It has always complained on Windows. If readline() is doomed to fail, why do we allow opening a directory for reading at all? OTOH, if it's not insane to open a directory for reading on Linux, why does readline() complain on Linux? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 08:07 Message: Logged In: YES user_id=21627 No. I think very few of the changes will ever cause problems in real software - including this one. I wouldn't be surprised if this remains the only reported incidence of that change. I *am* saying that for every change that has been made, one could construct an application that breaks under this change. This theoretical potential for breakage shouldn't cause prominent appearance in documentation; everybody who really wants to see documentation for all changes should consult the CVS logs. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-11-30 06:15 Message: Logged In: YES user_id=7887 I beg your pardon. Are you saying that there are many changes in Python 2.2 that will blow up code written in Python 2.1!? Why do we have __future__ than!? Why are we concerned about being careful with division upgrade when we have lots of small stuff breaking up *valid* code written one release ago? And, if this was not enough, these changes won't even be documented!?! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 04:21 Message: Logged In: YES user_id=21627 Well, I wouldn't object to anybody documenting this particular change (even though I won't do that myself, either). I'm just pointing out that there are many more changes of this kind, and that it would be an illusion that you could ever produce a complete list. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-30 01:36 Message: Logged In: YES user_id=38388 I disagree: any change which could potentially blow up existing programs should at least be mentioned somewhere in the docs, be it the NEWS file, the release page on python.org or (thanks to the great work of Andrew Kuchling) the "What's new in Python x.x" docs. This is simply needed due to the very dynamic way Python works: there's no way to test all paths through a program if you want to port it from one Python version to the next, so we'll have to be very careful about these changes even if they are clearly bug fixes. In the mentioned case, I'd say that the programmer was at fault, though: it's so much easier to test a path for being a directory than to rely on some obscure method return value and also much safer ! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-30 01:19 Message: Logged In: YES user_id=21627 Any change is user-visible: for any change, I can construct a program that behaves differently with the change. Otherwise, the change would be useless (except that it may add commentary or some such). In fact, the change *is* documented, namely in the CVS log. Extracting all those fragments into a single document would be time-consuming and pointless: nobody can read through hundreds of changes. Your program would have blown up even if there was such a document. If a change has severe effects on many existing programs, it should be implemented differently. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-11-29 16:10 Message: Logged In: YES user_id=7887 I think *any* change visible at user space should be documented. I discovered this change because a program I have never read in my life (in fact, I didn't even know it was written in python) has blown up in my hands. It was reading files and safely ignoring directories by testing readline()'s output. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-29 15:53 Message: Logged In: YES user_id=21627 I don't think this needs to be documented. The change is a bug fix, reading from a directory was never supposed to work (whether in lines or not). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487277&group_id=5470 From noreply@sourceforge.net Wed Dec 12 12:48:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 04:48:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-491953 ] ScrolledText.py has TabError Message-ID: Bugs item #491953, was opened at 2001-12-12 01:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491953&group_id=5470 Category: Tkinter Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andrew Dalke (dalke) >Assigned to: Guido van Rossum (gvanrossum) Summary: ScrolledText.py has TabError Initial Comment: [dalke@pw600a lib-tk]$ pwd /home/dalke/cvses/python/dist/src/Lib/lib-tk [dalke@pw600a lib-tk]$ date Wed Dec 12 04:32:25 EST 2001 [dalke@pw600a lib-tk]$ rm ScrolledText.py [dalke@pw600a lib-tk]$ cvs update ScrolledText.py U ScrolledText.py [dalke@pw600a lib-tk]$ python -tt ScrolledText.py File "", line 37 methods = Pack.__dict__.keys() ^ TabError: inconsistent use of tabs and spaces in indentation The fix is obvious - no need for a patch. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-12 04:48 Message: Logged In: YES user_id=6380 Oops! Thanks for finding this in time. Would be embarrassing given PEP 666 etc... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491953&group_id=5470 From noreply@sourceforge.net Wed Dec 12 13:20:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 05:20:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-457633 ] _cursesmodules.c does not build on MacOSX Message-ID: Bugs item #457633, was opened at 2001-09-01 16:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457633&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: Remind Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: _cursesmodules.c does not build on MacOSX Initial Comment: _cursesmodule.c suddenly stopped build on MacOSX. (this is from the CVS repository). The first error is on "chtype" on line 187, and you don't want the know the amount of errors it causes after that. I guess that some optional feature of curses was added without an appropriate ifdef or something. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-12 05:20 Message: Logged In: YES user_id=45365 It turns out that the curses supplied with OSX is far too old to be useable by cursesmodule. Building _curses is now disabled on OSX. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 08:53 Message: Logged In: YES user_id=6380 I'm reassigning this to Jack because Andrew is shedding load. Jack, is this still a problem? If you can't fix it, can you lower the priority? It's not going to hold up the 2.2 release... ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-09-04 12:38 Message: Logged In: YES user_id=11375 >(are there no other platforms that have this problem?) Probably not, as most systems are SYSV-based these days. It wouldn't work on, say, SunOS 4.1, but who uses such an old version? I'm surprised MacOS X has such an old version of curses, since current *BSDs don't have a problem. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-04 08:03 Message: Logged In: YES user_id=6380 Reopening, hoping for a better way to fix this. This should really check for a magic string that occurs in all recent curses.h files, or one that only occurs in ancient (unusable) cursees.h files, to distinguish between a good and a bad curses. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-09-04 02:07 Message: Logged In: YES user_id=45365 It turns out that the curses on MacOSX is a really old (1994?) Berkeley curses, not good enough for _cursesmodule.c. I've "manually" disabled it in setup.py (are there no other platforms that have this problem?). I have no idea why the problem only showed up recently, there appear to have been no changes around this area in setup.py... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-01 19:15 Message: Logged In: YES user_id=6380 When did it last build for you without problems? The last change was from 19 July, and unless MacOS X defines either sgi or __sgi, I don't see how that could cause lots of errors. The 'chtype' typedef isn't affected by the last two checkins. Maybe something changed in some header included y Python.h or pyport.h? Maybe something you changed yourself? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457633&group_id=5470 From noreply@sourceforge.net Wed Dec 12 15:34:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 07:34:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-457633 ] _cursesmodules.c does not build on MacOSX Message-ID: Bugs item #457633, was opened at 2001-09-01 16:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457633&group_id=5470 Category: Extension Modules Group: None >Status: Closed Resolution: Remind Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: _cursesmodules.c does not build on MacOSX Initial Comment: _cursesmodule.c suddenly stopped build on MacOSX. (this is from the CVS repository). The first error is on "chtype" on line 187, and you don't want the know the amount of errors it causes after that. I guess that some optional feature of curses was added without an appropriate ifdef or something. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-12 05:20 Message: Logged In: YES user_id=45365 It turns out that the curses supplied with OSX is far too old to be useable by cursesmodule. Building _curses is now disabled on OSX. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 08:53 Message: Logged In: YES user_id=6380 I'm reassigning this to Jack because Andrew is shedding load. Jack, is this still a problem? If you can't fix it, can you lower the priority? It's not going to hold up the 2.2 release... ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-09-04 12:38 Message: Logged In: YES user_id=11375 >(are there no other platforms that have this problem?) Probably not, as most systems are SYSV-based these days. It wouldn't work on, say, SunOS 4.1, but who uses such an old version? I'm surprised MacOS X has such an old version of curses, since current *BSDs don't have a problem. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-04 08:03 Message: Logged In: YES user_id=6380 Reopening, hoping for a better way to fix this. This should really check for a magic string that occurs in all recent curses.h files, or one that only occurs in ancient (unusable) cursees.h files, to distinguish between a good and a bad curses. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-09-04 02:07 Message: Logged In: YES user_id=45365 It turns out that the curses on MacOSX is a really old (1994?) Berkeley curses, not good enough for _cursesmodule.c. I've "manually" disabled it in setup.py (are there no other platforms that have this problem?). I have no idea why the problem only showed up recently, there appear to have been no changes around this area in setup.py... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-01 19:15 Message: Logged In: YES user_id=6380 When did it last build for you without problems? The last change was from 19 July, and unless MacOS X defines either sgi or __sgi, I don't see how that could cause lots of errors. The 'chtype' typedef isn't affected by the last two checkins. Maybe something changed in some header included y Python.h or pyport.h? Maybe something you changed yourself? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457633&group_id=5470 From noreply@sourceforge.net Wed Dec 12 15:47:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 07:47:30 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-490264 ] Portable compiler option specification Message-ID: Feature Requests item #490264, was opened at 2001-12-07 07:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=490264&group_id=5470 Category: Distutils Group: None Status: Open Priority: 5 Submitted By: Konrad Hinsen (hinsen) Assigned to: Nobody/Anonymous (nobody) Summary: Portable compiler option specification Initial Comment: Distutils should provide a portable way for packagers to specify common compiler options, e.g. "maximum optimization", "debugging symbols" etc. These should be per-module options that can be specified in the setup script. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-12 07:47 Message: Logged In: YES user_id=45365 I disagree: I think packages should inherit such options from the Python into which they're being installed. Allowing overrides of this can lead to all sorts of disastrous failures. For instance, a Unix person won't know that mixing debug/non-debug on Windows is a sure way to crash Python spectacularly. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=490264&group_id=5470 From noreply@sourceforge.net Wed Dec 12 16:12:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 08:12:49 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-490264 ] Portable compiler option specification Message-ID: Feature Requests item #490264, was opened at 2001-12-07 07:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=490264&group_id=5470 Category: Distutils Group: None Status: Open Priority: 5 Submitted By: Konrad Hinsen (hinsen) Assigned to: Nobody/Anonymous (nobody) Summary: Portable compiler option specification Initial Comment: Distutils should provide a portable way for packagers to specify common compiler options, e.g. "maximum optimization", "debugging symbols" etc. These should be per-module options that can be specified in the setup script. ---------------------------------------------------------------------- >Comment By: Konrad Hinsen (hinsen) Date: 2001-12-12 08:12 Message: Logged In: YES user_id=11850 If debug and non-debug cannot be mixed on Windows, then distutils should not allow such a combination on Windows, i.e. it should not allow a different debug option than the one with which Python was compiled. In fact, such dependencies are a good reason why distutils *should* support compilation options. Otherwise developers will have to use some hacks and run into trouble. When I tell distutils to compile a module with maximum optimization, this means of course maximum optimization while remaining compatible with the Python interpreter. Note also that the question for some users is not whether distutils supports optimization, but whether they can use distutils if they require optimization specifications. For example, I won't publish any MMTK release with distutils installation until I can set maximum optimization for two time-critical modules; the speed difference is a factor 2 with gcc, enough to make users run away (this is code that typically runs for days or weeks). I'd rather deal with installation problems for 1% of users than with performance complaints from 90%. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-12 07:47 Message: Logged In: YES user_id=45365 I disagree: I think packages should inherit such options from the Python into which they're being installed. Allowing overrides of this can lead to all sorts of disastrous failures. For instance, a Unix person won't know that mixing debug/non-debug on Windows is a sure way to crash Python spectacularly. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=490264&group_id=5470 From noreply@sourceforge.net Wed Dec 12 16:42:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 08:42:08 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-490264 ] Portable compiler option specification Message-ID: Feature Requests item #490264, was opened at 2001-12-07 07:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=490264&group_id=5470 Category: Distutils Group: None Status: Open Priority: 5 Submitted By: Konrad Hinsen (hinsen) Assigned to: Nobody/Anonymous (nobody) Summary: Portable compiler option specification Initial Comment: Distutils should provide a portable way for packagers to specify common compiler options, e.g. "maximum optimization", "debugging symbols" etc. These should be per-module options that can be specified in the setup script. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-12 08:42 Message: Logged In: YES user_id=45365 Ok, this sounds reasonable as a design, but implementation will probably be difficult (as distutils will have to merge the wishes of the package author, which are specified in a portable way, with Python's compile time options, which are specified in a very nonportable way). ---------------------------------------------------------------------- Comment By: Konrad Hinsen (hinsen) Date: 2001-12-12 08:12 Message: Logged In: YES user_id=11850 If debug and non-debug cannot be mixed on Windows, then distutils should not allow such a combination on Windows, i.e. it should not allow a different debug option than the one with which Python was compiled. In fact, such dependencies are a good reason why distutils *should* support compilation options. Otherwise developers will have to use some hacks and run into trouble. When I tell distutils to compile a module with maximum optimization, this means of course maximum optimization while remaining compatible with the Python interpreter. Note also that the question for some users is not whether distutils supports optimization, but whether they can use distutils if they require optimization specifications. For example, I won't publish any MMTK release with distutils installation until I can set maximum optimization for two time-critical modules; the speed difference is a factor 2 with gcc, enough to make users run away (this is code that typically runs for days or weeks). I'd rather deal with installation problems for 1% of users than with performance complaints from 90%. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-12 07:47 Message: Logged In: YES user_id=45365 I disagree: I think packages should inherit such options from the Python into which they're being installed. Allowing overrides of this can lead to all sorts of disastrous failures. For instance, a Unix person won't know that mixing debug/non-debug on Windows is a sure way to crash Python spectacularly. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=490264&group_id=5470 From noreply@sourceforge.net Wed Dec 12 23:28:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 15:28:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-491888 ] whichdb lies about db type Message-ID: Bugs item #491888, was opened at 2001-12-11 19:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491888&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: whichdb lies about db type Initial Comment: >>> import dbm >>> d = dbm.open('foo', 'n') >>> d['a'] = 'b' >>> d.close() >>> import whichdb >>> whichdb.whichdb('foo.db') 'dbhash' I'm currently testing for the existence of "foo.db" instead of "foo" and hard-code my routines to use dbm if there is a "foo.db" file (since all other db modules that I've tested do no append ".db") Might it also be possible to have anydbm perform a whichdb check in its open function, so that older databases are usable with newer, more feature-full installations that might include "better" dbm backends? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-12 15:28 Message: Logged In: YES user_id=21627 I fail to see the problem altogether. What system are you on? Why do you think dbm does not create dbhash files? It is not just that the magic says they are BSDDB DB_HASH files, they really are of that kind? Also, which of the APIs (dbm, dbhash) do you consider "better"? I'd say that dbhash is better, since it builds upon bsddb. So whichdbm, and anydbm, do use the "better" dbm backend already? Where is the bug? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 20:28 Message: Logged In: YES user_id=6380 Hm. anydmb *does* use whichdb. The problem seems to be that the dbm file really *does* look like a BSD hash -- the Unix file(1) command has the same problem. But I'm not sure I understand your question. Do you have a particular patch in mind? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491888&group_id=5470 From noreply@sourceforge.net Thu Dec 13 04:13:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 20:13:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-488730 ] os.popen() seg faults on FreeBSD 5 Message-ID: Bugs item #488730, was opened at 2001-12-03 21:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Marc Culler (marcculler) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen() seg faults on FreeBSD 5 Initial Comment: Here is the crash with Python 2.1.1 on my FreeBSD 5.0-current system: [ace:culler]$ python Python 2.1.1 (#5, Aug 18 2001, 17:41:43) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') Segmentation fault (core dumped) No problem occurs when I do the same thing in Python 2.0, which was compiled under FreeBSD 4, but is running here under FreeBSD 5: [ace:culler]$ python2.0 Python 2.0 (#2, Nov 16 2000, 22:22:48) [GCC 2.95.2 19991024 (release)] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') >>> mypipe.readlines() ['COPYRIGHT\012', 'bin\012', 'boot\012', 'cdrom\012', 'compat\012', 'dev\012', 'dist\012', 'entropy\012', 'etc\012', 'home\012', 'kernel\012', 'kernel.GENERIC\012', 'kernel.old\012', 'kernel.prev\012', 'mnt\012', 'modules\012', 'modules.old\012', 'proc\012', 'root\012', 'sbin\012', 'shared\012', 'stand\012', 'sys\012', 'tmp\012', 'usr\012', 'var\012'] >>> ---------------------------------------------------------------------- >Comment By: Marc Culler (marcculler) Date: 2001-12-12 20:13 Message: Logged In: YES user_id=392704 We are getting closer! Yes, it does seem to be related to linking against both libc and libc_r. If I compile the test program as follows: gcc -o test test.c -lc -lc_r I get a seg fault at the same location in _fcntl (and the backtrace shows that the libc_r version of _fcntl is being called from the libc version of fdopen). If I use just -lc, or just -lc_r, or even -lc_r -lc then the test program runs fine. So let's assume that the libc and libc_r versions of _fcntl use different structures for file descriptor table entries, or some such thing. The next question is how do I prevent python from being linked against both libraries? I looked through the output of make and nowhere did I see an explicit -lc flag. In the makefile it says LIBS= -lc_r -lutil and the linker command being used to link python is gcc -Wl,--export-dynamic -o python Modules/python.o libpython2.1.a -lc_r -lutil -L/usr/local/lib -ltk82 -ltcl82 -L/usr/X11R6/lib -lX11 -lm So why is it linking against libc and how do I make it stop? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-12 04:43 Message: Logged In: YES user_id=6380 Good point. The experiment with a little C program should be repeated, compiling and linking it with exactly the same flags as Python is compiled and linked. (Statically, since the posix module is statically linked into Python.) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 23:57 Message: Logged In: YES user_id=21627 Could that be one of those "it's BSD, never mix threading and non-threading C libraries" bugs? I find it surprising that it crashes inside the C library; the only known causes (besides genuine bugs) are: - memory management got corrupted. Without seeing the source of _fcntl, I think this is unlikely. - caller and callee have different ideas of how structures are layed out, due to being compiled with different definitions of those structures. Are you sure it is correct to link with both libc and libc_r simultaneously? Are there additional variants of the C library which only work in certain combinations? Is this documented anywhere? ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-11 15:43 Message: Logged In: YES user_id=392704 As to the subtlety of this bug, I meant to point out that Python 2.0, which presumably has a nearly identical posix module, has a working os.popen(). On the other hand, Python2.0 loads libc_r.so.4 rather than libc_r.so.5. So maybe that is where the secret lies. Interestingly, the size of that library has gone from 664784 to 108988. That suggests that there were some rather major changes there, doesn't it? ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-11 15:11 Message: Logged In: YES user_id=392704 Yes, I thought it looked like it was a FreeBSD bug too. Unfortunately, though, my little test program produced a nice listing of my / directory. I still think it is FreeBSD's problem, but it is at least a little bit subtle. I suppose I should build the latest FreeBSD sources before proceeding any further with this. #include int main(){ int c; FILE *fp; fp = popen("ls /", "r"); if (fp == NULL) { fprintf(stderr, "popen returned NULL\n"); exit(-1); } while ((c = getc(fp)) != EOF) { putchar(c); } printf("\nDone\n"); exit(0); } ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 14:28 Message: Logged In: YES user_id=6380 Marc, the Python popen code (if you can see through the #ifdefs for non-Unix platforms :-) is a pretty straightforward call of the C library popen(). The crash you receive suggests that it has nothing to do with Python. Can you try a C program containing the same call? Something like #include main() { popen("ls -l", "r"); } Does this crash in the same way? If so, you may close this bug report and report it to the FreeBSD folks instead... ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-11 14:14 Message: Logged In: YES user_id=392704 All I know so far is that, according to the stack trace, the crash seems to occur in _fcntl in libc_r.so: (gdb) run Starting program: /usr/local/src/Python211/python Python 2.1.1 (#14, Dec 11 2001, 15:55:41) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> x = os.popen('ls /') Program received signal SIGSEGV, Segmentation fault. 0x280e32ee in _fcntl () from /usr/lib/libc_r.so.5 (gdb) backtrace #0 0x280e32ee in _fcntl () from /usr/lib/libc_r.so.5 #1 0x28391c99 in fdopen () from /usr/lib/libc.so.5 #2 0x2834bf30 in popen () from /usr/lib/libc.so.5 #3 0x80735b1 in posix_popen (self=0x0, args=0x80f488c) at ./Modules/posixmodule.c:2936 #4 0x805921e in call_cfunction (func=0x80d0820, arg=0x80f488c, kw=0x0) at Python/ceval.c:2845 #5 0x8057cb1 in eval_code2 (co=0x8159ac0, globals=0x80e0ccc, locals=0x80e0ccc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:1948 #6 0x8055171 in PyEval_EvalCode (co=0x8159ac0, globals=0x80e0ccc, locals=0x80e0ccc) at Python/ceval.c:341 #7 0x806ca8f in run_node (n=0x8158280, filename=0x80a202d "", globals=0x80e0ccc, locals=0x80e0ccc, flags=0xbfbff70c) at Python/pythonrun.c:1045 #8 0x806bc86 in PyRun_InteractiveOneFlags (fp=0x80c93a0, filename=0x80a202d "", flags=0xbfbff70c) at Python/pythonrun.c:570 #9 0x806bae6 in PyRun_InteractiveLoopFlags (fp=0x80c93a0, filename=0x80a202d "", flags=0xbfbff70c) at Python/pythonrun.c:510 #10 0x806b9db in PyRun_AnyFileExFlags (fp=0x80c93a0, filename=0x80a202d "", closeit=0, flags=0xbfbff70c) at Python/pythonrun.c:473 #11 0x805222c in Py_Main (argc=0, argv=0xbfbff784) at Modules/main.c:320 #12 0x8051d04 in main (argc=1, argv=0xbfbff784) at Modules/python.c:10 #13 0x8051c35 in _start () ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 12:58 Message: Logged In: YES user_id=21627 Can't reproduce this on FreeBSD 4.4, either, using the current CVS. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:18 Message: Logged In: YES user_id=6380 I can't reproduce this, and I don't have access to a FreeBSD 5 machine. Can you debug this yourself? We'd welcome a patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 From noreply@sourceforge.net Thu Dec 13 04:26:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 20:26:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-492345 ] New-style class with only classic bases Message-ID: Bugs item #492345, was opened at 2001-12-12 20:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492345&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: New-style class with only classic bases Initial Comment: I just tried this: >>> class A: pass ... >>> class B: pass ... >>> class C(A, B): __metaclass__ = type ... Traceback (most recent call last): File "", line 1, in ? SystemError: NULL result without error in PyObject_Call >>> ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492345&group_id=5470 From noreply@sourceforge.net Thu Dec 13 04:44:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 20:44:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-492349 ] detail: tp_basicsize and tp_itemsize Message-ID: Bugs item #492349, was opened at 2001-12-12 20:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492349&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 4 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: detail: tp_basicsize and tp_itemsize Initial Comment: > Here's another question: for extensible types (which can grow beyond > tp_basicsize), I am guessing you give no guarantees about the aligment of > the following elements, so it's up to the programmer to make sure that > tp_basicsize is a multiple of the alignment of whatever's being put in the > extensible area. > > If that's true, I think the docs should say so. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492349&group_id=5470 From noreply@sourceforge.net Thu Dec 13 04:59:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 20:59:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-492345 ] New-style class with only classic bases Message-ID: Bugs item #492345, was opened at 2001-12-12 20:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492345&group_id=5470 >Category: Type/class unification >Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Guido van Rossum (gvanrossum) >Assigned to: Guido van Rossum (gvanrossum) Summary: New-style class with only classic bases Initial Comment: I just tried this: >>> class A: pass ... >>> class B: pass ... >>> class C(A, B): __metaclass__ = type ... Traceback (most recent call last): File "", line 1, in ? SystemError: NULL result without error in PyObject_Call >>> ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-12 20:59 Message: Logged In: YES user_id=6380 Oops, that was easier than I feared. best_bases() returned NULL without an error; there was an assert though in debug mode that helped me find it quickly. I've decided for now to declare this an error -- if you have a new-style metaclass, you must have at least one new-style base class. (I first tried to fix it, but after making the class statement pass, the constructed class couldn't be instantiated and didn't have 'object' in its __mro__, so I gave up quickly. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492345&group_id=5470 From noreply@sourceforge.net Thu Dec 13 06:38:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 22:38:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-488730 ] os.popen() seg faults on FreeBSD 5 Message-ID: Bugs item #488730, was opened at 2001-12-03 21:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Marc Culler (marcculler) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen() seg faults on FreeBSD 5 Initial Comment: Here is the crash with Python 2.1.1 on my FreeBSD 5.0-current system: [ace:culler]$ python Python 2.1.1 (#5, Aug 18 2001, 17:41:43) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') Segmentation fault (core dumped) No problem occurs when I do the same thing in Python 2.0, which was compiled under FreeBSD 4, but is running here under FreeBSD 5: [ace:culler]$ python2.0 Python 2.0 (#2, Nov 16 2000, 22:22:48) [GCC 2.95.2 19991024 (release)] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') >>> mypipe.readlines() ['COPYRIGHT\012', 'bin\012', 'boot\012', 'cdrom\012', 'compat\012', 'dev\012', 'dist\012', 'entropy\012', 'etc\012', 'home\012', 'kernel\012', 'kernel.GENERIC\012', 'kernel.old\012', 'kernel.prev\012', 'mnt\012', 'modules\012', 'modules.old\012', 'proc\012', 'root\012', 'sbin\012', 'shared\012', 'stand\012', 'sys\012', 'tmp\012', 'usr\012', 'var\012'] >>> ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-12 22:38 Message: Logged In: YES user_id=21627 It would be best if you ask a BSD expert for advise. I consider the notion of incompatible C libraries broken beyond repair (the only other system that does that is MS VC++, for debug and non-debug C libraries), so you really need to dig out some documentation that elaborates the problem and proposes work-arounds. Please do ldd on the resulting Python binary to see whether it directly links with libc. If it does, add the option -v to the linker line; most likely, gcc implicitly passes a -lc option. You may experiment with passing -pthread to the linker line (and all compiler lines) in this case. Another potential cause is that other libraries (like -ltk82) drag in libc.so. In that case, I'd say it is hopeless: you have than the following options 1. do not build a multi-threaded python, 2. do not build a Python that incorporates _tkinter (not sure that building tkinter as a shared module would help; you really need that expert to answer that question) 3. rebuild Tcl/Tk to link with -lc_r. If you ask that we do something about it: We could either add some text to README, or refuse to build --with-threads on FreeBSD. ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-12 20:13 Message: Logged In: YES user_id=392704 We are getting closer! Yes, it does seem to be related to linking against both libc and libc_r. If I compile the test program as follows: gcc -o test test.c -lc -lc_r I get a seg fault at the same location in _fcntl (and the backtrace shows that the libc_r version of _fcntl is being called from the libc version of fdopen). If I use just -lc, or just -lc_r, or even -lc_r -lc then the test program runs fine. So let's assume that the libc and libc_r versions of _fcntl use different structures for file descriptor table entries, or some such thing. The next question is how do I prevent python from being linked against both libraries? I looked through the output of make and nowhere did I see an explicit -lc flag. In the makefile it says LIBS= -lc_r -lutil and the linker command being used to link python is gcc -Wl,--export-dynamic -o python Modules/python.o libpython2.1.a -lc_r -lutil -L/usr/local/lib -ltk82 -ltcl82 -L/usr/X11R6/lib -lX11 -lm So why is it linking against libc and how do I make it stop? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-12 04:43 Message: Logged In: YES user_id=6380 Good point. The experiment with a little C program should be repeated, compiling and linking it with exactly the same flags as Python is compiled and linked. (Statically, since the posix module is statically linked into Python.) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 23:57 Message: Logged In: YES user_id=21627 Could that be one of those "it's BSD, never mix threading and non-threading C libraries" bugs? I find it surprising that it crashes inside the C library; the only known causes (besides genuine bugs) are: - memory management got corrupted. Without seeing the source of _fcntl, I think this is unlikely. - caller and callee have different ideas of how structures are layed out, due to being compiled with different definitions of those structures. Are you sure it is correct to link with both libc and libc_r simultaneously? Are there additional variants of the C library which only work in certain combinations? Is this documented anywhere? ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-11 15:43 Message: Logged In: YES user_id=392704 As to the subtlety of this bug, I meant to point out that Python 2.0, which presumably has a nearly identical posix module, has a working os.popen(). On the other hand, Python2.0 loads libc_r.so.4 rather than libc_r.so.5. So maybe that is where the secret lies. Interestingly, the size of that library has gone from 664784 to 108988. That suggests that there were some rather major changes there, doesn't it? ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-11 15:11 Message: Logged In: YES user_id=392704 Yes, I thought it looked like it was a FreeBSD bug too. Unfortunately, though, my little test program produced a nice listing of my / directory. I still think it is FreeBSD's problem, but it is at least a little bit subtle. I suppose I should build the latest FreeBSD sources before proceeding any further with this. #include int main(){ int c; FILE *fp; fp = popen("ls /", "r"); if (fp == NULL) { fprintf(stderr, "popen returned NULL\n"); exit(-1); } while ((c = getc(fp)) != EOF) { putchar(c); } printf("\nDone\n"); exit(0); } ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 14:28 Message: Logged In: YES user_id=6380 Marc, the Python popen code (if you can see through the #ifdefs for non-Unix platforms :-) is a pretty straightforward call of the C library popen(). The crash you receive suggests that it has nothing to do with Python. Can you try a C program containing the same call? Something like #include main() { popen("ls -l", "r"); } Does this crash in the same way? If so, you may close this bug report and report it to the FreeBSD folks instead... ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-11 14:14 Message: Logged In: YES user_id=392704 All I know so far is that, according to the stack trace, the crash seems to occur in _fcntl in libc_r.so: (gdb) run Starting program: /usr/local/src/Python211/python Python 2.1.1 (#14, Dec 11 2001, 15:55:41) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> x = os.popen('ls /') Program received signal SIGSEGV, Segmentation fault. 0x280e32ee in _fcntl () from /usr/lib/libc_r.so.5 (gdb) backtrace #0 0x280e32ee in _fcntl () from /usr/lib/libc_r.so.5 #1 0x28391c99 in fdopen () from /usr/lib/libc.so.5 #2 0x2834bf30 in popen () from /usr/lib/libc.so.5 #3 0x80735b1 in posix_popen (self=0x0, args=0x80f488c) at ./Modules/posixmodule.c:2936 #4 0x805921e in call_cfunction (func=0x80d0820, arg=0x80f488c, kw=0x0) at Python/ceval.c:2845 #5 0x8057cb1 in eval_code2 (co=0x8159ac0, globals=0x80e0ccc, locals=0x80e0ccc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:1948 #6 0x8055171 in PyEval_EvalCode (co=0x8159ac0, globals=0x80e0ccc, locals=0x80e0ccc) at Python/ceval.c:341 #7 0x806ca8f in run_node (n=0x8158280, filename=0x80a202d "", globals=0x80e0ccc, locals=0x80e0ccc, flags=0xbfbff70c) at Python/pythonrun.c:1045 #8 0x806bc86 in PyRun_InteractiveOneFlags (fp=0x80c93a0, filename=0x80a202d "", flags=0xbfbff70c) at Python/pythonrun.c:570 #9 0x806bae6 in PyRun_InteractiveLoopFlags (fp=0x80c93a0, filename=0x80a202d "", flags=0xbfbff70c) at Python/pythonrun.c:510 #10 0x806b9db in PyRun_AnyFileExFlags (fp=0x80c93a0, filename=0x80a202d "", closeit=0, flags=0xbfbff70c) at Python/pythonrun.c:473 #11 0x805222c in Py_Main (argc=0, argv=0xbfbff784) at Modules/main.c:320 #12 0x8051d04 in main (argc=1, argv=0xbfbff784) at Modules/python.c:10 #13 0x8051c35 in _start () ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 12:58 Message: Logged In: YES user_id=21627 Can't reproduce this on FreeBSD 4.4, either, using the current CVS. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:18 Message: Logged In: YES user_id=6380 I can't reproduce this, and I don't have access to a FreeBSD 5 machine. Can you debug this yourself? We'd welcome a patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 From noreply@sourceforge.net Thu Dec 13 07:05:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 23:05:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-491888 ] whichdb lies about db type Message-ID: Bugs item #491888, was opened at 2001-12-11 19:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491888&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: whichdb lies about db type Initial Comment: >>> import dbm >>> d = dbm.open('foo', 'n') >>> d['a'] = 'b' >>> d.close() >>> import whichdb >>> whichdb.whichdb('foo.db') 'dbhash' I'm currently testing for the existence of "foo.db" instead of "foo" and hard-code my routines to use dbm if there is a "foo.db" file (since all other db modules that I've tested do no append ".db") Might it also be possible to have anydbm perform a whichdb check in its open function, so that older databases are usable with newer, more feature-full installations that might include "better" dbm backends? ---------------------------------------------------------------------- >Comment By: Richard Jones (richard) Date: 2001-12-12 23:05 Message: Logged In: YES user_id=6405 Sorry about the anydbm/whichdb confusion - reading the source a little closer would have avoided my confusion. Regardless, there is still a problem that on my system, dbm files are reported as dbhash, and dbhash can't open the dbm files... [richard@co3044991-a tmp]$ python Python 2.1.1 (#1, Aug 30 2001, 17:36:05) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.61mdk)] on linux-i386 Type "copyright", "credits" or "license" for more information. >>> import dbm >>> dbm.open('foo','n') >>> import dbhash >>> dbhash.open('bar', 'n') >>> >>> import whichdb >>> whichdb.whichdb('foo.db') 'dbhash' >>> whichdb.whichdb('bar') 'dbhash' >>> dbhash.open('foo.db', 'r') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/dbhash.py", line 16, in open return bsddb.hashopen(file, flag, mode) bsddb.error: (-30990, 'Unknown error 4294936306') >>> dbhash.open('bar', 'r') >>> [richard@co3044991-a tmp]$ file foo.db foo.db: Berkeley DB (Hash, version 5, native byte-order) [richard@co3044991-a tmp]$ file bar bar: Berkeley DB (Hash, version 7, native byte-order) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-12 15:28 Message: Logged In: YES user_id=21627 I fail to see the problem altogether. What system are you on? Why do you think dbm does not create dbhash files? It is not just that the magic says they are BSDDB DB_HASH files, they really are of that kind? Also, which of the APIs (dbm, dbhash) do you consider "better"? I'd say that dbhash is better, since it builds upon bsddb. So whichdbm, and anydbm, do use the "better" dbm backend already? Where is the bug? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 20:28 Message: Logged In: YES user_id=6380 Hm. anydmb *does* use whichdb. The problem seems to be that the dbm file really *does* look like a BSD hash -- the Unix file(1) command has the same problem. But I'm not sure I understand your question. Do you have a particular patch in mind? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491888&group_id=5470 From noreply@sourceforge.net Thu Dec 13 07:57:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 12 Dec 2001 23:57:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-492386 ] Cascading menu bug on Linux Message-ID: Bugs item #492386, was opened at 2001-12-12 23:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492386&group_id=5470 Category: Tkinter Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Juhlin (faeltir) Assigned to: Nobody/Anonymous (nobody) Summary: Cascading menu bug on Linux Initial Comment: When using post() to display a cascading menu,it appears as if submenus don't get mouse events under Linux/X. I've submitted some test code below to demonstrate the problem. I'm using Linux 2.4.5/XFree86 4.1.0/Python 2.1/Tcl 8.3. I've been told that the same code works fine on Win2000. # Code to show problem with cascading menus import Tkinter def hello(): print "hello!" root = Tkinter.Tk() frame = Tkinter.Frame(root, width=200, height=200) frame.pack() menu1 = Tkinter.Menu(frame, tearoff=0) menu1.add_command(label="Foo", command=hello) menu1.add_command(label="Bar", command=hello) menu0 = Tkinter.Menu(frame, tearoff=0) menu0.add_command(label="Command 1", command=hello) #This works menu0.add_cascade(label="Menu 1", menu=menu1) #Commands used in this menu #won't work def showMenu(event): menu0.post(event.x_root, event.y_root) frame.bind("", showMenu) Tkinter.mainloop() ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492386&group_id=5470 From noreply@sourceforge.net Thu Dec 13 09:34:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 01:34:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-492403 ] exec() segfaults on closure's func_code Message-ID: Bugs item #492403, was opened at 2001-12-13 01:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492403&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Danny Yoo (dyoo) Assigned to: Nobody/Anonymous (nobody) Summary: exec() segfaults on closure's func_code Initial Comment: I was experimenting with func_code, and the documentation in: http://python.org/doc/current/lib/bltin-code-objects.html made me curious to see what would happen if I tried to exec() a closure's func_code. This produces a segfault under Python 2.1, 2.11, and 2.2b: ### >>> from __future__ import nested_scopes >>> def t1(n): ... def t2(): return n ... return t2 ... >>> f = t1(5) >>> f.func_code ", line 2> >>> exec(f.func_code) Segmentation fault ### This code also crashes if run as a program, so it's not just in the interactive interpreter. I've included a "crash.py" file that reproduces the bug. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492403&group_id=5470 From noreply@sourceforge.net Thu Dec 13 09:43:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 01:43:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-491888 ] whichdb lies about db type Message-ID: Bugs item #491888, was opened at 2001-12-11 19:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491888&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: whichdb lies about db type Initial Comment: >>> import dbm >>> d = dbm.open('foo', 'n') >>> d['a'] = 'b' >>> d.close() >>> import whichdb >>> whichdb.whichdb('foo.db') 'dbhash' I'm currently testing for the existence of "foo.db" instead of "foo" and hard-code my routines to use dbm if there is a "foo.db" file (since all other db modules that I've tested do no append ".db") Might it also be possible to have anydbm perform a whichdb check in its open function, so that older databases are usable with newer, more feature-full installations that might include "better" dbm backends? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-13 01:43 Message: Logged In: YES user_id=21627 I see. The problem appears to be that your BSDDB installation, which implements hash version 7, does not simultaneously support hash version 5 anymore. This primarily is a problem in the Sleepycat version shipped with your system (for not supporting old databases), and in glibc (for not incorporating a newer bsd db). Python can work around this problem, at best - there might always be DBHASH files that none of the DB implementations on a system can open. bsddb should expose version information, like DB_HASHVERSION and DB_HASHOLDVER (the current and the minimum hash version). Unfortunately, db_185.h, as used by bsddb.c, do not provide these constants, and db_185.h cannot be used simultaneously with db.h. db_185.h exposes a HASHVERSION constant, but that seems to stay at 2 regardless of the file version that the compatibility API uses. The right solution seems to drop support for the DB1 API, and mandate a DB2-or-better db.h. I'd personally recommend to integrate pybsddb.sf.net into Python 2.3, adding portability to BSDDB 2 if necessary (it could be a build-time decision to build either source module as bsddb). For the moment, I cannot recommend a good work-around; I see two options: - find out magically (by looking at db.h) what hash versions dbhash will support, then check the version of the hash file, and refuse to use dbash if the version won't be supported. Since this requires magic, such code should not be added to Python, but left to the application. - catch bsddb.error on dbhash.open, and retry with dbm.open. This is a heuristic which also shouldn't be added to Python, but which may be acceptable to the application. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-12-12 23:05 Message: Logged In: YES user_id=6405 Sorry about the anydbm/whichdb confusion - reading the source a little closer would have avoided my confusion. Regardless, there is still a problem that on my system, dbm files are reported as dbhash, and dbhash can't open the dbm files... [richard@co3044991-a tmp]$ python Python 2.1.1 (#1, Aug 30 2001, 17:36:05) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.61mdk)] on linux-i386 Type "copyright", "credits" or "license" for more information. >>> import dbm >>> dbm.open('foo','n') >>> import dbhash >>> dbhash.open('bar', 'n') >>> >>> import whichdb >>> whichdb.whichdb('foo.db') 'dbhash' >>> whichdb.whichdb('bar') 'dbhash' >>> dbhash.open('foo.db', 'r') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/dbhash.py", line 16, in open return bsddb.hashopen(file, flag, mode) bsddb.error: (-30990, 'Unknown error 4294936306') >>> dbhash.open('bar', 'r') >>> [richard@co3044991-a tmp]$ file foo.db foo.db: Berkeley DB (Hash, version 5, native byte-order) [richard@co3044991-a tmp]$ file bar bar: Berkeley DB (Hash, version 7, native byte-order) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-12 15:28 Message: Logged In: YES user_id=21627 I fail to see the problem altogether. What system are you on? Why do you think dbm does not create dbhash files? It is not just that the magic says they are BSDDB DB_HASH files, they really are of that kind? Also, which of the APIs (dbm, dbhash) do you consider "better"? I'd say that dbhash is better, since it builds upon bsddb. So whichdbm, and anydbm, do use the "better" dbm backend already? Where is the bug? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 20:28 Message: Logged In: YES user_id=6380 Hm. anydmb *does* use whichdb. The problem seems to be that the dbm file really *does* look like a BSD hash -- the Unix file(1) command has the same problem. But I'm not sure I understand your question. Do you have a particular patch in mind? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=491888&group_id=5470 From noreply@sourceforge.net Thu Dec 13 09:55:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 01:55:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-492403 ] exec() segfaults on closure's func_code Message-ID: Bugs item #492403, was opened at 2001-12-13 01:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492403&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Danny Yoo (dyoo) Assigned to: Nobody/Anonymous (nobody) Summary: exec() segfaults on closure's func_code Initial Comment: I was experimenting with func_code, and the documentation in: http://python.org/doc/current/lib/bltin-code-objects.html made me curious to see what would happen if I tried to exec() a closure's func_code. This produces a segfault under Python 2.1, 2.11, and 2.2b: ### >>> from __future__ import nested_scopes >>> def t1(n): ... def t2(): return n ... return t2 ... >>> f = t1(5) >>> f.func_code ", line 2> >>> exec(f.func_code) Segmentation fault ### This code also crashes if run as a program, so it's not just in the interactive interpreter. I've included a "crash.py" file that reproduces the bug. ---------------------------------------------------------------------- >Comment By: Danny Yoo (dyoo) Date: 2001-12-13 01:55 Message: Logged In: YES user_id=49843 Ok, I'm investigating this a little more. The segfault is coming from ceval.c in the Python 2.1 source, line 628: ### >>> exec(f.func_code) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 6752)] eval_code2 (co=0x810e5f8, globals=0x80cc2fc, locals=0x80cc2fc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:628 628 Python/ceval.c: No such file or directory. in Python/ceval.c (gdb) p f->f_nfreevars $1 = 1 (gdb) p closure $2 = (PyObject *) 0x0 ### Line 628 contains the following: PyObject *o = PyTuple_GET_ITEM(closure, i); Here's a backtrace after the segfault: ### (gdb) bt #0 eval_code2 (co=0x810e5f8, globals=0x80cc2fc, locals=0x80cc2fc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:628 #1 0x08054cc9 in PyEval_EvalCode (co=0x810e5f8, globals=0x80cc2fc, locals=0x80cc2fc) at Python/ceval.c:341 #2 0x08059c34 in exec_statement (f=0x80d3bc8, prog=0x810e5f8, globals=0x80b952c, locals=0x80cc2fc) at Python/ceval.c:3497 #3 0x08056890 in eval_code2 (co=0x810cd18, globals=0x80cc2fc, locals=0x80cc2fc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:1457 #4 0x08054cc9 in PyEval_EvalCode (co=0x810cd18, globals=0x80cc2fc, locals=0x80cc2fc) at Python/ceval.c:341 #5 0x0806c483 in run_node (n=0x80d82f0, filename=0x809ec2d "", globals=0x80cc2fc, locals=0x80cc2fc, flags=0xbffff958) at Python/pythonrun.c:1045 #6 0x0806b66e in PyRun_InteractiveOneFlags (fp=0x4017b3a0, filename=0x809ec2d "", flags=0xbffff958) at Python/pythonrun.c:570 #7 0x0806b4c5 in PyRun_InteractiveLoopFlags (fp=0x4017b3a0, filename=0x809ec2d "", flags=0xbffff958) at Python/pythonrun.c:510 #8 0x0806b3bb in PyRun_AnyFileExFlags (fp=0x4017b3a0, filename=0x809ec2d "", closeit=0, flags=0xbffff958) at Python/pythonrun.c:473 #9 0x08051dc0 in Py_Main (argc=1, argv=0xbffff9e4) at Modules/main.c:320 #10 0x08051888 in main (argc=1, argv=0xbffff9e4) at Modules/python.c:10 #11 0x4007e65f in __libc_start_main () from /lib/libc.so.6 ### I hope this makes sense to someone... *grin* ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492403&group_id=5470 From noreply@sourceforge.net Thu Dec 13 10:29:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 02:29:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-492403 ] exec() segfaults on closure's func_code Message-ID: Bugs item #492403, was opened at 2001-12-13 01:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492403&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 Status: Open Resolution: None >Priority: 7 Submitted By: Danny Yoo (dyoo) >Assigned to: Jeremy Hylton (jhylton) Summary: exec() segfaults on closure's func_code Initial Comment: I was experimenting with func_code, and the documentation in: http://python.org/doc/current/lib/bltin-code-objects.html made me curious to see what would happen if I tried to exec() a closure's func_code. This produces a segfault under Python 2.1, 2.11, and 2.2b: ### >>> from __future__ import nested_scopes >>> def t1(n): ... def t2(): return n ... return t2 ... >>> f = t1(5) >>> f.func_code ", line 2> >>> exec(f.func_code) Segmentation fault ### This code also crashes if run as a program, so it's not just in the interactive interpreter. I've included a "crash.py" file that reproduces the bug. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-13 02:29 Message: Logged In: YES user_id=6656 This is very similar to another bug: [ #443866 ] Evaluating func_code causing core dump It's a bit embarrassing that this didn't get fixed when that one did, but here's a fix. Maybe the check for free variables should be in PyEval_EvalCode()? But then it's harder to give sensible error messages. ---------------------------------------------------------------------- Comment By: Danny Yoo (dyoo) Date: 2001-12-13 01:55 Message: Logged In: YES user_id=49843 Ok, I'm investigating this a little more. The segfault is coming from ceval.c in the Python 2.1 source, line 628: ### >>> exec(f.func_code) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 6752)] eval_code2 (co=0x810e5f8, globals=0x80cc2fc, locals=0x80cc2fc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:628 628 Python/ceval.c: No such file or directory. in Python/ceval.c (gdb) p f->f_nfreevars $1 = 1 (gdb) p closure $2 = (PyObject *) 0x0 ### Line 628 contains the following: PyObject *o = PyTuple_GET_ITEM(closure, i); Here's a backtrace after the segfault: ### (gdb) bt #0 eval_code2 (co=0x810e5f8, globals=0x80cc2fc, locals=0x80cc2fc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:628 #1 0x08054cc9 in PyEval_EvalCode (co=0x810e5f8, globals=0x80cc2fc, locals=0x80cc2fc) at Python/ceval.c:341 #2 0x08059c34 in exec_statement (f=0x80d3bc8, prog=0x810e5f8, globals=0x80b952c, locals=0x80cc2fc) at Python/ceval.c:3497 #3 0x08056890 in eval_code2 (co=0x810cd18, globals=0x80cc2fc, locals=0x80cc2fc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:1457 #4 0x08054cc9 in PyEval_EvalCode (co=0x810cd18, globals=0x80cc2fc, locals=0x80cc2fc) at Python/ceval.c:341 #5 0x0806c483 in run_node (n=0x80d82f0, filename=0x809ec2d "", globals=0x80cc2fc, locals=0x80cc2fc, flags=0xbffff958) at Python/pythonrun.c:1045 #6 0x0806b66e in PyRun_InteractiveOneFlags (fp=0x4017b3a0, filename=0x809ec2d "", flags=0xbffff958) at Python/pythonrun.c:570 #7 0x0806b4c5 in PyRun_InteractiveLoopFlags (fp=0x4017b3a0, filename=0x809ec2d "", flags=0xbffff958) at Python/pythonrun.c:510 #8 0x0806b3bb in PyRun_AnyFileExFlags (fp=0x4017b3a0, filename=0x809ec2d "", closeit=0, flags=0xbffff958) at Python/pythonrun.c:473 #9 0x08051dc0 in Py_Main (argc=1, argv=0xbffff9e4) at Modules/main.c:320 #10 0x08051888 in main (argc=1, argv=0xbffff9e4) at Modules/python.c:10 #11 0x4007e65f in __libc_start_main () from /lib/libc.so.6 ### I hope this makes sense to someone... *grin* ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492403&group_id=5470 From noreply@sourceforge.net Thu Dec 13 14:23:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 06:23:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-492465 ] mkcwproject: custom __initialize routine Message-ID: Bugs item #492465, was opened at 2001-12-13 06:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492465&group_id=5470 Category: Macintosh Group: Feature Request Status: Open Resolution: None Priority: 1 Submitted By: Just van Rossum (jvr) Assigned to: Jack Jansen (jackjansen) Summary: mkcwproject: custom __initialize routine Initial Comment: Both for _Tkinter and CoreGraphics it is neccesary to specify a custom fragment initializer. It would be nice if this were doable with mkcwproject, as it would reduce the number of CW project file under CVS by 4... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492465&group_id=5470 From noreply@sourceforge.net Thu Dec 13 15:20:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 07:20:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-492386 ] Cascading menu bug on Linux Message-ID: Bugs item #492386, was opened at 2001-12-12 23:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492386&group_id=5470 Category: Tkinter Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Juhlin (faeltir) Assigned to: Nobody/Anonymous (nobody) Summary: Cascading menu bug on Linux Initial Comment: When using post() to display a cascading menu,it appears as if submenus don't get mouse events under Linux/X. I've submitted some test code below to demonstrate the problem. I'm using Linux 2.4.5/XFree86 4.1.0/Python 2.1/Tcl 8.3. I've been told that the same code works fine on Win2000. # Code to show problem with cascading menus import Tkinter def hello(): print "hello!" root = Tkinter.Tk() frame = Tkinter.Frame(root, width=200, height=200) frame.pack() menu1 = Tkinter.Menu(frame, tearoff=0) menu1.add_command(label="Foo", command=hello) menu1.add_command(label="Bar", command=hello) menu0 = Tkinter.Menu(frame, tearoff=0) menu0.add_command(label="Command 1", command=hello) #This works menu0.add_cascade(label="Menu 1", menu=menu1) #Commands used in this menu #won't work def showMenu(event): menu0.post(event.x_root, event.y_root) frame.bind("", showMenu) Tkinter.mainloop() ---------------------------------------------------------------------- >Comment By: Fredrik Juhlin (faeltir) Date: 2001-12-13 07:20 Message: Logged In: YES user_id=386805 My bad. I wasn't using the first-level menu as master for the second-level menu.I'm not sure how to set status for the bug-report properly, so I'll let some admin-type do that. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492386&group_id=5470 From noreply@sourceforge.net Thu Dec 13 15:42:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 07:42:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-479981 ] test_socket fails when compiled with threads (HP-UX) Message-ID: Bugs item #479981, was opened at 2001-11-09 05:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479981&group_id=5470 Category: Threads Group: Python 2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: test_socket fails when compiled with threads (HP-UX) Initial Comment: Operating System HP-UX 11.0 (64 Bit) I tried to compile Python 2.1.1 this thread support. Doing so, the tests test_socket and test_asynchat both failed with "(9, 'Bad file number')" The test_socket succeds if I compiled python without threads, so I think it's an thread-problem. The thread-test istself succeeds. I think also, that python is correctly linked against libpthread. The same Problem occurs this Python 2.2.b1. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-13 07:42 Message: Logged In: YES user_id=21627 Closing it. It could be anything: a bug in Python, in the operating system, or in gcc. Since none of the HP-UX users is confirming the problem, it is unlikely that we can resolve it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 06:24 Message: Logged In: YES user_id=6380 But how are we ever going to find out what to do about this? I'm tempted to close this -- what good is keeping it open going to do it? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-11 06:10 Message: Logged In: YES user_id=6656 Chaned summary. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-15 08:15 Message: Logged In: NO 1. As expected, there is no change whether to lock gethostbyname or not. 2. gethostbyname is said to be threadsafe at least with HPUX 11.00 and should it be on further releases. HPUX 10.X don't support native Threads anyway 3. Python 2.1 run's on 32 Bit HP-UX-Machines 4. On 64 Bit HP-UX Machines I have found that some Patches are nessesary. I don't know what exact Patch is required but have some experiences with HP-UX General-Release Patch-Bundles: September 2000 - python failed June 2001 or later - python works maybe this helps someone ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-14 06:43 Message: Logged In: YES user_id=21627 Python puts a lock around gethostbyname if gethostbyname_r is not available. I don't think that should cause a problem even if gethostbyname is thread-safe. If you want to further analyse this, you could try to put an && !defined(__hpux) around the line #define USE_GETHOSTBYNAME_LOCK If you do, please report whether it works. In that case, it would be good to know whether gethostbyname is thread-safe on *all* HP-UX versions, or just on some. Furthermore, since this wasn't reported before: Is it specific to your installation, or reproducable on all installations? Is it perhaps specific to 64-bit mode? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-12 02:12 Message: Logged In: NO Maybe the failure has to do with gethostbyname-stuff. according the hpux-manpages theese reentrant interfaces are obsolete: int gethostent_r(struct hostent *result, struct hostent_data *buffer); int gethostbyname_r(const char *name, struct hostent *result, struct hostent_data *buffer); int gethostbyaddr_r(const char *addr, int len, int type, struct hostent *result, struct hostent_data *buffer); int sethostent_r(int stayopen, struct hostent_data *buffer); int endhostent_r(struct hostent_data *buffer); The configure-script has correctly found, that there is only a gethostbyname, but no gethostbyname_r. according to the man-pages the call to gethostbyname IS thread-save: struct hostent *gethostent(void); struct hostent *gethostbyname(const char *name); struct hostent *gethostbyaddr(const char *addr, int len, int type); ... MULTITHREAD USAGE Thread Safe: Yes Cancel Safe: Yes Async-cancel Safe: No Async-signal Safe: No Is it a failure to expect the gethostbyname to be not thread-save ? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-12 01:29 Message: Logged In: NO the complete compiler line used to link together the python binary: gcc -Wl,-E -Wl,+s -Wl,+b/mosquito/python/lib/python2.1/lib- dynload -o python \ Modules/python.o \ libpython2.1.a -lnsl -ldld -lpthread -lm The compiler I used is gcc 3.01. I tried it out with the cc from HP - the same effect After installing the Kernelpatch PHKL_25475, wich supersedes both PHKL_23842 and PHKL_20942 the failure remains the same ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-09 16:13 Message: Logged In: YES user_id=21627 Can you please also check whether the patches PHKL_23842 (or equivalent) and/or PHKL_20942. The patch titles are PHKL_23842 s700_800 11.00 signal,threads,spinlock,scheduler,IDS,q3p PHKL_20942 s700_800 11.00 signal, nanosleep, spinlock, scheduler It appears that HP-UX has a number of bugs where signals, forking, and other aspects of the operating functionality stop working in the presence of threads. If you don't have these patches, it would be good if you could try to install them, and report back whether it changes anything. Notice that HP apparently has a number of patches with these titles; they seem to be intended for different machines. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-09 15:51 Message: Logged In: YES user_id=21627 What compiler are you using? Can you please report the complete compiler line used to link together the python binary? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479981&group_id=5470 From noreply@sourceforge.net Thu Dec 13 15:45:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 07:45:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-471942 ] python2.1.1 SEGV in GC on Solaris 2.7 Message-ID: Bugs item #471942, was opened at 2001-10-16 19:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Anthony Baxter (anthonybaxter) Summary: python2.1.1 SEGV in GC on Solaris 2.7 Initial Comment: I've got a Zope installation where python2.1.1 is segfaulting on Solaris2.7 - it's running a largish ZEO server. The tail of the gdb output is: #128 0x26164 in PyEval_CallObjectWithKeywords () #129 0x264c0 in PyEval_CallObjectWithKeywords () #130 0x26140 in PyEval_CallObjectWithKeywords () #131 0x25fc0 in PyEval_CallObjectWithKeywords () #132 0x517bc in PyInstance_New () #133 0x261a4 in PyEval_CallObjectWithKeywords () #134 0x25fc0 in PyEval_CallObjectWithKeywords () #135 0x42c90 in initgc () It's built with $ gcc -v Reading specs from /opt/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs gcc version 2.95.2 19991024 (release) which is a bit old. I'm going to rebuild with gcc3.0 and also try turning off the GC. Unfortunately I can't get this to happen on a smaller test system - it's only under load that it plows into the ground. I'll also leave symbols in this time... :/ ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-13 07:45 Message: Logged In: YES user_id=21627 What do you mean with "the same trouble"? Merely that Python crashes, or do you have some more specific information to contribute? ---------------------------------------------------------------------- Comment By: Joseph Wayne Norton (natsukashi) Date: 2001-12-11 18:37 Message: Logged In: YES user_id=358486 Do you have any updates on this issue? I'm facing the same trouble on the following solaris platform: SunOS i04sv2008 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-80 regards, - j ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-04 23:38 Message: Logged In: YES user_id=29957 Nah, this is a separate one to the frame bug. I'm still seeing it on a regular regular basis, but haven't narrowed it done to what's causing it. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-04 08:48 Message: Logged In: YES user_id=31392 This was the bug that was tracked down to a problem in try/except/finally, wasn't it? If this is fixed, can you close the bug report? If not, can you provide an udpate on its current status? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-07 14:13 Message: Logged In: YES user_id=21627 Any news on this report: did the problem disappear after backporting changes? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 04:32 Message: Logged In: YES user_id=21627 Looking at the changes since 2.1.1, I can see one bugfix that might explain strange behaviour, namely ceval.c 2.277. If you want to try it out, you can get the change here http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Python/ceval.c.diff?r1=2.276&r2=2.277 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 03:59 Message: Logged In: YES user_id=29957 What's the appropriate way to ask this? drop a line to python-dev? purify's showing a UMR in strop_expandtabs (from memory - don't have it on screen right now) when python starts up. Yeah, the realloc bug concerns me - I have to wonder if something's a little bit/lot screwy. I just don't know where. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 03:46 Message: Logged In: YES user_id=21627 This is something to ask the pythonlabs folks; I believe Python has been purified once in a while - perhaps even with Zope extensions. I'd still suspect a bug in the Zope extensions instead of a Python bug, though: if malloc crashes, chances are high that somebody was overwriting free memory. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 03:31 Message: Logged In: YES user_id=29957 It's not a GC object. I'm positive all the extension objects are correct - I just recompiled, without the 1.5/2.0 headers around. It's a different pointer each time round, unfortunately. It also takes anything from 5 minutes to 2 hours to reproduce. I've got about 4 copies of it running now, and I've got a bunch of different core files. I've grabbed purify and an eval license, and I'm feeding it the binary. The printf approach is probably not going to work - these are busy busy Zope servers. Instead, my plan, assuming that purify doesn't immediately spot a problem, is to change the code so that if it gets a dud GC object, it will just bust it out of the tree and let it leak, and print a message saying so. Then I can quit the program, and purify will tell me 'hey, you leaked!' and also tell me where it was allocated. More concerning, about half the segfaults are not from the GC at all, but from realloc in PyFrame_New (line 161 of frameobject). These are the only two I'm getting - it's split 50-50 amongst the 10 coredumps I have now. I'm not sure whether to open a seperate bug for this. Has python2.1.1 been purified? With Zope and zope's extensions? Wow - it's amazing how this SF bug thing is so painful for conversations :) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 03:11 Message: Logged In: YES user_id=21627 There are two options: a) the object isn't really a GC object, i.e. has no GC header. In gdb, you can try to cast gc to PyObject*, then see if the resulting pointer has a better ob_type (this is unlikely, though, since the logic entering the object was already using fromgc/togc) b) somebody has cleared the ob_type field. Can you guarantee that all extension modules have been compiled with the 2.1.1 header files? Is the problem repeatable in the sense that gc will have the same pointer value on each crash? If so, it is relatively easy to track down: just set a gdb change watchpoint on the address on the ob_type field of that address (note that setting watchpoints is not possible until there is really mapped memory on that address). If you can't analyse it through change breakpoints, I recommend to annotate the interpreter in the following way: in pyobject_init, put a printf that prints the address and the tp_name of the type. In subtract_refs, if the ob_type slot is null, print the address of the object and abort. Then analyse the log to see whether a object really has been allocated on that address, and what its type was (make sure you consider the possibility that address are off by the delta that FROM_GC adds). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-17 21:58 Message: Logged In: YES user_id=29957 Ok, I have an intact core file, and a matching binary, no optimisations, nothing. This crash is showing the crash at line 166 of gcmodule.c traverse = PyObject_FROM_GC(gc)->ob_type->tp_traverse; PyObject_FROM_GC(gc)->ob_type in this case is $24 = {ob_refcnt = 1, ob_type = 0x0} To check my logic, I checked gc_next and gc_prev using the same GDB magic, and they correctly show up as a tuple and an instance method. Some fiddling around seems to rule out stack space as the problem, as well. We're going to try and see if purify helps here, but the problem looks to be a junk object - I have no idea how to track this down further. Help? Would taking the horrible horrible hack of removing the object from the gc linked list if ob_type is null help? Well, it'd stop the crashes, anyway. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-17 13:44 Message: Logged In: YES user_id=21627 It would be interesting what the value of "gc" is at the time of the crash. It looks like you got an object that claims to support GC but has a null tp_traverse. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-17 06:08 Message: Logged In: YES user_id=29957 I'm a doofus who read the gdb trace from the wrong end - too much python lately :) Nonetheless, the other end of the trace failed in gc as well - and building without GC enabled worked. Here's the trace with debugging enabled: #0 0xff00 in ?? () #1 0x402f0 in collect (young=0x9b538, old=0x9b544) at ./Modules/gcmodule.c:379 #2 0x405a8 in collect_generations () at ./Modules/gcmodule.c:484 #3 0x40624 in _PyGC_Insert (op=0xbc1f24) at ./Modules/gcmodule.c:507 #4 0x5a224 in PyList_New (size=0) at Objects/listobject.c:61 #5 0x21bc8 in eval_code2 (co=0x1cb370, globals=0x21bc0, locals=0x67, args=0x0, argcount=1, kws=0xf89b24, kwcount=0, defs=0x0, defcount=0, closure=0xbc1f24) at Python/ceval.c:1741 Next trick is to rebuild without any optimisation (sigh) as I suspect that it's inlined subtract_refs(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 From noreply@sourceforge.net Thu Dec 13 15:49:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 07:49:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-492496 ] distutils, shared libraries and Mac OS X Message-ID: Bugs item #492496, was opened at 2001-12-13 07:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492496&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew King (kyrrigle) Assigned to: Nobody/Anonymous (nobody) Summary: distutils, shared libraries and Mac OS X Initial Comment: My python: Python 2.1.1 (#33, Dec 9 2001, 12:26:52) [GCC 2.95.2 19991024 (release)] on darwin5 I was trying to configure the sketch app and setup.py was complaining that it could not find my tcl/tk libraries. The problem is that Darwin uses the .dylib extension for shared libraries and distutils was looking for .so. as a "fix", in distutils/unixccompiler.py I made the following change: 76c76,78 < --- > import sys > if sys.platform[:-1] == "darwin": # Mac OS X > shared_lib_extension = ".dylib" this worked, but I'm sure there's a better way... i'd imagine that this would also be an issue on HP-UX with the .sl extension? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492496&group_id=5470 From noreply@sourceforge.net Thu Dec 13 16:17:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 08:17:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-492496 ] distutils, shared libraries and Mac OS X Message-ID: Bugs item #492496, was opened at 2001-12-13 07:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492496&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None >Priority: 1 Submitted By: Matthew King (kyrrigle) Assigned to: Nobody/Anonymous (nobody) Summary: distutils, shared libraries and Mac OS X Initial Comment: My python: Python 2.1.1 (#33, Dec 9 2001, 12:26:52) [GCC 2.95.2 19991024 (release)] on darwin5 I was trying to configure the sketch app and setup.py was complaining that it could not find my tcl/tk libraries. The problem is that Darwin uses the .dylib extension for shared libraries and distutils was looking for .so. as a "fix", in distutils/unixccompiler.py I made the following change: 76c76,78 < --- > import sys > if sys.platform[:-1] == "darwin": # Mac OS X > shared_lib_extension = ".dylib" this worked, but I'm sure there's a better way... i'd imagine that this would also be an issue on HP-UX with the .sl extension? ---------------------------------------------------------------------- >Comment By: Matthew King (kyrrigle) Date: 2001-12-13 08:17 Message: Logged In: YES user_id=247536 looks like patch #450862 already addresses this issue for .dylib ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492496&group_id=5470 From noreply@sourceforge.net Thu Dec 13 17:23:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 09:23:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-225003 ] Extension manual: Windows DLL/C++ info needs review Message-ID: Bugs item #225003, was opened at 2000-12-08 07:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=225003&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None >Priority: 4 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: Extension manual: Windows DLL/C++ info needs review Initial Comment: The section on building extensions on Windows needs to be updated. A single section, shared for Unix & Windows, needs to point out the distutils approach and point to the appropriate manual. Information about linking, DLLs/shared libraries, and use of C++ needs to be reviewed and updated. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-13 09:23 Message: Logged In: YES user_id=3066 The instructions for building extensions on Windows have been completely replaced in Doc/ext/windows.tex revision 1.3. The DLL discussion and C++ usage documentation still needs to be reviewed, but the known-broken docs have been corrected. Lowering the priority of the remaining aspects of this report, and changing the summary line. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-11 21:53 Message: Logged In: YES user_id=3066 This is closely related to SF bug #221671. Bumping the priority to match. I'll plan to get this done for 2.2rc1; Alex, I'll expect you to review the updated material once the release candidate is out so I can get your comments before the final release. ;-) ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2001-08-17 00:52 Message: Logged In: YES user_id=60314 Yes, I fully agree -- the information in the manual at http://python.sourceforge.net/devel-docs/ext/win- cookbook.html is positively wrong, and one of the major causes of help requests in my experience -- people look for inexistent http://starship.python.net/crew/da/compile/, download the sources to get a pyconfig.h they don't need and look for a PC\pyconfig.h that doesn't exist, and get tied into knots writing a Setup file. Seems a very serious situation to me. While we wait to do it 'just right', couldn't at least the present erroneous text be replaced with some temporary pointer e.g. to some of the various posts on the subject (cfr http://groups.google.com/groups? as_q=setup.py&as_uauthors=alex%20martelli for many examples, or my apparently popular recipe at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/6650 9, or...?) -- I'll be happy to write/rewrite this stuff with whatever mods you require, Fred, except that I can't seem to use the 'official' way to write Python docs (LaTex etc etc -- I thought a Linux box would make it easy but i'm still having problems setting it up, sigh). Let me know if I can be of help in any way, but I think that, particularly now with the nice new material in chapter 2, it's a positive ill to leave chapter 4 as it is now...:-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=225003&group_id=5470 From noreply@sourceforge.net Thu Dec 13 17:25:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 09:25:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-221671 ] bad link David Ascher's compile.py script Message-ID: Bugs item #221671, was opened at 2000-11-05 08:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=221671&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Mark Phillips (mphillips) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: bad link David Ascher's compile.py script Initial Comment: The document "Extending and Embedding the Python Interpreter, October 16, 2000, Release 2.0", at http://www.python.org/doc/current/ext/win-cookbook.html contains a bad link to bad link David Ascher's compile.py script; the link is to http://starship.python.net/crew/da/compile/ but this URL doesn't work (it redirects to one that refuses connections). It'd be great if someone could put compile.py someplace accessible and fix this link! --Mark ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-13 09:25 Message: Logged In: YES user_id=3066 I've completely replaced the "cookbook" approach with new instructions. There is no more broken link to the old compile.py script. Fixed in Doc/ext/windows.tex revision 1.3. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-11 21:49 Message: Logged In: YES user_id=3066 This keeps coming back to bite users. I've looked around to see whether I have all the information I need to update this (I think I do), so I'm raising the priority to make sure I get this done. I should be able to have this done for 2.2rc1. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-04 21:49 Message: Logged In: YES user_id=3066 The entire section that links to this script is seriously in need of updating. I'll try to look at this tomorrow. Bumping the priority up, but not so much as to block the release. ---------------------------------------------------------------------- Comment By: David Ascher (david_ascher) Date: 2001-09-05 22:37 Message: Logged In: YES user_id=6114 I'll gladly provide the script, but I've lost any energy keeping a permanent website up. I haven't touched the script in ages. I agree that distutils is probably the way to go at this point. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-11-08 22:38 Message: This is a known problem. I have a copy of the script, but I need someone to test it to make sure it works with Python 2.0. Another possibility is to push the Distutils tools; that may be a better option at this point. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=221671&group_id=5470 From noreply@sourceforge.net Thu Dec 13 20:03:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 12:03:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-480325 ] Tkinter crash on Win2000, OK on UNIX Message-ID: Bugs item #480325, was opened at 2001-11-10 01:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=480325&group_id=5470 Category: Tkinter >Group: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: John W Lewis (lewisjwl) >Assigned to: Martin v. Löwis (loewis) Summary: Tkinter crash on Win2000, OK on UNIX Initial Comment: Large Python/Tkinter application.... 2GB virtual, 3600 images, 3600 graphic objects, 3600x3600 arrays 3200x1600 dual monitor graphics Runs OK under 2.1.1 Python and Solaris8 Crashes in TK on Windows2000 at 3200 images DELL 530 workstation with 4GB RAM Windows 2000 SR1 2.1.1 Python How do I go about isolating this problem? Thanks John Lewis ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-13 12:03 Message: Logged In: YES user_id=31435 This reprot has sat a month without the requested followup, and there's no evidence of a Python bug, so closing as WontFix and presumed 3rdParty. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-13 00:56 Message: Logged In: YES user_id=21627 It helps to a degree, but only insofar as recognizing this as a Tk problem. If you have the Tk source, you may want to follow what I present as a theory: In generic/tkImgPhoto.c:ImgPhotoInstanceSetSize, it invokes Tk_GetPixmap. This is implemented in win/tkWinPixmap.c. If CreateBitmap fails, it will return None, which is 0. So back in ImgPhotoInstanceSetSize, it will pass the null pointer to TkSetPixmapColormap, which is again implemented in tkWinPixmap.c, where it says twdPtr->bitmap.colormap = colormap; Since twdPtr comes from pixmap, which comes from newPixmap, which may be null, this is a null-pointer access, which causes the Access Violation. Since this is the only action in TkSetPixmapColormap, and since ImgPhotoInstanceSetSize is the only place where TkSetPixmapColormap, this theory is quite likely, IMO, but only single-stepping in a debugger may tell for sure. In any case, it seems that CreateBitmap fails, which means that you are running out of bitmap handles. To my knowledge, on Win32, this only happens when you run out of memory; a Windows expert may be able to give a more detailed analysis. I see two problems: - why doesn't Tk report the error properly? It doesn't always check the return value, which it should; please report that as a Tk bug: This is nothing we can do much about; we won't go into the business of fixing Tk for ourselves. - why does it run out of bitmap handles? This depends on whether it is supposed to run out of bitmap handles: If it is out of memory, there is not much you could do - it is an application bug to allocate so many of them. If you are not out of memory, why does it fail to create more bitmaps? That would be a Windows bug; please report it to Microsoft :-) Perhaps MS has documented limitations on creating too many bitmaps; if so, the ball is back on Tk's side, which should use bitmap handles more conservatively, or on the application's side, which should not create so many bitmaps. Perhaps this is something completely different; only a debugger run could tell. ---------------------------------------------------------------------- Comment By: John W Lewis (lewisjwl) Date: 2001-11-12 09:27 Message: Logged In: YES user_id=89001 >From the dump file.... Microsoft (R) WIndows 2000 (TM) Version 5.00 DrWtsn32 Application exception occured App: (pid=1052) Exception number: c0000005 (access violation) Number of processors: 2 Processor Type x86 family 15 Model 0 Stepping 10 Windows 2000 VErsion: 5.0 Current Build 2195 Service Pack: 1 Current Type: Multiprocessor Free !TkSetPixmapColormap !Tk_CreatePhotoImageFormat !Tk_CreatePhotoImageFormat !Tk_CreatePhotoImageFormat !Tk_GetImage !Tk_InvokeButton !Tk_InvokeButton !Tk_CanvasObjCmd !Tcl_EvalObjv !Tcl_EvalObjv ! Is this helpful? John ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-10 06:07 Message: Logged In: YES user_id=21627 I recommend to attach to the process with a debugger (e.g. VC++). If you manage to do this, please report the stack trace at the moment of the crash. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=480325&group_id=5470 From noreply@sourceforge.net Thu Dec 13 20:04:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 12:04:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-492403 ] exec() segfaults on closure's func_code Message-ID: Bugs item #492403, was opened at 2001-12-13 01:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492403&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Danny Yoo (dyoo) Assigned to: Jeremy Hylton (jhylton) Summary: exec() segfaults on closure's func_code Initial Comment: I was experimenting with func_code, and the documentation in: http://python.org/doc/current/lib/bltin-code-objects.html made me curious to see what would happen if I tried to exec() a closure's func_code. This produces a segfault under Python 2.1, 2.11, and 2.2b: ### >>> from __future__ import nested_scopes >>> def t1(n): ... def t2(): return n ... return t2 ... >>> f = t1(5) >>> f.func_code ", line 2> >>> exec(f.func_code) Segmentation fault ### This code also crashes if run as a program, so it's not just in the interactive interpreter. I've included a "crash.py" file that reproduces the bug. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-12-13 12:04 Message: Logged In: YES user_id=31392 Fixed in rev 2.297 of ceval.c ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-13 02:29 Message: Logged In: YES user_id=6656 This is very similar to another bug: [ #443866 ] Evaluating func_code causing core dump It's a bit embarrassing that this didn't get fixed when that one did, but here's a fix. Maybe the check for free variables should be in PyEval_EvalCode()? But then it's harder to give sensible error messages. ---------------------------------------------------------------------- Comment By: Danny Yoo (dyoo) Date: 2001-12-13 01:55 Message: Logged In: YES user_id=49843 Ok, I'm investigating this a little more. The segfault is coming from ceval.c in the Python 2.1 source, line 628: ### >>> exec(f.func_code) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 6752)] eval_code2 (co=0x810e5f8, globals=0x80cc2fc, locals=0x80cc2fc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:628 628 Python/ceval.c: No such file or directory. in Python/ceval.c (gdb) p f->f_nfreevars $1 = 1 (gdb) p closure $2 = (PyObject *) 0x0 ### Line 628 contains the following: PyObject *o = PyTuple_GET_ITEM(closure, i); Here's a backtrace after the segfault: ### (gdb) bt #0 eval_code2 (co=0x810e5f8, globals=0x80cc2fc, locals=0x80cc2fc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:628 #1 0x08054cc9 in PyEval_EvalCode (co=0x810e5f8, globals=0x80cc2fc, locals=0x80cc2fc) at Python/ceval.c:341 #2 0x08059c34 in exec_statement (f=0x80d3bc8, prog=0x810e5f8, globals=0x80b952c, locals=0x80cc2fc) at Python/ceval.c:3497 #3 0x08056890 in eval_code2 (co=0x810cd18, globals=0x80cc2fc, locals=0x80cc2fc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:1457 #4 0x08054cc9 in PyEval_EvalCode (co=0x810cd18, globals=0x80cc2fc, locals=0x80cc2fc) at Python/ceval.c:341 #5 0x0806c483 in run_node (n=0x80d82f0, filename=0x809ec2d "", globals=0x80cc2fc, locals=0x80cc2fc, flags=0xbffff958) at Python/pythonrun.c:1045 #6 0x0806b66e in PyRun_InteractiveOneFlags (fp=0x4017b3a0, filename=0x809ec2d "", flags=0xbffff958) at Python/pythonrun.c:570 #7 0x0806b4c5 in PyRun_InteractiveLoopFlags (fp=0x4017b3a0, filename=0x809ec2d "", flags=0xbffff958) at Python/pythonrun.c:510 #8 0x0806b3bb in PyRun_AnyFileExFlags (fp=0x4017b3a0, filename=0x809ec2d "", closeit=0, flags=0xbffff958) at Python/pythonrun.c:473 #9 0x08051dc0 in Py_Main (argc=1, argv=0xbffff9e4) at Modules/main.c:320 #10 0x08051888 in main (argc=1, argv=0xbffff9e4) at Modules/python.c:10 #11 0x4007e65f in __libc_start_main () from /lib/libc.so.6 ### I hope this makes sense to someone... *grin* ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492403&group_id=5470 From noreply@sourceforge.net Thu Dec 13 20:12:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 12:12:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-471942 ] python2.1.1 SEGV in GC on Solaris 2.7 Message-ID: Bugs item #471942, was opened at 2001-10-16 19:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Anthony Baxter (anthonybaxter) Summary: python2.1.1 SEGV in GC on Solaris 2.7 Initial Comment: I've got a Zope installation where python2.1.1 is segfaulting on Solaris2.7 - it's running a largish ZEO server. The tail of the gdb output is: #128 0x26164 in PyEval_CallObjectWithKeywords () #129 0x264c0 in PyEval_CallObjectWithKeywords () #130 0x26140 in PyEval_CallObjectWithKeywords () #131 0x25fc0 in PyEval_CallObjectWithKeywords () #132 0x517bc in PyInstance_New () #133 0x261a4 in PyEval_CallObjectWithKeywords () #134 0x25fc0 in PyEval_CallObjectWithKeywords () #135 0x42c90 in initgc () It's built with $ gcc -v Reading specs from /opt/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs gcc version 2.95.2 19991024 (release) which is a bit old. I'm going to rebuild with gcc3.0 and also try turning off the GC. Unfortunately I can't get this to happen on a smaller test system - it's only under load that it plows into the ground. I'll also leave symbols in this time... :/ ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-13 12:12 Message: Logged In: YES user_id=31435 Just noting that the function names reported in the traceback in the original writeup are bogus: PyEval_CallObjectWithKeywords() doesn't call itself. Looks like gdb doesn't have enough info to report the true function name, so picks a function it does know about at an earlier address (or something ). I'm told this doesn't happen on Linux, but don't grasp why it might on Solaris. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-13 07:45 Message: Logged In: YES user_id=21627 What do you mean with "the same trouble"? Merely that Python crashes, or do you have some more specific information to contribute? ---------------------------------------------------------------------- Comment By: Joseph Wayne Norton (natsukashi) Date: 2001-12-11 18:37 Message: Logged In: YES user_id=358486 Do you have any updates on this issue? I'm facing the same trouble on the following solaris platform: SunOS i04sv2008 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-80 regards, - j ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-04 23:38 Message: Logged In: YES user_id=29957 Nah, this is a separate one to the frame bug. I'm still seeing it on a regular regular basis, but haven't narrowed it done to what's causing it. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-04 08:48 Message: Logged In: YES user_id=31392 This was the bug that was tracked down to a problem in try/except/finally, wasn't it? If this is fixed, can you close the bug report? If not, can you provide an udpate on its current status? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-07 14:13 Message: Logged In: YES user_id=21627 Any news on this report: did the problem disappear after backporting changes? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 04:32 Message: Logged In: YES user_id=21627 Looking at the changes since 2.1.1, I can see one bugfix that might explain strange behaviour, namely ceval.c 2.277. If you want to try it out, you can get the change here http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Python/ceval.c.diff?r1=2.276&r2=2.277 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 03:59 Message: Logged In: YES user_id=29957 What's the appropriate way to ask this? drop a line to python-dev? purify's showing a UMR in strop_expandtabs (from memory - don't have it on screen right now) when python starts up. Yeah, the realloc bug concerns me - I have to wonder if something's a little bit/lot screwy. I just don't know where. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 03:46 Message: Logged In: YES user_id=21627 This is something to ask the pythonlabs folks; I believe Python has been purified once in a while - perhaps even with Zope extensions. I'd still suspect a bug in the Zope extensions instead of a Python bug, though: if malloc crashes, chances are high that somebody was overwriting free memory. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 03:31 Message: Logged In: YES user_id=29957 It's not a GC object. I'm positive all the extension objects are correct - I just recompiled, without the 1.5/2.0 headers around. It's a different pointer each time round, unfortunately. It also takes anything from 5 minutes to 2 hours to reproduce. I've got about 4 copies of it running now, and I've got a bunch of different core files. I've grabbed purify and an eval license, and I'm feeding it the binary. The printf approach is probably not going to work - these are busy busy Zope servers. Instead, my plan, assuming that purify doesn't immediately spot a problem, is to change the code so that if it gets a dud GC object, it will just bust it out of the tree and let it leak, and print a message saying so. Then I can quit the program, and purify will tell me 'hey, you leaked!' and also tell me where it was allocated. More concerning, about half the segfaults are not from the GC at all, but from realloc in PyFrame_New (line 161 of frameobject). These are the only two I'm getting - it's split 50-50 amongst the 10 coredumps I have now. I'm not sure whether to open a seperate bug for this. Has python2.1.1 been purified? With Zope and zope's extensions? Wow - it's amazing how this SF bug thing is so painful for conversations :) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 03:11 Message: Logged In: YES user_id=21627 There are two options: a) the object isn't really a GC object, i.e. has no GC header. In gdb, you can try to cast gc to PyObject*, then see if the resulting pointer has a better ob_type (this is unlikely, though, since the logic entering the object was already using fromgc/togc) b) somebody has cleared the ob_type field. Can you guarantee that all extension modules have been compiled with the 2.1.1 header files? Is the problem repeatable in the sense that gc will have the same pointer value on each crash? If so, it is relatively easy to track down: just set a gdb change watchpoint on the address on the ob_type field of that address (note that setting watchpoints is not possible until there is really mapped memory on that address). If you can't analyse it through change breakpoints, I recommend to annotate the interpreter in the following way: in pyobject_init, put a printf that prints the address and the tp_name of the type. In subtract_refs, if the ob_type slot is null, print the address of the object and abort. Then analyse the log to see whether a object really has been allocated on that address, and what its type was (make sure you consider the possibility that address are off by the delta that FROM_GC adds). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-17 21:58 Message: Logged In: YES user_id=29957 Ok, I have an intact core file, and a matching binary, no optimisations, nothing. This crash is showing the crash at line 166 of gcmodule.c traverse = PyObject_FROM_GC(gc)->ob_type->tp_traverse; PyObject_FROM_GC(gc)->ob_type in this case is $24 = {ob_refcnt = 1, ob_type = 0x0} To check my logic, I checked gc_next and gc_prev using the same GDB magic, and they correctly show up as a tuple and an instance method. Some fiddling around seems to rule out stack space as the problem, as well. We're going to try and see if purify helps here, but the problem looks to be a junk object - I have no idea how to track this down further. Help? Would taking the horrible horrible hack of removing the object from the gc linked list if ob_type is null help? Well, it'd stop the crashes, anyway. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-17 13:44 Message: Logged In: YES user_id=21627 It would be interesting what the value of "gc" is at the time of the crash. It looks like you got an object that claims to support GC but has a null tp_traverse. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-17 06:08 Message: Logged In: YES user_id=29957 I'm a doofus who read the gdb trace from the wrong end - too much python lately :) Nonetheless, the other end of the trace failed in gc as well - and building without GC enabled worked. Here's the trace with debugging enabled: #0 0xff00 in ?? () #1 0x402f0 in collect (young=0x9b538, old=0x9b544) at ./Modules/gcmodule.c:379 #2 0x405a8 in collect_generations () at ./Modules/gcmodule.c:484 #3 0x40624 in _PyGC_Insert (op=0xbc1f24) at ./Modules/gcmodule.c:507 #4 0x5a224 in PyList_New (size=0) at Objects/listobject.c:61 #5 0x21bc8 in eval_code2 (co=0x1cb370, globals=0x21bc0, locals=0x67, args=0x0, argcount=1, kws=0xf89b24, kwcount=0, defs=0x0, defcount=0, closure=0xbc1f24) at Python/ceval.c:1741 Next trick is to rebuild without any optimisation (sigh) as I suspect that it's inlined subtract_refs(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 From noreply@sourceforge.net Thu Dec 13 21:03:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 13:03:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-492619 ] __del__ docs need update Message-ID: Bugs item #492619, was opened at 2001-12-13 13:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492619&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: __del__ docs need update Initial Comment: Similarly to words added in 2.2 to the gc module docs and extension docs, the Ref Man's section on __del__ should be clearer about the interactions between objects with __del__ methods and cyclic gc. The Ref Man should also be clearer about which parts of the semantics hold across all Python implementations, and which are specific to CPython (e.g., IIRC, __del__ isn't called by magic at all in Jython). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492619&group_id=5470 From noreply@sourceforge.net Thu Dec 13 21:29:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 13:29:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-492665 ] mac support broken? Message-ID: Bugs item #492665, was opened at 2001-12-13 13:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492665&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 7 Submitted By: Just van Rossum (jvr) Assigned to: Jack Jansen (jackjansen) Summary: mac support broken? Initial Comment: When I try to build NumPy I get the following error: running build running build_py not copying :Lib:ArrayPrinter.py (output up-to-date) not copying :Lib:LinearAlgebra.py (output up-to- date) not copying :Lib:Matrix.py (output up-to-date) not copying :Lib:MLab.py (output up-to-date) not copying :Lib:Numeric.py (output up-to-date) not copying :Lib:numeric_version.py (output up-to- date) not copying :Lib:Precision.py (output up-to-date) not copying :Lib:RandomArray.py (output up-to- date) not copying :Lib:UserArray.py (output up-to-date) running build_ext building '_numpy' extension Create export file Titaantje:DevDev:python:Numeric- 20.0.0:build:temp.mac-2.2:_numpy.mcp.exp Create XML file Titaantje:DevDev:python:Numeric- 20.0.0:build:temp.mac-2.2:_numpy.xml Traceback (most recent call last): File "Titaantje:DevDev:python:Numeric- 20.0.0:setup.py", line 61, in ? libraries = libraries_list) File "Titaantje:DevDev:python:python:Lib:distutils:core.p y", line 138, in setup dist.run_commands() File "Titaantje:DevDev:python:python:Lib:distutils:dist.p y", line 893, in run_commands self.run_command(cmd) File "Titaantje:DevDev:python:python:Lib:distutils:dist.p y", line 913, in run_command cmd_obj.run() File "Titaantje:DevDev:python:python:Lib:distutils:com mand:build.py", line 107, in run self.run_command(cmd_name) File "Titaantje:DevDev:python:python:Lib:distutils:cmd.p y", line 330, in run_command self.distribution.run_command(command) File "Titaantje:DevDev:python:python:Lib:distutils:dist.p y", line 913, in run_command cmd_obj.run() File "Titaantje:DevDev:python:python:Lib:distutils:com mand:build_ext.py", line 256, in run self.build_extensions() File "Titaantje:DevDev:python:python:Lib:distutils:com mand:build_ext.py", line 383, in build_extensions self.build_extension(ext) File "Titaantje:DevDev:python:python:Lib:distutils:com mand:build_ext.py", line 486, in build_extension build_temp=self.build_temp) File "Titaantje:DevDev:python:python:Lib:distutils:ccom piler.py", line 663, in link_shared_object extra_preargs, extra_postargs, build_temp) File "Titaantje:DevDev:python:python:Lib:distutils:mwer kscompiler.py", line 187, in link xmlbuilder.generate() File "Titaantje:DevDev:python:python:Mac:Lib:mkcwproj ect:cwxmlgen.py", line 49, in generate self._generate_one_template(tmpl) File "Titaantje:DevDev:python:python:Mac:Lib:mkcwproj ect:cwxmlgen.py", line 91, in _generate_one_template result = self._generate_one_value(datasource, dataname) File "Titaantje:DevDev:python:python:Mac:Lib:mkcwproj ect:cwxmlgen.py", line 104, in _generate_one_value return format % self.dict KeyError: stdlibraryflags ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492665&group_id=5470 From noreply@sourceforge.net Thu Dec 13 21:40:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 13:40:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-492743 ] time() return a negative value Message-ID: Bugs item #492743, was opened at 2001-12-13 13:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492743&group_id=5470 Category: Macintosh Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Larry Meyn (larrymeyn) Assigned to: Jack Jansen (jackjansen) Summary: time() return a negative value Initial Comment: time() returns a negative value in MacPython 2.2b2 Example: Python 2.2b2 (#116, Nov 27 2001, 23:37:30) [CW PPC GUSI2 THREADS GC] on mac Type "copyright", "credits" or "license" for more information. >>> import time >>> time.time() -1203879081.0 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492743&group_id=5470 From noreply@sourceforge.net Thu Dec 13 21:44:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 13:44:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-492743 ] time() returns a negative value Message-ID: Bugs item #492743, was opened at 2001-12-13 13:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492743&group_id=5470 Category: Macintosh Group: Python 2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Larry Meyn (larrymeyn) Assigned to: Jack Jansen (jackjansen) >Summary: time() returns a negative value Initial Comment: time() returns a negative value in MacPython 2.2b2 Example: Python 2.2b2 (#116, Nov 27 2001, 23:37:30) [CW PPC GUSI2 THREADS GC] on mac Type "copyright", "credits" or "license" for more information. >>> import time >>> time.time() -1203879081.0 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492743&group_id=5470 From noreply@sourceforge.net Thu Dec 13 22:41:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 14:41:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-492743 ] time() returns a negative value Message-ID: Bugs item #492743, was opened at 2001-12-13 13:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492743&group_id=5470 Category: Macintosh Group: Python 2.2 Status: Open Resolution: None >Priority: 8 Submitted By: Larry Meyn (larrymeyn) Assigned to: Jack Jansen (jackjansen) Summary: time() returns a negative value Initial Comment: time() returns a negative value in MacPython 2.2b2 Example: Python 2.2b2 (#116, Nov 27 2001, 23:37:30) [CW PPC GUSI2 THREADS GC] on mac Type "copyright", "credits" or "license" for more information. >>> import time >>> time.time() -1203879081.0 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492743&group_id=5470 From noreply@sourceforge.net Fri Dec 14 00:41:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 16:41:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-471942 ] python2.1.1 SEGV in GC on Solaris 2.7 Message-ID: Bugs item #471942, was opened at 2001-10-16 19:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Anthony Baxter (anthonybaxter) Summary: python2.1.1 SEGV in GC on Solaris 2.7 Initial Comment: I've got a Zope installation where python2.1.1 is segfaulting on Solaris2.7 - it's running a largish ZEO server. The tail of the gdb output is: #128 0x26164 in PyEval_CallObjectWithKeywords () #129 0x264c0 in PyEval_CallObjectWithKeywords () #130 0x26140 in PyEval_CallObjectWithKeywords () #131 0x25fc0 in PyEval_CallObjectWithKeywords () #132 0x517bc in PyInstance_New () #133 0x261a4 in PyEval_CallObjectWithKeywords () #134 0x25fc0 in PyEval_CallObjectWithKeywords () #135 0x42c90 in initgc () It's built with $ gcc -v Reading specs from /opt/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs gcc version 2.95.2 19991024 (release) which is a bit old. I'm going to rebuild with gcc3.0 and also try turning off the GC. Unfortunately I can't get this to happen on a smaller test system - it's only under load that it plows into the ground. I'll also leave symbols in this time... :/ ---------------------------------------------------------------------- Comment By: Joseph Wayne Norton (natsukashi) Date: 2001-12-13 16:41 Message: Logged In: YES user_id=358486 Here is an excerpt from one debugging session ... > (gdb) info threads > 17 Thread 10 0xef5b9810 in _lwp_sema_wait () > 16 Thread 9 0xef647cac in _swtch () > 15 Thread 8 0xef5b9810 in _lwp_sema_wait () > 14 Thread 7 (LWP 5) 0xcaeb50 in ?? () > 13 Thread 6 0xef647cac in _swtch () > 12 Thread 5 0xef5b9810 in _lwp_sema_wait () > 11 Thread 4 0xef647cac in _swtch () > 10 Thread 3 0xef647cac in _swtch () > 9 Thread 2 (LWP 2) 0xef5b9958 in _signotifywait () > 8 Thread 1 (LWP 6) 0xef5b7488 in _poll () > 7 LWP 8 0xef5b6a24 in door_restart () > 6 LWP 6 0xef5b7488 in _poll () > 5 LWP 5 0xcaeb50 in ?? () > 4 LWP 4 0xef5b9810 in _lwp_sema_wait () > 3 LWP 3 0xef5b9810 in _lwp_sema_wait () > 2 LWP 2 0xef5b9958 in _signotifywait () > * 1 LWP 1 0xef5b9810 in _lwp_sema_wait () > > (gdb) thread 14 > [Switching to Thread 7 (LWP 5)] > #0 0xcaeb50 in ?? () > > (gdb) where > #0 0xcaeb50 in ?? () > #1 0x516bc in collect (young=0x13dec8, old=0x13ded4) > at ./Modules/gcmodule.c:379 > #2 0x51984 in collect_generations () at ./Modules/gcmodule.c:484 > #3 0x519fc in _PyGC_Insert (op=0xecf7d4) at ./Modules/gcmodule.c:507 > #4 0x664ec in PyMethod_New (func=0x3f796c, self=0x11c0d44, > class=0x3c7e5c) > at Objects/classobject.c:1834 > #5 0x63850 in instance_getattr2 (inst=0x11c0d44, name=0x3d5378) > at Objects/classobject.c:642 > #6 0x63750 in instance_getattr1 (inst=0x11c0d44, name=0x3d5378) > at Objects/classobject.c:608 > #7 0x63898 in instance_getattr (inst=0x11c0d44, name=0x3d5378) > at Objects/classobject.c:656 > #8 0x78330 in PyObject_GetAttr (v=0x11c0d44, name=0x3d5378) > at Objects/object.c:1052 > #9 0x895ec in builtin_hasattr (self=0x0, args=0x12ed944) > at Python/bltinmodule.c:886 > #10 0x35a44 in call_cfunction (func=0x1609b0, arg=0x12ed944, kw=0x0) > at Python/ceval.c:2854 Unfortunately, I do not have any specific information at the moment. There is also portions of a discussion that can be viewed with the following url: http://lists.zope.org/pipermail/zope-dev/2001-December/014541.html Look for messages having the same subject. Basically, we are running python 2.1.1 and zope 2.4.3 on the solaris platform. We have 3 servers each having the same installed software except one server is solaris 5.6 and the other two are solaris 5.7. The zope process running on the solaris 5.6 machine is restarting at least a couple times a day due to a SIGSEGV or SIGILL signal. I can generate a core file using the truss command. The problem appears to be related to garbage collection. Unfortunately, this behavior only occurs on our production site and depends on the site load -- higher system load, more frequent restarts. We are not facing any restart troubles on the solaris 5.7 machines or on our linux and solaris development machines. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-13 12:12 Message: Logged In: YES user_id=31435 Just noting that the function names reported in the traceback in the original writeup are bogus: PyEval_CallObjectWithKeywords() doesn't call itself. Looks like gdb doesn't have enough info to report the true function name, so picks a function it does know about at an earlier address (or something ). I'm told this doesn't happen on Linux, but don't grasp why it might on Solaris. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-13 07:45 Message: Logged In: YES user_id=21627 What do you mean with "the same trouble"? Merely that Python crashes, or do you have some more specific information to contribute? ---------------------------------------------------------------------- Comment By: Joseph Wayne Norton (natsukashi) Date: 2001-12-11 18:37 Message: Logged In: YES user_id=358486 Do you have any updates on this issue? I'm facing the same trouble on the following solaris platform: SunOS i04sv2008 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-80 regards, - j ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-04 23:38 Message: Logged In: YES user_id=29957 Nah, this is a separate one to the frame bug. I'm still seeing it on a regular regular basis, but haven't narrowed it done to what's causing it. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-04 08:48 Message: Logged In: YES user_id=31392 This was the bug that was tracked down to a problem in try/except/finally, wasn't it? If this is fixed, can you close the bug report? If not, can you provide an udpate on its current status? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-07 14:13 Message: Logged In: YES user_id=21627 Any news on this report: did the problem disappear after backporting changes? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 04:32 Message: Logged In: YES user_id=21627 Looking at the changes since 2.1.1, I can see one bugfix that might explain strange behaviour, namely ceval.c 2.277. If you want to try it out, you can get the change here http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Python/ceval.c.diff?r1=2.276&r2=2.277 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 03:59 Message: Logged In: YES user_id=29957 What's the appropriate way to ask this? drop a line to python-dev? purify's showing a UMR in strop_expandtabs (from memory - don't have it on screen right now) when python starts up. Yeah, the realloc bug concerns me - I have to wonder if something's a little bit/lot screwy. I just don't know where. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 03:46 Message: Logged In: YES user_id=21627 This is something to ask the pythonlabs folks; I believe Python has been purified once in a while - perhaps even with Zope extensions. I'd still suspect a bug in the Zope extensions instead of a Python bug, though: if malloc crashes, chances are high that somebody was overwriting free memory. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 03:31 Message: Logged In: YES user_id=29957 It's not a GC object. I'm positive all the extension objects are correct - I just recompiled, without the 1.5/2.0 headers around. It's a different pointer each time round, unfortunately. It also takes anything from 5 minutes to 2 hours to reproduce. I've got about 4 copies of it running now, and I've got a bunch of different core files. I've grabbed purify and an eval license, and I'm feeding it the binary. The printf approach is probably not going to work - these are busy busy Zope servers. Instead, my plan, assuming that purify doesn't immediately spot a problem, is to change the code so that if it gets a dud GC object, it will just bust it out of the tree and let it leak, and print a message saying so. Then I can quit the program, and purify will tell me 'hey, you leaked!' and also tell me where it was allocated. More concerning, about half the segfaults are not from the GC at all, but from realloc in PyFrame_New (line 161 of frameobject). These are the only two I'm getting - it's split 50-50 amongst the 10 coredumps I have now. I'm not sure whether to open a seperate bug for this. Has python2.1.1 been purified? With Zope and zope's extensions? Wow - it's amazing how this SF bug thing is so painful for conversations :) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 03:11 Message: Logged In: YES user_id=21627 There are two options: a) the object isn't really a GC object, i.e. has no GC header. In gdb, you can try to cast gc to PyObject*, then see if the resulting pointer has a better ob_type (this is unlikely, though, since the logic entering the object was already using fromgc/togc) b) somebody has cleared the ob_type field. Can you guarantee that all extension modules have been compiled with the 2.1.1 header files? Is the problem repeatable in the sense that gc will have the same pointer value on each crash? If so, it is relatively easy to track down: just set a gdb change watchpoint on the address on the ob_type field of that address (note that setting watchpoints is not possible until there is really mapped memory on that address). If you can't analyse it through change breakpoints, I recommend to annotate the interpreter in the following way: in pyobject_init, put a printf that prints the address and the tp_name of the type. In subtract_refs, if the ob_type slot is null, print the address of the object and abort. Then analyse the log to see whether a object really has been allocated on that address, and what its type was (make sure you consider the possibility that address are off by the delta that FROM_GC adds). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-17 21:58 Message: Logged In: YES user_id=29957 Ok, I have an intact core file, and a matching binary, no optimisations, nothing. This crash is showing the crash at line 166 of gcmodule.c traverse = PyObject_FROM_GC(gc)->ob_type->tp_traverse; PyObject_FROM_GC(gc)->ob_type in this case is $24 = {ob_refcnt = 1, ob_type = 0x0} To check my logic, I checked gc_next and gc_prev using the same GDB magic, and they correctly show up as a tuple and an instance method. Some fiddling around seems to rule out stack space as the problem, as well. We're going to try and see if purify helps here, but the problem looks to be a junk object - I have no idea how to track this down further. Help? Would taking the horrible horrible hack of removing the object from the gc linked list if ob_type is null help? Well, it'd stop the crashes, anyway. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-17 13:44 Message: Logged In: YES user_id=21627 It would be interesting what the value of "gc" is at the time of the crash. It looks like you got an object that claims to support GC but has a null tp_traverse. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-17 06:08 Message: Logged In: YES user_id=29957 I'm a doofus who read the gdb trace from the wrong end - too much python lately :) Nonetheless, the other end of the trace failed in gc as well - and building without GC enabled worked. Here's the trace with debugging enabled: #0 0xff00 in ?? () #1 0x402f0 in collect (young=0x9b538, old=0x9b544) at ./Modules/gcmodule.c:379 #2 0x405a8 in collect_generations () at ./Modules/gcmodule.c:484 #3 0x40624 in _PyGC_Insert (op=0xbc1f24) at ./Modules/gcmodule.c:507 #4 0x5a224 in PyList_New (size=0) at Objects/listobject.c:61 #5 0x21bc8 in eval_code2 (co=0x1cb370, globals=0x21bc0, locals=0x67, args=0x0, argcount=1, kws=0xf89b24, kwcount=0, defs=0x0, defcount=0, closure=0xbc1f24) at Python/ceval.c:1741 Next trick is to rebuild without any optimisation (sigh) as I suspect that it's inlined subtract_refs(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 From noreply@sourceforge.net Fri Dec 14 04:19:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 20:19:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-492345 ] New-style class with only classic bases Message-ID: Bugs item #492345, was opened at 2001-12-12 20:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492345&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Closed Resolution: Fixed Priority: 7 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: New-style class with only classic bases Initial Comment: I just tried this: >>> class A: pass ... >>> class B: pass ... >>> class C(A, B): __metaclass__ = type ... Traceback (most recent call last): File "", line 1, in ? SystemError: NULL result without error in PyObject_Call >>> ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 20:19 Message: Logged In: YES user_id=6380 Hm. I forgot to checkin. Fixed now: 2.124.2.1 (release branch), 2.125 (trunk). Plus added a test to test_descr.py. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-12 20:59 Message: Logged In: YES user_id=6380 Oops, that was easier than I feared. best_bases() returned NULL without an error; there was an assert though in debug mode that helped me find it quickly. I've decided for now to declare this an error -- if you have a new-style metaclass, you must have at least one new-style base class. (I first tried to fix it, but after making the class statement pass, the constructed class couldn't be instantiated and didn't have 'object' in its __mro__, so I gave up quickly. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492345&group_id=5470 From noreply@sourceforge.net Fri Dec 14 05:02:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 21:02:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-488730 ] os.popen() seg faults on FreeBSD 5 Message-ID: Bugs item #488730, was opened at 2001-12-03 21:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Marc Culler (marcculler) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen() seg faults on FreeBSD 5 Initial Comment: Here is the crash with Python 2.1.1 on my FreeBSD 5.0-current system: [ace:culler]$ python Python 2.1.1 (#5, Aug 18 2001, 17:41:43) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') Segmentation fault (core dumped) No problem occurs when I do the same thing in Python 2.0, which was compiled under FreeBSD 4, but is running here under FreeBSD 5: [ace:culler]$ python2.0 Python 2.0 (#2, Nov 16 2000, 22:22:48) [GCC 2.95.2 19991024 (release)] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') >>> mypipe.readlines() ['COPYRIGHT\012', 'bin\012', 'boot\012', 'cdrom\012', 'compat\012', 'dev\012', 'dist\012', 'entropy\012', 'etc\012', 'home\012', 'kernel\012', 'kernel.GENERIC\012', 'kernel.old\012', 'kernel.prev\012', 'mnt\012', 'modules\012', 'modules.old\012', 'proc\012', 'root\012', 'sbin\012', 'shared\012', 'stand\012', 'sys\012', 'tmp\012', 'usr\012', 'var\012'] >>> ---------------------------------------------------------------------- >Comment By: Marc Culler (marcculler) Date: 2001-12-13 21:02 Message: Logged In: YES user_id=392704 Thank you, Martin. The situation with incompatible C libraries is not quite as bad as you suggest. It turned out that not only was the -ltk82 dragging in libc, it was dragging in libc.so.4. I recompiled the tcl and tk ports and the seg faults went away. The stupidest part was that the compiler had tried to warn me about this, and I wasn't paying attention. Perhaps you could add a warning in the README file that the FreeBSD 4 versions of libtk82 and libtcl82 cannot be used when building pyton under FreeBSD 5. Thank you for taking the time to advise me on this. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-12 22:38 Message: Logged In: YES user_id=21627 It would be best if you ask a BSD expert for advise. I consider the notion of incompatible C libraries broken beyond repair (the only other system that does that is MS VC++, for debug and non-debug C libraries), so you really need to dig out some documentation that elaborates the problem and proposes work-arounds. Please do ldd on the resulting Python binary to see whether it directly links with libc. If it does, add the option -v to the linker line; most likely, gcc implicitly passes a -lc option. You may experiment with passing -pthread to the linker line (and all compiler lines) in this case. Another potential cause is that other libraries (like -ltk82) drag in libc.so. In that case, I'd say it is hopeless: you have than the following options 1. do not build a multi-threaded python, 2. do not build a Python that incorporates _tkinter (not sure that building tkinter as a shared module would help; you really need that expert to answer that question) 3. rebuild Tcl/Tk to link with -lc_r. If you ask that we do something about it: We could either add some text to README, or refuse to build --with-threads on FreeBSD. ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-12 20:13 Message: Logged In: YES user_id=392704 We are getting closer! Yes, it does seem to be related to linking against both libc and libc_r. If I compile the test program as follows: gcc -o test test.c -lc -lc_r I get a seg fault at the same location in _fcntl (and the backtrace shows that the libc_r version of _fcntl is being called from the libc version of fdopen). If I use just -lc, or just -lc_r, or even -lc_r -lc then the test program runs fine. So let's assume that the libc and libc_r versions of _fcntl use different structures for file descriptor table entries, or some such thing. The next question is how do I prevent python from being linked against both libraries? I looked through the output of make and nowhere did I see an explicit -lc flag. In the makefile it says LIBS= -lc_r -lutil and the linker command being used to link python is gcc -Wl,--export-dynamic -o python Modules/python.o libpython2.1.a -lc_r -lutil -L/usr/local/lib -ltk82 -ltcl82 -L/usr/X11R6/lib -lX11 -lm So why is it linking against libc and how do I make it stop? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-12 04:43 Message: Logged In: YES user_id=6380 Good point. The experiment with a little C program should be repeated, compiling and linking it with exactly the same flags as Python is compiled and linked. (Statically, since the posix module is statically linked into Python.) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 23:57 Message: Logged In: YES user_id=21627 Could that be one of those "it's BSD, never mix threading and non-threading C libraries" bugs? I find it surprising that it crashes inside the C library; the only known causes (besides genuine bugs) are: - memory management got corrupted. Without seeing the source of _fcntl, I think this is unlikely. - caller and callee have different ideas of how structures are layed out, due to being compiled with different definitions of those structures. Are you sure it is correct to link with both libc and libc_r simultaneously? Are there additional variants of the C library which only work in certain combinations? Is this documented anywhere? ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-11 15:43 Message: Logged In: YES user_id=392704 As to the subtlety of this bug, I meant to point out that Python 2.0, which presumably has a nearly identical posix module, has a working os.popen(). On the other hand, Python2.0 loads libc_r.so.4 rather than libc_r.so.5. So maybe that is where the secret lies. Interestingly, the size of that library has gone from 664784 to 108988. That suggests that there were some rather major changes there, doesn't it? ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-11 15:11 Message: Logged In: YES user_id=392704 Yes, I thought it looked like it was a FreeBSD bug too. Unfortunately, though, my little test program produced a nice listing of my / directory. I still think it is FreeBSD's problem, but it is at least a little bit subtle. I suppose I should build the latest FreeBSD sources before proceeding any further with this. #include int main(){ int c; FILE *fp; fp = popen("ls /", "r"); if (fp == NULL) { fprintf(stderr, "popen returned NULL\n"); exit(-1); } while ((c = getc(fp)) != EOF) { putchar(c); } printf("\nDone\n"); exit(0); } ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 14:28 Message: Logged In: YES user_id=6380 Marc, the Python popen code (if you can see through the #ifdefs for non-Unix platforms :-) is a pretty straightforward call of the C library popen(). The crash you receive suggests that it has nothing to do with Python. Can you try a C program containing the same call? Something like #include main() { popen("ls -l", "r"); } Does this crash in the same way? If so, you may close this bug report and report it to the FreeBSD folks instead... ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-11 14:14 Message: Logged In: YES user_id=392704 All I know so far is that, according to the stack trace, the crash seems to occur in _fcntl in libc_r.so: (gdb) run Starting program: /usr/local/src/Python211/python Python 2.1.1 (#14, Dec 11 2001, 15:55:41) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> x = os.popen('ls /') Program received signal SIGSEGV, Segmentation fault. 0x280e32ee in _fcntl () from /usr/lib/libc_r.so.5 (gdb) backtrace #0 0x280e32ee in _fcntl () from /usr/lib/libc_r.so.5 #1 0x28391c99 in fdopen () from /usr/lib/libc.so.5 #2 0x2834bf30 in popen () from /usr/lib/libc.so.5 #3 0x80735b1 in posix_popen (self=0x0, args=0x80f488c) at ./Modules/posixmodule.c:2936 #4 0x805921e in call_cfunction (func=0x80d0820, arg=0x80f488c, kw=0x0) at Python/ceval.c:2845 #5 0x8057cb1 in eval_code2 (co=0x8159ac0, globals=0x80e0ccc, locals=0x80e0ccc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:1948 #6 0x8055171 in PyEval_EvalCode (co=0x8159ac0, globals=0x80e0ccc, locals=0x80e0ccc) at Python/ceval.c:341 #7 0x806ca8f in run_node (n=0x8158280, filename=0x80a202d "", globals=0x80e0ccc, locals=0x80e0ccc, flags=0xbfbff70c) at Python/pythonrun.c:1045 #8 0x806bc86 in PyRun_InteractiveOneFlags (fp=0x80c93a0, filename=0x80a202d "", flags=0xbfbff70c) at Python/pythonrun.c:570 #9 0x806bae6 in PyRun_InteractiveLoopFlags (fp=0x80c93a0, filename=0x80a202d "", flags=0xbfbff70c) at Python/pythonrun.c:510 #10 0x806b9db in PyRun_AnyFileExFlags (fp=0x80c93a0, filename=0x80a202d "", closeit=0, flags=0xbfbff70c) at Python/pythonrun.c:473 #11 0x805222c in Py_Main (argc=0, argv=0xbfbff784) at Modules/main.c:320 #12 0x8051d04 in main (argc=1, argv=0xbfbff784) at Modules/python.c:10 #13 0x8051c35 in _start () ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 12:58 Message: Logged In: YES user_id=21627 Can't reproduce this on FreeBSD 4.4, either, using the current CVS. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:18 Message: Logged In: YES user_id=6380 I can't reproduce this, and I don't have access to a FreeBSD 5 machine. Can you debug this yourself? We'd welcome a patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 From noreply@sourceforge.net Fri Dec 14 05:02:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 21:02:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Fri Dec 14 05:02:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 21:02:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-488730 ] os.popen() seg faults on FreeBSD 5 Message-ID: Bugs item #488730, was opened at 2001-12-03 21:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 Category: Extension Modules Group: Platform-specific >Status: Closed Resolution: None Priority: 5 Submitted By: Marc Culler (marcculler) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen() seg faults on FreeBSD 5 Initial Comment: Here is the crash with Python 2.1.1 on my FreeBSD 5.0-current system: [ace:culler]$ python Python 2.1.1 (#5, Aug 18 2001, 17:41:43) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') Segmentation fault (core dumped) No problem occurs when I do the same thing in Python 2.0, which was compiled under FreeBSD 4, but is running here under FreeBSD 5: [ace:culler]$ python2.0 Python 2.0 (#2, Nov 16 2000, 22:22:48) [GCC 2.95.2 19991024 (release)] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> import os >>> mypipe = os.popen('ls /') >>> mypipe.readlines() ['COPYRIGHT\012', 'bin\012', 'boot\012', 'cdrom\012', 'compat\012', 'dev\012', 'dist\012', 'entropy\012', 'etc\012', 'home\012', 'kernel\012', 'kernel.GENERIC\012', 'kernel.old\012', 'kernel.prev\012', 'mnt\012', 'modules\012', 'modules.old\012', 'proc\012', 'root\012', 'sbin\012', 'shared\012', 'stand\012', 'sys\012', 'tmp\012', 'usr\012', 'var\012'] >>> ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-13 21:02 Message: Logged In: YES user_id=392704 Thank you, Martin. The situation with incompatible C libraries is not quite as bad as you suggest. It turned out that not only was the -ltk82 dragging in libc, it was dragging in libc.so.4. I recompiled the tcl and tk ports and the seg faults went away. The stupidest part was that the compiler had tried to warn me about this, and I wasn't paying attention. Perhaps you could add a warning in the README file that the FreeBSD 4 versions of libtk82 and libtcl82 cannot be used when building pyton under FreeBSD 5. Thank you for taking the time to advise me on this. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-12 22:38 Message: Logged In: YES user_id=21627 It would be best if you ask a BSD expert for advise. I consider the notion of incompatible C libraries broken beyond repair (the only other system that does that is MS VC++, for debug and non-debug C libraries), so you really need to dig out some documentation that elaborates the problem and proposes work-arounds. Please do ldd on the resulting Python binary to see whether it directly links with libc. If it does, add the option -v to the linker line; most likely, gcc implicitly passes a -lc option. You may experiment with passing -pthread to the linker line (and all compiler lines) in this case. Another potential cause is that other libraries (like -ltk82) drag in libc.so. In that case, I'd say it is hopeless: you have than the following options 1. do not build a multi-threaded python, 2. do not build a Python that incorporates _tkinter (not sure that building tkinter as a shared module would help; you really need that expert to answer that question) 3. rebuild Tcl/Tk to link with -lc_r. If you ask that we do something about it: We could either add some text to README, or refuse to build --with-threads on FreeBSD. ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-12 20:13 Message: Logged In: YES user_id=392704 We are getting closer! Yes, it does seem to be related to linking against both libc and libc_r. If I compile the test program as follows: gcc -o test test.c -lc -lc_r I get a seg fault at the same location in _fcntl (and the backtrace shows that the libc_r version of _fcntl is being called from the libc version of fdopen). If I use just -lc, or just -lc_r, or even -lc_r -lc then the test program runs fine. So let's assume that the libc and libc_r versions of _fcntl use different structures for file descriptor table entries, or some such thing. The next question is how do I prevent python from being linked against both libraries? I looked through the output of make and nowhere did I see an explicit -lc flag. In the makefile it says LIBS= -lc_r -lutil and the linker command being used to link python is gcc -Wl,--export-dynamic -o python Modules/python.o libpython2.1.a -lc_r -lutil -L/usr/local/lib -ltk82 -ltcl82 -L/usr/X11R6/lib -lX11 -lm So why is it linking against libc and how do I make it stop? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-12 04:43 Message: Logged In: YES user_id=6380 Good point. The experiment with a little C program should be repeated, compiling and linking it with exactly the same flags as Python is compiled and linked. (Statically, since the posix module is statically linked into Python.) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 23:57 Message: Logged In: YES user_id=21627 Could that be one of those "it's BSD, never mix threading and non-threading C libraries" bugs? I find it surprising that it crashes inside the C library; the only known causes (besides genuine bugs) are: - memory management got corrupted. Without seeing the source of _fcntl, I think this is unlikely. - caller and callee have different ideas of how structures are layed out, due to being compiled with different definitions of those structures. Are you sure it is correct to link with both libc and libc_r simultaneously? Are there additional variants of the C library which only work in certain combinations? Is this documented anywhere? ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-11 15:43 Message: Logged In: YES user_id=392704 As to the subtlety of this bug, I meant to point out that Python 2.0, which presumably has a nearly identical posix module, has a working os.popen(). On the other hand, Python2.0 loads libc_r.so.4 rather than libc_r.so.5. So maybe that is where the secret lies. Interestingly, the size of that library has gone from 664784 to 108988. That suggests that there were some rather major changes there, doesn't it? ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-11 15:11 Message: Logged In: YES user_id=392704 Yes, I thought it looked like it was a FreeBSD bug too. Unfortunately, though, my little test program produced a nice listing of my / directory. I still think it is FreeBSD's problem, but it is at least a little bit subtle. I suppose I should build the latest FreeBSD sources before proceeding any further with this. #include int main(){ int c; FILE *fp; fp = popen("ls /", "r"); if (fp == NULL) { fprintf(stderr, "popen returned NULL\n"); exit(-1); } while ((c = getc(fp)) != EOF) { putchar(c); } printf("\nDone\n"); exit(0); } ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 14:28 Message: Logged In: YES user_id=6380 Marc, the Python popen code (if you can see through the #ifdefs for non-Unix platforms :-) is a pretty straightforward call of the C library popen(). The crash you receive suggests that it has nothing to do with Python. Can you try a C program containing the same call? Something like #include main() { popen("ls -l", "r"); } Does this crash in the same way? If so, you may close this bug report and report it to the FreeBSD folks instead... ---------------------------------------------------------------------- Comment By: Marc Culler (marcculler) Date: 2001-12-11 14:14 Message: Logged In: YES user_id=392704 All I know so far is that, according to the stack trace, the crash seems to occur in _fcntl in libc_r.so: (gdb) run Starting program: /usr/local/src/Python211/python Python 2.1.1 (#14, Dec 11 2001, 15:55:41) [GCC 2.95.3 20010315 (release)] on freebsd5 Type "copyright", "credits" or "license" for more information. >>> import os >>> x = os.popen('ls /') Program received signal SIGSEGV, Segmentation fault. 0x280e32ee in _fcntl () from /usr/lib/libc_r.so.5 (gdb) backtrace #0 0x280e32ee in _fcntl () from /usr/lib/libc_r.so.5 #1 0x28391c99 in fdopen () from /usr/lib/libc.so.5 #2 0x2834bf30 in popen () from /usr/lib/libc.so.5 #3 0x80735b1 in posix_popen (self=0x0, args=0x80f488c) at ./Modules/posixmodule.c:2936 #4 0x805921e in call_cfunction (func=0x80d0820, arg=0x80f488c, kw=0x0) at Python/ceval.c:2845 #5 0x8057cb1 in eval_code2 (co=0x8159ac0, globals=0x80e0ccc, locals=0x80e0ccc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:1948 #6 0x8055171 in PyEval_EvalCode (co=0x8159ac0, globals=0x80e0ccc, locals=0x80e0ccc) at Python/ceval.c:341 #7 0x806ca8f in run_node (n=0x8158280, filename=0x80a202d "", globals=0x80e0ccc, locals=0x80e0ccc, flags=0xbfbff70c) at Python/pythonrun.c:1045 #8 0x806bc86 in PyRun_InteractiveOneFlags (fp=0x80c93a0, filename=0x80a202d "", flags=0xbfbff70c) at Python/pythonrun.c:570 #9 0x806bae6 in PyRun_InteractiveLoopFlags (fp=0x80c93a0, filename=0x80a202d "", flags=0xbfbff70c) at Python/pythonrun.c:510 #10 0x806b9db in PyRun_AnyFileExFlags (fp=0x80c93a0, filename=0x80a202d "", closeit=0, flags=0xbfbff70c) at Python/pythonrun.c:473 #11 0x805222c in Py_Main (argc=0, argv=0xbfbff784) at Modules/main.c:320 #12 0x8051d04 in main (argc=1, argv=0xbfbff784) at Modules/python.c:10 #13 0x8051c35 in _start () ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-11 12:58 Message: Logged In: YES user_id=21627 Can't reproduce this on FreeBSD 4.4, either, using the current CVS. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-08 09:18 Message: Logged In: YES user_id=6380 I can't reproduce this, and I don't have access to a FreeBSD 5 machine. Can you debug this yourself? We'd welcome a patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=488730&group_id=5470 From noreply@sourceforge.net Fri Dec 14 05:13:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 21:13:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Fri Dec 14 05:25:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 13 Dec 2001 21:25:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Fri Dec 14 10:22:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 02:22:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-493243 ] ext call doco warts Message-ID: Bugs item #493243, was opened at 2001-12-14 02:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493243&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 3 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ext call doco warts Initial Comment: Now they've been compiled , I notice that there are some warts in my docs for the *- and **-style call syntax. 1) the "argument_list" production is really, really confusing. there must be a better BNF-style way of saying that. I don't think vertically centering the production name against the production helps. 2) For some reason, where I say It is unusual for both keyword arguments and the "*expression"syntax to be used in the same call, so in practice this confusion does not arise. there's no space between `"*expression"' and `syntax'. I'd guess that this is because in the source, the \samp{} macro is the last thing on the line, but why that should lead to a missing space is beyond me -- more latex2html bugs? (just noticed the same thing a bit higher up too -- the "**expression"argument, if any No hurry with these. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493243&group_id=5470 From noreply@sourceforge.net Fri Dec 14 10:46:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 02:46:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-471942 ] python2.1.1 SEGV in GC on Solaris 2.7 Message-ID: Bugs item #471942, was opened at 2001-10-16 19:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Anthony Baxter (anthonybaxter) Summary: python2.1.1 SEGV in GC on Solaris 2.7 Initial Comment: I've got a Zope installation where python2.1.1 is segfaulting on Solaris2.7 - it's running a largish ZEO server. The tail of the gdb output is: #128 0x26164 in PyEval_CallObjectWithKeywords () #129 0x264c0 in PyEval_CallObjectWithKeywords () #130 0x26140 in PyEval_CallObjectWithKeywords () #131 0x25fc0 in PyEval_CallObjectWithKeywords () #132 0x517bc in PyInstance_New () #133 0x261a4 in PyEval_CallObjectWithKeywords () #134 0x25fc0 in PyEval_CallObjectWithKeywords () #135 0x42c90 in initgc () It's built with $ gcc -v Reading specs from /opt/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs gcc version 2.95.2 19991024 (release) which is a bit old. I'm going to rebuild with gcc3.0 and also try turning off the GC. Unfortunately I can't get this to happen on a smaller test system - it's only under load that it plows into the ground. I'll also leave symbols in this time... :/ ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-14 02:46 Message: Logged In: YES user_id=21627 natsukashi, have you applied 2.277 of ceval.c? ---------------------------------------------------------------------- Comment By: Joseph Wayne Norton (natsukashi) Date: 2001-12-13 16:41 Message: Logged In: YES user_id=358486 Here is an excerpt from one debugging session ... > (gdb) info threads > 17 Thread 10 0xef5b9810 in _lwp_sema_wait () > 16 Thread 9 0xef647cac in _swtch () > 15 Thread 8 0xef5b9810 in _lwp_sema_wait () > 14 Thread 7 (LWP 5) 0xcaeb50 in ?? () > 13 Thread 6 0xef647cac in _swtch () > 12 Thread 5 0xef5b9810 in _lwp_sema_wait () > 11 Thread 4 0xef647cac in _swtch () > 10 Thread 3 0xef647cac in _swtch () > 9 Thread 2 (LWP 2) 0xef5b9958 in _signotifywait () > 8 Thread 1 (LWP 6) 0xef5b7488 in _poll () > 7 LWP 8 0xef5b6a24 in door_restart () > 6 LWP 6 0xef5b7488 in _poll () > 5 LWP 5 0xcaeb50 in ?? () > 4 LWP 4 0xef5b9810 in _lwp_sema_wait () > 3 LWP 3 0xef5b9810 in _lwp_sema_wait () > 2 LWP 2 0xef5b9958 in _signotifywait () > * 1 LWP 1 0xef5b9810 in _lwp_sema_wait () > > (gdb) thread 14 > [Switching to Thread 7 (LWP 5)] > #0 0xcaeb50 in ?? () > > (gdb) where > #0 0xcaeb50 in ?? () > #1 0x516bc in collect (young=0x13dec8, old=0x13ded4) > at ./Modules/gcmodule.c:379 > #2 0x51984 in collect_generations () at ./Modules/gcmodule.c:484 > #3 0x519fc in _PyGC_Insert (op=0xecf7d4) at ./Modules/gcmodule.c:507 > #4 0x664ec in PyMethod_New (func=0x3f796c, self=0x11c0d44, > class=0x3c7e5c) > at Objects/classobject.c:1834 > #5 0x63850 in instance_getattr2 (inst=0x11c0d44, name=0x3d5378) > at Objects/classobject.c:642 > #6 0x63750 in instance_getattr1 (inst=0x11c0d44, name=0x3d5378) > at Objects/classobject.c:608 > #7 0x63898 in instance_getattr (inst=0x11c0d44, name=0x3d5378) > at Objects/classobject.c:656 > #8 0x78330 in PyObject_GetAttr (v=0x11c0d44, name=0x3d5378) > at Objects/object.c:1052 > #9 0x895ec in builtin_hasattr (self=0x0, args=0x12ed944) > at Python/bltinmodule.c:886 > #10 0x35a44 in call_cfunction (func=0x1609b0, arg=0x12ed944, kw=0x0) > at Python/ceval.c:2854 Unfortunately, I do not have any specific information at the moment. There is also portions of a discussion that can be viewed with the following url: http://lists.zope.org/pipermail/zope-dev/2001-December/014541.html Look for messages having the same subject. Basically, we are running python 2.1.1 and zope 2.4.3 on the solaris platform. We have 3 servers each having the same installed software except one server is solaris 5.6 and the other two are solaris 5.7. The zope process running on the solaris 5.6 machine is restarting at least a couple times a day due to a SIGSEGV or SIGILL signal. I can generate a core file using the truss command. The problem appears to be related to garbage collection. Unfortunately, this behavior only occurs on our production site and depends on the site load -- higher system load, more frequent restarts. We are not facing any restart troubles on the solaris 5.7 machines or on our linux and solaris development machines. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-13 12:12 Message: Logged In: YES user_id=31435 Just noting that the function names reported in the traceback in the original writeup are bogus: PyEval_CallObjectWithKeywords() doesn't call itself. Looks like gdb doesn't have enough info to report the true function name, so picks a function it does know about at an earlier address (or something ). I'm told this doesn't happen on Linux, but don't grasp why it might on Solaris. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-13 07:45 Message: Logged In: YES user_id=21627 What do you mean with "the same trouble"? Merely that Python crashes, or do you have some more specific information to contribute? ---------------------------------------------------------------------- Comment By: Joseph Wayne Norton (natsukashi) Date: 2001-12-11 18:37 Message: Logged In: YES user_id=358486 Do you have any updates on this issue? I'm facing the same trouble on the following solaris platform: SunOS i04sv2008 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-80 regards, - j ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-04 23:38 Message: Logged In: YES user_id=29957 Nah, this is a separate one to the frame bug. I'm still seeing it on a regular regular basis, but haven't narrowed it done to what's causing it. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-04 08:48 Message: Logged In: YES user_id=31392 This was the bug that was tracked down to a problem in try/except/finally, wasn't it? If this is fixed, can you close the bug report? If not, can you provide an udpate on its current status? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-07 14:13 Message: Logged In: YES user_id=21627 Any news on this report: did the problem disappear after backporting changes? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 04:32 Message: Logged In: YES user_id=21627 Looking at the changes since 2.1.1, I can see one bugfix that might explain strange behaviour, namely ceval.c 2.277. If you want to try it out, you can get the change here http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Python/ceval.c.diff?r1=2.276&r2=2.277 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 03:59 Message: Logged In: YES user_id=29957 What's the appropriate way to ask this? drop a line to python-dev? purify's showing a UMR in strop_expandtabs (from memory - don't have it on screen right now) when python starts up. Yeah, the realloc bug concerns me - I have to wonder if something's a little bit/lot screwy. I just don't know where. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 03:46 Message: Logged In: YES user_id=21627 This is something to ask the pythonlabs folks; I believe Python has been purified once in a while - perhaps even with Zope extensions. I'd still suspect a bug in the Zope extensions instead of a Python bug, though: if malloc crashes, chances are high that somebody was overwriting free memory. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 03:31 Message: Logged In: YES user_id=29957 It's not a GC object. I'm positive all the extension objects are correct - I just recompiled, without the 1.5/2.0 headers around. It's a different pointer each time round, unfortunately. It also takes anything from 5 minutes to 2 hours to reproduce. I've got about 4 copies of it running now, and I've got a bunch of different core files. I've grabbed purify and an eval license, and I'm feeding it the binary. The printf approach is probably not going to work - these are busy busy Zope servers. Instead, my plan, assuming that purify doesn't immediately spot a problem, is to change the code so that if it gets a dud GC object, it will just bust it out of the tree and let it leak, and print a message saying so. Then I can quit the program, and purify will tell me 'hey, you leaked!' and also tell me where it was allocated. More concerning, about half the segfaults are not from the GC at all, but from realloc in PyFrame_New (line 161 of frameobject). These are the only two I'm getting - it's split 50-50 amongst the 10 coredumps I have now. I'm not sure whether to open a seperate bug for this. Has python2.1.1 been purified? With Zope and zope's extensions? Wow - it's amazing how this SF bug thing is so painful for conversations :) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 03:11 Message: Logged In: YES user_id=21627 There are two options: a) the object isn't really a GC object, i.e. has no GC header. In gdb, you can try to cast gc to PyObject*, then see if the resulting pointer has a better ob_type (this is unlikely, though, since the logic entering the object was already using fromgc/togc) b) somebody has cleared the ob_type field. Can you guarantee that all extension modules have been compiled with the 2.1.1 header files? Is the problem repeatable in the sense that gc will have the same pointer value on each crash? If so, it is relatively easy to track down: just set a gdb change watchpoint on the address on the ob_type field of that address (note that setting watchpoints is not possible until there is really mapped memory on that address). If you can't analyse it through change breakpoints, I recommend to annotate the interpreter in the following way: in pyobject_init, put a printf that prints the address and the tp_name of the type. In subtract_refs, if the ob_type slot is null, print the address of the object and abort. Then analyse the log to see whether a object really has been allocated on that address, and what its type was (make sure you consider the possibility that address are off by the delta that FROM_GC adds). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-17 21:58 Message: Logged In: YES user_id=29957 Ok, I have an intact core file, and a matching binary, no optimisations, nothing. This crash is showing the crash at line 166 of gcmodule.c traverse = PyObject_FROM_GC(gc)->ob_type->tp_traverse; PyObject_FROM_GC(gc)->ob_type in this case is $24 = {ob_refcnt = 1, ob_type = 0x0} To check my logic, I checked gc_next and gc_prev using the same GDB magic, and they correctly show up as a tuple and an instance method. Some fiddling around seems to rule out stack space as the problem, as well. We're going to try and see if purify helps here, but the problem looks to be a junk object - I have no idea how to track this down further. Help? Would taking the horrible horrible hack of removing the object from the gc linked list if ob_type is null help? Well, it'd stop the crashes, anyway. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-17 13:44 Message: Logged In: YES user_id=21627 It would be interesting what the value of "gc" is at the time of the crash. It looks like you got an object that claims to support GC but has a null tp_traverse. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-17 06:08 Message: Logged In: YES user_id=29957 I'm a doofus who read the gdb trace from the wrong end - too much python lately :) Nonetheless, the other end of the trace failed in gc as well - and building without GC enabled worked. Here's the trace with debugging enabled: #0 0xff00 in ?? () #1 0x402f0 in collect (young=0x9b538, old=0x9b544) at ./Modules/gcmodule.c:379 #2 0x405a8 in collect_generations () at ./Modules/gcmodule.c:484 #3 0x40624 in _PyGC_Insert (op=0xbc1f24) at ./Modules/gcmodule.c:507 #4 0x5a224 in PyList_New (size=0) at Objects/listobject.c:61 #5 0x21bc8 in eval_code2 (co=0x1cb370, globals=0x21bc0, locals=0x67, args=0x0, argcount=1, kws=0xf89b24, kwcount=0, defs=0x0, defcount=0, closure=0xbc1f24) at Python/ceval.c:1741 Next trick is to rebuild without any optimisation (sigh) as I suspect that it's inlined subtract_refs(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 From noreply@sourceforge.net Fri Dec 14 10:54:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 02:54:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-493252 ] maximum recursion limit exceeded in matc Message-ID: Bugs item #493252, was opened at 2001-12-14 02:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: P. de Jong (peterdejong) Assigned to: Nobody/Anonymous (nobody) Summary: maximum recursion limit exceeded in matc Initial Comment: RuntimeError: maximum recursion limit exceeded in match, while trying to match a string of 16384 bytes. (Python 2.0) The error does not occur after eliminating some 100 characters from the string. The error does not occur in Python 1.5.2. So I cannot upgrade. Peter de Jong ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 From noreply@sourceforge.net Fri Dec 14 12:44:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 04:44:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-225003 ] Extension manual: Windows DLL/C++ info needs review Message-ID: Bugs item #225003, was opened at 2000-12-08 07:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=225003&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 4 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Extension manual: Windows DLL/C++ info needs review Initial Comment: The section on building extensions on Windows needs to be updated. A single section, shared for Unix & Windows, needs to point out the distutils approach and point to the appropriate manual. Information about linking, DLLs/shared libraries, and use of C++ needs to be reviewed and updated. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2001-12-14 04:44 Message: Logged In: YES user_id=60314 I have reviewed Doc/ext/windows.tex, rev=1.3. Every issue I had noticed seems fixed very well. The only remaining problem I can see are many mentions of python15.lib at the end of the documents; these should presumably be changed to python22.lib (a mention of version dependency of these numbers would probably be a good idea). Great job! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-13 09:23 Message: Logged In: YES user_id=3066 The instructions for building extensions on Windows have been completely replaced in Doc/ext/windows.tex revision 1.3. The DLL discussion and C++ usage documentation still needs to be reviewed, but the known-broken docs have been corrected. Lowering the priority of the remaining aspects of this report, and changing the summary line. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-11 21:53 Message: Logged In: YES user_id=3066 This is closely related to SF bug #221671. Bumping the priority to match. I'll plan to get this done for 2.2rc1; Alex, I'll expect you to review the updated material once the release candidate is out so I can get your comments before the final release. ;-) ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2001-08-17 00:52 Message: Logged In: YES user_id=60314 Yes, I fully agree -- the information in the manual at http://python.sourceforge.net/devel-docs/ext/win- cookbook.html is positively wrong, and one of the major causes of help requests in my experience -- people look for inexistent http://starship.python.net/crew/da/compile/, download the sources to get a pyconfig.h they don't need and look for a PC\pyconfig.h that doesn't exist, and get tied into knots writing a Setup file. Seems a very serious situation to me. While we wait to do it 'just right', couldn't at least the present erroneous text be replaced with some temporary pointer e.g. to some of the various posts on the subject (cfr http://groups.google.com/groups? as_q=setup.py&as_uauthors=alex%20martelli for many examples, or my apparently popular recipe at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/6650 9, or...?) -- I'll be happy to write/rewrite this stuff with whatever mods you require, Fred, except that I can't seem to use the 'official' way to write Python docs (LaTex etc etc -- I thought a Linux box would make it easy but i'm still having problems setting it up, sigh). Let me know if I can be of help in any way, but I think that, particularly now with the nice new material in chapter 2, it's a positive ill to leave chapter 4 as it is now...:-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=225003&group_id=5470 From noreply@sourceforge.net Fri Dec 14 13:45:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 05:45:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-492743 ] time() returns a negative value Message-ID: Bugs item #492743, was opened at 2001-12-13 13:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492743&group_id=5470 Category: Macintosh Group: Python 2.2 >Status: Closed Resolution: None Priority: 8 Submitted By: Larry Meyn (larrymeyn) Assigned to: Jack Jansen (jackjansen) Summary: time() returns a negative value Initial Comment: time() returns a negative value in MacPython 2.2b2 Example: Python 2.2b2 (#116, Nov 27 2001, 23:37:30) [CW PPC GUSI2 THREADS GC] on mac Type "copyright", "credits" or "license" for more information. >>> import time >>> time.time() -1203879081.0 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-14 05:45 Message: Logged In: YES user_id=45365 This has been fixed in GUSI, the I/O library used in MacPython, and therefore the bug will not be there in the next release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492743&group_id=5470 From noreply@sourceforge.net Fri Dec 14 13:53:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 05:53:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-493252 ] maximum recursion limit exceeded in matc Message-ID: Bugs item #493252, was opened at 2001-12-14 02:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 >Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: P. de Jong (peterdejong) Assigned to: Nobody/Anonymous (nobody) Summary: maximum recursion limit exceeded in matc Initial Comment: RuntimeError: maximum recursion limit exceeded in match, while trying to match a string of 16384 bytes. (Python 2.0) The error does not occur after eliminating some 100 characters from the string. The error does not occur in Python 1.5.2. So I cannot upgrade. Peter de Jong ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 05:53 Message: Logged In: YES user_id=6380 Hi Peter! This usually happens when the pattern contains * or + in a way that causes more backtracking than one would naively expect. Can you show us the pattern? There's usually an easy way to rewrite the pattern so that it won't overflow -- and it will be faster too... BTW I would upgrade to Python 2.1.1 -- that's the most stable release to date. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 From noreply@sourceforge.net Fri Dec 14 14:31:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 06:31:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-492665 ] mac support broken? Message-ID: Bugs item #492665, was opened at 2001-12-13 13:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492665&group_id=5470 Category: Distutils Group: Platform-specific >Status: Closed Resolution: None Priority: 7 Submitted By: Just van Rossum (jvr) Assigned to: Jack Jansen (jackjansen) Summary: mac support broken? Initial Comment: When I try to build NumPy I get the following error: running build running build_py not copying :Lib:ArrayPrinter.py (output up-to-date) not copying :Lib:LinearAlgebra.py (output up-to- date) not copying :Lib:Matrix.py (output up-to-date) not copying :Lib:MLab.py (output up-to-date) not copying :Lib:Numeric.py (output up-to-date) not copying :Lib:numeric_version.py (output up-to- date) not copying :Lib:Precision.py (output up-to-date) not copying :Lib:RandomArray.py (output up-to- date) not copying :Lib:UserArray.py (output up-to-date) running build_ext building '_numpy' extension Create export file Titaantje:DevDev:python:Numeric- 20.0.0:build:temp.mac-2.2:_numpy.mcp.exp Create XML file Titaantje:DevDev:python:Numeric- 20.0.0:build:temp.mac-2.2:_numpy.xml Traceback (most recent call last): File "Titaantje:DevDev:python:Numeric- 20.0.0:setup.py", line 61, in ? libraries = libraries_list) File "Titaantje:DevDev:python:python:Lib:distutils:core.p y", line 138, in setup dist.run_commands() File "Titaantje:DevDev:python:python:Lib:distutils:dist.p y", line 893, in run_commands self.run_command(cmd) File "Titaantje:DevDev:python:python:Lib:distutils:dist.p y", line 913, in run_command cmd_obj.run() File "Titaantje:DevDev:python:python:Lib:distutils:com mand:build.py", line 107, in run self.run_command(cmd_name) File "Titaantje:DevDev:python:python:Lib:distutils:cmd.p y", line 330, in run_command self.distribution.run_command(command) File "Titaantje:DevDev:python:python:Lib:distutils:dist.p y", line 913, in run_command cmd_obj.run() File "Titaantje:DevDev:python:python:Lib:distutils:com mand:build_ext.py", line 256, in run self.build_extensions() File "Titaantje:DevDev:python:python:Lib:distutils:com mand:build_ext.py", line 383, in build_extensions self.build_extension(ext) File "Titaantje:DevDev:python:python:Lib:distutils:com mand:build_ext.py", line 486, in build_extension build_temp=self.build_temp) File "Titaantje:DevDev:python:python:Lib:distutils:ccom piler.py", line 663, in link_shared_object extra_preargs, extra_postargs, build_temp) File "Titaantje:DevDev:python:python:Lib:distutils:mwer kscompiler.py", line 187, in link xmlbuilder.generate() File "Titaantje:DevDev:python:python:Mac:Lib:mkcwproj ect:cwxmlgen.py", line 49, in generate self._generate_one_template(tmpl) File "Titaantje:DevDev:python:python:Mac:Lib:mkcwproj ect:cwxmlgen.py", line 91, in _generate_one_template result = self._generate_one_value(datasource, dataname) File "Titaantje:DevDev:python:python:Mac:Lib:mkcwproj ect:cwxmlgen.py", line 104, in _generate_one_value return format % self.dict KeyError: stdlibraryflags ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-14 06:31 Message: Logged In: YES user_id=45365 Fixed in the CVS tree. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492665&group_id=5470 From noreply@sourceforge.net Fri Dec 14 14:52:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 06:52:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-492496 ] distutils, shared libraries and Mac OS X Message-ID: Bugs item #492496, was opened at 2001-12-13 07:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492496&group_id=5470 Category: Distutils Group: None >Status: Closed Resolution: None Priority: 1 Submitted By: Matthew King (kyrrigle) Assigned to: Nobody/Anonymous (nobody) Summary: distutils, shared libraries and Mac OS X Initial Comment: My python: Python 2.1.1 (#33, Dec 9 2001, 12:26:52) [GCC 2.95.2 19991024 (release)] on darwin5 I was trying to configure the sketch app and setup.py was complaining that it could not find my tcl/tk libraries. The problem is that Darwin uses the .dylib extension for shared libraries and distutils was looking for .so. as a "fix", in distutils/unixccompiler.py I made the following change: 76c76,78 < --- > import sys > if sys.platform[:-1] == "darwin": # Mac OS X > shared_lib_extension = ".dylib" this worked, but I'm sure there's a better way... i'd imagine that this would also be an issue on HP-UX with the .sl extension? ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-14 06:52 Message: Logged In: YES user_id=45365 Yes, this has been addressed by that patch, and the patch has been applied to the CVS tree, so I'm closing this report. ---------------------------------------------------------------------- Comment By: Matthew King (kyrrigle) Date: 2001-12-13 08:17 Message: Logged In: YES user_id=247536 looks like patch #450862 already addresses this issue for .dylib ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492496&group_id=5470 From noreply@sourceforge.net Fri Dec 14 15:57:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 07:57:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-493252 ] maximum recursion limit exceeded in match Message-ID: Bugs item #493252, was opened at 2001-12-14 02:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: P. de Jong (peterdejong) >Assigned to: Fredrik Lundh (effbot) >Summary: maximum recursion limit exceeded in match Initial Comment: RuntimeError: maximum recursion limit exceeded in match, while trying to match a string of 16384 bytes. (Python 2.0) The error does not occur after eliminating some 100 characters from the string. The error does not occur in Python 1.5.2. So I cannot upgrade. Peter de Jong ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-14 07:57 Message: Logged In: YES user_id=31435 Assigned to /F. Echo Guido's belief that the regexp can almost certainly be rewritten to avoid this and run much faster at the same time. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 05:53 Message: Logged In: YES user_id=6380 Hi Peter! This usually happens when the pattern contains * or + in a way that causes more backtracking than one would naively expect. Can you show us the pattern? There's usually an easy way to rewrite the pattern so that it won't overflow -- and it will be faster too... BTW I would upgrade to Python 2.1.1 -- that's the most stable release to date. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 From noreply@sourceforge.net Fri Dec 14 16:16:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 08:16:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-482631 ] Integrate Pynche enhancements Message-ID: Bugs item #482631, was opened at 2001-11-16 13:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482631&group_id=5470 Category: Demos and Tools Group: Python 2.2 >Status: Closed >Resolution: Later Priority: 6 Submitted By: Barry Warsaw (bwarsaw) Assigned to: Barry Warsaw (bwarsaw) Summary: Integrate Pynche enhancements Initial Comment: Just filing a bug report so I don't forget to integrate Laura Creighton's Pynche enhancements before 2.2 final. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-14 08:16 Message: Logged In: YES user_id=12800 This won't happen for 2.2. We'll try again for Python 2.3. Laura is going to rework the patches. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482631&group_id=5470 From noreply@sourceforge.net Fri Dec 14 16:32:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 08:32:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-493252 ] maximum recursion limit exceeded in match Message-ID: Bugs item #493252, was opened at 2001-12-14 02:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: P. de Jong (peterdejong) Assigned to: Fredrik Lundh (effbot) Summary: maximum recursion limit exceeded in match Initial Comment: RuntimeError: maximum recursion limit exceeded in match, while trying to match a string of 16384 bytes. (Python 2.0) The error does not occur after eliminating some 100 characters from the string. The error does not occur in Python 1.5.2. So I cannot upgrade. Peter de Jong ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2001-12-14 08:32 Message: Logged In: YES user_id=38376 Three additional comments: 1) The fact that you get this under 2.0 indicates that your regular expression doesn't run very well under 1.5.2 either; it can most likely be rewritten to be much faster, and use much less memory. 2) But if that's okay, you can always work around this by replacing "import re" with "import pre as re" (or "import pre; re = pre") 3) This will be fixed in future versions. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-14 07:57 Message: Logged In: YES user_id=31435 Assigned to /F. Echo Guido's belief that the regexp can almost certainly be rewritten to avoid this and run much faster at the same time. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 05:53 Message: Logged In: YES user_id=6380 Hi Peter! This usually happens when the pattern contains * or + in a way that causes more backtracking than one would naively expect. Can you show us the pattern? There's usually an easy way to rewrite the pattern so that it won't overflow -- and it will be faster too... BTW I would upgrade to Python 2.1.1 -- that's the most stable release to date. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 From noreply@sourceforge.net Fri Dec 14 16:48:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 08:48:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-487310 ] smtplib mishandles SMTP disconnects Message-ID: Bugs item #487310, was opened at 2001-11-29 16:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487310&group_id=5470 Category: Python Library Group: Python 2.1.1 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Fazal Majid (majid) Assigned to: Barry Warsaw (bwarsaw) Summary: smtplib mishandles SMTP disconnects Initial Comment: smtplib handles SMTP disconnects (e.g. timeouts) inconsistently. The smtplib.SMTP.send() method does not reset self.file on a socket error, unlike getreply(), and thus a close() is necessary for in one case but not in the other. Recommendation: have smtplib.SMTP.send() call close() on socket.error just as smtplib.SMTP.getreply() does on EOF on self.file. In the following test case, I have set the SMTP timeout on my local machine to 10 seconds: Python 2.1.1 (#1, Nov 7 2001, 16:18:10) [GCC 2.95.3 20010315 (release)] on sunos5 Type "copyright", "credits" or "license" for more information. >>> import smtplib >>> s = smtplib.SMTP('localhost', 25) >>> import time >>> time.sleep(10) >>> s.sendmail('fmajid@kefta.com', 'fmajid@kefta.com', '...') Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.1/smtplib.py", line 469, in sendmail (code,resp) = self.helo() File "/usr/local/lib/python2.1/smtplib.py", line 305, in helo self.putcmd("helo", socket.getfqdn()) File "/usr/local/lib/python2.1/smtplib.py", line 249, in putcmd self.send(str) File "/usr/local/lib/python2.1/smtplib.py", line 239, in send raise SMTPServerDisconnected('Server not connected') smtplib.SMTPServerDisconnected: Server not connected >>> s.connect('localhost', 25) Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.1/smtplib.py", line 226, in connect (code,msg)=self.getreply() File "/usr/local/lib/python2.1/smtplib.py", line 271, in getreply raise SMTPServerDisconnected("Connection unexpectedly closed") smtplib.SMTPServerDisconnected: Connection unexpectedly closed >>> s.connect('localhost', 25) (220, 'bayazid.kefta.com ESMTP Postfix') ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-14 08:48 Message: Logged In: YES user_id=12800 Patch seems good to me, so I'm going to apply it to smtplib.py for both 2.2c1 and 2.2 trunk. Yes, it would be very nice to have a test suite for smtplib.py. I have a start of one in Mailman that uses smtpd.py. If you think it's worthwhile, why don't you upload your test suite to the patch tracker, assign it to me, and I'll merge it with what I have. This would be for Python 2.3. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2001-12-05 15:44 Message: Logged In: YES user_id=110477 Oops... forgot to check the checkbox for attachments. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2001-12-05 15:42 Message: Logged In: YES user_id=110477 I am attaching a patch that calls self.close() before raising the SMTPServerDisconnected exception. There does not seem to be a standard unit test for smtplib. I have run this patch through a unit test of my own that exercises smtplib. I don't have a way to test a broken MTA that disconnects on EHLO, however. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 08:45 Message: Logged In: YES user_id=6380 Can you please supply a patch? Upload a context diff, don't forget to check the file upload checkbox. ---------------------------------------------------------------------- Comment By: Fazal Majid (majid) Date: 2001-11-30 07:04 Message: Logged In: YES user_id=110477 I forgot to mention a workaround: if you catch SMTPServerDisconnected, call self.close(). The operation is idempotent so it isn't a problem if you do it twice, for instance if the exception occurs in getreply(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487310&group_id=5470 From noreply@sourceforge.net Fri Dec 14 17:01:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 09:01:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-493243 ] ext call doco warts Message-ID: Bugs item #493243, was opened at 2001-12-14 02:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493243&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None >Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ext call doco warts Initial Comment: Now they've been compiled , I notice that there are some warts in my docs for the *- and **-style call syntax. 1) the "argument_list" production is really, really confusing. there must be a better BNF-style way of saying that. I don't think vertically centering the production name against the production helps. 2) For some reason, where I say It is unusual for both keyword arguments and the "*expression"syntax to be used in the same call, so in practice this confusion does not arise. there's no space between `"*expression"' and `syntax'. I'd guess that this is because in the source, the \samp{} macro is the last thing on the line, but why that should lead to a missing space is beyond me -- more latex2html bugs? (just noticed the same thing a bit higher up too -- the "**expression"argument, if any No hurry with these. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-14 09:01 Message: Logged In: YES user_id=3066 Fixed table cell alignment in Doc/perl/python.perl revision 1.115. Fixed item 2: Worked around spaces problem in Doc/ref/ref5.tex 1.53 This bug remains open; I still need to address the basic problem in item 1 (confusing pseudo-EBNF). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493243&group_id=5470 From noreply@sourceforge.net Fri Dec 14 19:04:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 11:04:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-493415 ] "Type Methods" section cut off Message-ID: Bugs item #493415, was opened at 2001-12-14 11:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493415&group_id=5470 Category: Documentation Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Doug Zongker (dzongker) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: "Type Methods" section cut off Initial Comment: Section 2.2 ("Type Methods") of "Extending and Embedding" seems to be cut off. It claims it will go over a long definition line-by-line, then ends abruptly about ten lines in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493415&group_id=5470 From noreply@sourceforge.net Fri Dec 14 21:17:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 13:17:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-493462 ] Attribute Search in MRO w/o tp_getattr Message-ID: Bugs item #493462, was opened at 2001-12-14 13:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493462&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Robert Stewart (rstewart) Assigned to: Nobody/Anonymous (nobody) Summary: Attribute Search in MRO w/o tp_getattr Initial Comment: In writing a metatype, I wanted to resolve attribute references via a tp_getattr-style function -- with either a char * or a Python string. Unfortunately, PyObject_GenericGetAttr() first tries _PyType_Lookup() to find a descriptor via base class dictionaries. Searching according to the MRO is fine. The problem is that _PyType_Lookup() only searches the dictionary of each base class. It never checks those bases to see it tp_getattr is set. My workaround, which is not ideal, is to implement my own tp_getattro function which first calls PyObject_GenericGetAttr() to locate the attribute. If that succeeds, that attribute is returned. If it fails, then the tp_getattr-style function is called to locate the attribute. This approach will return a base class attribute when the derived class overrides it, which is why I said it was not ideal. The only way I can improve this process is to write my own replacement for PyObject_GenericGetAttr() and _PyType_Lookup(). That would make my code very brittle, so that's not a good solution. What I'd like to see is for _PyType_Lookup() to try the dictionary, as it does now. If that fails, I'd like it to check to see if tp_getattr is set. If so, I'd like it to call the tp_getattr function to resolve the attribute. Perhaps this change violates some ideal of Python that I can't foresee, but it would sure work great for me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493462&group_id=5470 From noreply@sourceforge.net Fri Dec 14 21:41:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 13:41:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-493462 ] Attribute Search in MRO w/o tp_getattr Message-ID: Bugs item #493462, was opened at 2001-12-14 13:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493462&group_id=5470 >Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Robert Stewart (rstewart) >Assigned to: Guido van Rossum (gvanrossum) Summary: Attribute Search in MRO w/o tp_getattr Initial Comment: In writing a metatype, I wanted to resolve attribute references via a tp_getattr-style function -- with either a char * or a Python string. Unfortunately, PyObject_GenericGetAttr() first tries _PyType_Lookup() to find a descriptor via base class dictionaries. Searching according to the MRO is fine. The problem is that _PyType_Lookup() only searches the dictionary of each base class. It never checks those bases to see it tp_getattr is set. My workaround, which is not ideal, is to implement my own tp_getattro function which first calls PyObject_GenericGetAttr() to locate the attribute. If that succeeds, that attribute is returned. If it fails, then the tp_getattr-style function is called to locate the attribute. This approach will return a base class attribute when the derived class overrides it, which is why I said it was not ideal. The only way I can improve this process is to write my own replacement for PyObject_GenericGetAttr() and _PyType_Lookup(). That would make my code very brittle, so that's not a good solution. What I'd like to see is for _PyType_Lookup() to try the dictionary, as it does now. If that fails, I'd like it to check to see if tp_getattr is set. If so, I'd like it to call the tp_getattr function to resolve the attribute. Perhaps this change violates some ideal of Python that I can't foresee, but it would sure work great for me. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 13:41 Message: Logged In: YES user_id=6380 When you talk about the bases and their tp_getattr, are you talking about the tp_getattr of the base type, or of its metatype? (Note: forget about tp_getattr -- you should leave that NULL, and only implement tp_getatto.) PyObject_GenericGetAttr() should only be used in situations where the base type's tp_getattro is also PyObject_GenericGetAttr(). Why do you think that writing your own replacement for PyObject_GenericGetAttr() and _PyType_Lookup() would be brittle? That's what you are *supposed* to do if you're not happy with them. What do you want to do with your metatype? Why do you need one? Have you considered prototyping it in Python? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493462&group_id=5470 From noreply@sourceforge.net Fri Dec 14 22:53:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 14:53:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-492619 ] __del__ docs need update Message-ID: Bugs item #492619, was opened at 2001-12-13 13:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492619&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Finn Bock (bckfnn) Summary: __del__ docs need update Initial Comment: Similarly to words added in 2.2 to the gc module docs and extension docs, the Ref Man's section on __del__ should be clearer about the interactions between objects with __del__ methods and cyclic gc. The Ref Man should also be clearer about which parts of the semantics hold across all Python implementations, and which are specific to CPython (e.g., IIRC, __del__ isn't called by magic at all in Jython). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-14 14:53 Message: Logged In: YES user_id=3066 Fixed for CPython in Doc/ref/ref3.tex 1.82. Finn, can you review the __del__() description for Jython? Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492619&group_id=5470 From noreply@sourceforge.net Fri Dec 14 23:03:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 15:03:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-493493 ] https error Message-ID: Bugs item #493493, was opened at 2001-12-14 15:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493493&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Ryan Morillo (srart) Assigned to: Nobody/Anonymous (nobody) Summary: https error Initial Comment: when using urllib.urlopen it raises an IOError: [Errno url error] unknown url type: 'https' trace back: File "", line 1, in ? f('https://prodigycentral- ykt.prodigy.com/tools/wcr.nsf/launch?OpenForm') File "C:\PYTHON22\lib\urllib.py", line 73, in urlopen return _urlopener.open(url) File "C:\PYTHON22\lib\urllib.py", line 175, in open return self.open_unknown(fullurl, data) File "C:\PYTHON22\lib\urllib.py", line 187, in open_unknown raise IOError, ('url error', 'unknown url type', type) IOError: [Errno url error] unknown url type: 'https' ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493493&group_id=5470 From noreply@sourceforge.net Fri Dec 14 23:04:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 15:04:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-493496 ] https error Message-ID: Bugs item #493496, was opened at 2001-12-14 15:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493496&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Ryan Morillo (srart) Assigned to: Nobody/Anonymous (nobody) Summary: https error Initial Comment: when using urllib.urlopen it raises an IOError: [Errno url error] unknown url type: 'https' trace back: File "", line 1, in ? f('https://prodigycentral- ykt.prodigy.com/tools/wcr.nsf/launch?OpenForm') File "C:\PYTHON22\lib\urllib.py", line 73, in urlopen return _urlopener.open(url) File "C:\PYTHON22\lib\urllib.py", line 175, in open return self.open_unknown(fullurl, data) File "C:\PYTHON22\lib\urllib.py", line 187, in open_unknown raise IOError, ('url error', 'unknown url type', type) IOError: [Errno url error] unknown url type: 'https' ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493496&group_id=5470 From noreply@sourceforge.net Fri Dec 14 23:58:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 15:58:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-493514 ] test_hotshot hangs under cygwin Message-ID: Bugs item #493514, was opened at 2001-12-14 15:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493514&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Samuele Pedroni (pedronis) Assigned to: Nobody/Anonymous (nobody) Summary: test_hotshot hangs under cygwin Initial Comment: It seems that test_hotshot simply hangs under cygwin (dll 1.3.6). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493514&group_id=5470 From noreply@sourceforge.net Sat Dec 15 03:04:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 19:04:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-493548 ] delbitset() unused Message-ID: Bugs item #493548, was opened at 2001-12-14 19:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493548&group_id=5470 Category: Parser/Compiler Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: delbitset() unused Initial Comment: delbitset() doesn't appear to be used anywhere. here are all the references from find: ./Include/bitset.h:void delbitset(bitset bs); ./Include/pgenheaders.h:#define delbitset _Py_delbitset ./PC/os2vacpp/python.def:; _Py_delbitset ./Parser/bitset.c:delbitset(bitset ss) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493548&group_id=5470 From noreply@sourceforge.net Sat Dec 15 03:51:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 19:51:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-493561 ] incorrect format string descrobject.c Message-ID: Bugs item #493561, was opened at 2001-12-14 19:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493561&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect format string descrobject.c Initial Comment: The following lines appear to have an incorrect format string: descrobject.c:111: "attribute '%300s' of '%.100s' objects is not readable", descrobject.c:166: "attribute '%300s' of '%.100s' objects is not writable", it seems there should be a . as in '%.300s' ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493561&group_id=5470 From noreply@sourceforge.net Sat Dec 15 04:58:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 20:58:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-493548 ] delbitset() unused Message-ID: Bugs item #493548, was opened at 2001-12-14 19:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493548&group_id=5470 Category: Parser/Compiler Group: Python 2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Guido van Rossum (gvanrossum) Summary: delbitset() unused Initial Comment: delbitset() doesn't appear to be used anywhere. here are all the references from find: ./Include/bitset.h:void delbitset(bitset bs); ./Include/pgenheaders.h:#define delbitset _Py_delbitset ./PC/os2vacpp/python.def:; _Py_delbitset ./Parser/bitset.c:delbitset(bitset ss) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 20:58 Message: Logged In: YES user_id=6380 Hm, I'd rather keep this function around for completeness -- the bitset datatype reads better if there's a del as well as a new. The waste in space is minimal. :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493548&group_id=5470 From noreply@sourceforge.net Sat Dec 15 05:01:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 21:01:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-493561 ] incorrect format string descrobject.c Message-ID: Bugs item #493561, was opened at 2001-12-14 19:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493561&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Guido van Rossum (gvanrossum) Summary: incorrect format string descrobject.c Initial Comment: The following lines appear to have an incorrect format string: descrobject.c:111: "attribute '%300s' of '%.100s' objects is not readable", descrobject.c:166: "attribute '%300s' of '%.100s' objects is not writable", it seems there should be a . as in '%.300s' ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 21:01 Message: Logged In: YES user_id=6380 Thanks! Fixed. (We need to get you CVS commit permission. Do you think you'd use it wisely?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493561&group_id=5470 From noreply@sourceforge.net Sat Dec 15 05:18:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 21:18:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-493561 ] incorrect format string descrobject.c Message-ID: Bugs item #493561, was opened at 2001-12-14 19:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493561&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Guido van Rossum (gvanrossum) Summary: incorrect format string descrobject.c Initial Comment: The following lines appear to have an incorrect format string: descrobject.c:111: "attribute '%300s' of '%.100s' objects is not readable", descrobject.c:166: "attribute '%300s' of '%.100s' objects is not writable", it seems there should be a . as in '%.300s' ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2001-12-14 21:18 Message: Logged In: YES user_id=33168 Sure, it's your system, you set the rules. Right now, I'm looking at test coverage. That's why I posted some test patches a while ago and why I'm finding these little problems. I have more tests I'm updating to improve coverage. But I'm not always sure the best place to put stuff. You can respond to me by mail if that's easier than using SF. If I get commit permission, should I also be added to python-dev? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 21:01 Message: Logged In: YES user_id=6380 Thanks! Fixed. (We need to get you CVS commit permission. Do you think you'd use it wisely?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493561&group_id=5470 From noreply@sourceforge.net Sat Dec 15 05:26:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 21:26:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-493561 ] incorrect format string descrobject.c Message-ID: Bugs item #493561, was opened at 2001-12-14 19:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493561&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Guido van Rossum (gvanrossum) Summary: incorrect format string descrobject.c Initial Comment: The following lines appear to have an incorrect format string: descrobject.c:111: "attribute '%300s' of '%.100s' objects is not readable", descrobject.c:166: "attribute '%300s' of '%.100s' objects is not writable", it seems there should be a . as in '%.300s' ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 21:26 Message: Logged In: YES user_id=6380 I've added you to the project as a developer. You should sign up for python-dev, the moderator will approve you. Typical policy is that when you have an idea for a change, you put up a patch on SF for review; when it's approved you can check it in yourself. You should also be able to review other people's patches if you feel like it. :-) Enjoy! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2001-12-14 21:18 Message: Logged In: YES user_id=33168 Sure, it's your system, you set the rules. Right now, I'm looking at test coverage. That's why I posted some test patches a while ago and why I'm finding these little problems. I have more tests I'm updating to improve coverage. But I'm not always sure the best place to put stuff. You can respond to me by mail if that's easier than using SF. If I get commit permission, should I also be added to python-dev? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 21:01 Message: Logged In: YES user_id=6380 Thanks! Fixed. (We need to get you CVS commit permission. Do you think you'd use it wisely?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493561&group_id=5470 From noreply@sourceforge.net Sat Dec 15 05:28:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 21:28:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-493496 ] https error Message-ID: Bugs item #493496, was opened at 2001-12-14 15:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493496&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Ryan Morillo (srart) Assigned to: Nobody/Anonymous (nobody) Summary: https error Initial Comment: when using urllib.urlopen it raises an IOError: [Errno url error] unknown url type: 'https' trace back: File "", line 1, in ? f('https://prodigycentral- ykt.prodigy.com/tools/wcr.nsf/launch?OpenForm') File "C:\PYTHON22\lib\urllib.py", line 73, in urlopen return _urlopener.open(url) File "C:\PYTHON22\lib\urllib.py", line 175, in open return self.open_unknown(fullurl, data) File "C:\PYTHON22\lib\urllib.py", line 187, in open_unknown raise IOError, ('url error', 'unknown url type', type) IOError: [Errno url error] unknown url type: 'https' ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493496&group_id=5470 From noreply@sourceforge.net Sat Dec 15 05:29:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 21:29:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-493493 ] https error Message-ID: Bugs item #493493, was opened at 2001-12-14 15:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493493&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Ryan Morillo (srart) Assigned to: Nobody/Anonymous (nobody) Summary: https error Initial Comment: when using urllib.urlopen it raises an IOError: [Errno url error] unknown url type: 'https' trace back: File "", line 1, in ? f('https://prodigycentral- ykt.prodigy.com/tools/wcr.nsf/launch?OpenForm') File "C:\PYTHON22\lib\urllib.py", line 73, in urlopen return _urlopener.open(url) File "C:\PYTHON22\lib\urllib.py", line 175, in open return self.open_unknown(fullurl, data) File "C:\PYTHON22\lib\urllib.py", line 187, in open_unknown raise IOError, ('url error', 'unknown url type', type) IOError: [Errno url error] unknown url type: 'https' ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 21:29 Message: Logged In: YES user_id=6380 This happens when you haven't installed and configured openssl. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493493&group_id=5470 From noreply@sourceforge.net Sat Dec 15 05:30:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 14 Dec 2001 21:30:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-492386 ] Cascading menu bug on Linux Message-ID: Bugs item #492386, was opened at 2001-12-12 23:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492386&group_id=5470 Category: Tkinter Group: Platform-specific >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Fredrik Juhlin (faeltir) Assigned to: Nobody/Anonymous (nobody) Summary: Cascading menu bug on Linux Initial Comment: When using post() to display a cascading menu,it appears as if submenus don't get mouse events under Linux/X. I've submitted some test code below to demonstrate the problem. I'm using Linux 2.4.5/XFree86 4.1.0/Python 2.1/Tcl 8.3. I've been told that the same code works fine on Win2000. # Code to show problem with cascading menus import Tkinter def hello(): print "hello!" root = Tkinter.Tk() frame = Tkinter.Frame(root, width=200, height=200) frame.pack() menu1 = Tkinter.Menu(frame, tearoff=0) menu1.add_command(label="Foo", command=hello) menu1.add_command(label="Bar", command=hello) menu0 = Tkinter.Menu(frame, tearoff=0) menu0.add_command(label="Command 1", command=hello) #This works menu0.add_cascade(label="Menu 1", menu=menu1) #Commands used in this menu #won't work def showMenu(event): menu0.post(event.x_root, event.y_root) frame.bind("", showMenu) Tkinter.mainloop() ---------------------------------------------------------------------- Comment By: Fredrik Juhlin (faeltir) Date: 2001-12-13 07:20 Message: Logged In: YES user_id=386805 My bad. I wasn't using the first-level menu as master for the second-level menu.I'm not sure how to set status for the bug-report properly, so I'll let some admin-type do that. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492386&group_id=5470 From noreply@sourceforge.net Sat Dec 15 11:38:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 03:38:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-493628 ] import not pythonic in 2.1.1 Message-ID: Bugs item #493628, was opened at 2001-12-15 03:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: import not pythonic in 2.1.1 Initial Comment: Take a package 'aPackage', which contains a sub-package 'aSubPackage' that in turn contains a module 'aModule' that defines a class 'aClass'. If I do: import aPackage.aSubPackage print aPackage.aSubPackage.aModule I get: Traceback (most recent call last): File "x.py", line xx, in ? print aPackage.aSubPackage.aModule AttributeError: 'aPackage.aSubPackage' module has no attribute 'aModule' A yet, if I do: import aPackage.aSubPackage.aModule print aPackage.aSubPackage.aModule I get: ...as expected, which is very confusing and doesn't feel 'right' :-S ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 From noreply@sourceforge.net Sat Dec 15 12:17:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 04:17:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-493631 ] Problem with mpz module (gmp4) Message-ID: Bugs item #493631, was opened at 2001-12-15 04:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Damien Wyart (chlick) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with mpz module (gmp4) Initial Comment: Trying to compile latest Python-2.2 (rc1), I found the following problem : I can't compile mpzmodule.c without modifying it. I use gcc-3.0.2 and gmp-4.0. I am not a gmp not a Python expert, but the problems seems to come mainly from lack of clear support of gmp-4 in mpzmodule.c. MPZ_GET_STR_BUG is obsolete now, and should not be used with gmp-4. #ifdef cases with MPZ_GET_STR_BUG defined uses obsolete struct field calls and leads to compilation problems. In fact, gmp-mparam.h should be included in all cases (not only when MPZ_GET_STR_BUG defined), and the whole file should be cleaned a bit to fully support gmp4. including longlong.h is not necessary. For now, there are two alternatives : gmp is gmp-2 and is really bogus, or gmp is not 2 and is bogus with respect to MPZ_GET_STR_BUG. The alternative "gmp-4" (not bogus) should be added. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 From noreply@sourceforge.net Sat Dec 15 12:18:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 04:18:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-493631 ] Problem with mpz module (gmp4) Message-ID: Bugs item #493631, was opened at 2001-12-15 04:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Damien Wyart (chlick) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with mpz module (gmp4) Initial Comment: Trying to compile latest Python-2.2 (rc1), I found the following problem : I can't compile mpzmodule.c without modifying it. I use gcc-3.0.2 and gmp-4.0. I am not a gmp not a Python expert, but the problems seems to come mainly from lack of clear support of gmp-4 in mpzmodule.c. MPZ_GET_STR_BUG is obsolete now, and should not be used with gmp-4. #ifdef cases with MPZ_GET_STR_BUG defined uses obsolete struct field calls and leads to compilation problems. In fact, gmp-mparam.h should be included in all cases (not only when MPZ_GET_STR_BUG defined), and the whole file should be cleaned a bit to fully support gmp4. including longlong.h is not necessary. For now, there are two alternatives : gmp is gmp-2 and is really bogus, or gmp is not 2 and is bogus with respect to MPZ_GET_STR_BUG. The alternative "gmp-4" (not bogus) should be added. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 From noreply@sourceforge.net Sat Dec 15 13:23:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 05:23:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-493252 ] maximum recursion limit exceeded in match Message-ID: Bugs item #493252, was opened at 2001-12-14 02:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: P. de Jong (peterdejong) Assigned to: Fredrik Lundh (effbot) Summary: maximum recursion limit exceeded in match Initial Comment: RuntimeError: maximum recursion limit exceeded in match, while trying to match a string of 16384 bytes. (Python 2.0) The error does not occur after eliminating some 100 characters from the string. The error does not occur in Python 1.5.2. So I cannot upgrade. Peter de Jong ---------------------------------------------------------------------- >Comment By: P. de Jong (peterdejong) Date: 2001-12-15 05:23 Message: Logged In: YES user_id=402001 Hi Guido! The regular expression used was: '(?s)"(.*?)"(;|\n)' Peter ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-12-14 08:32 Message: Logged In: YES user_id=38376 Three additional comments: 1) The fact that you get this under 2.0 indicates that your regular expression doesn't run very well under 1.5.2 either; it can most likely be rewritten to be much faster, and use much less memory. 2) But if that's okay, you can always work around this by replacing "import re" with "import pre as re" (or "import pre; re = pre") 3) This will be fixed in future versions. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-14 07:57 Message: Logged In: YES user_id=31435 Assigned to /F. Echo Guido's belief that the regexp can almost certainly be rewritten to avoid this and run much faster at the same time. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 05:53 Message: Logged In: YES user_id=6380 Hi Peter! This usually happens when the pattern contains * or + in a way that causes more backtracking than one would naively expect. Can you show us the pattern? There's usually an easy way to rewrite the pattern so that it won't overflow -- and it will be faster too... BTW I would upgrade to Python 2.1.1 -- that's the most stable release to date. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 From noreply@sourceforge.net Sat Dec 15 14:11:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 06:11:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-493514 ] test_hotshot hangs under cygwin Message-ID: Bugs item #493514, was opened at 2001-12-14 15:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493514&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Samuele Pedroni (pedronis) >Assigned to: Michael Hudson (mwh) Summary: test_hotshot hangs under cygwin Initial Comment: It seems that test_hotshot simply hangs under cygwin (dll 1.3.6). ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-15 06:11 Message: Logged In: YES user_id=6656 Works for me. More information? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493514&group_id=5470 From noreply@sourceforge.net Sat Dec 15 15:36:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 07:36:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-492619 ] __del__ docs need update Message-ID: Bugs item #492619, was opened at 2001-12-13 13:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492619&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: __del__ docs need update Initial Comment: Similarly to words added in 2.2 to the gc module docs and extension docs, the Ref Man's section on __del__ should be clearer about the interactions between objects with __del__ methods and cyclic gc. The Ref Man should also be clearer about which parts of the semantics hold across all Python implementations, and which are specific to CPython (e.g., IIRC, __del__ isn't called by magic at all in Jython). ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2001-12-15 07:36 Message: Logged In: YES user_id=4201 __del__ is only called once in Jython, even if the object is made reachable by the __del__ method. This restriction is inherited from java. A known difference which isn't covered by the ref, is that Jython requires that a class is born with a __del__ method in order to call it during finalization. Added a __del__ method to a class after the "class" statement does not enable the __del__ magic. I dunno if such implementation details should be documented. In general I think the describtion for __del__ also covers the gist of __del__ in Jython. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-14 14:53 Message: Logged In: YES user_id=3066 Fixed for CPython in Doc/ref/ref3.tex 1.82. Finn, can you review the __del__() description for Jython? Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492619&group_id=5470 From noreply@sourceforge.net Sat Dec 15 15:39:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 07:39:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-493628 ] import not pythonic in 2.1.1 Message-ID: Bugs item #493628, was opened at 2001-12-15 03:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 Category: Python Interpreter Core >Group: Not a Bug >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: import not pythonic in 2.1.1 Initial Comment: Take a package 'aPackage', which contains a sub-package 'aSubPackage' that in turn contains a module 'aModule' that defines a class 'aClass'. If I do: import aPackage.aSubPackage print aPackage.aSubPackage.aModule I get: Traceback (most recent call last): File "x.py", line xx, in ? print aPackage.aSubPackage.aModule AttributeError: 'aPackage.aSubPackage' module has no attribute 'aModule' A yet, if I do: import aPackage.aSubPackage.aModule print aPackage.aSubPackage.aModule I get: ...as expected, which is very confusing and doesn't feel 'right' :-S ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 07:39 Message: Logged In: YES user_id=6380 Better adjust your intuition. :-) This is as intended. Attributes of packages that are *modules* are only loaded when the corresponding module is explicitly imported (by you, or by some other code, e.g. the package's __init__.py). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 From noreply@sourceforge.net Sat Dec 15 16:03:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 08:03:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-493252 ] maximum recursion limit exceeded in match Message-ID: Bugs item #493252, was opened at 2001-12-14 02:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: P. de Jong (peterdejong) Assigned to: Fredrik Lundh (effbot) Summary: maximum recursion limit exceeded in match Initial Comment: RuntimeError: maximum recursion limit exceeded in match, while trying to match a string of 16384 bytes. (Python 2.0) The error does not occur after eliminating some 100 characters from the string. The error does not occur in Python 1.5.2. So I cannot upgrade. Peter de Jong ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:03 Message: Logged In: YES user_id=6380 Do you really *want* that pattern to match input like this: "xxx"xxx"; ??? If not, replace the (.*?) with ([^"]*) -- this will dramatically reduce the amount of backtracking generated if there are unbalanced quotes in the input. ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-15 05:23 Message: Logged In: YES user_id=402001 Hi Guido! The regular expression used was: '(?s)"(.*?)"(;|\n)' Peter ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-12-14 08:32 Message: Logged In: YES user_id=38376 Three additional comments: 1) The fact that you get this under 2.0 indicates that your regular expression doesn't run very well under 1.5.2 either; it can most likely be rewritten to be much faster, and use much less memory. 2) But if that's okay, you can always work around this by replacing "import re" with "import pre as re" (or "import pre; re = pre") 3) This will be fixed in future versions. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-14 07:57 Message: Logged In: YES user_id=31435 Assigned to /F. Echo Guido's belief that the regexp can almost certainly be rewritten to avoid this and run much faster at the same time. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 05:53 Message: Logged In: YES user_id=6380 Hi Peter! This usually happens when the pattern contains * or + in a way that causes more backtracking than one would naively expect. Can you show us the pattern? There's usually an easy way to rewrite the pattern so that it won't overflow -- and it will be faster too... BTW I would upgrade to Python 2.1.1 -- that's the most stable release to date. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 From noreply@sourceforge.net Sat Dec 15 16:08:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 08:08:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-493631 ] Problem with mpz module (gmp4) Message-ID: Bugs item #493631, was opened at 2001-12-15 04:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Damien Wyart (chlick) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with mpz module (gmp4) Initial Comment: Trying to compile latest Python-2.2 (rc1), I found the following problem : I can't compile mpzmodule.c without modifying it. I use gcc-3.0.2 and gmp-4.0. I am not a gmp not a Python expert, but the problems seems to come mainly from lack of clear support of gmp-4 in mpzmodule.c. MPZ_GET_STR_BUG is obsolete now, and should not be used with gmp-4. #ifdef cases with MPZ_GET_STR_BUG defined uses obsolete struct field calls and leads to compilation problems. In fact, gmp-mparam.h should be included in all cases (not only when MPZ_GET_STR_BUG defined), and the whole file should be cleaned a bit to fully support gmp4. including longlong.h is not necessary. For now, there are two alternatives : gmp is gmp-2 and is really bogus, or gmp is not 2 and is bogus with respect to MPZ_GET_STR_BUG. The alternative "gmp-4" (not bogus) should be added. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:08 Message: Logged In: YES user_id=6380 I'm afraid we won't have time to fix the mpz module before the planned final release of 2.2 next week, although I'll see if we have someone on call who understands the issues. If you want to help by providing a patch, that would work too! According to some comments in setup.py, there's an improved mpz wrapper for Python here: pympz.sf.net. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 From noreply@sourceforge.net Sat Dec 15 16:18:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 08:18:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-493631 ] Problem with mpz module (gmp4) Message-ID: Bugs item #493631, was opened at 2001-12-15 04:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Damien Wyart (chlick) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with mpz module (gmp4) Initial Comment: Trying to compile latest Python-2.2 (rc1), I found the following problem : I can't compile mpzmodule.c without modifying it. I use gcc-3.0.2 and gmp-4.0. I am not a gmp not a Python expert, but the problems seems to come mainly from lack of clear support of gmp-4 in mpzmodule.c. MPZ_GET_STR_BUG is obsolete now, and should not be used with gmp-4. #ifdef cases with MPZ_GET_STR_BUG defined uses obsolete struct field calls and leads to compilation problems. In fact, gmp-mparam.h should be included in all cases (not only when MPZ_GET_STR_BUG defined), and the whole file should be cleaned a bit to fully support gmp4. including longlong.h is not necessary. For now, there are two alternatives : gmp is gmp-2 and is really bogus, or gmp is not 2 and is bogus with respect to MPZ_GET_STR_BUG. The alternative "gmp-4" (not bogus) should be added. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:18 Message: Logged In: YES user_id=6380 I apologize, pympz.sf.net doesn't exist (anymore?). I don't know what happened to it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:08 Message: Logged In: YES user_id=6380 I'm afraid we won't have time to fix the mpz module before the planned final release of 2.2 next week, although I'll see if we have someone on call who understands the issues. If you want to help by providing a patch, that would work too! According to some comments in setup.py, there's an improved mpz wrapper for Python here: pympz.sf.net. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 From noreply@sourceforge.net Sat Dec 15 16:26:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 08:26:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-493631 ] Problem with mpz module (gmp4) Message-ID: Bugs item #493631, was opened at 2001-12-15 04:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Damien Wyart (chlick) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with mpz module (gmp4) Initial Comment: Trying to compile latest Python-2.2 (rc1), I found the following problem : I can't compile mpzmodule.c without modifying it. I use gcc-3.0.2 and gmp-4.0. I am not a gmp not a Python expert, but the problems seems to come mainly from lack of clear support of gmp-4 in mpzmodule.c. MPZ_GET_STR_BUG is obsolete now, and should not be used with gmp-4. #ifdef cases with MPZ_GET_STR_BUG defined uses obsolete struct field calls and leads to compilation problems. In fact, gmp-mparam.h should be included in all cases (not only when MPZ_GET_STR_BUG defined), and the whole file should be cleaned a bit to fully support gmp4. including longlong.h is not necessary. For now, there are two alternatives : gmp is gmp-2 and is really bogus, or gmp is not 2 and is bogus with respect to MPZ_GET_STR_BUG. The alternative "gmp-4" (not bogus) should be added. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:26 Message: Logged In: YES user_id=6380 However there's gmpy.sf.net, which appears a more recent GMP wrapper for Python. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:18 Message: Logged In: YES user_id=6380 I apologize, pympz.sf.net doesn't exist (anymore?). I don't know what happened to it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:08 Message: Logged In: YES user_id=6380 I'm afraid we won't have time to fix the mpz module before the planned final release of 2.2 next week, although I'll see if we have someone on call who understands the issues. If you want to help by providing a patch, that would work too! According to some comments in setup.py, there's an improved mpz wrapper for Python here: pympz.sf.net. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 From noreply@sourceforge.net Sat Dec 15 16:48:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 08:48:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-493631 ] Problem with mpz module (gmp4) Message-ID: Bugs item #493631, was opened at 2001-12-15 04:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Damien Wyart (chlick) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with mpz module (gmp4) Initial Comment: Trying to compile latest Python-2.2 (rc1), I found the following problem : I can't compile mpzmodule.c without modifying it. I use gcc-3.0.2 and gmp-4.0. I am not a gmp not a Python expert, but the problems seems to come mainly from lack of clear support of gmp-4 in mpzmodule.c. MPZ_GET_STR_BUG is obsolete now, and should not be used with gmp-4. #ifdef cases with MPZ_GET_STR_BUG defined uses obsolete struct field calls and leads to compilation problems. In fact, gmp-mparam.h should be included in all cases (not only when MPZ_GET_STR_BUG defined), and the whole file should be cleaned a bit to fully support gmp4. including longlong.h is not necessary. For now, there are two alternatives : gmp is gmp-2 and is really bogus, or gmp is not 2 and is bogus with respect to MPZ_GET_STR_BUG. The alternative "gmp-4" (not bogus) should be added. ---------------------------------------------------------------------- >Comment By: Damien Wyart (chlick) Date: 2001-12-15 08:48 Message: Logged In: YES user_id=402822 In fact, I was quite afraid by this bug at first (I'm not a Python expert, as already said), because I knew arbitrary length integers support had changed in 2.2, and thought the mp support module was directly used for bignum calculations! This is not the case, because you said this bug hasn't to be killed before official 2.2. I could provide a patch bypassing the MPZ_GET_STR thing for gmp-4, but as I do not know the situation about gmp versions between 2 and 4, this is not really safe. I have been able to compile fine, but this was more a hack than a clean patching, and not suitable for all versions of gmp. If there is an official mpz maintainer, I think it would be better he handles the job. If there is no maintainer at all, I can try to provide a fix, but will have to get in touch with gmp author and act calmly. So this could take a while. Thanks for your answers. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:26 Message: Logged In: YES user_id=6380 However there's gmpy.sf.net, which appears a more recent GMP wrapper for Python. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:18 Message: Logged In: YES user_id=6380 I apologize, pympz.sf.net doesn't exist (anymore?). I don't know what happened to it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:08 Message: Logged In: YES user_id=6380 I'm afraid we won't have time to fix the mpz module before the planned final release of 2.2 next week, although I'll see if we have someone on call who understands the issues. If you want to help by providing a patch, that would work too! According to some comments in setup.py, there's an improved mpz wrapper for Python here: pympz.sf.net. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 From noreply@sourceforge.net Sat Dec 15 17:15:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 09:15:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-493628 ] import not pythonic in 2.1.1 Message-ID: Bugs item #493628, was opened at 2001-12-15 03:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: import not pythonic in 2.1.1 Initial Comment: Take a package 'aPackage', which contains a sub-package 'aSubPackage' that in turn contains a module 'aModule' that defines a class 'aClass'. If I do: import aPackage.aSubPackage print aPackage.aSubPackage.aModule I get: Traceback (most recent call last): File "x.py", line xx, in ? print aPackage.aSubPackage.aModule AttributeError: 'aPackage.aSubPackage' module has no attribute 'aModule' A yet, if I do: import aPackage.aSubPackage.aModule print aPackage.aSubPackage.aModule I get: ...as expected, which is very confusing and doesn't feel 'right' :-S ---------------------------------------------------------------------- >Comment By: Chris Withers (fresh) Date: 2001-12-15 09:15 Message: Logged In: YES user_id=24723 Okay, if it's intended, that means there's a good reason for it... ...where can I look for enlightenment as to what that is? cheers, Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 07:39 Message: Logged In: YES user_id=6380 Better adjust your intuition. :-) This is as intended. Attributes of packages that are *modules* are only loaded when the corresponding module is explicitly imported (by you, or by some other code, e.g. the package's __init__.py). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 From noreply@sourceforge.net Sat Dec 15 17:26:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 09:26:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-493631 ] Problem with mpz module (gmp4) Message-ID: Bugs item #493631, was opened at 2001-12-15 04:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None >Priority: 5 Submitted By: Damien Wyart (chlick) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with mpz module (gmp4) Initial Comment: Trying to compile latest Python-2.2 (rc1), I found the following problem : I can't compile mpzmodule.c without modifying it. I use gcc-3.0.2 and gmp-4.0. I am not a gmp not a Python expert, but the problems seems to come mainly from lack of clear support of gmp-4 in mpzmodule.c. MPZ_GET_STR_BUG is obsolete now, and should not be used with gmp-4. #ifdef cases with MPZ_GET_STR_BUG defined uses obsolete struct field calls and leads to compilation problems. In fact, gmp-mparam.h should be included in all cases (not only when MPZ_GET_STR_BUG defined), and the whole file should be cleaned a bit to fully support gmp4. including longlong.h is not necessary. For now, there are two alternatives : gmp is gmp-2 and is really bogus, or gmp is not 2 and is bogus with respect to MPZ_GET_STR_BUG. The alternative "gmp-4" (not bogus) should be added. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 09:26 Message: Logged In: YES user_id=6380 You're right, Python does not depend on GMP or MPZ for its long arithmetic. There's no mpz maintainer that I know of, so a patch would be much appreciated! ---------------------------------------------------------------------- Comment By: Damien Wyart (chlick) Date: 2001-12-15 08:48 Message: Logged In: YES user_id=402822 In fact, I was quite afraid by this bug at first (I'm not a Python expert, as already said), because I knew arbitrary length integers support had changed in 2.2, and thought the mp support module was directly used for bignum calculations! This is not the case, because you said this bug hasn't to be killed before official 2.2. I could provide a patch bypassing the MPZ_GET_STR thing for gmp-4, but as I do not know the situation about gmp versions between 2 and 4, this is not really safe. I have been able to compile fine, but this was more a hack than a clean patching, and not suitable for all versions of gmp. If there is an official mpz maintainer, I think it would be better he handles the job. If there is no maintainer at all, I can try to provide a fix, but will have to get in touch with gmp author and act calmly. So this could take a while. Thanks for your answers. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:26 Message: Logged In: YES user_id=6380 However there's gmpy.sf.net, which appears a more recent GMP wrapper for Python. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:18 Message: Logged In: YES user_id=6380 I apologize, pympz.sf.net doesn't exist (anymore?). I don't know what happened to it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:08 Message: Logged In: YES user_id=6380 I'm afraid we won't have time to fix the mpz module before the planned final release of 2.2 next week, although I'll see if we have someone on call who understands the issues. If you want to help by providing a patch, that would work too! According to some comments in setup.py, there's an improved mpz wrapper for Python here: pympz.sf.net. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 From noreply@sourceforge.net Sat Dec 15 17:45:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 09:45:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-493631 ] Problem with mpz module (gmp4) Message-ID: Bugs item #493631, was opened at 2001-12-15 04:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Damien Wyart (chlick) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with mpz module (gmp4) Initial Comment: Trying to compile latest Python-2.2 (rc1), I found the following problem : I can't compile mpzmodule.c without modifying it. I use gcc-3.0.2 and gmp-4.0. I am not a gmp not a Python expert, but the problems seems to come mainly from lack of clear support of gmp-4 in mpzmodule.c. MPZ_GET_STR_BUG is obsolete now, and should not be used with gmp-4. #ifdef cases with MPZ_GET_STR_BUG defined uses obsolete struct field calls and leads to compilation problems. In fact, gmp-mparam.h should be included in all cases (not only when MPZ_GET_STR_BUG defined), and the whole file should be cleaned a bit to fully support gmp4. including longlong.h is not necessary. For now, there are two alternatives : gmp is gmp-2 and is really bogus, or gmp is not 2 and is bogus with respect to MPZ_GET_STR_BUG. The alternative "gmp-4" (not bogus) should be added. ---------------------------------------------------------------------- >Comment By: Damien Wyart (chlick) Date: 2001-12-15 09:45 Message: Logged In: YES user_id=402822 OK, I will have a look at it and also contact gmp main author. I will let you know about it asap... Thanks for your kindness and patience. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 09:26 Message: Logged In: YES user_id=6380 You're right, Python does not depend on GMP or MPZ for its long arithmetic. There's no mpz maintainer that I know of, so a patch would be much appreciated! ---------------------------------------------------------------------- Comment By: Damien Wyart (chlick) Date: 2001-12-15 08:48 Message: Logged In: YES user_id=402822 In fact, I was quite afraid by this bug at first (I'm not a Python expert, as already said), because I knew arbitrary length integers support had changed in 2.2, and thought the mp support module was directly used for bignum calculations! This is not the case, because you said this bug hasn't to be killed before official 2.2. I could provide a patch bypassing the MPZ_GET_STR thing for gmp-4, but as I do not know the situation about gmp versions between 2 and 4, this is not really safe. I have been able to compile fine, but this was more a hack than a clean patching, and not suitable for all versions of gmp. If there is an official mpz maintainer, I think it would be better he handles the job. If there is no maintainer at all, I can try to provide a fix, but will have to get in touch with gmp author and act calmly. So this could take a while. Thanks for your answers. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:26 Message: Logged In: YES user_id=6380 However there's gmpy.sf.net, which appears a more recent GMP wrapper for Python. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:18 Message: Logged In: YES user_id=6380 I apologize, pympz.sf.net doesn't exist (anymore?). I don't know what happened to it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:08 Message: Logged In: YES user_id=6380 I'm afraid we won't have time to fix the mpz module before the planned final release of 2.2 next week, although I'll see if we have someone on call who understands the issues. If you want to help by providing a patch, that would work too! According to some comments in setup.py, there's an improved mpz wrapper for Python here: pympz.sf.net. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 From noreply@sourceforge.net Sat Dec 15 17:46:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 09:46:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-493628 ] import not pythonic in 2.1.1 Message-ID: Bugs item #493628, was opened at 2001-12-15 03:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: import not pythonic in 2.1.1 Initial Comment: Take a package 'aPackage', which contains a sub-package 'aSubPackage' that in turn contains a module 'aModule' that defines a class 'aClass'. If I do: import aPackage.aSubPackage print aPackage.aSubPackage.aModule I get: Traceback (most recent call last): File "x.py", line xx, in ? print aPackage.aSubPackage.aModule AttributeError: 'aPackage.aSubPackage' module has no attribute 'aModule' A yet, if I do: import aPackage.aSubPackage.aModule print aPackage.aSubPackage.aModule I get: ...as expected, which is very confusing and doesn't feel 'right' :-S ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 09:46 Message: Logged In: YES user_id=6380 http://www.python.org/doc/essays/packages.html ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-15 09:15 Message: Logged In: YES user_id=24723 Okay, if it's intended, that means there's a good reason for it... ...where can I look for enlightenment as to what that is? cheers, Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 07:39 Message: Logged In: YES user_id=6380 Better adjust your intuition. :-) This is as intended. Attributes of packages that are *modules* are only loaded when the corresponding module is explicitly imported (by you, or by some other code, e.g. the package's __init__.py). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 From noreply@sourceforge.net Sat Dec 15 18:23:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 10:23:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-493700 ] Installing Python2.2b2 compileall hangs Message-ID: Bugs item #493700, was opened at 2001-12-15 10:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493700&group_id=5470 Category: Installation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Horst Eyermann (horst) Assigned to: Nobody/Anonymous (nobody) Summary: Installing Python2.2b2 compileall hangs Initial Comment: Installing python 2.2.b2 on my linux machine fails, as it is hanging in the compileall step: PYTHONPATH=/usr/local/lib/python2.2 ./python -tt /usr/local/lib/python2.2/compileall.py -x badsyntax /usr/local/lib/python2.2 Listing /usr/local/lib/python2.2 ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... goes on forever without doing anything. when I insert a line 37: print names I just receive an empty list Horsrt ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493700&group_id=5470 From noreply@sourceforge.net Sat Dec 15 18:33:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 10:33:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-493700 ] Installing Python2.2b2 compileall hangs Message-ID: Bugs item #493700, was opened at 2001-12-15 10:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493700&group_id=5470 Category: Installation Group: Python 2.2 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Horst Eyermann (horst) Assigned to: Nobody/Anonymous (nobody) Summary: Installing Python2.2b2 compileall hangs Initial Comment: Installing python 2.2.b2 on my linux machine fails, as it is hanging in the compileall step: PYTHONPATH=/usr/local/lib/python2.2 ./python -tt /usr/local/lib/python2.2/compileall.py -x badsyntax /usr/local/lib/python2.2 Listing /usr/local/lib/python2.2 ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... goes on forever without doing anything. when I insert a line 37: print names I just receive an empty list Horsrt ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 10:33 Message: Logged In: YES user_id=6380 Something truly bizarre must be the matter with /usr/local/lib/python-2.2. I can only understand that the code would do this if you have a subdirectory with an empty name! What operating system? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493700&group_id=5470 From noreply@sourceforge.net Sat Dec 15 19:08:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 11:08:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-493252 ] maximum recursion limit exceeded in match Message-ID: Bugs item #493252, was opened at 2001-12-14 02:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: P. de Jong (peterdejong) Assigned to: Fredrik Lundh (effbot) Summary: maximum recursion limit exceeded in match Initial Comment: RuntimeError: maximum recursion limit exceeded in match, while trying to match a string of 16384 bytes. (Python 2.0) The error does not occur after eliminating some 100 characters from the string. The error does not occur in Python 1.5.2. So I cannot upgrade. Peter de Jong ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-15 11:08 Message: Logged In: YES user_id=31435 Peter, assuming Guido is correct that you did not intend to match strings with embedded double quotes, here's a correct (and much more efficient) replacement for your regexp: r'"[^"\n]*"[;\n]' Note that (contra Guido's suggestion ), a newline has to be part of the negated character class, because you asked for single-line mode so presumably didn't want your .*? to match any newlines either. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:03 Message: Logged In: YES user_id=6380 Do you really *want* that pattern to match input like this: "xxx"xxx"; ??? If not, replace the (.*?) with ([^"]*) -- this will dramatically reduce the amount of backtracking generated if there are unbalanced quotes in the input. ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-15 05:23 Message: Logged In: YES user_id=402001 Hi Guido! The regular expression used was: '(?s)"(.*?)"(;|\n)' Peter ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-12-14 08:32 Message: Logged In: YES user_id=38376 Three additional comments: 1) The fact that you get this under 2.0 indicates that your regular expression doesn't run very well under 1.5.2 either; it can most likely be rewritten to be much faster, and use much less memory. 2) But if that's okay, you can always work around this by replacing "import re" with "import pre as re" (or "import pre; re = pre") 3) This will be fixed in future versions. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-14 07:57 Message: Logged In: YES user_id=31435 Assigned to /F. Echo Guido's belief that the regexp can almost certainly be rewritten to avoid this and run much faster at the same time. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 05:53 Message: Logged In: YES user_id=6380 Hi Peter! This usually happens when the pattern contains * or + in a way that causes more backtracking than one would naively expect. Can you show us the pattern? There's usually an easy way to rewrite the pattern so that it won't overflow -- and it will be faster too... BTW I would upgrade to Python 2.1.1 -- that's the most stable release to date. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 From noreply@sourceforge.net Sat Dec 15 19:20:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 11:20:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-493631 ] Problem with mpz module (gmp4) Message-ID: Bugs item #493631, was opened at 2001-12-15 04:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Damien Wyart (chlick) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with mpz module (gmp4) Initial Comment: Trying to compile latest Python-2.2 (rc1), I found the following problem : I can't compile mpzmodule.c without modifying it. I use gcc-3.0.2 and gmp-4.0. I am not a gmp not a Python expert, but the problems seems to come mainly from lack of clear support of gmp-4 in mpzmodule.c. MPZ_GET_STR_BUG is obsolete now, and should not be used with gmp-4. #ifdef cases with MPZ_GET_STR_BUG defined uses obsolete struct field calls and leads to compilation problems. In fact, gmp-mparam.h should be included in all cases (not only when MPZ_GET_STR_BUG defined), and the whole file should be cleaned a bit to fully support gmp4. including longlong.h is not necessary. For now, there are two alternatives : gmp is gmp-2 and is really bogus, or gmp is not 2 and is bogus with respect to MPZ_GET_STR_BUG. The alternative "gmp-4" (not bogus) should be added. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-15 11:19 Message: Logged In: YES user_id=31435 We should phase out mpz, because we can't support it (== nobody wants it enough to maintain it -- and don't look at me, unless it comes out of paid time and even then under protest ). There are (at least) two more-current GMP wrappers for Python: 1) http://gmpy.sourceforge.net/ 2) http://www.lemburg.com/files/python/mxNumber.html I'd recommend the latter for a casual user, as Marc-Andre is still actively developing his mxNumber package. ---------------------------------------------------------------------- Comment By: Damien Wyart (chlick) Date: 2001-12-15 09:45 Message: Logged In: YES user_id=402822 OK, I will have a look at it and also contact gmp main author. I will let you know about it asap... Thanks for your kindness and patience. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 09:26 Message: Logged In: YES user_id=6380 You're right, Python does not depend on GMP or MPZ for its long arithmetic. There's no mpz maintainer that I know of, so a patch would be much appreciated! ---------------------------------------------------------------------- Comment By: Damien Wyart (chlick) Date: 2001-12-15 08:48 Message: Logged In: YES user_id=402822 In fact, I was quite afraid by this bug at first (I'm not a Python expert, as already said), because I knew arbitrary length integers support had changed in 2.2, and thought the mp support module was directly used for bignum calculations! This is not the case, because you said this bug hasn't to be killed before official 2.2. I could provide a patch bypassing the MPZ_GET_STR thing for gmp-4, but as I do not know the situation about gmp versions between 2 and 4, this is not really safe. I have been able to compile fine, but this was more a hack than a clean patching, and not suitable for all versions of gmp. If there is an official mpz maintainer, I think it would be better he handles the job. If there is no maintainer at all, I can try to provide a fix, but will have to get in touch with gmp author and act calmly. So this could take a while. Thanks for your answers. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:26 Message: Logged In: YES user_id=6380 However there's gmpy.sf.net, which appears a more recent GMP wrapper for Python. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:18 Message: Logged In: YES user_id=6380 I apologize, pympz.sf.net doesn't exist (anymore?). I don't know what happened to it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:08 Message: Logged In: YES user_id=6380 I'm afraid we won't have time to fix the mpz module before the planned final release of 2.2 next week, although I'll see if we have someone on call who understands the issues. If you want to help by providing a patch, that would work too! According to some comments in setup.py, there's an improved mpz wrapper for Python here: pympz.sf.net. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 From noreply@sourceforge.net Sat Dec 15 21:59:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 13:59:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-493631 ] Problem with mpz module (gmp4) Message-ID: Bugs item #493631, was opened at 2001-12-15 04:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Damien Wyart (chlick) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with mpz module (gmp4) Initial Comment: Trying to compile latest Python-2.2 (rc1), I found the following problem : I can't compile mpzmodule.c without modifying it. I use gcc-3.0.2 and gmp-4.0. I am not a gmp not a Python expert, but the problems seems to come mainly from lack of clear support of gmp-4 in mpzmodule.c. MPZ_GET_STR_BUG is obsolete now, and should not be used with gmp-4. #ifdef cases with MPZ_GET_STR_BUG defined uses obsolete struct field calls and leads to compilation problems. In fact, gmp-mparam.h should be included in all cases (not only when MPZ_GET_STR_BUG defined), and the whole file should be cleaned a bit to fully support gmp4. including longlong.h is not necessary. For now, there are two alternatives : gmp is gmp-2 and is really bogus, or gmp is not 2 and is bogus with respect to MPZ_GET_STR_BUG. The alternative "gmp-4" (not bogus) should be added. ---------------------------------------------------------------------- >Comment By: Damien Wyart (chlick) Date: 2001-12-15 13:59 Message: Logged In: YES user_id=402822 So, Guido, could you tell what you think about all this ? Should I start digging into mpz or is it droppable right now ? Thanks in advance for any thoughts... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 11:19 Message: Logged In: YES user_id=31435 We should phase out mpz, because we can't support it (== nobody wants it enough to maintain it -- and don't look at me, unless it comes out of paid time and even then under protest ). There are (at least) two more-current GMP wrappers for Python: 1) http://gmpy.sourceforge.net/ 2) http://www.lemburg.com/files/python/mxNumber.html I'd recommend the latter for a casual user, as Marc-Andre is still actively developing his mxNumber package. ---------------------------------------------------------------------- Comment By: Damien Wyart (chlick) Date: 2001-12-15 09:45 Message: Logged In: YES user_id=402822 OK, I will have a look at it and also contact gmp main author. I will let you know about it asap... Thanks for your kindness and patience. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 09:26 Message: Logged In: YES user_id=6380 You're right, Python does not depend on GMP or MPZ for its long arithmetic. There's no mpz maintainer that I know of, so a patch would be much appreciated! ---------------------------------------------------------------------- Comment By: Damien Wyart (chlick) Date: 2001-12-15 08:48 Message: Logged In: YES user_id=402822 In fact, I was quite afraid by this bug at first (I'm not a Python expert, as already said), because I knew arbitrary length integers support had changed in 2.2, and thought the mp support module was directly used for bignum calculations! This is not the case, because you said this bug hasn't to be killed before official 2.2. I could provide a patch bypassing the MPZ_GET_STR thing for gmp-4, but as I do not know the situation about gmp versions between 2 and 4, this is not really safe. I have been able to compile fine, but this was more a hack than a clean patching, and not suitable for all versions of gmp. If there is an official mpz maintainer, I think it would be better he handles the job. If there is no maintainer at all, I can try to provide a fix, but will have to get in touch with gmp author and act calmly. So this could take a while. Thanks for your answers. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:26 Message: Logged In: YES user_id=6380 However there's gmpy.sf.net, which appears a more recent GMP wrapper for Python. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:18 Message: Logged In: YES user_id=6380 I apologize, pympz.sf.net doesn't exist (anymore?). I don't know what happened to it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:08 Message: Logged In: YES user_id=6380 I'm afraid we won't have time to fix the mpz module before the planned final release of 2.2 next week, although I'll see if we have someone on call who understands the issues. If you want to help by providing a patch, that would work too! According to some comments in setup.py, there's an improved mpz wrapper for Python here: pympz.sf.net. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 From noreply@sourceforge.net Sun Dec 16 00:47:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 16:47:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Sun Dec 16 00:50:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 16:50:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Sun Dec 16 01:02:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 17:02:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-493631 ] Problem with mpz module (gmp4) Message-ID: Bugs item #493631, was opened at 2001-12-15 04:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Damien Wyart (chlick) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with mpz module (gmp4) Initial Comment: Trying to compile latest Python-2.2 (rc1), I found the following problem : I can't compile mpzmodule.c without modifying it. I use gcc-3.0.2 and gmp-4.0. I am not a gmp not a Python expert, but the problems seems to come mainly from lack of clear support of gmp-4 in mpzmodule.c. MPZ_GET_STR_BUG is obsolete now, and should not be used with gmp-4. #ifdef cases with MPZ_GET_STR_BUG defined uses obsolete struct field calls and leads to compilation problems. In fact, gmp-mparam.h should be included in all cases (not only when MPZ_GET_STR_BUG defined), and the whole file should be cleaned a bit to fully support gmp4. including longlong.h is not necessary. For now, there are two alternatives : gmp is gmp-2 and is really bogus, or gmp is not 2 and is bogus with respect to MPZ_GET_STR_BUG. The alternative "gmp-4" (not bogus) should be added. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:02 Message: Logged In: YES user_id=6380 chlick, I think we're deciding to deprecate mpz, so you won't have to put any effort in it. Thanks! ---------------------------------------------------------------------- Comment By: Damien Wyart (chlick) Date: 2001-12-15 13:59 Message: Logged In: YES user_id=402822 So, Guido, could you tell what you think about all this ? Should I start digging into mpz or is it droppable right now ? Thanks in advance for any thoughts... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 11:19 Message: Logged In: YES user_id=31435 We should phase out mpz, because we can't support it (== nobody wants it enough to maintain it -- and don't look at me, unless it comes out of paid time and even then under protest ). There are (at least) two more-current GMP wrappers for Python: 1) http://gmpy.sourceforge.net/ 2) http://www.lemburg.com/files/python/mxNumber.html I'd recommend the latter for a casual user, as Marc-Andre is still actively developing his mxNumber package. ---------------------------------------------------------------------- Comment By: Damien Wyart (chlick) Date: 2001-12-15 09:45 Message: Logged In: YES user_id=402822 OK, I will have a look at it and also contact gmp main author. I will let you know about it asap... Thanks for your kindness and patience. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 09:26 Message: Logged In: YES user_id=6380 You're right, Python does not depend on GMP or MPZ for its long arithmetic. There's no mpz maintainer that I know of, so a patch would be much appreciated! ---------------------------------------------------------------------- Comment By: Damien Wyart (chlick) Date: 2001-12-15 08:48 Message: Logged In: YES user_id=402822 In fact, I was quite afraid by this bug at first (I'm not a Python expert, as already said), because I knew arbitrary length integers support had changed in 2.2, and thought the mp support module was directly used for bignum calculations! This is not the case, because you said this bug hasn't to be killed before official 2.2. I could provide a patch bypassing the MPZ_GET_STR thing for gmp-4, but as I do not know the situation about gmp versions between 2 and 4, this is not really safe. I have been able to compile fine, but this was more a hack than a clean patching, and not suitable for all versions of gmp. If there is an official mpz maintainer, I think it would be better he handles the job. If there is no maintainer at all, I can try to provide a fix, but will have to get in touch with gmp author and act calmly. So this could take a while. Thanks for your answers. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:26 Message: Logged In: YES user_id=6380 However there's gmpy.sf.net, which appears a more recent GMP wrapper for Python. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:18 Message: Logged In: YES user_id=6380 I apologize, pympz.sf.net doesn't exist (anymore?). I don't know what happened to it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:08 Message: Logged In: YES user_id=6380 I'm afraid we won't have time to fix the mpz module before the planned final release of 2.2 next week, although I'll see if we have someone on call who understands the issues. If you want to help by providing a patch, that would work too! According to some comments in setup.py, there's an improved mpz wrapper for Python here: pympz.sf.net. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 From noreply@sourceforge.net Sun Dec 16 01:18:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 17:18:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Sun Dec 16 01:30:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 17:30:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-493252 ] maximum recursion limit exceeded in match Message-ID: Bugs item #493252, was opened at 2001-12-14 02:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: P. de Jong (peterdejong) Assigned to: Fredrik Lundh (effbot) Summary: maximum recursion limit exceeded in match Initial Comment: RuntimeError: maximum recursion limit exceeded in match, while trying to match a string of 16384 bytes. (Python 2.0) The error does not occur after eliminating some 100 characters from the string. The error does not occur in Python 1.5.2. So I cannot upgrade. Peter de Jong ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:30 Message: Logged In: YES user_id=6380 Tim, Peter's regex starts with (?s) which is the same as compiling with re.S or re.DOTALL which makes '.' match newline -- the opposite of what you seem to think (?s) means. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 11:08 Message: Logged In: YES user_id=31435 Peter, assuming Guido is correct that you did not intend to match strings with embedded double quotes, here's a correct (and much more efficient) replacement for your regexp: r'"[^"\n]*"[;\n]' Note that (contra Guido's suggestion ), a newline has to be part of the negated character class, because you asked for single-line mode so presumably didn't want your .*? to match any newlines either. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:03 Message: Logged In: YES user_id=6380 Do you really *want* that pattern to match input like this: "xxx"xxx"; ??? If not, replace the (.*?) with ([^"]*) -- this will dramatically reduce the amount of backtracking generated if there are unbalanced quotes in the input. ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-15 05:23 Message: Logged In: YES user_id=402001 Hi Guido! The regular expression used was: '(?s)"(.*?)"(;|\n)' Peter ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-12-14 08:32 Message: Logged In: YES user_id=38376 Three additional comments: 1) The fact that you get this under 2.0 indicates that your regular expression doesn't run very well under 1.5.2 either; it can most likely be rewritten to be much faster, and use much less memory. 2) But if that's okay, you can always work around this by replacing "import re" with "import pre as re" (or "import pre; re = pre") 3) This will be fixed in future versions. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-14 07:57 Message: Logged In: YES user_id=31435 Assigned to /F. Echo Guido's belief that the regexp can almost certainly be rewritten to avoid this and run much faster at the same time. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 05:53 Message: Logged In: YES user_id=6380 Hi Peter! This usually happens when the pattern contains * or + in a way that causes more backtracking than one would naively expect. Can you show us the pattern? There's usually an easy way to rewrite the pattern so that it won't overflow -- and it will be faster too... BTW I would upgrade to Python 2.1.1 -- that's the most stable release to date. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 From noreply@sourceforge.net Sun Dec 16 04:34:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 20:34:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-493252 ] maximum recursion limit exceeded in match Message-ID: Bugs item #493252, was opened at 2001-12-14 02:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: P. de Jong (peterdejong) Assigned to: Fredrik Lundh (effbot) Summary: maximum recursion limit exceeded in match Initial Comment: RuntimeError: maximum recursion limit exceeded in match, while trying to match a string of 16384 bytes. (Python 2.0) The error does not occur after eliminating some 100 characters from the string. The error does not occur in Python 1.5.2. So I cannot upgrade. Peter de Jong ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-15 20:34 Message: Logged In: YES user_id=31435 Oops! I used to make the same mistake in Perl too (which is I pushed to name the symbolic flag DOTALL instead of SINGLELINE). So the correct regexp is r'"[^"]*"[;\n]' Assuming, of course, that Peter does want embedded newlines to get sucked up. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:30 Message: Logged In: YES user_id=6380 Tim, Peter's regex starts with (?s) which is the same as compiling with re.S or re.DOTALL which makes '.' match newline -- the opposite of what you seem to think (?s) means. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 11:08 Message: Logged In: YES user_id=31435 Peter, assuming Guido is correct that you did not intend to match strings with embedded double quotes, here's a correct (and much more efficient) replacement for your regexp: r'"[^"\n]*"[;\n]' Note that (contra Guido's suggestion ), a newline has to be part of the negated character class, because you asked for single-line mode so presumably didn't want your .*? to match any newlines either. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:03 Message: Logged In: YES user_id=6380 Do you really *want* that pattern to match input like this: "xxx"xxx"; ??? If not, replace the (.*?) with ([^"]*) -- this will dramatically reduce the amount of backtracking generated if there are unbalanced quotes in the input. ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-15 05:23 Message: Logged In: YES user_id=402001 Hi Guido! The regular expression used was: '(?s)"(.*?)"(;|\n)' Peter ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-12-14 08:32 Message: Logged In: YES user_id=38376 Three additional comments: 1) The fact that you get this under 2.0 indicates that your regular expression doesn't run very well under 1.5.2 either; it can most likely be rewritten to be much faster, and use much less memory. 2) But if that's okay, you can always work around this by replacing "import re" with "import pre as re" (or "import pre; re = pre") 3) This will be fixed in future versions. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-14 07:57 Message: Logged In: YES user_id=31435 Assigned to /F. Echo Guido's belief that the regexp can almost certainly be rewritten to avoid this and run much faster at the same time. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 05:53 Message: Logged In: YES user_id=6380 Hi Peter! This usually happens when the pattern contains * or + in a way that causes more backtracking than one would naively expect. Can you show us the pattern? There's usually an easy way to rewrite the pattern so that it won't overflow -- and it will be faster too... BTW I would upgrade to Python 2.1.1 -- that's the most stable release to date. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 From noreply@sourceforge.net Sun Dec 16 05:56:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 21:56:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-493815 ] IRIX 6.5 bus error Message-ID: Bugs item #493815, was opened at 2001-12-15 21:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493815&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: IRIX 6.5 bus error Initial Comment: A simple statement causes a bus error under IRIX 6.5: % ./configure -without-threads % make % ./python Python 2.1.1 (#1, Dec 15 2001, 21:40:34) [C] on irix6 Type "copyright", "credits" or "license" for more information. >>> print 3. * 24 Bus error OS version: IRIX 6.5.10m MIPSpro Compilers: Version 7.3.1.2m The threaded version of Python does not exhibit the same problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493815&group_id=5470 From noreply@sourceforge.net Sun Dec 16 06:04:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 22:04:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-493815 ] IRIX 6.5 bus error Message-ID: Bugs item #493815, was opened at 2001-12-15 21:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493815&group_id=5470 Category: Python Interpreter Core >Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) >Assigned to: Tim Peters (tim_one) Summary: IRIX 6.5 bus error Initial Comment: A simple statement causes a bus error under IRIX 6.5: % ./configure -without-threads % make % ./python Python 2.1.1 (#1, Dec 15 2001, 21:40:34) [C] on irix6 Type "copyright", "credits" or "license" for more information. >>> print 3. * 24 Bus error OS version: IRIX 6.5.10m MIPSpro Compilers: Version 7.3.1.2m The threaded version of Python does not exhibit the same problem. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-15 22:04 Message: Logged In: YES user_id=31435 Recompile floatobject.c with optimization disabled; the problem will almost certainly go away; it's an SGI compiler bug if so. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493815&group_id=5470 From noreply@sourceforge.net Sun Dec 16 07:00:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 23:00:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-493826 ] Finder Tool Move not working on MOSX Message-ID: Bugs item #493826, was opened at 2001-12-15 23:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493826&group_id=5470 Category: Macintosh Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Benjamin Schollnick (bscholln) Assigned to: Jack Jansen (jackjansen) Summary: Finder Tool Move not working on MOSX Initial Comment: Under Mac OS X v10.1.1, Mac Python does not seem to handle a findertool move command. old: Macintosh HD:Desktop Folder:downloads: new: Macintosh HD:Desktop Folder:downloads:Achikatactics filename: ACHIKA_TACTICS_2_00.JPG old + file: Macintosh HD:Desktop Folder:downloads:ACHIKA_TACTICS_2_00.JPG Traceback (most recent call last): File "OS v9.1:Desktop Folder:python work:re-dup-file.py", line 104, in ? File "OS v9.1:Desktop Folder:python work:re-dup-file.py", line 53, in move_file File "OS v9.1:Applications (Mac OS 9):Python 2.1.1:Mac:Lib:findertools.py", line 74, in move File "OS v9.1:Applications (Mac OS 9):Python 2.1.1:Mac:Lib:lib-scriptpackages:Finder:Standard_Suite.py", line 293, in move aetools.Error: (0, 'component result = no error', None) The file *does* get moved, but the above trace is reported. I'll append the actual code, once I boot back to OS 9. The same code *DOES* work under OS 9... (So it is restricted to Mac OS X 10.1.1). I do not *REMEMBER* seeing the problem in earlier versions of Mac OS X, but that is suspect. (I can't say for certain that it doesn't appear). - Benjamin ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493826&group_id=5470 From noreply@sourceforge.net Sun Dec 16 07:39:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 23:39:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-493815 ] IRIX 6.5 bus error Message-ID: Bugs item #493815, was opened at 2001-12-15 21:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493815&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Tim Peters (tim_one) Summary: IRIX 6.5 bus error Initial Comment: A simple statement causes a bus error under IRIX 6.5: % ./configure -without-threads % make % ./python Python 2.1.1 (#1, Dec 15 2001, 21:40:34) [C] on irix6 Type "copyright", "credits" or "license" for more information. >>> print 3. * 24 Bus error OS version: IRIX 6.5.10m MIPSpro Compilers: Version 7.3.1.2m The threaded version of Python does not exhibit the same problem. ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2001-12-15 23:39 Message: Logged In: YES user_id=71407 Thanks for the fast response. Compiling floatobject.c with -O0 does the trick. It would be advantageous if configure could print a warning about SGI problems with floatobject.c (and didn't Python 1.5.2 have a problem with complexobject.c?). Ralf ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 22:04 Message: Logged In: YES user_id=31435 Recompile floatobject.c with optimization disabled; the problem will almost certainly go away; it's an SGI compiler bug if so. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493815&group_id=5470 From noreply@sourceforge.net Sun Dec 16 07:49:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 15 Dec 2001 23:49:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Sun Dec 16 08:12:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 00:12:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-493815 ] IRIX 6.5 bus error Message-ID: Bugs item #493815, was opened at 2001-12-15 21:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493815&group_id=5470 Category: Python Interpreter Core Group: Platform-specific >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Tim Peters (tim_one) Summary: IRIX 6.5 bus error Initial Comment: A simple statement causes a bus error under IRIX 6.5: % ./configure -without-threads % make % ./python Python 2.1.1 (#1, Dec 15 2001, 21:40:34) [C] on irix6 Type "copyright", "credits" or "license" for more information. >>> print 3. * 24 Bus error OS version: IRIX 6.5.10m MIPSpro Compilers: Version 7.3.1.2m The threaded version of Python does not exhibit the same problem. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-16 00:12 Message: Logged In: YES user_id=31435 Well, there's always *some* optimization problem with SGI's compiler du jour. That's why the primary Python README file has said this for years: """ WARNING: There are bugs in the optimizer of some versions of SGI's compilers that can cause bus errors or other strange behavior, especially on numerical operations. To avoid this, try building with "make OPT=". """ "Turn off optimization" is the first response to every SGI bug report, and is also usually the last. I don't know whether SGI users report these bugs to SGI (they're not due to non-standard C in Python -- every one to date has been pinned on the compiler), but things never really improve there -- the bugs just shift around. I wish SGI would add Python to their compiler regression test suite. If you want to submit a patch to spray configure warnings, someone will look at it, but since it's already covered in README and the bugs differ across compiler versions, I'm not keen on the idea. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2001-12-15 23:39 Message: Logged In: YES user_id=71407 Thanks for the fast response. Compiling floatobject.c with -O0 does the trick. It would be advantageous if configure could print a warning about SGI problems with floatobject.c (and didn't Python 1.5.2 have a problem with complexobject.c?). Ralf ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 22:04 Message: Logged In: YES user_id=31435 Recompile floatobject.c with optimization disabled; the problem will almost certainly go away; it's an SGI compiler bug if so. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493815&group_id=5470 From noreply@sourceforge.net Sun Dec 16 08:17:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 00:17:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-493837 ] Distutils not finding Python on Win2K Message-ID: Bugs item #493837, was opened at 2001-12-16 00:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493837&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Thomas Heller (theller) Summary: Distutils not finding Python on Win2K Initial Comment: Thomas (or anyone else), can you help this fellow who posted to the Tutor list? If there's a systematic problem here with 2.2c1, we've only got a window of a few days to fix it. """ From: tutor-admin@python.org [mailto:tutor- admin@python.org]On Behalf Of Quniceleaf Listservs Sent: Sunday, December 16, 2001 2:02 AM To: tutor@python.org Subject: [Tutor] Python not being found in the registry? I'm using Python 2.2c1 on a Win2K machine. I've repeatedly tried installing two Python addons from different sources (XIST and the MySQL-interface) that each use a Windows installer program based on distutils-1.0.2pre. Both need to locate the Python installation before proceeding with the setup, and will not allow the user to browse and specify the location themselves. Unfortunately, neither can ever find a Python installation, and thus will not install. I've tried this repeatedly with Python 2.1, 2.2b, 2.2c1, and with ActiveState's distribution. In each case the installation is reflected in the Windows registry, but only the ActiveState install appears in the setup (and due to instability issues I am sticking with the standard distribution). Has anyone else encountered this problem? - Brian """ Unfortunately, the Tutor list reports his email address as listservb@quinceleaf.com, which doesn't seem reasonable. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493837&group_id=5470 From noreply@sourceforge.net Sun Dec 16 12:58:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 04:58:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-493628 ] import not pythonic in 2.1.1 Message-ID: Bugs item #493628, was opened at 2001-12-15 03:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: import not pythonic in 2.1.1 Initial Comment: Take a package 'aPackage', which contains a sub-package 'aSubPackage' that in turn contains a module 'aModule' that defines a class 'aClass'. If I do: import aPackage.aSubPackage print aPackage.aSubPackage.aModule I get: Traceback (most recent call last): File "x.py", line xx, in ? print aPackage.aSubPackage.aModule AttributeError: 'aPackage.aSubPackage' module has no attribute 'aModule' A yet, if I do: import aPackage.aSubPackage.aModule print aPackage.aSubPackage.aModule I get: ...as expected, which is very confusing and doesn't feel 'right' :-S ---------------------------------------------------------------------- >Comment By: Chris Withers (fresh) Date: 2001-12-16 04:58 Message: Logged In: YES user_id=24723 Well, I read it, and it explains the history, but it doesn't give reasons, particularly for: > Contrarily, when using syntax like import item.subitem.subsubitem, each item except for the last must be a package; the last item can be a module > or a package but can't be a class or function or variable defined in the previous item. ...or for the above stuff. But, while I find it counter-intuitive (and means I have to use unpleasant exec statements), I am but one voice among many who probably feel differently so I'll just accept it as one of the things i don't like about python... thanks for your time :-) Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 09:46 Message: Logged In: YES user_id=6380 http://www.python.org/doc/essays/packages.html ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-15 09:15 Message: Logged In: YES user_id=24723 Okay, if it's intended, that means there's a good reason for it... ...where can I look for enlightenment as to what that is? cheers, Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 07:39 Message: Logged In: YES user_id=6380 Better adjust your intuition. :-) This is as intended. Attributes of packages that are *modules* are only loaded when the corresponding module is explicitly imported (by you, or by some other code, e.g. the package's __init__.py). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 From noreply@sourceforge.net Sun Dec 16 16:52:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 08:52:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-493415 ] "Type Methods" section cut off Message-ID: Bugs item #493415, was opened at 2001-12-14 11:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493415&group_id=5470 Category: Documentation Group: Python 2.1.1 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Doug Zongker (dzongker) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: "Type Methods" section cut off Initial Comment: Section 2.2 ("Type Methods") of "Extending and Embedding" seems to be cut off. It claims it will go over a long definition line-by-line, then ends abruptly about ten lines in. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-16 08:52 Message: Logged In: YES user_id=3066 This section was not completed in time for the 2.1.x release; additional information will be included in the documentation for Python 2.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493415&group_id=5470 From noreply@sourceforge.net Sun Dec 16 18:03:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 10:03:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-493628 ] import not pythonic in 2.1.1 Message-ID: Bugs item #493628, was opened at 2001-12-15 03:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: import not pythonic in 2.1.1 Initial Comment: Take a package 'aPackage', which contains a sub-package 'aSubPackage' that in turn contains a module 'aModule' that defines a class 'aClass'. If I do: import aPackage.aSubPackage print aPackage.aSubPackage.aModule I get: Traceback (most recent call last): File "x.py", line xx, in ? print aPackage.aSubPackage.aModule AttributeError: 'aPackage.aSubPackage' module has no attribute 'aModule' A yet, if I do: import aPackage.aSubPackage.aModule print aPackage.aSubPackage.aModule I get: ...as expected, which is very confusing and doesn't feel 'right' :-S ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-16 10:03 Message: Logged In: YES user_id=31435 Chris, why do you think you need to use an exec stmt? You haven't shown an example of why it's needed, and it sure isn't obvious. Modules must be imported, and importing a module M requires an import stmt whose last path component is M -- that's about all there is to it. ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-16 04:58 Message: Logged In: YES user_id=24723 Well, I read it, and it explains the history, but it doesn't give reasons, particularly for: > Contrarily, when using syntax like import item.subitem.subsubitem, each item except for the last must be a package; the last item can be a module > or a package but can't be a class or function or variable defined in the previous item. ...or for the above stuff. But, while I find it counter-intuitive (and means I have to use unpleasant exec statements), I am but one voice among many who probably feel differently so I'll just accept it as one of the things i don't like about python... thanks for your time :-) Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 09:46 Message: Logged In: YES user_id=6380 http://www.python.org/doc/essays/packages.html ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-15 09:15 Message: Logged In: YES user_id=24723 Okay, if it's intended, that means there's a good reason for it... ...where can I look for enlightenment as to what that is? cheers, Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 07:39 Message: Logged In: YES user_id=6380 Better adjust your intuition. :-) This is as intended. Attributes of packages that are *modules* are only loaded when the corresponding module is explicitly imported (by you, or by some other code, e.g. the package's __init__.py). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 From noreply@sourceforge.net Sun Dec 16 18:57:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 10:57:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-493936 ] _PyEval_SliceIndex vs NULL Message-ID: Bugs item #493936, was opened at 2001-12-16 10:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493936&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Tim Peters (tim_one) Summary: _PyEval_SliceIndex vs NULL Initial Comment: _PyEval_SliceIndex goes out of its way to say everything's fine when passed a NULL pointer, but leaves the output *pi untouched in that case. But, AFAICT, it doesn't make sense to call this routine with a NULL pointer, and nobody does. So it should assert that v is not NULL. Hold for 2.3 "just in case". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493936&group_id=5470 From noreply@sourceforge.net Sun Dec 16 19:23:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 11:23:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-493951 ] string.{starts,ends}with vs slices Message-ID: Bugs item #493951, was opened at 2001-12-16 11:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493951&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Barry Warsaw (bwarsaw) Summary: string.{starts,ends}with vs slices Initial Comment: The attached test shows many cases where string.startswith() and string.endswith() fail to handle negative slice indices correctly. The failures are in both the start and end indices. I stumbled into this when tracking down why (what turned out to be) this didn't work: >>> file = 'difflib.pyc' >>> file.endswith('.py', 0, -1) # should be 1 0 >>> file[0:-1].endswith('.py') # like this is 1 >>> Can we risk changing this for 2.2? Don't know. If not, reduce the priority. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493951&group_id=5470 From noreply@sourceforge.net Sun Dec 16 19:24:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 11:24:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=6380 See the repeated "(no debugging symbols found)..." in the gdb output? try recompiling with -g. I strongly suspect that the traceback is lying, and we're in fact not in PyString_AsStringAndSize() when we call sprintf -- there's no sprintf call in that function (I checked the 2.1.1 source) but there is one two static functions down, in string_repr(), which is indeed called when you pickle a string object. This would match the original gdb stacktrace you reported: there's no sprintf call in _PyString_FormatLong(), but there are two in the next static function, formatint(), and it does make sense that that function would be called by the %02x format. All this makes no sense, however, because I can see nothing wrong with the arguments to sprintf here! I've heard of problems on FreeBSD having to do with different (threaded and unthreaded?) versions of libc. Could that be the issue here? Can you rebuild Python 2.1.1 with debugg flags on? (./configure --with-pydebug should do it for 2.2; I don't recall if the 2.2.1 configure supports that though -- try --help first.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Sun Dec 16 19:24:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 11:24:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-493951 ] string.{starts,ends}with vs slices Message-ID: Bugs item #493951, was opened at 2001-12-16 11:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493951&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Barry Warsaw (bwarsaw) Summary: string.{starts,ends}with vs slices Initial Comment: The attached test shows many cases where string.startswith() and string.endswith() fail to handle negative slice indices correctly. The failures are in both the start and end indices. I stumbled into this when tracking down why (what turned out to be) this didn't work: >>> file = 'difflib.pyc' >>> file.endswith('.py', 0, -1) # should be 1 0 >>> file[0:-1].endswith('.py') # like this is 1 >>> Can we risk changing this for 2.2? Don't know. If not, reduce the priority. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=31435 Attached the test case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493951&group_id=5470 From noreply@sourceforge.net Sun Dec 16 19:33:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 11:33:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-493936 ] _PyEval_SliceIndex vs NULL Message-ID: Bugs item #493936, was opened at 2001-12-16 10:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493936&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Tim Peters (tim_one) Summary: _PyEval_SliceIndex vs NULL Initial Comment: _PyEval_SliceIndex goes out of its way to say everything's fine when passed a NULL pointer, but leaves the output *pi untouched in that case. But, AFAICT, it doesn't make sense to call this routine with a NULL pointer, and nobody does. So it should assert that v is not NULL. Hold for 2.3 "just in case". ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:33 Message: Logged In: YES user_id=6380 Get some sleep. :-) _PyEval_SliceIndex() is called by apply_slice() which can be called by the SLICE opcode with v and/or w equal to NULL. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493936&group_id=5470 From noreply@sourceforge.net Sun Dec 16 19:38:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 11:38:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-493628 ] import not pythonic in 2.1.1 Message-ID: Bugs item #493628, was opened at 2001-12-15 03:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: import not pythonic in 2.1.1 Initial Comment: Take a package 'aPackage', which contains a sub-package 'aSubPackage' that in turn contains a module 'aModule' that defines a class 'aClass'. If I do: import aPackage.aSubPackage print aPackage.aSubPackage.aModule I get: Traceback (most recent call last): File "x.py", line xx, in ? print aPackage.aSubPackage.aModule AttributeError: 'aPackage.aSubPackage' module has no attribute 'aModule' A yet, if I do: import aPackage.aSubPackage.aModule print aPackage.aSubPackage.aModule I get: ...as expected, which is very confusing and doesn't feel 'right' :-S ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:38 Message: Logged In: YES user_id=6380 OK, the motivation is that importing a package shouldn't recursively import all its submodules -- else importing a top-level package could do an immense amount of work. The motivation for the thing you quote is less clear -- it follows from the requirement that in "import ", "" refers to a module (where a package is a special case of a module). I'm not sure what to do with your whine about being one of the many who find it counter-intuitive. Can you explain how you would like it to behave? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 10:03 Message: Logged In: YES user_id=31435 Chris, why do you think you need to use an exec stmt? You haven't shown an example of why it's needed, and it sure isn't obvious. Modules must be imported, and importing a module M requires an import stmt whose last path component is M -- that's about all there is to it. ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-16 04:58 Message: Logged In: YES user_id=24723 Well, I read it, and it explains the history, but it doesn't give reasons, particularly for: > Contrarily, when using syntax like import item.subitem.subsubitem, each item except for the last must be a package; the last item can be a module > or a package but can't be a class or function or variable defined in the previous item. ...or for the above stuff. But, while I find it counter-intuitive (and means I have to use unpleasant exec statements), I am but one voice among many who probably feel differently so I'll just accept it as one of the things i don't like about python... thanks for your time :-) Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 09:46 Message: Logged In: YES user_id=6380 http://www.python.org/doc/essays/packages.html ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-15 09:15 Message: Logged In: YES user_id=24723 Okay, if it's intended, that means there's a good reason for it... ...where can I look for enlightenment as to what that is? cheers, Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 07:39 Message: Logged In: YES user_id=6380 Better adjust your intuition. :-) This is as intended. Attributes of packages that are *modules* are only loaded when the corresponding module is explicitly imported (by you, or by some other code, e.g. the package's __init__.py). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 From noreply@sourceforge.net Sun Dec 16 19:45:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 11:45:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-493951 ] string.{starts,ends}with vs slices Message-ID: Bugs item #493951, was opened at 2001-12-16 11:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493951&group_id=5470 Category: Python Interpreter Core >Group: Python 2.3 Status: Open >Resolution: Remind >Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Barry Warsaw (bwarsaw) Summary: string.{starts,ends}with vs slices Initial Comment: The attached test shows many cases where string.startswith() and string.endswith() fail to handle negative slice indices correctly. The failures are in both the start and end indices. I stumbled into this when tracking down why (what turned out to be) this didn't work: >>> file = 'difflib.pyc' >>> file.endswith('.py', 0, -1) # should be 1 0 >>> file[0:-1].endswith('.py') # like this is 1 >>> Can we risk changing this for 2.2? Don't know. If not, reduce the priority. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:45 Message: Logged In: YES user_id=6380 Hm, the docs don't exactly suggest that negative indices would be supported. While that would be nice, it's definitely a feature request, so no, please don't do this in 2.2. (The absent of unit tests for negative indices also suggests this was not an oversight. :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=31435 Attached the test case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493951&group_id=5470 From noreply@sourceforge.net Sun Dec 16 19:45:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 11:45:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-493936 ] _PyEval_SliceIndex vs NULL Message-ID: Bugs item #493936, was opened at 2001-12-16 10:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493936&group_id=5470 Category: Python Interpreter Core >Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Tim Peters (tim_one) Summary: _PyEval_SliceIndex vs NULL Initial Comment: _PyEval_SliceIndex goes out of its way to say everything's fine when passed a NULL pointer, but leaves the output *pi untouched in that case. But, AFAICT, it doesn't make sense to call this routine with a NULL pointer, and nobody does. So it should assert that v is not NULL. Hold for 2.3 "just in case". ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-16 11:45 Message: Logged In: YES user_id=31435 Thanks! I checked in your comment as a code comment, since it's mondo obscure even after a 10-second nap . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:33 Message: Logged In: YES user_id=6380 Get some sleep. :-) _PyEval_SliceIndex() is called by apply_slice() which can be called by the SLICE opcode with v and/or w equal to NULL. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493936&group_id=5470 From noreply@sourceforge.net Sun Dec 16 20:03:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 12:03:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-493951 ] string.{starts,ends}with vs slices Message-ID: Bugs item #493951, was opened at 2001-12-16 11:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493951&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: Remind Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Barry Warsaw (bwarsaw) Summary: string.{starts,ends}with vs slices Initial Comment: The attached test shows many cases where string.startswith() and string.endswith() fail to handle negative slice indices correctly. The failures are in both the start and end indices. I stumbled into this when tracking down why (what turned out to be) this didn't work: >>> file = 'difflib.pyc' >>> file.endswith('.py', 0, -1) # should be 1 0 >>> file[0:-1].endswith('.py') # like this is 1 >>> Can we risk changing this for 2.2? Don't know. If not, reduce the priority. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-16 12:03 Message: Logged In: YES user_id=31435 I can't guess what the docs intended to say (they're vague - - I can read them several ways). In all other cases where optional string-method args named "start" and "end" are accepted (find(), rfind(), count (), index(), rindex()), the docs are clear that they're interpreted as slice notation. It doesn't make sense for the two newest methods to behave differently in this respect. The unit tests aren't evidence one way or the other to me -- the behavior of negative indices should be covered by the tests no matter what the intended semantics. Overall, I expect the behavior here is an accident (as opposed to intended). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:45 Message: Logged In: YES user_id=6380 Hm, the docs don't exactly suggest that negative indices would be supported. While that would be nice, it's definitely a feature request, so no, please don't do this in 2.2. (The absent of unit tests for negative indices also suggests this was not an oversight. :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=31435 Attached the test case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493951&group_id=5470 From noreply@sourceforge.net Sun Dec 16 20:21:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 12:21:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-493959 ] 2.2c1 configure bug Message-ID: Bugs item #493959, was opened at 2001-12-16 12:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493959&group_id=5470 Category: Installation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Whitaker (jswhit) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2c1 configure bug Initial Comment: Hi: Found a small bug in the configure script for 2.2c1 that manifests itself on case-insensitive filesystems (like HFS+) when --with-suffix= is given, and is not set to ".exe". EXEEXT is set to (in my case "x") and BUILDEXEEXT is set to ".exe", leading to the following error during the install: /usr/bin/install -c python.exe /sw/src/root-python-unstable-2.2c1-1/sw/bin/ python2.2x if test -f libpython2.2.so; then \ /usr/bin/install -c -m 644 libpython2.2.so /sw/src/root-python-unstable-2.2c1-1/sw/lib; \ else true; \ fi if test -f ""; then \ /usr/bin/install -c -m 555 /sw/src/root-python-unstable-2.2c1-1/sw/bin; \ else true; \ fi mkdir ./Lib/plat-darwin cp ./Lib/plat-generic/regen ./Lib/plat-darwin/regen export PATH; PATH="`pwd`:$PATH"; \ export PYTHONPATH; PYTHONPATH="`pwd`/Lib"; \ export DYLD_FRAMEWORK_PATH; DYLD_FRAMEWORK_PATH="`pwd`"; \ export EXE; EXE="x"; \ cd ./Lib/plat-darwin; ./regen python$EXE ../../Tools/scripts/h2py.py -i '(u_long)' /usr/include/netinet/in.h Traceback (most recent call last): File "../../Tools/scripts/h2py.py", line 24, in ? import sys, re, getopt, os File "/sw/src/python-unstable-2.2c1-1/Python- 2.2c1/Lib/re.py", line 27, in ? from sre import * File "/sw/src/python-unstable-2.2c1-1/Python- 2.2c1/Lib/sre.py", line 97, in ? import sre_compile File "/sw/src/python-unstable-2.2c1-1/Python- 2.2c1/Lib/sre_compile.py", line 17, in ? assert _sre.MAGIC == MAGIC, "SRE module mismatch" AssertionError: SRE module mismatch make: *** [Lib/plat-darwin] Error 1 ### make failed, exit code 2 Failed: installing python-unstable-2.2c1-1 failed The only way to make it build correctly is to use -- with-suffix=.exe, leaving --with-suffix out entirely doesn't work since EXEEXT is then null, and BUILDEXEEXT is still .exe. Seems like BUILDEXEEXT and EXEEXT need to be the same. -Jeff ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493959&group_id=5470 From noreply@sourceforge.net Sun Dec 16 20:23:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 12:23:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-493959 ] 2.2c1 configure bug Message-ID: Bugs item #493959, was opened at 2001-12-16 12:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493959&group_id=5470 Category: Installation Group: Python 2.2 Status: Open Resolution: None >Priority: 8 Submitted By: Jeff Whitaker (jswhit) >Assigned to: Jack Jansen (jackjansen) Summary: 2.2c1 configure bug Initial Comment: Hi: Found a small bug in the configure script for 2.2c1 that manifests itself on case-insensitive filesystems (like HFS+) when --with-suffix= is given, and is not set to ".exe". EXEEXT is set to (in my case "x") and BUILDEXEEXT is set to ".exe", leading to the following error during the install: /usr/bin/install -c python.exe /sw/src/root-python-unstable-2.2c1-1/sw/bin/ python2.2x if test -f libpython2.2.so; then \ /usr/bin/install -c -m 644 libpython2.2.so /sw/src/root-python-unstable-2.2c1-1/sw/lib; \ else true; \ fi if test -f ""; then \ /usr/bin/install -c -m 555 /sw/src/root-python-unstable-2.2c1-1/sw/bin; \ else true; \ fi mkdir ./Lib/plat-darwin cp ./Lib/plat-generic/regen ./Lib/plat-darwin/regen export PATH; PATH="`pwd`:$PATH"; \ export PYTHONPATH; PYTHONPATH="`pwd`/Lib"; \ export DYLD_FRAMEWORK_PATH; DYLD_FRAMEWORK_PATH="`pwd`"; \ export EXE; EXE="x"; \ cd ./Lib/plat-darwin; ./regen python$EXE ../../Tools/scripts/h2py.py -i '(u_long)' /usr/include/netinet/in.h Traceback (most recent call last): File "../../Tools/scripts/h2py.py", line 24, in ? import sys, re, getopt, os File "/sw/src/python-unstable-2.2c1-1/Python- 2.2c1/Lib/re.py", line 27, in ? from sre import * File "/sw/src/python-unstable-2.2c1-1/Python- 2.2c1/Lib/sre.py", line 97, in ? import sre_compile File "/sw/src/python-unstable-2.2c1-1/Python- 2.2c1/Lib/sre_compile.py", line 17, in ? assert _sre.MAGIC == MAGIC, "SRE module mismatch" AssertionError: SRE module mismatch make: *** [Lib/plat-darwin] Error 1 ### make failed, exit code 2 Failed: installing python-unstable-2.2c1-1 failed The only way to make it build correctly is to use -- with-suffix=.exe, leaving --with-suffix out entirely doesn't work since EXEEXT is then null, and BUILDEXEEXT is still .exe. Seems like BUILDEXEEXT and EXEEXT need to be the same. -Jeff ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493959&group_id=5470 From noreply@sourceforge.net Sun Dec 16 20:45:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 12:45:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-493628 ] import not pythonic in 2.1.1 Message-ID: Bugs item #493628, was opened at 2001-12-15 03:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: import not pythonic in 2.1.1 Initial Comment: Take a package 'aPackage', which contains a sub-package 'aSubPackage' that in turn contains a module 'aModule' that defines a class 'aClass'. If I do: import aPackage.aSubPackage print aPackage.aSubPackage.aModule I get: Traceback (most recent call last): File "x.py", line xx, in ? print aPackage.aSubPackage.aModule AttributeError: 'aPackage.aSubPackage' module has no attribute 'aModule' A yet, if I do: import aPackage.aSubPackage.aModule print aPackage.aSubPackage.aModule I get: ...as expected, which is very confusing and doesn't feel 'right' :-S ---------------------------------------------------------------------- >Comment By: Chris Withers (fresh) Date: 2001-12-16 12:45 Message: Logged In: YES user_id=24723 > I'm not sure what to do with your whine about being one of > the many who find it counter-intuitive. Can you explain how > you would like it to behave? Sorry, that was me being unclear... I meant I am probably one of the few who finds it unintuitive ;-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:38 Message: Logged In: YES user_id=6380 OK, the motivation is that importing a package shouldn't recursively import all its submodules -- else importing a top-level package could do an immense amount of work. The motivation for the thing you quote is less clear -- it follows from the requirement that in "import ", "" refers to a module (where a package is a special case of a module). I'm not sure what to do with your whine about being one of the many who find it counter-intuitive. Can you explain how you would like it to behave? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 10:03 Message: Logged In: YES user_id=31435 Chris, why do you think you need to use an exec stmt? You haven't shown an example of why it's needed, and it sure isn't obvious. Modules must be imported, and importing a module M requires an import stmt whose last path component is M -- that's about all there is to it. ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-16 04:58 Message: Logged In: YES user_id=24723 Well, I read it, and it explains the history, but it doesn't give reasons, particularly for: > Contrarily, when using syntax like import item.subitem.subsubitem, each item except for the last must be a package; the last item can be a module > or a package but can't be a class or function or variable defined in the previous item. ...or for the above stuff. But, while I find it counter-intuitive (and means I have to use unpleasant exec statements), I am but one voice among many who probably feel differently so I'll just accept it as one of the things i don't like about python... thanks for your time :-) Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 09:46 Message: Logged In: YES user_id=6380 http://www.python.org/doc/essays/packages.html ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-15 09:15 Message: Logged In: YES user_id=24723 Okay, if it's intended, that means there's a good reason for it... ...where can I look for enlightenment as to what that is? cheers, Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 07:39 Message: Logged In: YES user_id=6380 Better adjust your intuition. :-) This is as intended. Attributes of packages that are *modules* are only loaded when the corresponding module is explicitly imported (by you, or by some other code, e.g. the package's __init__.py). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 From noreply@sourceforge.net Sun Dec 16 23:19:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 15:19:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-494007 ] Py_INCREF(Py_None) in documentation Message-ID: Bugs item #494007, was opened at 2001-12-16 15:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494007&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Achim Gaedke (achimgaedke) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Py_INCREF(Py_None) in documentation Initial Comment: Since 5 hours I am debugging the pygsl ( http://pygsl.sourceforge.net ) module... The reason: I forgot to increment the reference counter of Py_None before returning it. Maybe it is a good idea to underline this case. The Py_None object is a constant pointer, maybe some other people do not think about it. Here is a code example: static PyObject* my_func(PyObject *self, PyObject *args ) { Py_INCREF(Py_None); return Py_None; } Is it possible, that this case was handled without reference counter in version 2.0 and older? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494007&group_id=5470 From noreply@sourceforge.net Sun Dec 16 23:26:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 15:26:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 15:26 Message: Logged In: YES user_id=85984 Alright, I rebuilt Python 2.1.1 with -g, so the gdb backtrace now contains some more information. I attached backtrace2.txt which is a backtrace of the program failing when calling the hexlify() function. I tried compiling with `--with-pydebug', but then I can't reproduce the core dump for some reason. As you mention, this could have something to do with FreeBSD's libc. However, does that explain why I only have this problem with 2.1.1? On the same system, Python 1.5.2, 2.0, and 2.2c1 compiled in the same manner (simply ./configure && gmake) don't produce a core dump. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=6380 See the repeated "(no debugging symbols found)..." in the gdb output? try recompiling with -g. I strongly suspect that the traceback is lying, and we're in fact not in PyString_AsStringAndSize() when we call sprintf -- there's no sprintf call in that function (I checked the 2.1.1 source) but there is one two static functions down, in string_repr(), which is indeed called when you pickle a string object. This would match the original gdb stacktrace you reported: there's no sprintf call in _PyString_FormatLong(), but there are two in the next static function, formatint(), and it does make sense that that function would be called by the %02x format. All this makes no sense, however, because I can see nothing wrong with the arguments to sprintf here! I've heard of problems on FreeBSD having to do with different (threaded and unthreaded?) versions of libc. Could that be the issue here? Can you rebuild Python 2.1.1 with debugg flags on? (./configure --with-pydebug should do it for 2.2; I don't recall if the 2.2.1 configure supports that though -- try --help first.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Mon Dec 17 00:31:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 16:31:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-471942 ] python2.1.1 SEGV in GC on Solaris 2.7 Message-ID: Bugs item #471942, was opened at 2001-10-16 19:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Anthony Baxter (anthonybaxter) Summary: python2.1.1 SEGV in GC on Solaris 2.7 Initial Comment: I've got a Zope installation where python2.1.1 is segfaulting on Solaris2.7 - it's running a largish ZEO server. The tail of the gdb output is: #128 0x26164 in PyEval_CallObjectWithKeywords () #129 0x264c0 in PyEval_CallObjectWithKeywords () #130 0x26140 in PyEval_CallObjectWithKeywords () #131 0x25fc0 in PyEval_CallObjectWithKeywords () #132 0x517bc in PyInstance_New () #133 0x261a4 in PyEval_CallObjectWithKeywords () #134 0x25fc0 in PyEval_CallObjectWithKeywords () #135 0x42c90 in initgc () It's built with $ gcc -v Reading specs from /opt/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs gcc version 2.95.2 19991024 (release) which is a bit old. I'm going to rebuild with gcc3.0 and also try turning off the GC. Unfortunately I can't get this to happen on a smaller test system - it's only under load that it plows into the ground. I'll also leave symbols in this time... :/ ---------------------------------------------------------------------- Comment By: Joseph Wayne Norton (natsukashi) Date: 2001-12-16 16:31 Message: Logged In: YES user_id=358486 No, I haven't tried the ceval.c patch. Do know of any documentation regarding this bug and the bug fix? I'm just curious before applying this patch. There also is an update from the folks at ZC. They located a source of trouble with respect to python 2.1 and the restricted dtml engine. See the zope-dev mailing list for futher details. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-14 02:46 Message: Logged In: YES user_id=21627 natsukashi, have you applied 2.277 of ceval.c? ---------------------------------------------------------------------- Comment By: Joseph Wayne Norton (natsukashi) Date: 2001-12-13 16:41 Message: Logged In: YES user_id=358486 Here is an excerpt from one debugging session ... > (gdb) info threads > 17 Thread 10 0xef5b9810 in _lwp_sema_wait () > 16 Thread 9 0xef647cac in _swtch () > 15 Thread 8 0xef5b9810 in _lwp_sema_wait () > 14 Thread 7 (LWP 5) 0xcaeb50 in ?? () > 13 Thread 6 0xef647cac in _swtch () > 12 Thread 5 0xef5b9810 in _lwp_sema_wait () > 11 Thread 4 0xef647cac in _swtch () > 10 Thread 3 0xef647cac in _swtch () > 9 Thread 2 (LWP 2) 0xef5b9958 in _signotifywait () > 8 Thread 1 (LWP 6) 0xef5b7488 in _poll () > 7 LWP 8 0xef5b6a24 in door_restart () > 6 LWP 6 0xef5b7488 in _poll () > 5 LWP 5 0xcaeb50 in ?? () > 4 LWP 4 0xef5b9810 in _lwp_sema_wait () > 3 LWP 3 0xef5b9810 in _lwp_sema_wait () > 2 LWP 2 0xef5b9958 in _signotifywait () > * 1 LWP 1 0xef5b9810 in _lwp_sema_wait () > > (gdb) thread 14 > [Switching to Thread 7 (LWP 5)] > #0 0xcaeb50 in ?? () > > (gdb) where > #0 0xcaeb50 in ?? () > #1 0x516bc in collect (young=0x13dec8, old=0x13ded4) > at ./Modules/gcmodule.c:379 > #2 0x51984 in collect_generations () at ./Modules/gcmodule.c:484 > #3 0x519fc in _PyGC_Insert (op=0xecf7d4) at ./Modules/gcmodule.c:507 > #4 0x664ec in PyMethod_New (func=0x3f796c, self=0x11c0d44, > class=0x3c7e5c) > at Objects/classobject.c:1834 > #5 0x63850 in instance_getattr2 (inst=0x11c0d44, name=0x3d5378) > at Objects/classobject.c:642 > #6 0x63750 in instance_getattr1 (inst=0x11c0d44, name=0x3d5378) > at Objects/classobject.c:608 > #7 0x63898 in instance_getattr (inst=0x11c0d44, name=0x3d5378) > at Objects/classobject.c:656 > #8 0x78330 in PyObject_GetAttr (v=0x11c0d44, name=0x3d5378) > at Objects/object.c:1052 > #9 0x895ec in builtin_hasattr (self=0x0, args=0x12ed944) > at Python/bltinmodule.c:886 > #10 0x35a44 in call_cfunction (func=0x1609b0, arg=0x12ed944, kw=0x0) > at Python/ceval.c:2854 Unfortunately, I do not have any specific information at the moment. There is also portions of a discussion that can be viewed with the following url: http://lists.zope.org/pipermail/zope-dev/2001-December/014541.html Look for messages having the same subject. Basically, we are running python 2.1.1 and zope 2.4.3 on the solaris platform. We have 3 servers each having the same installed software except one server is solaris 5.6 and the other two are solaris 5.7. The zope process running on the solaris 5.6 machine is restarting at least a couple times a day due to a SIGSEGV or SIGILL signal. I can generate a core file using the truss command. The problem appears to be related to garbage collection. Unfortunately, this behavior only occurs on our production site and depends on the site load -- higher system load, more frequent restarts. We are not facing any restart troubles on the solaris 5.7 machines or on our linux and solaris development machines. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-13 12:12 Message: Logged In: YES user_id=31435 Just noting that the function names reported in the traceback in the original writeup are bogus: PyEval_CallObjectWithKeywords() doesn't call itself. Looks like gdb doesn't have enough info to report the true function name, so picks a function it does know about at an earlier address (or something ). I'm told this doesn't happen on Linux, but don't grasp why it might on Solaris. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-13 07:45 Message: Logged In: YES user_id=21627 What do you mean with "the same trouble"? Merely that Python crashes, or do you have some more specific information to contribute? ---------------------------------------------------------------------- Comment By: Joseph Wayne Norton (natsukashi) Date: 2001-12-11 18:37 Message: Logged In: YES user_id=358486 Do you have any updates on this issue? I'm facing the same trouble on the following solaris platform: SunOS i04sv2008 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-80 regards, - j ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-04 23:38 Message: Logged In: YES user_id=29957 Nah, this is a separate one to the frame bug. I'm still seeing it on a regular regular basis, but haven't narrowed it done to what's causing it. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-04 08:48 Message: Logged In: YES user_id=31392 This was the bug that was tracked down to a problem in try/except/finally, wasn't it? If this is fixed, can you close the bug report? If not, can you provide an udpate on its current status? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-07 14:13 Message: Logged In: YES user_id=21627 Any news on this report: did the problem disappear after backporting changes? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 04:32 Message: Logged In: YES user_id=21627 Looking at the changes since 2.1.1, I can see one bugfix that might explain strange behaviour, namely ceval.c 2.277. If you want to try it out, you can get the change here http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Python/ceval.c.diff?r1=2.276&r2=2.277 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 03:59 Message: Logged In: YES user_id=29957 What's the appropriate way to ask this? drop a line to python-dev? purify's showing a UMR in strop_expandtabs (from memory - don't have it on screen right now) when python starts up. Yeah, the realloc bug concerns me - I have to wonder if something's a little bit/lot screwy. I just don't know where. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 03:46 Message: Logged In: YES user_id=21627 This is something to ask the pythonlabs folks; I believe Python has been purified once in a while - perhaps even with Zope extensions. I'd still suspect a bug in the Zope extensions instead of a Python bug, though: if malloc crashes, chances are high that somebody was overwriting free memory. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 03:31 Message: Logged In: YES user_id=29957 It's not a GC object. I'm positive all the extension objects are correct - I just recompiled, without the 1.5/2.0 headers around. It's a different pointer each time round, unfortunately. It also takes anything from 5 minutes to 2 hours to reproduce. I've got about 4 copies of it running now, and I've got a bunch of different core files. I've grabbed purify and an eval license, and I'm feeding it the binary. The printf approach is probably not going to work - these are busy busy Zope servers. Instead, my plan, assuming that purify doesn't immediately spot a problem, is to change the code so that if it gets a dud GC object, it will just bust it out of the tree and let it leak, and print a message saying so. Then I can quit the program, and purify will tell me 'hey, you leaked!' and also tell me where it was allocated. More concerning, about half the segfaults are not from the GC at all, but from realloc in PyFrame_New (line 161 of frameobject). These are the only two I'm getting - it's split 50-50 amongst the 10 coredumps I have now. I'm not sure whether to open a seperate bug for this. Has python2.1.1 been purified? With Zope and zope's extensions? Wow - it's amazing how this SF bug thing is so painful for conversations :) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 03:11 Message: Logged In: YES user_id=21627 There are two options: a) the object isn't really a GC object, i.e. has no GC header. In gdb, you can try to cast gc to PyObject*, then see if the resulting pointer has a better ob_type (this is unlikely, though, since the logic entering the object was already using fromgc/togc) b) somebody has cleared the ob_type field. Can you guarantee that all extension modules have been compiled with the 2.1.1 header files? Is the problem repeatable in the sense that gc will have the same pointer value on each crash? If so, it is relatively easy to track down: just set a gdb change watchpoint on the address on the ob_type field of that address (note that setting watchpoints is not possible until there is really mapped memory on that address). If you can't analyse it through change breakpoints, I recommend to annotate the interpreter in the following way: in pyobject_init, put a printf that prints the address and the tp_name of the type. In subtract_refs, if the ob_type slot is null, print the address of the object and abort. Then analyse the log to see whether a object really has been allocated on that address, and what its type was (make sure you consider the possibility that address are off by the delta that FROM_GC adds). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-17 21:58 Message: Logged In: YES user_id=29957 Ok, I have an intact core file, and a matching binary, no optimisations, nothing. This crash is showing the crash at line 166 of gcmodule.c traverse = PyObject_FROM_GC(gc)->ob_type->tp_traverse; PyObject_FROM_GC(gc)->ob_type in this case is $24 = {ob_refcnt = 1, ob_type = 0x0} To check my logic, I checked gc_next and gc_prev using the same GDB magic, and they correctly show up as a tuple and an instance method. Some fiddling around seems to rule out stack space as the problem, as well. We're going to try and see if purify helps here, but the problem looks to be a junk object - I have no idea how to track this down further. Help? Would taking the horrible horrible hack of removing the object from the gc linked list if ob_type is null help? Well, it'd stop the crashes, anyway. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-17 13:44 Message: Logged In: YES user_id=21627 It would be interesting what the value of "gc" is at the time of the crash. It looks like you got an object that claims to support GC but has a null tp_traverse. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-17 06:08 Message: Logged In: YES user_id=29957 I'm a doofus who read the gdb trace from the wrong end - too much python lately :) Nonetheless, the other end of the trace failed in gc as well - and building without GC enabled worked. Here's the trace with debugging enabled: #0 0xff00 in ?? () #1 0x402f0 in collect (young=0x9b538, old=0x9b544) at ./Modules/gcmodule.c:379 #2 0x405a8 in collect_generations () at ./Modules/gcmodule.c:484 #3 0x40624 in _PyGC_Insert (op=0xbc1f24) at ./Modules/gcmodule.c:507 #4 0x5a224 in PyList_New (size=0) at Objects/listobject.c:61 #5 0x21bc8 in eval_code2 (co=0x1cb370, globals=0x21bc0, locals=0x67, args=0x0, argcount=1, kws=0xf89b24, kwcount=0, defs=0x0, defcount=0, closure=0xbc1f24) at Python/ceval.c:1741 Next trick is to rebuild without any optimisation (sigh) as I suspect that it's inlined subtract_refs(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 From noreply@sourceforge.net Mon Dec 17 01:03:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 17:03:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-494007 ] Py_INCREF(Py_None) in documentation Message-ID: Bugs item #494007, was opened at 2001-12-16 15:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494007&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Achim Gaedke (achimgaedke) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Py_INCREF(Py_None) in documentation Initial Comment: Since 5 hours I am debugging the pygsl ( http://pygsl.sourceforge.net ) module... The reason: I forgot to increment the reference counter of Py_None before returning it. Maybe it is a good idea to underline this case. The Py_None object is a constant pointer, maybe some other people do not think about it. Here is a code example: static PyObject* my_func(PyObject *self, PyObject *args ) { Py_INCREF(Py_None); return Py_None; } Is it possible, that this case was handled without reference counter in version 2.0 and older? ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:03 Message: Logged In: YES user_id=31435 No, Py_None has always pointed to an object, exactly like every other object wrt reference counting. But, also as for any other object, if you screw up its refcount, there's no predicting when (or even if) an error will result -- it depends on all other uses of the object everywhere. Note that a debug build of Python 2.2 will print a message when Py_DECREF creates a negative refcount. That should help a lot in cases like this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494007&group_id=5470 From noreply@sourceforge.net Mon Dec 17 01:17:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 17:17:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:17 Message: Logged In: YES user_id=31435 The new backtrace is helpful (thanks!), but it just makes it harder to believe that Python is at fault. The segfault occurs four levels deep in system library functions, and from inspection there's nothing even remotely suspicious about the sprintf call that kicks it off. As Guido suggested, can you verify you're not mixing the threaded and non-threaded versions of libc? Short of that, you really need a FreeBSD libc author to help with this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 15:26 Message: Logged In: YES user_id=85984 Alright, I rebuilt Python 2.1.1 with -g, so the gdb backtrace now contains some more information. I attached backtrace2.txt which is a backtrace of the program failing when calling the hexlify() function. I tried compiling with `--with-pydebug', but then I can't reproduce the core dump for some reason. As you mention, this could have something to do with FreeBSD's libc. However, does that explain why I only have this problem with 2.1.1? On the same system, Python 1.5.2, 2.0, and 2.2c1 compiled in the same manner (simply ./configure && gmake) don't produce a core dump. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=6380 See the repeated "(no debugging symbols found)..." in the gdb output? try recompiling with -g. I strongly suspect that the traceback is lying, and we're in fact not in PyString_AsStringAndSize() when we call sprintf -- there's no sprintf call in that function (I checked the 2.1.1 source) but there is one two static functions down, in string_repr(), which is indeed called when you pickle a string object. This would match the original gdb stacktrace you reported: there's no sprintf call in _PyString_FormatLong(), but there are two in the next static function, formatint(), and it does make sense that that function would be called by the %02x format. All this makes no sense, however, because I can see nothing wrong with the arguments to sprintf here! I've heard of problems on FreeBSD having to do with different (threaded and unthreaded?) versions of libc. Could that be the issue here? Can you rebuild Python 2.1.1 with debugg flags on? (./configure --with-pydebug should do it for 2.2; I don't recall if the 2.2.1 configure supports that though -- try --help first.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Mon Dec 17 01:20:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 17:20:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 17:20 Message: Logged In: YES user_id=6380 OK, it's the second sprintf call in formatint. Can you check some local variables in that stack frame? I expect fmt to be "%.1lx", but would like to see that confirmed; x should be one of the values from your binary string: 206, 199, 166. Can you see which one? It would then be interesting to find out what a small C program with that same sprintf() does. Make sure that the C program is compiled and linked in exactly the same way as python. (What I do in such cases is I put the experimental statement in Python's main() and rebuild Python. :-) The build procedure of each Python version is somewhat different, and it's likely that each version picks slightly different compile/link options. Also, did you build all the Python versions you tried yourself? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:17 Message: Logged In: YES user_id=31435 The new backtrace is helpful (thanks!), but it just makes it harder to believe that Python is at fault. The segfault occurs four levels deep in system library functions, and from inspection there's nothing even remotely suspicious about the sprintf call that kicks it off. As Guido suggested, can you verify you're not mixing the threaded and non-threaded versions of libc? Short of that, you really need a FreeBSD libc author to help with this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 15:26 Message: Logged In: YES user_id=85984 Alright, I rebuilt Python 2.1.1 with -g, so the gdb backtrace now contains some more information. I attached backtrace2.txt which is a backtrace of the program failing when calling the hexlify() function. I tried compiling with `--with-pydebug', but then I can't reproduce the core dump for some reason. As you mention, this could have something to do with FreeBSD's libc. However, does that explain why I only have this problem with 2.1.1? On the same system, Python 1.5.2, 2.0, and 2.2c1 compiled in the same manner (simply ./configure && gmake) don't produce a core dump. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=6380 See the repeated "(no debugging symbols found)..." in the gdb output? try recompiling with -g. I strongly suspect that the traceback is lying, and we're in fact not in PyString_AsStringAndSize() when we call sprintf -- there's no sprintf call in that function (I checked the 2.1.1 source) but there is one two static functions down, in string_repr(), which is indeed called when you pickle a string object. This would match the original gdb stacktrace you reported: there's no sprintf call in _PyString_FormatLong(), but there are two in the next static function, formatint(), and it does make sense that that function would be called by the %02x format. All this makes no sense, however, because I can see nothing wrong with the arguments to sprintf here! I've heard of problems on FreeBSD having to do with different (threaded and unthreaded?) versions of libc. Could that be the issue here? Can you rebuild Python 2.1.1 with debugg flags on? (./configure --with-pydebug should do it for 2.2; I don't recall if the 2.2.1 configure supports that though -- try --help first.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Mon Dec 17 01:24:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 17:24:30 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-494034 ] a smarter rfc822.dump_address_pair() Message-ID: Feature Requests item #494034, was opened at 2001-12-16 17:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494034&group_id=5470 Category: Python Library Group: None Status: Open Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: a smarter rfc822.dump_address_pair() Initial Comment: Please see: http://mail.python.org/pipermail/python-list/2001-December/075881.html I'm turning this into a feature request since I didn't get any responses on comp.lang.python. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494034&group_id=5470 From noreply@sourceforge.net Mon Dec 17 01:24:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 17:24:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-493462 ] Attribute Search in MRO w/o tp_getattr Message-ID: Bugs item #493462, was opened at 2001-12-14 13:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493462&group_id=5470 Category: Type/class unification Group: Python 2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Robert Stewart (rstewart) Assigned to: Guido van Rossum (gvanrossum) Summary: Attribute Search in MRO w/o tp_getattr Initial Comment: In writing a metatype, I wanted to resolve attribute references via a tp_getattr-style function -- with either a char * or a Python string. Unfortunately, PyObject_GenericGetAttr() first tries _PyType_Lookup() to find a descriptor via base class dictionaries. Searching according to the MRO is fine. The problem is that _PyType_Lookup() only searches the dictionary of each base class. It never checks those bases to see it tp_getattr is set. My workaround, which is not ideal, is to implement my own tp_getattro function which first calls PyObject_GenericGetAttr() to locate the attribute. If that succeeds, that attribute is returned. If it fails, then the tp_getattr-style function is called to locate the attribute. This approach will return a base class attribute when the derived class overrides it, which is why I said it was not ideal. The only way I can improve this process is to write my own replacement for PyObject_GenericGetAttr() and _PyType_Lookup(). That would make my code very brittle, so that's not a good solution. What I'd like to see is for _PyType_Lookup() to try the dictionary, as it does now. If that fails, I'd like it to check to see if tp_getattr is set. If so, I'd like it to call the tp_getattr function to resolve the attribute. Perhaps this change violates some ideal of Python that I can't foresee, but it would sure work great for me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 13:41 Message: Logged In: YES user_id=6380 When you talk about the bases and their tp_getattr, are you talking about the tp_getattr of the base type, or of its metatype? (Note: forget about tp_getattr -- you should leave that NULL, and only implement tp_getatto.) PyObject_GenericGetAttr() should only be used in situations where the base type's tp_getattro is also PyObject_GenericGetAttr(). Why do you think that writing your own replacement for PyObject_GenericGetAttr() and _PyType_Lookup() would be brittle? That's what you are *supposed* to do if you're not happy with them. What do you want to do with your metatype? Why do you need one? Have you considered prototyping it in Python? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493462&group_id=5470 From noreply@sourceforge.net Mon Dec 17 01:47:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 17:47:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:47 Message: Logged In: YES user_id=31435 BTW, a google search on _thread_autoinit_dummy_decl turns up another FreeBSD bug report of a death deep in libc_r starting with a sprintf() call. It had to do with mysql, not with Python. The tracebacks in both cases look worthless to me, because (for example) _thread_autoinit_dummy_decl is an extern int in the FreeBSD source, not a function at all. This increases the suspicion that libc versions are getting mixed up (and that gdb is looking up addresses in "the wrong" libc). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 17:20 Message: Logged In: YES user_id=6380 OK, it's the second sprintf call in formatint. Can you check some local variables in that stack frame? I expect fmt to be "%.1lx", but would like to see that confirmed; x should be one of the values from your binary string: 206, 199, 166. Can you see which one? It would then be interesting to find out what a small C program with that same sprintf() does. Make sure that the C program is compiled and linked in exactly the same way as python. (What I do in such cases is I put the experimental statement in Python's main() and rebuild Python. :-) The build procedure of each Python version is somewhat different, and it's likely that each version picks slightly different compile/link options. Also, did you build all the Python versions you tried yourself? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:17 Message: Logged In: YES user_id=31435 The new backtrace is helpful (thanks!), but it just makes it harder to believe that Python is at fault. The segfault occurs four levels deep in system library functions, and from inspection there's nothing even remotely suspicious about the sprintf call that kicks it off. As Guido suggested, can you verify you're not mixing the threaded and non-threaded versions of libc? Short of that, you really need a FreeBSD libc author to help with this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 15:26 Message: Logged In: YES user_id=85984 Alright, I rebuilt Python 2.1.1 with -g, so the gdb backtrace now contains some more information. I attached backtrace2.txt which is a backtrace of the program failing when calling the hexlify() function. I tried compiling with `--with-pydebug', but then I can't reproduce the core dump for some reason. As you mention, this could have something to do with FreeBSD's libc. However, does that explain why I only have this problem with 2.1.1? On the same system, Python 1.5.2, 2.0, and 2.2c1 compiled in the same manner (simply ./configure && gmake) don't produce a core dump. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=6380 See the repeated "(no debugging symbols found)..." in the gdb output? try recompiling with -g. I strongly suspect that the traceback is lying, and we're in fact not in PyString_AsStringAndSize() when we call sprintf -- there's no sprintf call in that function (I checked the 2.1.1 source) but there is one two static functions down, in string_repr(), which is indeed called when you pickle a string object. This would match the original gdb stacktrace you reported: there's no sprintf call in _PyString_FormatLong(), but there are two in the next static function, formatint(), and it does make sense that that function would be called by the %02x format. All this makes no sense, however, because I can see nothing wrong with the arguments to sprintf here! I've heard of problems on FreeBSD having to do with different (threaded and unthreaded?) versions of libc. Could that be the issue here? Can you rebuild Python 2.1.1 with debugg flags on? (./configure --with-pydebug should do it for 2.2; I don't recall if the 2.2.1 configure supports that though -- try --help first.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Mon Dec 17 03:09:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 19:09:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 19:09 Message: Logged In: YES user_id=85984 Tim asked whather I can verify whether I'm mixing the threaded and non-threaded versions of libc. Is the following enough to tell? $ ldd /usr/local/src/Python-2.1.1/python /usr/local/src/Python-2.1.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x280ca000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28182000) libm.so.2 => /usr/lib/libm.so.2 (0x2818b000) libc.so.4 => /usr/lib/libc.so.4 (0x281a7000) libc is the non-threaded library, and libc_r is the threaded version, so it looks like they are being mixed, yes? However, my Python 2.0.1 also looks the same way, and I'm not having any problems with it. $ ldd /usr/local/src/Python-2.0.1/python /usr/local/src/Python-2.0.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x2816c000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28224000) libm.so.2 => /usr/lib/libm.so.2 (0x2822d000) libc.so.4 => /usr/lib/libc.so.4 (0x28249000) Next, Guido asked me to check some local variables in that stack frame. See attached backtrace3.txt. And to answer your question, yes I built all the Python versions I'm testing myself. I even rebuilt 2.0.1 and 2.1.1 in the simplest manner to make sure I'm comparing them equally. (Just ./configure && make). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:47 Message: Logged In: YES user_id=31435 BTW, a google search on _thread_autoinit_dummy_decl turns up another FreeBSD bug report of a death deep in libc_r starting with a sprintf() call. It had to do with mysql, not with Python. The tracebacks in both cases look worthless to me, because (for example) _thread_autoinit_dummy_decl is an extern int in the FreeBSD source, not a function at all. This increases the suspicion that libc versions are getting mixed up (and that gdb is looking up addresses in "the wrong" libc). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 17:20 Message: Logged In: YES user_id=6380 OK, it's the second sprintf call in formatint. Can you check some local variables in that stack frame? I expect fmt to be "%.1lx", but would like to see that confirmed; x should be one of the values from your binary string: 206, 199, 166. Can you see which one? It would then be interesting to find out what a small C program with that same sprintf() does. Make sure that the C program is compiled and linked in exactly the same way as python. (What I do in such cases is I put the experimental statement in Python's main() and rebuild Python. :-) The build procedure of each Python version is somewhat different, and it's likely that each version picks slightly different compile/link options. Also, did you build all the Python versions you tried yourself? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:17 Message: Logged In: YES user_id=31435 The new backtrace is helpful (thanks!), but it just makes it harder to believe that Python is at fault. The segfault occurs four levels deep in system library functions, and from inspection there's nothing even remotely suspicious about the sprintf call that kicks it off. As Guido suggested, can you verify you're not mixing the threaded and non-threaded versions of libc? Short of that, you really need a FreeBSD libc author to help with this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 15:26 Message: Logged In: YES user_id=85984 Alright, I rebuilt Python 2.1.1 with -g, so the gdb backtrace now contains some more information. I attached backtrace2.txt which is a backtrace of the program failing when calling the hexlify() function. I tried compiling with `--with-pydebug', but then I can't reproduce the core dump for some reason. As you mention, this could have something to do with FreeBSD's libc. However, does that explain why I only have this problem with 2.1.1? On the same system, Python 1.5.2, 2.0, and 2.2c1 compiled in the same manner (simply ./configure && gmake) don't produce a core dump. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=6380 See the repeated "(no debugging symbols found)..." in the gdb output? try recompiling with -g. I strongly suspect that the traceback is lying, and we're in fact not in PyString_AsStringAndSize() when we call sprintf -- there's no sprintf call in that function (I checked the 2.1.1 source) but there is one two static functions down, in string_repr(), which is indeed called when you pickle a string object. This would match the original gdb stacktrace you reported: there's no sprintf call in _PyString_FormatLong(), but there are two in the next static function, formatint(), and it does make sense that that function would be called by the %02x format. All this makes no sense, however, because I can see nothing wrong with the arguments to sprintf here! I've heard of problems on FreeBSD having to do with different (threaded and unthreaded?) versions of libc. Could that be the issue here? Can you rebuild Python 2.1.1 with debugg flags on? (./configure --with-pydebug should do it for 2.2; I don't recall if the 2.2.1 configure supports that though -- try --help first.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Mon Dec 17 04:23:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 20:23:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 20:23 Message: Logged In: YES user_id=6380 Sigh. I think it's a dead end. What about a stand-alone program? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 19:09 Message: Logged In: YES user_id=85984 Tim asked whather I can verify whether I'm mixing the threaded and non-threaded versions of libc. Is the following enough to tell? $ ldd /usr/local/src/Python-2.1.1/python /usr/local/src/Python-2.1.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x280ca000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28182000) libm.so.2 => /usr/lib/libm.so.2 (0x2818b000) libc.so.4 => /usr/lib/libc.so.4 (0x281a7000) libc is the non-threaded library, and libc_r is the threaded version, so it looks like they are being mixed, yes? However, my Python 2.0.1 also looks the same way, and I'm not having any problems with it. $ ldd /usr/local/src/Python-2.0.1/python /usr/local/src/Python-2.0.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x2816c000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28224000) libm.so.2 => /usr/lib/libm.so.2 (0x2822d000) libc.so.4 => /usr/lib/libc.so.4 (0x28249000) Next, Guido asked me to check some local variables in that stack frame. See attached backtrace3.txt. And to answer your question, yes I built all the Python versions I'm testing myself. I even rebuilt 2.0.1 and 2.1.1 in the simplest manner to make sure I'm comparing them equally. (Just ./configure && make). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:47 Message: Logged In: YES user_id=31435 BTW, a google search on _thread_autoinit_dummy_decl turns up another FreeBSD bug report of a death deep in libc_r starting with a sprintf() call. It had to do with mysql, not with Python. The tracebacks in both cases look worthless to me, because (for example) _thread_autoinit_dummy_decl is an extern int in the FreeBSD source, not a function at all. This increases the suspicion that libc versions are getting mixed up (and that gdb is looking up addresses in "the wrong" libc). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 17:20 Message: Logged In: YES user_id=6380 OK, it's the second sprintf call in formatint. Can you check some local variables in that stack frame? I expect fmt to be "%.1lx", but would like to see that confirmed; x should be one of the values from your binary string: 206, 199, 166. Can you see which one? It would then be interesting to find out what a small C program with that same sprintf() does. Make sure that the C program is compiled and linked in exactly the same way as python. (What I do in such cases is I put the experimental statement in Python's main() and rebuild Python. :-) The build procedure of each Python version is somewhat different, and it's likely that each version picks slightly different compile/link options. Also, did you build all the Python versions you tried yourself? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:17 Message: Logged In: YES user_id=31435 The new backtrace is helpful (thanks!), but it just makes it harder to believe that Python is at fault. The segfault occurs four levels deep in system library functions, and from inspection there's nothing even remotely suspicious about the sprintf call that kicks it off. As Guido suggested, can you verify you're not mixing the threaded and non-threaded versions of libc? Short of that, you really need a FreeBSD libc author to help with this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 15:26 Message: Logged In: YES user_id=85984 Alright, I rebuilt Python 2.1.1 with -g, so the gdb backtrace now contains some more information. I attached backtrace2.txt which is a backtrace of the program failing when calling the hexlify() function. I tried compiling with `--with-pydebug', but then I can't reproduce the core dump for some reason. As you mention, this could have something to do with FreeBSD's libc. However, does that explain why I only have this problem with 2.1.1? On the same system, Python 1.5.2, 2.0, and 2.2c1 compiled in the same manner (simply ./configure && gmake) don't produce a core dump. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=6380 See the repeated "(no debugging symbols found)..." in the gdb output? try recompiling with -g. I strongly suspect that the traceback is lying, and we're in fact not in PyString_AsStringAndSize() when we call sprintf -- there's no sprintf call in that function (I checked the 2.1.1 source) but there is one two static functions down, in string_repr(), which is indeed called when you pickle a string object. This would match the original gdb stacktrace you reported: there's no sprintf call in _PyString_FormatLong(), but there are two in the next static function, formatint(), and it does make sense that that function would be called by the %02x format. All this makes no sense, however, because I can see nothing wrong with the arguments to sprintf here! I've heard of problems on FreeBSD having to do with different (threaded and unthreaded?) versions of libc. Could that be the issue here? Can you rebuild Python 2.1.1 with debugg flags on? (./configure --with-pydebug should do it for 2.2; I don't recall if the 2.2.1 configure supports that though -- try --help first.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Mon Dec 17 05:01:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 21:01:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 21:01 Message: Logged In: YES user_id=85984 As far as the standalone program, I'm not a C programmer, (I've become Python-dependent :-), but if you can give me an idea of what it should contain, I'll give it a try. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 20:23 Message: Logged In: YES user_id=6380 Sigh. I think it's a dead end. What about a stand-alone program? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 19:09 Message: Logged In: YES user_id=85984 Tim asked whather I can verify whether I'm mixing the threaded and non-threaded versions of libc. Is the following enough to tell? $ ldd /usr/local/src/Python-2.1.1/python /usr/local/src/Python-2.1.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x280ca000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28182000) libm.so.2 => /usr/lib/libm.so.2 (0x2818b000) libc.so.4 => /usr/lib/libc.so.4 (0x281a7000) libc is the non-threaded library, and libc_r is the threaded version, so it looks like they are being mixed, yes? However, my Python 2.0.1 also looks the same way, and I'm not having any problems with it. $ ldd /usr/local/src/Python-2.0.1/python /usr/local/src/Python-2.0.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x2816c000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28224000) libm.so.2 => /usr/lib/libm.so.2 (0x2822d000) libc.so.4 => /usr/lib/libc.so.4 (0x28249000) Next, Guido asked me to check some local variables in that stack frame. See attached backtrace3.txt. And to answer your question, yes I built all the Python versions I'm testing myself. I even rebuilt 2.0.1 and 2.1.1 in the simplest manner to make sure I'm comparing them equally. (Just ./configure && make). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:47 Message: Logged In: YES user_id=31435 BTW, a google search on _thread_autoinit_dummy_decl turns up another FreeBSD bug report of a death deep in libc_r starting with a sprintf() call. It had to do with mysql, not with Python. The tracebacks in both cases look worthless to me, because (for example) _thread_autoinit_dummy_decl is an extern int in the FreeBSD source, not a function at all. This increases the suspicion that libc versions are getting mixed up (and that gdb is looking up addresses in "the wrong" libc). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 17:20 Message: Logged In: YES user_id=6380 OK, it's the second sprintf call in formatint. Can you check some local variables in that stack frame? I expect fmt to be "%.1lx", but would like to see that confirmed; x should be one of the values from your binary string: 206, 199, 166. Can you see which one? It would then be interesting to find out what a small C program with that same sprintf() does. Make sure that the C program is compiled and linked in exactly the same way as python. (What I do in such cases is I put the experimental statement in Python's main() and rebuild Python. :-) The build procedure of each Python version is somewhat different, and it's likely that each version picks slightly different compile/link options. Also, did you build all the Python versions you tried yourself? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:17 Message: Logged In: YES user_id=31435 The new backtrace is helpful (thanks!), but it just makes it harder to believe that Python is at fault. The segfault occurs four levels deep in system library functions, and from inspection there's nothing even remotely suspicious about the sprintf call that kicks it off. As Guido suggested, can you verify you're not mixing the threaded and non-threaded versions of libc? Short of that, you really need a FreeBSD libc author to help with this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 15:26 Message: Logged In: YES user_id=85984 Alright, I rebuilt Python 2.1.1 with -g, so the gdb backtrace now contains some more information. I attached backtrace2.txt which is a backtrace of the program failing when calling the hexlify() function. I tried compiling with `--with-pydebug', but then I can't reproduce the core dump for some reason. As you mention, this could have something to do with FreeBSD's libc. However, does that explain why I only have this problem with 2.1.1? On the same system, Python 1.5.2, 2.0, and 2.2c1 compiled in the same manner (simply ./configure && gmake) don't produce a core dump. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=6380 See the repeated "(no debugging symbols found)..." in the gdb output? try recompiling with -g. I strongly suspect that the traceback is lying, and we're in fact not in PyString_AsStringAndSize() when we call sprintf -- there's no sprintf call in that function (I checked the 2.1.1 source) but there is one two static functions down, in string_repr(), which is indeed called when you pickle a string object. This would match the original gdb stacktrace you reported: there's no sprintf call in _PyString_FormatLong(), but there are two in the next static function, formatint(), and it does make sense that that function would be called by the %02x format. All this makes no sense, however, because I can see nothing wrong with the arguments to sprintf here! I've heard of problems on FreeBSD having to do with different (threaded and unthreaded?) versions of libc. Could that be the issue here? Can you rebuild Python 2.1.1 with debugg flags on? (./configure --with-pydebug should do it for 2.2; I don't recall if the 2.2.1 configure supports that though -- try --help first.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Mon Dec 17 05:13:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 16 Dec 2001 21:13:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 21:13 Message: Logged In: YES user_id=6380 Add these three lines to Py_Main() in Modules/main.c, after the line saying "PyCompilerFlags cf;": char buffer[120]; sprintf(buffer, "%.1lx", 223L); printf("%s\n", buffer); and rebuild Python. When you run Python, it should print "df" before the standard banner. If it crashes, we've proved that Python is not the cause of the problem. But I predict that it'll work. :-( ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 21:01 Message: Logged In: YES user_id=85984 As far as the standalone program, I'm not a C programmer, (I've become Python-dependent :-), but if you can give me an idea of what it should contain, I'll give it a try. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 20:23 Message: Logged In: YES user_id=6380 Sigh. I think it's a dead end. What about a stand-alone program? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 19:09 Message: Logged In: YES user_id=85984 Tim asked whather I can verify whether I'm mixing the threaded and non-threaded versions of libc. Is the following enough to tell? $ ldd /usr/local/src/Python-2.1.1/python /usr/local/src/Python-2.1.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x280ca000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28182000) libm.so.2 => /usr/lib/libm.so.2 (0x2818b000) libc.so.4 => /usr/lib/libc.so.4 (0x281a7000) libc is the non-threaded library, and libc_r is the threaded version, so it looks like they are being mixed, yes? However, my Python 2.0.1 also looks the same way, and I'm not having any problems with it. $ ldd /usr/local/src/Python-2.0.1/python /usr/local/src/Python-2.0.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x2816c000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28224000) libm.so.2 => /usr/lib/libm.so.2 (0x2822d000) libc.so.4 => /usr/lib/libc.so.4 (0x28249000) Next, Guido asked me to check some local variables in that stack frame. See attached backtrace3.txt. And to answer your question, yes I built all the Python versions I'm testing myself. I even rebuilt 2.0.1 and 2.1.1 in the simplest manner to make sure I'm comparing them equally. (Just ./configure && make). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:47 Message: Logged In: YES user_id=31435 BTW, a google search on _thread_autoinit_dummy_decl turns up another FreeBSD bug report of a death deep in libc_r starting with a sprintf() call. It had to do with mysql, not with Python. The tracebacks in both cases look worthless to me, because (for example) _thread_autoinit_dummy_decl is an extern int in the FreeBSD source, not a function at all. This increases the suspicion that libc versions are getting mixed up (and that gdb is looking up addresses in "the wrong" libc). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 17:20 Message: Logged In: YES user_id=6380 OK, it's the second sprintf call in formatint. Can you check some local variables in that stack frame? I expect fmt to be "%.1lx", but would like to see that confirmed; x should be one of the values from your binary string: 206, 199, 166. Can you see which one? It would then be interesting to find out what a small C program with that same sprintf() does. Make sure that the C program is compiled and linked in exactly the same way as python. (What I do in such cases is I put the experimental statement in Python's main() and rebuild Python. :-) The build procedure of each Python version is somewhat different, and it's likely that each version picks slightly different compile/link options. Also, did you build all the Python versions you tried yourself? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:17 Message: Logged In: YES user_id=31435 The new backtrace is helpful (thanks!), but it just makes it harder to believe that Python is at fault. The segfault occurs four levels deep in system library functions, and from inspection there's nothing even remotely suspicious about the sprintf call that kicks it off. As Guido suggested, can you verify you're not mixing the threaded and non-threaded versions of libc? Short of that, you really need a FreeBSD libc author to help with this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 15:26 Message: Logged In: YES user_id=85984 Alright, I rebuilt Python 2.1.1 with -g, so the gdb backtrace now contains some more information. I attached backtrace2.txt which is a backtrace of the program failing when calling the hexlify() function. I tried compiling with `--with-pydebug', but then I can't reproduce the core dump for some reason. As you mention, this could have something to do with FreeBSD's libc. However, does that explain why I only have this problem with 2.1.1? On the same system, Python 1.5.2, 2.0, and 2.2c1 compiled in the same manner (simply ./configure && gmake) don't produce a core dump. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=6380 See the repeated "(no debugging symbols found)..." in the gdb output? try recompiling with -g. I strongly suspect that the traceback is lying, and we're in fact not in PyString_AsStringAndSize() when we call sprintf -- there's no sprintf call in that function (I checked the 2.1.1 source) but there is one two static functions down, in string_repr(), which is indeed called when you pickle a string object. This would match the original gdb stacktrace you reported: there's no sprintf call in _PyString_FormatLong(), but there are two in the next static function, formatint(), and it does make sense that that function would be called by the %02x format. All this makes no sense, however, because I can see nothing wrong with the arguments to sprintf here! I've heard of problems on FreeBSD having to do with different (threaded and unthreaded?) versions of libc. Could that be the issue here? Can you rebuild Python 2.1.1 with debugg flags on? (./configure --with-pydebug should do it for 2.2; I don't recall if the 2.2.1 configure supports that though -- try --help first.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Mon Dec 17 09:02:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 01:02:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-493252 ] maximum recursion limit exceeded in match Message-ID: Bugs item #493252, was opened at 2001-12-14 02:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: P. de Jong (peterdejong) Assigned to: Fredrik Lundh (effbot) Summary: maximum recursion limit exceeded in match Initial Comment: RuntimeError: maximum recursion limit exceeded in match, while trying to match a string of 16384 bytes. (Python 2.0) The error does not occur after eliminating some 100 characters from the string. The error does not occur in Python 1.5.2. So I cannot upgrade. Peter de Jong ---------------------------------------------------------------------- >Comment By: P. de Jong (peterdejong) Date: 2001-12-17 01:02 Message: Logged In: YES user_id=402001 Tim and Guido, I want to match things like: "jlkjkl ""kjlklkjkl""ljk ;lkk;l"; or: "jlkjkl ""kjlklkjkl""ljk ;lkk;l" Maybe I can trust the embedded quotes to be doubled, but I was not sure at the moment of writing the expression. I do have to include newlines inside the enclosing quotes. Peter de Jong ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 20:34 Message: Logged In: YES user_id=31435 Oops! I used to make the same mistake in Perl too (which is I pushed to name the symbolic flag DOTALL instead of SINGLELINE). So the correct regexp is r'"[^"]*"[;\n]' Assuming, of course, that Peter does want embedded newlines to get sucked up. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:30 Message: Logged In: YES user_id=6380 Tim, Peter's regex starts with (?s) which is the same as compiling with re.S or re.DOTALL which makes '.' match newline -- the opposite of what you seem to think (?s) means. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 11:08 Message: Logged In: YES user_id=31435 Peter, assuming Guido is correct that you did not intend to match strings with embedded double quotes, here's a correct (and much more efficient) replacement for your regexp: r'"[^"\n]*"[;\n]' Note that (contra Guido's suggestion ), a newline has to be part of the negated character class, because you asked for single-line mode so presumably didn't want your .*? to match any newlines either. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:03 Message: Logged In: YES user_id=6380 Do you really *want* that pattern to match input like this: "xxx"xxx"; ??? If not, replace the (.*?) with ([^"]*) -- this will dramatically reduce the amount of backtracking generated if there are unbalanced quotes in the input. ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-15 05:23 Message: Logged In: YES user_id=402001 Hi Guido! The regular expression used was: '(?s)"(.*?)"(;|\n)' Peter ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-12-14 08:32 Message: Logged In: YES user_id=38376 Three additional comments: 1) The fact that you get this under 2.0 indicates that your regular expression doesn't run very well under 1.5.2 either; it can most likely be rewritten to be much faster, and use much less memory. 2) But if that's okay, you can always work around this by replacing "import re" with "import pre as re" (or "import pre; re = pre") 3) This will be fixed in future versions. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-14 07:57 Message: Logged In: YES user_id=31435 Assigned to /F. Echo Guido's belief that the regexp can almost certainly be rewritten to avoid this and run much faster at the same time. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 05:53 Message: Logged In: YES user_id=6380 Hi Peter! This usually happens when the pattern contains * or + in a way that causes more backtracking than one would naively expect. Can you show us the pattern? There's usually an easy way to rewrite the pattern so that it won't overflow -- and it will be faster too... BTW I would upgrade to Python 2.1.1 -- that's the most stable release to date. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 From noreply@sourceforge.net Mon Dec 17 09:28:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 01:28:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-493837 ] Distutils not finding Python on Win2K Message-ID: Bugs item #493837, was opened at 2001-12-16 00:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493837&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Thomas Heller (theller) Summary: Distutils not finding Python on Win2K Initial Comment: Thomas (or anyone else), can you help this fellow who posted to the Tutor list? If there's a systematic problem here with 2.2c1, we've only got a window of a few days to fix it. """ From: tutor-admin@python.org [mailto:tutor- admin@python.org]On Behalf Of Quniceleaf Listservs Sent: Sunday, December 16, 2001 2:02 AM To: tutor@python.org Subject: [Tutor] Python not being found in the registry? I'm using Python 2.2c1 on a Win2K machine. I've repeatedly tried installing two Python addons from different sources (XIST and the MySQL-interface) that each use a Windows installer program based on distutils-1.0.2pre. Both need to locate the Python installation before proceeding with the setup, and will not allow the user to browse and specify the location themselves. Unfortunately, neither can ever find a Python installation, and thus will not install. I've tried this repeatedly with Python 2.1, 2.2b, 2.2c1, and with ActiveState's distribution. In each case the installation is reflected in the Windows registry, but only the ActiveState install appears in the setup (and due to instability issues I am sticking with the standard distribution). Has anyone else encountered this problem? - Brian """ Unfortunately, the Tutor list reports his email address as listservb@quinceleaf.com, which doesn't seem reasonable. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 01:28 Message: Logged In: YES user_id=38388 One problem could be that Brian is trying to install a binary for a non-installed Python version on the machine. In that case, the installer does not display any entries in the Python directory selection box. Another possibility is fixing the binaries to use the latest distutils version available. Thomas Heller made some changes which solved a few problems in distutils 1.0.3 AFAIR. As a test I'd suggest to install egenix-mx-base on the machine and see what you get (the installer for that package was built using distutils 2.0.3). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493837&group_id=5470 From noreply@sourceforge.net Mon Dec 17 10:44:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 02:44:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-493837 ] Distutils not finding Python on Win2K Message-ID: Bugs item #493837, was opened at 2001-12-16 00:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493837&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Thomas Heller (theller) Summary: Distutils not finding Python on Win2K Initial Comment: Thomas (or anyone else), can you help this fellow who posted to the Tutor list? If there's a systematic problem here with 2.2c1, we've only got a window of a few days to fix it. """ From: tutor-admin@python.org [mailto:tutor- admin@python.org]On Behalf Of Quniceleaf Listservs Sent: Sunday, December 16, 2001 2:02 AM To: tutor@python.org Subject: [Tutor] Python not being found in the registry? I'm using Python 2.2c1 on a Win2K machine. I've repeatedly tried installing two Python addons from different sources (XIST and the MySQL-interface) that each use a Windows installer program based on distutils-1.0.2pre. Both need to locate the Python installation before proceeding with the setup, and will not allow the user to browse and specify the location themselves. Unfortunately, neither can ever find a Python installation, and thus will not install. I've tried this repeatedly with Python 2.1, 2.2b, 2.2c1, and with ActiveState's distribution. In each case the installation is reflected in the Windows registry, but only the ActiveState install appears in the setup (and due to instability issues I am sticking with the standard distribution). Has anyone else encountered this problem? - Brian """ Unfortunately, the Tutor list reports his email address as listservb@quinceleaf.com, which doesn't seem reasonable. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2001-12-17 02:44 Message: Logged In: YES user_id=11105 I think MAL is right: It seems Brian is trying to install XIST and MySQL, which are built for Python2.1 (only), and the installer does not show (for purpose) the 2.2 installation. Probably the installer should display a clear message to the user if there are other Python versions not matching the requirements for the package to install. (But maybe also the packagers of packages should clearly indicate that this is build for a certain Python version?) The only other possibility could be that the bdist_wininst installer does not work correctly if the registry entries are under HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE. The code is there - but how can I test it. Tried to install python2.1.1 when using the Guest account (Win2k, SP2), but all I get is 'corrupt installation detected'. Is this a known problem? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 01:28 Message: Logged In: YES user_id=38388 One problem could be that Brian is trying to install a binary for a non-installed Python version on the machine. In that case, the installer does not display any entries in the Python directory selection box. Another possibility is fixing the binaries to use the latest distutils version available. Thomas Heller made some changes which solved a few problems in distutils 1.0.3 AFAIR. As a test I'd suggest to install egenix-mx-base on the machine and see what you get (the installer for that package was built using distutils 2.0.3). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493837&group_id=5470 From noreply@sourceforge.net Mon Dec 17 11:41:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 03:41:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-493628 ] import not pythonic in 2.1.1 Message-ID: Bugs item #493628, was opened at 2001-12-15 03:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: import not pythonic in 2.1.1 Initial Comment: Take a package 'aPackage', which contains a sub-package 'aSubPackage' that in turn contains a module 'aModule' that defines a class 'aClass'. If I do: import aPackage.aSubPackage print aPackage.aSubPackage.aModule I get: Traceback (most recent call last): File "x.py", line xx, in ? print aPackage.aSubPackage.aModule AttributeError: 'aPackage.aSubPackage' module has no attribute 'aModule' A yet, if I do: import aPackage.aSubPackage.aModule print aPackage.aSubPackage.aModule I get: ...as expected, which is very confusing and doesn't feel 'right' :-S ---------------------------------------------------------------------- >Comment By: Chris Withers (fresh) Date: 2001-12-17 03:41 Message: Logged In: YES user_id=24723 > OK, the motivation is that importing a package shouldn't > recursively import all its submodules -- else importing a > top-level package could do an immense amount of work. Fair enough, I guess I don't use any packages where this is true, apart from Zope, but "import Zope" certainly takes some time anyway ;-) To answer Tim's question, I need to store the minimum amount of information necessary to re-constitute an object in a MySQL database. The attributes that need to persist are easy, just shove 'em in columns. However, to actually create the object, I need to instantiate a class. With the above restrictions, I've ended doing: k = str(object.__class__) i = k.rindex('.') module = k[:i] klass = k[i+1:] ..and storing module and class in columns. Then, to reconstitute the object, I do: exec("import "+module) exec("k = "+module+'.'+klass) object=k() the second exec is needed because import fails if the last name isn't a module or package. the first exec is needed because: 1. __import__ doesn't handle . seperated names to import 2. If I use __import__ to import the top level package, none of the modules/packages below it are imported so getattr(module,klass) fails with an AttributeError Thinking about it, if (1) worked, then I probably wouldn't have a problem... That said, if there's a simpler way to do all this, I'd happily use that ;-) cheers, Chris ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-16 12:45 Message: Logged In: YES user_id=24723 > I'm not sure what to do with your whine about being one of > the many who find it counter-intuitive. Can you explain how > you would like it to behave? Sorry, that was me being unclear... I meant I am probably one of the few who finds it unintuitive ;-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:38 Message: Logged In: YES user_id=6380 OK, the motivation is that importing a package shouldn't recursively import all its submodules -- else importing a top-level package could do an immense amount of work. The motivation for the thing you quote is less clear -- it follows from the requirement that in "import ", "" refers to a module (where a package is a special case of a module). I'm not sure what to do with your whine about being one of the many who find it counter-intuitive. Can you explain how you would like it to behave? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 10:03 Message: Logged In: YES user_id=31435 Chris, why do you think you need to use an exec stmt? You haven't shown an example of why it's needed, and it sure isn't obvious. Modules must be imported, and importing a module M requires an import stmt whose last path component is M -- that's about all there is to it. ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-16 04:58 Message: Logged In: YES user_id=24723 Well, I read it, and it explains the history, but it doesn't give reasons, particularly for: > Contrarily, when using syntax like import item.subitem.subsubitem, each item except for the last must be a package; the last item can be a module > or a package but can't be a class or function or variable defined in the previous item. ...or for the above stuff. But, while I find it counter-intuitive (and means I have to use unpleasant exec statements), I am but one voice among many who probably feel differently so I'll just accept it as one of the things i don't like about python... thanks for your time :-) Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 09:46 Message: Logged In: YES user_id=6380 http://www.python.org/doc/essays/packages.html ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-15 09:15 Message: Logged In: YES user_id=24723 Okay, if it's intended, that means there's a good reason for it... ...where can I look for enlightenment as to what that is? cheers, Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 07:39 Message: Logged In: YES user_id=6380 Better adjust your intuition. :-) This is as intended. Attributes of packages that are *modules* are only loaded when the corresponding module is explicitly imported (by you, or by some other code, e.g. the package's __init__.py). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 From noreply@sourceforge.net Mon Dec 17 13:37:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 05:37:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-493462 ] Attribute Search in MRO w/o tp_getattr Message-ID: Bugs item #493462, was opened at 2001-12-14 13:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493462&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Robert Stewart (rstewart) Assigned to: Guido van Rossum (gvanrossum) Summary: Attribute Search in MRO w/o tp_getattr Initial Comment: In writing a metatype, I wanted to resolve attribute references via a tp_getattr-style function -- with either a char * or a Python string. Unfortunately, PyObject_GenericGetAttr() first tries _PyType_Lookup() to find a descriptor via base class dictionaries. Searching according to the MRO is fine. The problem is that _PyType_Lookup() only searches the dictionary of each base class. It never checks those bases to see it tp_getattr is set. My workaround, which is not ideal, is to implement my own tp_getattro function which first calls PyObject_GenericGetAttr() to locate the attribute. If that succeeds, that attribute is returned. If it fails, then the tp_getattr-style function is called to locate the attribute. This approach will return a base class attribute when the derived class overrides it, which is why I said it was not ideal. The only way I can improve this process is to write my own replacement for PyObject_GenericGetAttr() and _PyType_Lookup(). That would make my code very brittle, so that's not a good solution. What I'd like to see is for _PyType_Lookup() to try the dictionary, as it does now. If that fails, I'd like it to check to see if tp_getattr is set. If so, I'd like it to call the tp_getattr function to resolve the attribute. Perhaps this change violates some ideal of Python that I can't foresee, but it would sure work great for me. ---------------------------------------------------------------------- >Comment By: Robert Stewart (rstewart) Date: 2001-12-17 05:37 Message: Logged In: YES user_id=402463 Guido, Let me explain in more detail and, hopefully, answer your questions. I'm sure there's something better I can do, but I do have performance constraints which may override anything else. (This is for a real time financial program, so I need to keep overhead to a minimum.) > When you talk about the bases and their tp_getattr, > are you talking about the tp_getattr of the base > type, or of its metatype? I'm referring to the base type so that the lookup occurs on instances of the Python class derived from that base. Perhaps my terminology is too loose. I've created some metatypes (right?) that are created in C++ for derivation by Python programmers. Several of the metatypes include the special behavior of hooking the class parsing by including a meta-metatype (or is it a metatype type?) whose tp_new creates the class object and then searches for and saves certain methods that will be used to override virtual functions in C++. (The C++ virtual functions will check to see whether the Python programmer defined the corresponding method and, if so, calls that method.) This has the behavior of only crossing into Python when the Python programmer wants it. That is, my metatype does not define those methods, so unless the derived class does, no Python calls will be made. > (Note: forget about tp_getattr -- you should leave > that NULL, and only implement tp_getatto.) I already have functionality in place -- from implementing many extension types -- that relies on the tp_getattr mechanism to map more easily into C++. It's that functionality that I'm trying to use during attribute lookup on the Python instance. Implementing the tp_getattro mechanism means that I must put objects into the metatype's dictionary and rely on Python to locate them and call them, which in turn relies on my defining extern "C" functions which can call the C++ code. I'm trying to avoid that overhead. Is there something I'm missing? > PyObject_GenericGetAttr() should only be used in > situations where the base type's tp_getattro is also > PyObject_GenericGetAttr(). There's no documentation to this effect that I've seen. > Why do you think that writing your own replacement > for PyObject_GenericGetAttr() and _PyType_Lookup() > would be brittle? That's what you are *supposed* to > do if you're not happy with them. The mechanism for locating attributes changed drastically in Python 2.2. The logic in PyObject_GenericGetAttr() and _PyType_Lookup() changed accordingly. Any version of those functions that I might write will be completely dependent upon the implementation of many of the underlying details such as tp_mro, tp_getattro, etc. Furthermore, the correct behavior of the Python derived class depends upon a correct implementation of tp_getattro. Thus, since the documentation for PyObject_GenericGetAttr() does not detail its contract with the caller, how can I write an equivalent function that won't break when the next version of Python is released? You could change any underlying aspect and break my implementation of tp_getattro. That's why I think it is brittle. IOW, if you supplied more fundamental building blocks by which I could implement my own tp_getattro -- indeed, upon which PyObject_GenericGetAttr() is built -- then I would rely on you to make the low level implementation details right. That means I only have to keep the higher level details of tp_getattro right. For example, _PyType_Lookup() is documented as being an "Internal API." By definition, that means that what it is not something I should need to be concerned with. Clearly, the implementation of _PyType_Lookup() is not rocket science, but it seems like a reasonable piece to expose to developers like me. Why should we have to reimplement such a fundamental piece if you expect us to implement our own tp_getattro functions? (Mind you, as implemented, _PyType_Lookup() doesn't do what I want, so I'd need to reimplement it for my purposes, but the point is valid in general.) As another example, the high level logic of PyObject_GenericGetAttr() is not at all obvious to me. I haven't studied descriptors in detail, so that aspect of the behavior is fuzzy. Nevertheless, PyObject_GenericGetAttr() does some oddball things: it uses _PyType_Lookup() to locate something that is ostensibly a descriptor, since it's saved in "descr", and, if "descr" refers to the right kind of thing, it is called; but, after some other gamesmanship (_PyObject_GetDictPtr(), etc.) looking for something else, "descr" is called. That behavior is not obvious, not documented, and closely tied to the underlying implementation of types. That doesn't bode well for me implementing a replacement. > What do you want to do with your metatype? Why do > you need one? Have you considered prototyping it in > Python? The metatype is a means to allow the Python programmer to implement what our C++ programmers can. In C++, a programmer derives from certain classes and overrides various virtual functions. In Python, a programmer derives from metatypes named the same as the C++ base classes and implements methods that match the C++ virtual function signatures for those s/he wishes to override. As I said in the beginning, this has to handle real time data, so I need to eliminate as much overhead as I can: milliseconds are significant. Thus, I'm trying to handle as much as I can myself, and in C++, without writing code that is closely coupled to the current implementation of Python. If there's a published API for my purpose, I'll gladly use it. If not, I'm wary. So, what have I missed? Is there a better way to do what I want? I don't have to use the tp_getattr mechanism, but I do need a high performance attribute lookup/C++ call mechanism. Thus, my thought was that _PyType_Lookup() could check to see whether the type object set tp_getattr. If so, it could call that function before moving on to the next type in the MRO. This would allow developers like me the flexibility to put things in the dictionary or to use a dispatch function like tp_getattr (or both) as we see fit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 13:41 Message: Logged In: YES user_id=6380 When you talk about the bases and their tp_getattr, are you talking about the tp_getattr of the base type, or of its metatype? (Note: forget about tp_getattr -- you should leave that NULL, and only implement tp_getatto.) PyObject_GenericGetAttr() should only be used in situations where the base type's tp_getattro is also PyObject_GenericGetAttr(). Why do you think that writing your own replacement for PyObject_GenericGetAttr() and _PyType_Lookup() would be brittle? That's what you are *supposed* to do if you're not happy with them. What do you want to do with your metatype? Why do you need one? Have you considered prototyping it in Python? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493462&group_id=5470 From noreply@sourceforge.net Mon Dec 17 14:08:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 06:08:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-493252 ] maximum recursion limit exceeded in match Message-ID: Bugs item #493252, was opened at 2001-12-14 02:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: P. de Jong (peterdejong) Assigned to: Fredrik Lundh (effbot) Summary: maximum recursion limit exceeded in match Initial Comment: RuntimeError: maximum recursion limit exceeded in match, while trying to match a string of 16384 bytes. (Python 2.0) The error does not occur after eliminating some 100 characters from the string. The error does not occur in Python 1.5.2. So I cannot upgrade. Peter de Jong ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 06:08 Message: Logged In: YES user_id=6380 Peter, if the internal quotes are doubled, try this: r'"([^"]|"")*"[;\n]' if you can't trust them to be doubled, you're in trouble -- your language is ambiguous. :-( ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-17 01:02 Message: Logged In: YES user_id=402001 Tim and Guido, I want to match things like: "jlkjkl ""kjlklkjkl""ljk ;lkk;l"; or: "jlkjkl ""kjlklkjkl""ljk ;lkk;l" Maybe I can trust the embedded quotes to be doubled, but I was not sure at the moment of writing the expression. I do have to include newlines inside the enclosing quotes. Peter de Jong ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 20:34 Message: Logged In: YES user_id=31435 Oops! I used to make the same mistake in Perl too (which is I pushed to name the symbolic flag DOTALL instead of SINGLELINE). So the correct regexp is r'"[^"]*"[;\n]' Assuming, of course, that Peter does want embedded newlines to get sucked up. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:30 Message: Logged In: YES user_id=6380 Tim, Peter's regex starts with (?s) which is the same as compiling with re.S or re.DOTALL which makes '.' match newline -- the opposite of what you seem to think (?s) means. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 11:08 Message: Logged In: YES user_id=31435 Peter, assuming Guido is correct that you did not intend to match strings with embedded double quotes, here's a correct (and much more efficient) replacement for your regexp: r'"[^"\n]*"[;\n]' Note that (contra Guido's suggestion ), a newline has to be part of the negated character class, because you asked for single-line mode so presumably didn't want your .*? to match any newlines either. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:03 Message: Logged In: YES user_id=6380 Do you really *want* that pattern to match input like this: "xxx"xxx"; ??? If not, replace the (.*?) with ([^"]*) -- this will dramatically reduce the amount of backtracking generated if there are unbalanced quotes in the input. ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-15 05:23 Message: Logged In: YES user_id=402001 Hi Guido! The regular expression used was: '(?s)"(.*?)"(;|\n)' Peter ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-12-14 08:32 Message: Logged In: YES user_id=38376 Three additional comments: 1) The fact that you get this under 2.0 indicates that your regular expression doesn't run very well under 1.5.2 either; it can most likely be rewritten to be much faster, and use much less memory. 2) But if that's okay, you can always work around this by replacing "import re" with "import pre as re" (or "import pre; re = pre") 3) This will be fixed in future versions. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-14 07:57 Message: Logged In: YES user_id=31435 Assigned to /F. Echo Guido's belief that the regexp can almost certainly be rewritten to avoid this and run much faster at the same time. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 05:53 Message: Logged In: YES user_id=6380 Hi Peter! This usually happens when the pattern contains * or + in a way that causes more backtracking than one would naively expect. Can you show us the pattern? There's usually an easy way to rewrite the pattern so that it won't overflow -- and it will be faster too... BTW I would upgrade to Python 2.1.1 -- that's the most stable release to date. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 From noreply@sourceforge.net Mon Dec 17 14:35:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 06:35:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-493628 ] import not pythonic in 2.1.1 Message-ID: Bugs item #493628, was opened at 2001-12-15 03:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: import not pythonic in 2.1.1 Initial Comment: Take a package 'aPackage', which contains a sub-package 'aSubPackage' that in turn contains a module 'aModule' that defines a class 'aClass'. If I do: import aPackage.aSubPackage print aPackage.aSubPackage.aModule I get: Traceback (most recent call last): File "x.py", line xx, in ? print aPackage.aSubPackage.aModule AttributeError: 'aPackage.aSubPackage' module has no attribute 'aModule' A yet, if I do: import aPackage.aSubPackage.aModule print aPackage.aSubPackage.aModule I get: ...as expected, which is very confusing and doesn't feel 'right' :-S ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 06:35 Message: Logged In: YES user_id=6380 Yeah, Zope has many __init__.py files that I consider immoral. We're fixing this in Zope3. :-) What you're doing is similar to what pickle does, by the way. Can't you store pickles? Several tips: - instead of getting str(object.__class__) and then parsing the result, use module, klass = k.__class__.__name__, k.__class__.__module__ - __import__ *does* support packages, if you do it right: __import__(module) m = sys.modules[module] - Instead of exec("k ="...), use k = getattr(m, klass) So please don't blame this in import. :-) ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-17 03:41 Message: Logged In: YES user_id=24723 > OK, the motivation is that importing a package shouldn't > recursively import all its submodules -- else importing a > top-level package could do an immense amount of work. Fair enough, I guess I don't use any packages where this is true, apart from Zope, but "import Zope" certainly takes some time anyway ;-) To answer Tim's question, I need to store the minimum amount of information necessary to re-constitute an object in a MySQL database. The attributes that need to persist are easy, just shove 'em in columns. However, to actually create the object, I need to instantiate a class. With the above restrictions, I've ended doing: k = str(object.__class__) i = k.rindex('.') module = k[:i] klass = k[i+1:] ..and storing module and class in columns. Then, to reconstitute the object, I do: exec("import "+module) exec("k = "+module+'.'+klass) object=k() the second exec is needed because import fails if the last name isn't a module or package. the first exec is needed because: 1. __import__ doesn't handle . seperated names to import 2. If I use __import__ to import the top level package, none of the modules/packages below it are imported so getattr(module,klass) fails with an AttributeError Thinking about it, if (1) worked, then I probably wouldn't have a problem... That said, if there's a simpler way to do all this, I'd happily use that ;-) cheers, Chris ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-16 12:45 Message: Logged In: YES user_id=24723 > I'm not sure what to do with your whine about being one of > the many who find it counter-intuitive. Can you explain how > you would like it to behave? Sorry, that was me being unclear... I meant I am probably one of the few who finds it unintuitive ;-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:38 Message: Logged In: YES user_id=6380 OK, the motivation is that importing a package shouldn't recursively import all its submodules -- else importing a top-level package could do an immense amount of work. The motivation for the thing you quote is less clear -- it follows from the requirement that in "import ", "" refers to a module (where a package is a special case of a module). I'm not sure what to do with your whine about being one of the many who find it counter-intuitive. Can you explain how you would like it to behave? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 10:03 Message: Logged In: YES user_id=31435 Chris, why do you think you need to use an exec stmt? You haven't shown an example of why it's needed, and it sure isn't obvious. Modules must be imported, and importing a module M requires an import stmt whose last path component is M -- that's about all there is to it. ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-16 04:58 Message: Logged In: YES user_id=24723 Well, I read it, and it explains the history, but it doesn't give reasons, particularly for: > Contrarily, when using syntax like import item.subitem.subsubitem, each item except for the last must be a package; the last item can be a module > or a package but can't be a class or function or variable defined in the previous item. ...or for the above stuff. But, while I find it counter-intuitive (and means I have to use unpleasant exec statements), I am but one voice among many who probably feel differently so I'll just accept it as one of the things i don't like about python... thanks for your time :-) Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 09:46 Message: Logged In: YES user_id=6380 http://www.python.org/doc/essays/packages.html ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-15 09:15 Message: Logged In: YES user_id=24723 Okay, if it's intended, that means there's a good reason for it... ...where can I look for enlightenment as to what that is? cheers, Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 07:39 Message: Logged In: YES user_id=6380 Better adjust your intuition. :-) This is as intended. Attributes of packages that are *modules* are only loaded when the corresponding module is explicitly imported (by you, or by some other code, e.g. the package's __init__.py). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 From noreply@sourceforge.net Mon Dec 17 14:37:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 06:37:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-494203 ] Interpreter won't exit with daemonic Message-ID: Bugs item #494203, was opened at 2001-12-17 06:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494203&group_id=5470 Category: Threads Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Morten W. Petersen (morphex) Assigned to: Nobody/Anonymous (nobody) Summary: Interpreter won't exit with daemonic Initial Comment: See file. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494203&group_id=5470 From noreply@sourceforge.net Mon Dec 17 14:45:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 06:45:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-493462 ] Attribute Search in MRO w/o tp_getattr Message-ID: Bugs item #493462, was opened at 2001-12-14 13:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493462&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Robert Stewart (rstewart) Assigned to: Guido van Rossum (gvanrossum) Summary: Attribute Search in MRO w/o tp_getattr Initial Comment: In writing a metatype, I wanted to resolve attribute references via a tp_getattr-style function -- with either a char * or a Python string. Unfortunately, PyObject_GenericGetAttr() first tries _PyType_Lookup() to find a descriptor via base class dictionaries. Searching according to the MRO is fine. The problem is that _PyType_Lookup() only searches the dictionary of each base class. It never checks those bases to see it tp_getattr is set. My workaround, which is not ideal, is to implement my own tp_getattro function which first calls PyObject_GenericGetAttr() to locate the attribute. If that succeeds, that attribute is returned. If it fails, then the tp_getattr-style function is called to locate the attribute. This approach will return a base class attribute when the derived class overrides it, which is why I said it was not ideal. The only way I can improve this process is to write my own replacement for PyObject_GenericGetAttr() and _PyType_Lookup(). That would make my code very brittle, so that's not a good solution. What I'd like to see is for _PyType_Lookup() to try the dictionary, as it does now. If that fails, I'd like it to check to see if tp_getattr is set. If so, I'd like it to call the tp_getattr function to resolve the attribute. Perhaps this change violates some ideal of Python that I can't foresee, but it would sure work great for me. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 06:45 Message: Logged In: YES user_id=6380 I'm sending an email reply to rstewart@users.sf.net ---------------------------------------------------------------------- Comment By: Robert Stewart (rstewart) Date: 2001-12-17 05:37 Message: Logged In: YES user_id=402463 Guido, Let me explain in more detail and, hopefully, answer your questions. I'm sure there's something better I can do, but I do have performance constraints which may override anything else. (This is for a real time financial program, so I need to keep overhead to a minimum.) > When you talk about the bases and their tp_getattr, > are you talking about the tp_getattr of the base > type, or of its metatype? I'm referring to the base type so that the lookup occurs on instances of the Python class derived from that base. Perhaps my terminology is too loose. I've created some metatypes (right?) that are created in C++ for derivation by Python programmers. Several of the metatypes include the special behavior of hooking the class parsing by including a meta-metatype (or is it a metatype type?) whose tp_new creates the class object and then searches for and saves certain methods that will be used to override virtual functions in C++. (The C++ virtual functions will check to see whether the Python programmer defined the corresponding method and, if so, calls that method.) This has the behavior of only crossing into Python when the Python programmer wants it. That is, my metatype does not define those methods, so unless the derived class does, no Python calls will be made. > (Note: forget about tp_getattr -- you should leave > that NULL, and only implement tp_getatto.) I already have functionality in place -- from implementing many extension types -- that relies on the tp_getattr mechanism to map more easily into C++. It's that functionality that I'm trying to use during attribute lookup on the Python instance. Implementing the tp_getattro mechanism means that I must put objects into the metatype's dictionary and rely on Python to locate them and call them, which in turn relies on my defining extern "C" functions which can call the C++ code. I'm trying to avoid that overhead. Is there something I'm missing? > PyObject_GenericGetAttr() should only be used in > situations where the base type's tp_getattro is also > PyObject_GenericGetAttr(). There's no documentation to this effect that I've seen. > Why do you think that writing your own replacement > for PyObject_GenericGetAttr() and _PyType_Lookup() > would be brittle? That's what you are *supposed* to > do if you're not happy with them. The mechanism for locating attributes changed drastically in Python 2.2. The logic in PyObject_GenericGetAttr() and _PyType_Lookup() changed accordingly. Any version of those functions that I might write will be completely dependent upon the implementation of many of the underlying details such as tp_mro, tp_getattro, etc. Furthermore, the correct behavior of the Python derived class depends upon a correct implementation of tp_getattro. Thus, since the documentation for PyObject_GenericGetAttr() does not detail its contract with the caller, how can I write an equivalent function that won't break when the next version of Python is released? You could change any underlying aspect and break my implementation of tp_getattro. That's why I think it is brittle. IOW, if you supplied more fundamental building blocks by which I could implement my own tp_getattro -- indeed, upon which PyObject_GenericGetAttr() is built -- then I would rely on you to make the low level implementation details right. That means I only have to keep the higher level details of tp_getattro right. For example, _PyType_Lookup() is documented as being an "Internal API." By definition, that means that what it is not something I should need to be concerned with. Clearly, the implementation of _PyType_Lookup() is not rocket science, but it seems like a reasonable piece to expose to developers like me. Why should we have to reimplement such a fundamental piece if you expect us to implement our own tp_getattro functions? (Mind you, as implemented, _PyType_Lookup() doesn't do what I want, so I'd need to reimplement it for my purposes, but the point is valid in general.) As another example, the high level logic of PyObject_GenericGetAttr() is not at all obvious to me. I haven't studied descriptors in detail, so that aspect of the behavior is fuzzy. Nevertheless, PyObject_GenericGetAttr() does some oddball things: it uses _PyType_Lookup() to locate something that is ostensibly a descriptor, since it's saved in "descr", and, if "descr" refers to the right kind of thing, it is called; but, after some other gamesmanship (_PyObject_GetDictPtr(), etc.) looking for something else, "descr" is called. That behavior is not obvious, not documented, and closely tied to the underlying implementation of types. That doesn't bode well for me implementing a replacement. > What do you want to do with your metatype? Why do > you need one? Have you considered prototyping it in > Python? The metatype is a means to allow the Python programmer to implement what our C++ programmers can. In C++, a programmer derives from certain classes and overrides various virtual functions. In Python, a programmer derives from metatypes named the same as the C++ base classes and implements methods that match the C++ virtual function signatures for those s/he wishes to override. As I said in the beginning, this has to handle real time data, so I need to eliminate as much overhead as I can: milliseconds are significant. Thus, I'm trying to handle as much as I can myself, and in C++, without writing code that is closely coupled to the current implementation of Python. If there's a published API for my purpose, I'll gladly use it. If not, I'm wary. So, what have I missed? Is there a better way to do what I want? I don't have to use the tp_getattr mechanism, but I do need a high performance attribute lookup/C++ call mechanism. Thus, my thought was that _PyType_Lookup() could check to see whether the type object set tp_getattr. If so, it could call that function before moving on to the next type in the MRO. This would allow developers like me the flexibility to put things in the dictionary or to use a dispatch function like tp_getattr (or both) as we see fit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 13:41 Message: Logged In: YES user_id=6380 When you talk about the bases and their tp_getattr, are you talking about the tp_getattr of the base type, or of its metatype? (Note: forget about tp_getattr -- you should leave that NULL, and only implement tp_getatto.) PyObject_GenericGetAttr() should only be used in situations where the base type's tp_getattro is also PyObject_GenericGetAttr(). Why do you think that writing your own replacement for PyObject_GenericGetAttr() and _PyType_Lookup() would be brittle? That's what you are *supposed* to do if you're not happy with them. What do you want to do with your metatype? Why do you need one? Have you considered prototyping it in Python? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493462&group_id=5470 From noreply@sourceforge.net Mon Dec 17 15:04:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 07:04:47 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-494034 ] a smarter rfc822.dump_address_pair() Message-ID: Feature Requests item #494034, was opened at 2001-12-16 17:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494034&group_id=5470 Category: Python Library Group: None Status: Open Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) >Assigned to: Barry Warsaw (bwarsaw) Summary: a smarter rfc822.dump_address_pair() Initial Comment: Please see: http://mail.python.org/pipermail/python-list/2001-December/075881.html I'm turning this into a feature request since I didn't get any responses on comp.lang.python. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-17 07:04 Message: Logged In: YES user_id=12800 Claiming this item. There appears to be no groups set for the feature request tracker, but I'll look at this for Python 2.3 (to late to add it to Python 2.2). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494034&group_id=5470 From noreply@sourceforge.net Mon Dec 17 15:58:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 07:58:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-494203 ] Interpreter won't always exit with daemonic thread Message-ID: Bugs item #494203, was opened at 2001-12-17 06:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494203&group_id=5470 Category: Threads Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Morten W. Petersen (morphex) Assigned to: Nobody/Anonymous (nobody) >Summary: Interpreter won't always exit with daemonic thread Initial Comment: See file. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 07:58 Message: Logged In: YES user_id=6380 I can't reproduce this on Red Hat 6.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494203&group_id=5470 From noreply@sourceforge.net Mon Dec 17 16:21:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 08:21:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-494203 ] Interpreter won't always exit with daemonic thread Message-ID: Bugs item #494203, was opened at 2001-12-17 06:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494203&group_id=5470 Category: Threads Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Morten W. Petersen (morphex) Assigned to: Nobody/Anonymous (nobody) Summary: Interpreter won't always exit with daemonic thread Initial Comment: See file. ---------------------------------------------------------------------- >Comment By: Morten W. Petersen (morphex) Date: 2001-12-17 08:21 Message: Logged In: YES user_id=68005 Ok, the system I'm using is: morten@debian$ python Python 2.1.1 (#1, Nov 11 2001, 18:19:24) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> morten@debian$ uname -a Linux debian 2.4.14 #1 SMP Mon Dec 10 20:40:22 CET 2001 i686 unknown With a customized kernel. Should I contact the Debian maintainers ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 07:58 Message: Logged In: YES user_id=6380 I can't reproduce this on Red Hat 6.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494203&group_id=5470 From noreply@sourceforge.net Mon Dec 17 16:33:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 08:33:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-494203 ] Interpreter won't always exit with daemonic thread Message-ID: Bugs item #494203, was opened at 2001-12-17 06:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494203&group_id=5470 Category: Threads Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Morten W. Petersen (morphex) Assigned to: Nobody/Anonymous (nobody) Summary: Interpreter won't always exit with daemonic thread Initial Comment: See file. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 08:33 Message: Logged In: YES user_id=6380 I dunno. They're likely to shoot back to Python. Can you do some more digging (e.g. what is the program doing when it's hanging)? ---------------------------------------------------------------------- Comment By: Morten W. Petersen (morphex) Date: 2001-12-17 08:21 Message: Logged In: YES user_id=68005 Ok, the system I'm using is: morten@debian$ python Python 2.1.1 (#1, Nov 11 2001, 18:19:24) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> morten@debian$ uname -a Linux debian 2.4.14 #1 SMP Mon Dec 10 20:40:22 CET 2001 i686 unknown With a customized kernel. Should I contact the Debian maintainers ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 07:58 Message: Logged In: YES user_id=6380 I can't reproduce this on Red Hat 6.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494203&group_id=5470 From noreply@sourceforge.net Mon Dec 17 16:42:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 08:42:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-494203 ] Interpreter won't always exit with daemonic thread Message-ID: Bugs item #494203, was opened at 2001-12-17 06:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494203&group_id=5470 Category: Threads Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Morten W. Petersen (morphex) Assigned to: Nobody/Anonymous (nobody) Summary: Interpreter won't always exit with daemonic thread Initial Comment: See file. ---------------------------------------------------------------------- >Comment By: Morten W. Petersen (morphex) Date: 2001-12-17 08:42 Message: Logged In: YES user_id=68005 I'm attaching a trace.. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 08:33 Message: Logged In: YES user_id=6380 I dunno. They're likely to shoot back to Python. Can you do some more digging (e.g. what is the program doing when it's hanging)? ---------------------------------------------------------------------- Comment By: Morten W. Petersen (morphex) Date: 2001-12-17 08:21 Message: Logged In: YES user_id=68005 Ok, the system I'm using is: morten@debian$ python Python 2.1.1 (#1, Nov 11 2001, 18:19:24) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> morten@debian$ uname -a Linux debian 2.4.14 #1 SMP Mon Dec 10 20:40:22 CET 2001 i686 unknown With a customized kernel. Should I contact the Debian maintainers ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 07:58 Message: Logged In: YES user_id=6380 I can't reproduce this on Red Hat 6.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494203&group_id=5470 From noreply@sourceforge.net Mon Dec 17 16:47:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 08:47:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-493252 ] maximum recursion limit exceeded in match Message-ID: Bugs item #493252, was opened at 2001-12-14 02:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: P. de Jong (peterdejong) Assigned to: Fredrik Lundh (effbot) Summary: maximum recursion limit exceeded in match Initial Comment: RuntimeError: maximum recursion limit exceeded in match, while trying to match a string of 16384 bytes. (Python 2.0) The error does not occur after eliminating some 100 characters from the string. The error does not occur in Python 1.5.2. So I cannot upgrade. Peter de Jong ---------------------------------------------------------------------- >Comment By: P. de Jong (peterdejong) Date: 2001-12-17 08:47 Message: Logged In: YES user_id=402001 Guido, Indeed. in many cases my language is ambious. I will try your solution. It is not clear to me what induces the recursion; Maybe something like '(?s)"(.*?)(";|"\n)' will not give the recursion cascade? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 06:08 Message: Logged In: YES user_id=6380 Peter, if the internal quotes are doubled, try this: r'"([^"]|"")*"[;\n]' if you can't trust them to be doubled, you're in trouble -- your language is ambiguous. :-( ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-17 01:02 Message: Logged In: YES user_id=402001 Tim and Guido, I want to match things like: "jlkjkl ""kjlklkjkl""ljk ;lkk;l"; or: "jlkjkl ""kjlklkjkl""ljk ;lkk;l" Maybe I can trust the embedded quotes to be doubled, but I was not sure at the moment of writing the expression. I do have to include newlines inside the enclosing quotes. Peter de Jong ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 20:34 Message: Logged In: YES user_id=31435 Oops! I used to make the same mistake in Perl too (which is I pushed to name the symbolic flag DOTALL instead of SINGLELINE). So the correct regexp is r'"[^"]*"[;\n]' Assuming, of course, that Peter does want embedded newlines to get sucked up. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:30 Message: Logged In: YES user_id=6380 Tim, Peter's regex starts with (?s) which is the same as compiling with re.S or re.DOTALL which makes '.' match newline -- the opposite of what you seem to think (?s) means. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 11:08 Message: Logged In: YES user_id=31435 Peter, assuming Guido is correct that you did not intend to match strings with embedded double quotes, here's a correct (and much more efficient) replacement for your regexp: r'"[^"\n]*"[;\n]' Note that (contra Guido's suggestion ), a newline has to be part of the negated character class, because you asked for single-line mode so presumably didn't want your .*? to match any newlines either. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:03 Message: Logged In: YES user_id=6380 Do you really *want* that pattern to match input like this: "xxx"xxx"; ??? If not, replace the (.*?) with ([^"]*) -- this will dramatically reduce the amount of backtracking generated if there are unbalanced quotes in the input. ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-15 05:23 Message: Logged In: YES user_id=402001 Hi Guido! The regular expression used was: '(?s)"(.*?)"(;|\n)' Peter ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-12-14 08:32 Message: Logged In: YES user_id=38376 Three additional comments: 1) The fact that you get this under 2.0 indicates that your regular expression doesn't run very well under 1.5.2 either; it can most likely be rewritten to be much faster, and use much less memory. 2) But if that's okay, you can always work around this by replacing "import re" with "import pre as re" (or "import pre; re = pre") 3) This will be fixed in future versions. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-14 07:57 Message: Logged In: YES user_id=31435 Assigned to /F. Echo Guido's belief that the regexp can almost certainly be rewritten to avoid this and run much faster at the same time. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 05:53 Message: Logged In: YES user_id=6380 Hi Peter! This usually happens when the pattern contains * or + in a way that causes more backtracking than one would naively expect. Can you show us the pattern? There's usually an easy way to rewrite the pattern so that it won't overflow -- and it will be faster too... BTW I would upgrade to Python 2.1.1 -- that's the most stable release to date. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 From noreply@sourceforge.net Mon Dec 17 16:48:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 08:48:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-494203 ] Interpreter won't always exit with daemonic thread Message-ID: Bugs item #494203, was opened at 2001-12-17 06:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494203&group_id=5470 Category: Threads Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Morten W. Petersen (morphex) Assigned to: Nobody/Anonymous (nobody) Summary: Interpreter won't always exit with daemonic thread Initial Comment: See file. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 08:48 Message: Logged In: YES user_id=6380 Sorry, I don't know how to interpret the trace. Someone else, please? ---------------------------------------------------------------------- Comment By: Morten W. Petersen (morphex) Date: 2001-12-17 08:42 Message: Logged In: YES user_id=68005 I'm attaching a trace.. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 08:33 Message: Logged In: YES user_id=6380 I dunno. They're likely to shoot back to Python. Can you do some more digging (e.g. what is the program doing when it's hanging)? ---------------------------------------------------------------------- Comment By: Morten W. Petersen (morphex) Date: 2001-12-17 08:21 Message: Logged In: YES user_id=68005 Ok, the system I'm using is: morten@debian$ python Python 2.1.1 (#1, Nov 11 2001, 18:19:24) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> morten@debian$ uname -a Linux debian 2.4.14 #1 SMP Mon Dec 10 20:40:22 CET 2001 i686 unknown With a customized kernel. Should I contact the Debian maintainers ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 07:58 Message: Logged In: YES user_id=6380 I can't reproduce this on Red Hat 6.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494203&group_id=5470 From noreply@sourceforge.net Mon Dec 17 16:50:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 08:50:33 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-494240 ] str.reverse Message-ID: Feature Requests item #494240, was opened at 2001-12-17 08:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494240&group_id=5470 Category: Python Library Group: None Status: Open Priority: 5 Submitted By: Allan Crooks (amc1) Assigned to: Nobody/Anonymous (nobody) Summary: str.reverse Initial Comment: The str type should *really* have a reverse method. "How do I reverse a string?" crops up too often on tutor lists, and there should be a neater way to do it other than converting it to a list, reversing it, and then joining it... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494240&group_id=5470 From noreply@sourceforge.net Mon Dec 17 16:57:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 08:57:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-494203 ] Interpreter won't always exit with daemonic thread Message-ID: Bugs item #494203, was opened at 2001-12-17 06:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494203&group_id=5470 Category: Threads Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Morten W. Petersen (morphex) Assigned to: Nobody/Anonymous (nobody) Summary: Interpreter won't always exit with daemonic thread Initial Comment: See file. ---------------------------------------------------------------------- >Comment By: Morten W. Petersen (morphex) Date: 2001-12-17 08:57 Message: Logged In: YES user_id=68005 I can't interpret it either. :-) Is there another way to to provide debugging information ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 08:48 Message: Logged In: YES user_id=6380 Sorry, I don't know how to interpret the trace. Someone else, please? ---------------------------------------------------------------------- Comment By: Morten W. Petersen (morphex) Date: 2001-12-17 08:42 Message: Logged In: YES user_id=68005 I'm attaching a trace.. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 08:33 Message: Logged In: YES user_id=6380 I dunno. They're likely to shoot back to Python. Can you do some more digging (e.g. what is the program doing when it's hanging)? ---------------------------------------------------------------------- Comment By: Morten W. Petersen (morphex) Date: 2001-12-17 08:21 Message: Logged In: YES user_id=68005 Ok, the system I'm using is: morten@debian$ python Python 2.1.1 (#1, Nov 11 2001, 18:19:24) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> morten@debian$ uname -a Linux debian 2.4.14 #1 SMP Mon Dec 10 20:40:22 CET 2001 i686 unknown With a customized kernel. Should I contact the Debian maintainers ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 07:58 Message: Logged In: YES user_id=6380 I can't reproduce this on Red Hat 6.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494203&group_id=5470 From noreply@sourceforge.net Mon Dec 17 16:57:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 08:57:34 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-494240 ] str.reverse Message-ID: Feature Requests item #494240, was opened at 2001-12-17 08:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494240&group_id=5470 Category: Python Library Group: None Status: Open Priority: 5 Submitted By: Allan Crooks (amc1) Assigned to: Nobody/Anonymous (nobody) Summary: str.reverse Initial Comment: The str type should *really* have a reverse method. "How do I reverse a string?" crops up too often on tutor lists, and there should be a neater way to do it other than converting it to a list, reversing it, and then joining it... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 08:57 Message: Logged In: YES user_id=6380 Show me one real-life application of reversing a string. This comes from textbook exercises IMO, and doesn't occur in real life. Adding the method would reduce the utility of the textbook exercise... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494240&group_id=5470 From noreply@sourceforge.net Mon Dec 17 17:00:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 09:00:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-493252 ] maximum recursion limit exceeded in match Message-ID: Bugs item #493252, was opened at 2001-12-14 02:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: P. de Jong (peterdejong) Assigned to: Fredrik Lundh (effbot) Summary: maximum recursion limit exceeded in match Initial Comment: RuntimeError: maximum recursion limit exceeded in match, while trying to match a string of 16384 bytes. (Python 2.0) The error does not occur after eliminating some 100 characters from the string. The error does not occur in Python 1.5.2. So I cannot upgrade. Peter de Jong ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 09:00 Message: Logged In: YES user_id=6380 I don't think that would make a difference. I don't understand SRE enough to know where the recursion cascade comes from; maybe Tim or Fredrik can explain? I believe it has something to do with an unexpected behavior of the *? operator. Note that it's a well-known theoretical result that parsing ambiguous languages can be O(n**3), so you might want to rethink this decision. ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-17 08:47 Message: Logged In: YES user_id=402001 Guido, Indeed. in many cases my language is ambious. I will try your solution. It is not clear to me what induces the recursion; Maybe something like '(?s)"(.*?)(";|"\n)' will not give the recursion cascade? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 06:08 Message: Logged In: YES user_id=6380 Peter, if the internal quotes are doubled, try this: r'"([^"]|"")*"[;\n]' if you can't trust them to be doubled, you're in trouble -- your language is ambiguous. :-( ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-17 01:02 Message: Logged In: YES user_id=402001 Tim and Guido, I want to match things like: "jlkjkl ""kjlklkjkl""ljk ;lkk;l"; or: "jlkjkl ""kjlklkjkl""ljk ;lkk;l" Maybe I can trust the embedded quotes to be doubled, but I was not sure at the moment of writing the expression. I do have to include newlines inside the enclosing quotes. Peter de Jong ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 20:34 Message: Logged In: YES user_id=31435 Oops! I used to make the same mistake in Perl too (which is I pushed to name the symbolic flag DOTALL instead of SINGLELINE). So the correct regexp is r'"[^"]*"[;\n]' Assuming, of course, that Peter does want embedded newlines to get sucked up. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:30 Message: Logged In: YES user_id=6380 Tim, Peter's regex starts with (?s) which is the same as compiling with re.S or re.DOTALL which makes '.' match newline -- the opposite of what you seem to think (?s) means. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 11:08 Message: Logged In: YES user_id=31435 Peter, assuming Guido is correct that you did not intend to match strings with embedded double quotes, here's a correct (and much more efficient) replacement for your regexp: r'"[^"\n]*"[;\n]' Note that (contra Guido's suggestion ), a newline has to be part of the negated character class, because you asked for single-line mode so presumably didn't want your .*? to match any newlines either. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:03 Message: Logged In: YES user_id=6380 Do you really *want* that pattern to match input like this: "xxx"xxx"; ??? If not, replace the (.*?) with ([^"]*) -- this will dramatically reduce the amount of backtracking generated if there are unbalanced quotes in the input. ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-15 05:23 Message: Logged In: YES user_id=402001 Hi Guido! The regular expression used was: '(?s)"(.*?)"(;|\n)' Peter ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-12-14 08:32 Message: Logged In: YES user_id=38376 Three additional comments: 1) The fact that you get this under 2.0 indicates that your regular expression doesn't run very well under 1.5.2 either; it can most likely be rewritten to be much faster, and use much less memory. 2) But if that's okay, you can always work around this by replacing "import re" with "import pre as re" (or "import pre; re = pre") 3) This will be fixed in future versions. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-14 07:57 Message: Logged In: YES user_id=31435 Assigned to /F. Echo Guido's belief that the regexp can almost certainly be rewritten to avoid this and run much faster at the same time. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 05:53 Message: Logged In: YES user_id=6380 Hi Peter! This usually happens when the pattern contains * or + in a way that causes more backtracking than one would naively expect. Can you show us the pattern? There's usually an easy way to rewrite the pattern so that it won't overflow -- and it will be faster too... BTW I would upgrade to Python 2.1.1 -- that's the most stable release to date. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 From noreply@sourceforge.net Mon Dec 17 17:06:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 09:06:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-494203 ] Interpreter won't always exit with daemonic thread Message-ID: Bugs item #494203, was opened at 2001-12-17 06:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494203&group_id=5470 Category: Threads Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Morten W. Petersen (morphex) Assigned to: Nobody/Anonymous (nobody) Summary: Interpreter won't always exit with daemonic thread Initial Comment: See file. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 09:06 Message: Logged In: YES user_id=6380 gdb? ---------------------------------------------------------------------- Comment By: Morten W. Petersen (morphex) Date: 2001-12-17 08:57 Message: Logged In: YES user_id=68005 I can't interpret it either. :-) Is there another way to to provide debugging information ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 08:48 Message: Logged In: YES user_id=6380 Sorry, I don't know how to interpret the trace. Someone else, please? ---------------------------------------------------------------------- Comment By: Morten W. Petersen (morphex) Date: 2001-12-17 08:42 Message: Logged In: YES user_id=68005 I'm attaching a trace.. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 08:33 Message: Logged In: YES user_id=6380 I dunno. They're likely to shoot back to Python. Can you do some more digging (e.g. what is the program doing when it's hanging)? ---------------------------------------------------------------------- Comment By: Morten W. Petersen (morphex) Date: 2001-12-17 08:21 Message: Logged In: YES user_id=68005 Ok, the system I'm using is: morten@debian$ python Python 2.1.1 (#1, Nov 11 2001, 18:19:24) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> morten@debian$ uname -a Linux debian 2.4.14 #1 SMP Mon Dec 10 20:40:22 CET 2001 i686 unknown With a customized kernel. Should I contact the Debian maintainers ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 07:58 Message: Logged In: YES user_id=6380 I can't reproduce this on Red Hat 6.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494203&group_id=5470 From noreply@sourceforge.net Mon Dec 17 17:37:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 09:37:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-493837 ] Distutils not finding Python on Win2K Message-ID: Bugs item #493837, was opened at 2001-12-16 00:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493837&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Thomas Heller (theller) Summary: Distutils not finding Python on Win2K Initial Comment: Thomas (or anyone else), can you help this fellow who posted to the Tutor list? If there's a systematic problem here with 2.2c1, we've only got a window of a few days to fix it. """ From: tutor-admin@python.org [mailto:tutor- admin@python.org]On Behalf Of Quniceleaf Listservs Sent: Sunday, December 16, 2001 2:02 AM To: tutor@python.org Subject: [Tutor] Python not being found in the registry? I'm using Python 2.2c1 on a Win2K machine. I've repeatedly tried installing two Python addons from different sources (XIST and the MySQL-interface) that each use a Windows installer program based on distutils-1.0.2pre. Both need to locate the Python installation before proceeding with the setup, and will not allow the user to browse and specify the location themselves. Unfortunately, neither can ever find a Python installation, and thus will not install. I've tried this repeatedly with Python 2.1, 2.2b, 2.2c1, and with ActiveState's distribution. In each case the installation is reflected in the Windows registry, but only the ActiveState install appears in the setup (and due to instability issues I am sticking with the standard distribution). Has anyone else encountered this problem? - Brian """ Unfortunately, the Tutor list reports his email address as listservb@quinceleaf.com, which doesn't seem reasonable. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-17 09:37 Message: Logged In: YES user_id=31435 Thanks, guys -- I think you've explained it. Feel free to close this if you can't think of anything else to do -- I don't have a way to contact the OP. PythonLabs installers previous to 2.2 used a much older version of Wise (dating back to when Win95 was brand new), and there are many problems with Win2K installs, esp. under non-Admin accounts; I've seen the bogus "corrupt installation" msg myself. Nothing we can do about it, alas. The 2.2 installer uses an up-to-date Wise, and the install script was extensively reworked to support non-Admin installs on Win2K; and you can use the "advanced options" screen in the 2.2 installer to select a non-Admin install even if you are an Admin (then it writes under HKCU instead of HKLM, and stores DLLs in the Python root instead of in the system dir). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-17 02:44 Message: Logged In: YES user_id=11105 I think MAL is right: It seems Brian is trying to install XIST and MySQL, which are built for Python2.1 (only), and the installer does not show (for purpose) the 2.2 installation. Probably the installer should display a clear message to the user if there are other Python versions not matching the requirements for the package to install. (But maybe also the packagers of packages should clearly indicate that this is build for a certain Python version?) The only other possibility could be that the bdist_wininst installer does not work correctly if the registry entries are under HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE. The code is there - but how can I test it. Tried to install python2.1.1 when using the Guest account (Win2k, SP2), but all I get is 'corrupt installation detected'. Is this a known problem? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 01:28 Message: Logged In: YES user_id=38388 One problem could be that Brian is trying to install a binary for a non-installed Python version on the machine. In that case, the installer does not display any entries in the Python directory selection box. Another possibility is fixing the binaries to use the latest distutils version available. Thomas Heller made some changes which solved a few problems in distutils 1.0.3 AFAIR. As a test I'd suggest to install egenix-mx-base on the machine and see what you get (the installer for that package was built using distutils 2.0.3). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493837&group_id=5470 From noreply@sourceforge.net Mon Dec 17 17:38:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 09:38:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-483982 ] Python 2.2b2 bdist_wininst crashes Message-ID: Bugs item #483982, was opened at 2001-11-20 15:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=483982&group_id=5470 >Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: Tarn Weisner Burton (twburton) >Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.2b2 bdist_wininst crashes Initial Comment: The executable created by Python 2.2b2 bdist_wininst crashes on my system. Python 2.1's version works fine. This could just be my system and I can recompile the installer to test that, if that's needed, but after I looked into CVS I noted that it looks like wininst.exe has been checked in as a text file....hmmm I've attached a minimal dist which exhibits to problem. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2001-12-17 09:38 Message: Logged In: YES user_id=11105 Moved from patches to bugs. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-17 09:31 Message: Logged In: YES user_id=11105 Raised priority to 7 because this MUST be fixed before release (see PEP3). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-17 08:55 Message: Logged In: YES user_id=11105 Tarn, good work! I can now reproduce your problem here: It only appears when _no_ external zip.exe program is found somewhere on the PATH. In this case Python's zipfile.py is used, and this indeed creates an entry foo-1.0.win32.zip, leading to the crash. This entry is not present when an zip.exe is used. I will work on this. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-12-10 07:37 Message: Logged In: YES user_id=21784 This fails on the first file lookup. I agree that it shouldn't but you can see the file that it is failing on by looking in the Python root. In the case of a installer called "foo-1.0.win32-py2.2.exe" the first file appears to be "foo-1.0.win32.zip" which looks like the archive name. An empty file of this name also gets created by the installer. I don't know if this is a normal part of a zip file. If it is then adding if (n==0) continue; before line 228 which is pcomp = &data[pcdir->ofs_local_header will fix it. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-10 02:29 Message: Logged In: YES user_id=11105 Tarn, this is really a problem. Thanks for finding it. I still wonder how this bug lead to a crash. Usually the for-loop doesn't run up to beyond the end of the list, because the prefix *should* always be found. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-12-08 18:42 Message: Logged In: YES user_id=21784 Looks like I've found the problem: line 244 in misc/extract.c is currently this: for (i = 0; *scheme[i].name; ++i) { The scheme list is terminated by a NULL, so *NULL causes an exception at the end of the list. Instead this should be: for (i = 0; scheme[i].name; ++i) { ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-12-06 12:55 Message: Logged In: YES user_id=11375 Reassigning to Thomas Heller; I know nothing about bdist_wininst. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-11-21 16:16 Message: Logged In: YES user_id=21784 Looks like I put this under Patches instead of Bugs. Sorry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=483982&group_id=5470 From noreply@sourceforge.net Mon Dec 17 17:42:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 09:42:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-483982 ] Python 2.2b2 bdist_wininst crashes Message-ID: Bugs item #483982, was opened at 2001-11-20 15:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=483982&group_id=5470 >Category: Distutils Group: None Status: Open Resolution: None Priority: 7 Submitted By: Tarn Weisner Burton (twburton) >Assigned to: Thomas Heller (theller) Summary: Python 2.2b2 bdist_wininst crashes Initial Comment: The executable created by Python 2.2b2 bdist_wininst crashes on my system. Python 2.1's version works fine. This could just be my system and I can recompile the installer to test that, if that's needed, but after I looked into CVS I noted that it looks like wininst.exe has been checked in as a text file....hmmm I've attached a minimal dist which exhibits to problem. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2001-12-17 09:42 Message: Logged In: YES user_id=11105 It seems all fields have to be updated after moving this... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-17 09:38 Message: Logged In: YES user_id=11105 Moved from patches to bugs. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-17 09:31 Message: Logged In: YES user_id=11105 Raised priority to 7 because this MUST be fixed before release (see PEP3). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-17 08:55 Message: Logged In: YES user_id=11105 Tarn, good work! I can now reproduce your problem here: It only appears when _no_ external zip.exe program is found somewhere on the PATH. In this case Python's zipfile.py is used, and this indeed creates an entry foo-1.0.win32.zip, leading to the crash. This entry is not present when an zip.exe is used. I will work on this. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-12-10 07:37 Message: Logged In: YES user_id=21784 This fails on the first file lookup. I agree that it shouldn't but you can see the file that it is failing on by looking in the Python root. In the case of a installer called "foo-1.0.win32-py2.2.exe" the first file appears to be "foo-1.0.win32.zip" which looks like the archive name. An empty file of this name also gets created by the installer. I don't know if this is a normal part of a zip file. If it is then adding if (n==0) continue; before line 228 which is pcomp = &data[pcdir->ofs_local_header will fix it. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-10 02:29 Message: Logged In: YES user_id=11105 Tarn, this is really a problem. Thanks for finding it. I still wonder how this bug lead to a crash. Usually the for-loop doesn't run up to beyond the end of the list, because the prefix *should* always be found. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-12-08 18:42 Message: Logged In: YES user_id=21784 Looks like I've found the problem: line 244 in misc/extract.c is currently this: for (i = 0; *scheme[i].name; ++i) { The scheme list is terminated by a NULL, so *NULL causes an exception at the end of the list. Instead this should be: for (i = 0; scheme[i].name; ++i) { ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-12-06 12:55 Message: Logged In: YES user_id=11375 Reassigning to Thomas Heller; I know nothing about bdist_wininst. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-11-21 16:16 Message: Logged In: YES user_id=21784 Looks like I put this under Patches instead of Bugs. Sorry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=483982&group_id=5470 From noreply@sourceforge.net Mon Dec 17 18:15:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 10:15:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-493252 ] maximum recursion limit exceeded in match Message-ID: Bugs item #493252, was opened at 2001-12-14 02:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: P. de Jong (peterdejong) Assigned to: Fredrik Lundh (effbot) Summary: maximum recursion limit exceeded in match Initial Comment: RuntimeError: maximum recursion limit exceeded in match, while trying to match a string of 16384 bytes. (Python 2.0) The error does not occur after eliminating some 100 characters from the string. The error does not occur in Python 1.5.2. So I cannot upgrade. Peter de Jong ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-17 10:15 Message: Logged In: YES user_id=31435 I'm afraid Guido's rewrite stacks a backtracking point for each character, so it can still die on strings of the length you're looking at. For example, here's a ~16KB string that kills it on Windows: test = '"' + ('a' * 128 + '""') * 128 + '";' The only info I know of on how to write robust regexps is in Friedl's "Mastering Regular Expressions" book, which does an excellent job. Using his "unrolling" pattern leads to the regexp r'"[^"]*(""[^"]*)*"[;\n]' which is an instance of the general normal* (special normal*)* pattern, and reduces the number of stacked backtracking points from the number of characters in the string to the number of special strings within it (given various preconditions that happen to be satisfied here -- you really need to read the book, as it resists a pithy summary). That works fine with the test string above, and even if you change it to test = '"' + ('a' * 5000 + '""') * 5000 + '";' At that point you're matching a 25MB string, which should be big enough for most web use . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 09:00 Message: Logged In: YES user_id=6380 I don't think that would make a difference. I don't understand SRE enough to know where the recursion cascade comes from; maybe Tim or Fredrik can explain? I believe it has something to do with an unexpected behavior of the *? operator. Note that it's a well-known theoretical result that parsing ambiguous languages can be O(n**3), so you might want to rethink this decision. ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-17 08:47 Message: Logged In: YES user_id=402001 Guido, Indeed. in many cases my language is ambious. I will try your solution. It is not clear to me what induces the recursion; Maybe something like '(?s)"(.*?)(";|"\n)' will not give the recursion cascade? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 06:08 Message: Logged In: YES user_id=6380 Peter, if the internal quotes are doubled, try this: r'"([^"]|"")*"[;\n]' if you can't trust them to be doubled, you're in trouble -- your language is ambiguous. :-( ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-17 01:02 Message: Logged In: YES user_id=402001 Tim and Guido, I want to match things like: "jlkjkl ""kjlklkjkl""ljk ;lkk;l"; or: "jlkjkl ""kjlklkjkl""ljk ;lkk;l" Maybe I can trust the embedded quotes to be doubled, but I was not sure at the moment of writing the expression. I do have to include newlines inside the enclosing quotes. Peter de Jong ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 20:34 Message: Logged In: YES user_id=31435 Oops! I used to make the same mistake in Perl too (which is I pushed to name the symbolic flag DOTALL instead of SINGLELINE). So the correct regexp is r'"[^"]*"[;\n]' Assuming, of course, that Peter does want embedded newlines to get sucked up. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:30 Message: Logged In: YES user_id=6380 Tim, Peter's regex starts with (?s) which is the same as compiling with re.S or re.DOTALL which makes '.' match newline -- the opposite of what you seem to think (?s) means. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 11:08 Message: Logged In: YES user_id=31435 Peter, assuming Guido is correct that you did not intend to match strings with embedded double quotes, here's a correct (and much more efficient) replacement for your regexp: r'"[^"\n]*"[;\n]' Note that (contra Guido's suggestion ), a newline has to be part of the negated character class, because you asked for single-line mode so presumably didn't want your .*? to match any newlines either. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:03 Message: Logged In: YES user_id=6380 Do you really *want* that pattern to match input like this: "xxx"xxx"; ??? If not, replace the (.*?) with ([^"]*) -- this will dramatically reduce the amount of backtracking generated if there are unbalanced quotes in the input. ---------------------------------------------------------------------- Comment By: P. de Jong (peterdejong) Date: 2001-12-15 05:23 Message: Logged In: YES user_id=402001 Hi Guido! The regular expression used was: '(?s)"(.*?)"(;|\n)' Peter ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-12-14 08:32 Message: Logged In: YES user_id=38376 Three additional comments: 1) The fact that you get this under 2.0 indicates that your regular expression doesn't run very well under 1.5.2 either; it can most likely be rewritten to be much faster, and use much less memory. 2) But if that's okay, you can always work around this by replacing "import re" with "import pre as re" (or "import pre; re = pre") 3) This will be fixed in future versions. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-14 07:57 Message: Logged In: YES user_id=31435 Assigned to /F. Echo Guido's belief that the regexp can almost certainly be rewritten to avoid this and run much faster at the same time. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-14 05:53 Message: Logged In: YES user_id=6380 Hi Peter! This usually happens when the pattern contains * or + in a way that causes more backtracking than one would naively expect. Can you show us the pattern? There's usually an easy way to rewrite the pattern so that it won't overflow -- and it will be faster too... BTW I would upgrade to Python 2.1.1 -- that's the most stable release to date. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493252&group_id=5470 From noreply@sourceforge.net Mon Dec 17 21:02:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 13:02:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-494320 ] Memory leaks in 2.2c1? Message-ID: Bugs item #494320, was opened at 2001-12-17 13:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Escoto (bescoto) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leaks in 2.2c1? Initial Comment: Sorry, this won't be a very good bug report, but perhaps you can tell me how to make it better. I wrote a little python project (rdiff-backup at http://www.stanford.edu/~bescoto/rdiff-backup). On my computer it takes up about 7MB of memory even for large datasets, but several users have complained that it takes up so much memory on their systems (hundreds of MB) it is totally unusable. I suspect the problem is a memory leak in Python, but the only way I know of isolating the problem is pretty long, and none of the users affected know Python. I can't have them try an earlier version because the program depends on generators extensively. So, any advice? Do you think the problem could be in python? How could I go about trying to replicate this error? Of course, if I end up finding it is python, I'll try to submit a code snippet short enough to be helpful to you guys... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 From noreply@sourceforge.net Mon Dec 17 21:17:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 13:17:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-494320 ] Memory leaks in 2.2c1? Message-ID: Bugs item #494320, was opened at 2001-12-17 13:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Escoto (bescoto) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leaks in 2.2c1? Initial Comment: Sorry, this won't be a very good bug report, but perhaps you can tell me how to make it better. I wrote a little python project (rdiff-backup at http://www.stanford.edu/~bescoto/rdiff-backup). On my computer it takes up about 7MB of memory even for large datasets, but several users have complained that it takes up so much memory on their systems (hundreds of MB) it is totally unusable. I suspect the problem is a memory leak in Python, but the only way I know of isolating the problem is pretty long, and none of the users affected know Python. I can't have them try an earlier version because the program depends on generators extensively. So, any advice? Do you think the problem could be in python? How could I go about trying to replicate this error? Of course, if I end up finding it is python, I'll try to submit a code snippet short enough to be helpful to you guys... ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 13:17 Message: Logged In: YES user_id=38388 Since you are using * nested scopes * static methods and * generators I'd suggest to first try to find the group of features that's causing the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 From noreply@sourceforge.net Mon Dec 17 21:22:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 13:22:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-494320 ] Memory leaks in 2.2c1? Message-ID: Bugs item #494320, was opened at 2001-12-17 13:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Escoto (bescoto) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leaks in 2.2c1? Initial Comment: Sorry, this won't be a very good bug report, but perhaps you can tell me how to make it better. I wrote a little python project (rdiff-backup at http://www.stanford.edu/~bescoto/rdiff-backup). On my computer it takes up about 7MB of memory even for large datasets, but several users have complained that it takes up so much memory on their systems (hundreds of MB) it is totally unusable. I suspect the problem is a memory leak in Python, but the only way I know of isolating the problem is pretty long, and none of the users affected know Python. I can't have them try an earlier version because the program depends on generators extensively. So, any advice? Do you think the problem could be in python? How could I go about trying to replicate this error? Of course, if I end up finding it is python, I'll try to submit a code snippet short enough to be helpful to you guys... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 13:22 Message: Logged In: YES user_id=6380 Surely it could be Python. You're using all the latest features (nested scopes and generators, class and static methods, ...). We're not *aware* of current leaks (we stamped out a bunch a couple of weeks ago) but there probably are some. It's also possible that you are creating cycles that the garbage collector doesn't find (they would have to involve types that don't support GC; fortunately you don't use __del__ or __slots__). Are you sure they aren't using it with previous 2.2 beta versions? Some of the plugged leaks were pretty severe. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 13:17 Message: Logged In: YES user_id=38388 Since you are using * nested scopes * static methods and * generators I'd suggest to first try to find the group of features that's causing the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 From noreply@sourceforge.net Mon Dec 17 21:30:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 13:30:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-494320 ] Memory leaks in 2.2c1? Message-ID: Bugs item #494320, was opened at 2001-12-17 13:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Escoto (bescoto) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leaks in 2.2c1? Initial Comment: Sorry, this won't be a very good bug report, but perhaps you can tell me how to make it better. I wrote a little python project (rdiff-backup at http://www.stanford.edu/~bescoto/rdiff-backup). On my computer it takes up about 7MB of memory even for large datasets, but several users have complained that it takes up so much memory on their systems (hundreds of MB) it is totally unusable. I suspect the problem is a memory leak in Python, but the only way I know of isolating the problem is pretty long, and none of the users affected know Python. I can't have them try an earlier version because the program depends on generators extensively. So, any advice? Do you think the problem could be in python? How could I go about trying to replicate this error? Of course, if I end up finding it is python, I'll try to submit a code snippet short enough to be helpful to you guys... ---------------------------------------------------------------------- >Comment By: Ben Escoto (bescoto) Date: 2001-12-17 13:30 Message: Logged In: YES user_id=218965 I had been following some of the memory leak bugs, and had hoped that an upgrade to 2.2c1 would fix things. But I asked the affected users to upgrade, and at least one of them claims to have the same error with 2.2c1 (others haven't tried upgrading yet). I might be able to get more information out of them, but only if the procedure is relatively painless.. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 13:22 Message: Logged In: YES user_id=6380 Surely it could be Python. You're using all the latest features (nested scopes and generators, class and static methods, ...). We're not *aware* of current leaks (we stamped out a bunch a couple of weeks ago) but there probably are some. It's also possible that you are creating cycles that the garbage collector doesn't find (they would have to involve types that don't support GC; fortunately you don't use __del__ or __slots__). Are you sure they aren't using it with previous 2.2 beta versions? Some of the plugged leaks were pretty severe. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 13:17 Message: Logged In: YES user_id=38388 Since you are using * nested scopes * static methods and * generators I'd suggest to first try to find the group of features that's causing the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 From noreply@sourceforge.net Mon Dec 17 21:58:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 13:58:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-494320 ] Memory leaks in 2.2c1? Message-ID: Bugs item #494320, was opened at 2001-12-17 13:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Escoto (bescoto) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leaks in 2.2c1? Initial Comment: Sorry, this won't be a very good bug report, but perhaps you can tell me how to make it better. I wrote a little python project (rdiff-backup at http://www.stanford.edu/~bescoto/rdiff-backup). On my computer it takes up about 7MB of memory even for large datasets, but several users have complained that it takes up so much memory on their systems (hundreds of MB) it is totally unusable. I suspect the problem is a memory leak in Python, but the only way I know of isolating the problem is pretty long, and none of the users affected know Python. I can't have them try an earlier version because the program depends on generators extensively. So, any advice? Do you think the problem could be in python? How could I go about trying to replicate this error? Of course, if I end up finding it is python, I'll try to submit a code snippet short enough to be helpful to you guys... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 13:58 Message: Logged In: YES user_id=6380 Typically, the way to squash a leak is: 1. get a reproducible test case that grows unbounded when watched with "top" 2. try to whittle the test case down to something really simple by removing code until it no longer leaks (and then going back to the previous version :-) 3. show the test case to an expert who will make an educated guess at where in the C code to look Can you do this? ---------------------------------------------------------------------- Comment By: Ben Escoto (bescoto) Date: 2001-12-17 13:30 Message: Logged In: YES user_id=218965 I had been following some of the memory leak bugs, and had hoped that an upgrade to 2.2c1 would fix things. But I asked the affected users to upgrade, and at least one of them claims to have the same error with 2.2c1 (others haven't tried upgrading yet). I might be able to get more information out of them, but only if the procedure is relatively painless.. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 13:22 Message: Logged In: YES user_id=6380 Surely it could be Python. You're using all the latest features (nested scopes and generators, class and static methods, ...). We're not *aware* of current leaks (we stamped out a bunch a couple of weeks ago) but there probably are some. It's also possible that you are creating cycles that the garbage collector doesn't find (they would have to involve types that don't support GC; fortunately you don't use __del__ or __slots__). Are you sure they aren't using it with previous 2.2 beta versions? Some of the plugged leaks were pretty severe. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 13:17 Message: Logged In: YES user_id=38388 Since you are using * nested scopes * static methods and * generators I'd suggest to first try to find the group of features that's causing the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 From noreply@sourceforge.net Mon Dec 17 22:01:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 14:01:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-494320 ] Memory leaks in 2.2c1? Message-ID: Bugs item #494320, was opened at 2001-12-17 13:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Escoto (bescoto) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leaks in 2.2c1? Initial Comment: Sorry, this won't be a very good bug report, but perhaps you can tell me how to make it better. I wrote a little python project (rdiff-backup at http://www.stanford.edu/~bescoto/rdiff-backup). On my computer it takes up about 7MB of memory even for large datasets, but several users have complained that it takes up so much memory on their systems (hundreds of MB) it is totally unusable. I suspect the problem is a memory leak in Python, but the only way I know of isolating the problem is pretty long, and none of the users affected know Python. I can't have them try an earlier version because the program depends on generators extensively. So, any advice? Do you think the problem could be in python? How could I go about trying to replicate this error? Of course, if I end up finding it is python, I'll try to submit a code snippet short enough to be helpful to you guys... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:01 Message: Logged In: YES user_id=6380 (I meant, I'll be the expert, and if it doesn't require me to load countless megabytes of data I'll even do step 2, but I need you to perform step 1, and I could use help with step 2.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 13:58 Message: Logged In: YES user_id=6380 Typically, the way to squash a leak is: 1. get a reproducible test case that grows unbounded when watched with "top" 2. try to whittle the test case down to something really simple by removing code until it no longer leaks (and then going back to the previous version :-) 3. show the test case to an expert who will make an educated guess at where in the C code to look Can you do this? ---------------------------------------------------------------------- Comment By: Ben Escoto (bescoto) Date: 2001-12-17 13:30 Message: Logged In: YES user_id=218965 I had been following some of the memory leak bugs, and had hoped that an upgrade to 2.2c1 would fix things. But I asked the affected users to upgrade, and at least one of them claims to have the same error with 2.2c1 (others haven't tried upgrading yet). I might be able to get more information out of them, but only if the procedure is relatively painless.. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 13:22 Message: Logged In: YES user_id=6380 Surely it could be Python. You're using all the latest features (nested scopes and generators, class and static methods, ...). We're not *aware* of current leaks (we stamped out a bunch a couple of weeks ago) but there probably are some. It's also possible that you are creating cycles that the garbage collector doesn't find (they would have to involve types that don't support GC; fortunately you don't use __del__ or __slots__). Are you sure they aren't using it with previous 2.2 beta versions? Some of the plugged leaks were pretty severe. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 13:17 Message: Logged In: YES user_id=38388 Since you are using * nested scopes * static methods and * generators I'd suggest to first try to find the group of features that's causing the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 From noreply@sourceforge.net Mon Dec 17 22:07:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 14:07:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:07 Message: Logged In: YES user_id=85984 Your prediction is correct: [root@nightshade Python-2.1.1]# ./python df Python 2.1.1 (#1, Dec 17 2001, 15:01:24) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 21:13 Message: Logged In: YES user_id=6380 Add these three lines to Py_Main() in Modules/main.c, after the line saying "PyCompilerFlags cf;": char buffer[120]; sprintf(buffer, "%.1lx", 223L); printf("%s\n", buffer); and rebuild Python. When you run Python, it should print "df" before the standard banner. If it crashes, we've proved that Python is not the cause of the problem. But I predict that it'll work. :-( ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 21:01 Message: Logged In: YES user_id=85984 As far as the standalone program, I'm not a C programmer, (I've become Python-dependent :-), but if you can give me an idea of what it should contain, I'll give it a try. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 20:23 Message: Logged In: YES user_id=6380 Sigh. I think it's a dead end. What about a stand-alone program? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 19:09 Message: Logged In: YES user_id=85984 Tim asked whather I can verify whether I'm mixing the threaded and non-threaded versions of libc. Is the following enough to tell? $ ldd /usr/local/src/Python-2.1.1/python /usr/local/src/Python-2.1.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x280ca000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28182000) libm.so.2 => /usr/lib/libm.so.2 (0x2818b000) libc.so.4 => /usr/lib/libc.so.4 (0x281a7000) libc is the non-threaded library, and libc_r is the threaded version, so it looks like they are being mixed, yes? However, my Python 2.0.1 also looks the same way, and I'm not having any problems with it. $ ldd /usr/local/src/Python-2.0.1/python /usr/local/src/Python-2.0.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x2816c000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28224000) libm.so.2 => /usr/lib/libm.so.2 (0x2822d000) libc.so.4 => /usr/lib/libc.so.4 (0x28249000) Next, Guido asked me to check some local variables in that stack frame. See attached backtrace3.txt. And to answer your question, yes I built all the Python versions I'm testing myself. I even rebuilt 2.0.1 and 2.1.1 in the simplest manner to make sure I'm comparing them equally. (Just ./configure && make). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:47 Message: Logged In: YES user_id=31435 BTW, a google search on _thread_autoinit_dummy_decl turns up another FreeBSD bug report of a death deep in libc_r starting with a sprintf() call. It had to do with mysql, not with Python. The tracebacks in both cases look worthless to me, because (for example) _thread_autoinit_dummy_decl is an extern int in the FreeBSD source, not a function at all. This increases the suspicion that libc versions are getting mixed up (and that gdb is looking up addresses in "the wrong" libc). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 17:20 Message: Logged In: YES user_id=6380 OK, it's the second sprintf call in formatint. Can you check some local variables in that stack frame? I expect fmt to be "%.1lx", but would like to see that confirmed; x should be one of the values from your binary string: 206, 199, 166. Can you see which one? It would then be interesting to find out what a small C program with that same sprintf() does. Make sure that the C program is compiled and linked in exactly the same way as python. (What I do in such cases is I put the experimental statement in Python's main() and rebuild Python. :-) The build procedure of each Python version is somewhat different, and it's likely that each version picks slightly different compile/link options. Also, did you build all the Python versions you tried yourself? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:17 Message: Logged In: YES user_id=31435 The new backtrace is helpful (thanks!), but it just makes it harder to believe that Python is at fault. The segfault occurs four levels deep in system library functions, and from inspection there's nothing even remotely suspicious about the sprintf call that kicks it off. As Guido suggested, can you verify you're not mixing the threaded and non-threaded versions of libc? Short of that, you really need a FreeBSD libc author to help with this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 15:26 Message: Logged In: YES user_id=85984 Alright, I rebuilt Python 2.1.1 with -g, so the gdb backtrace now contains some more information. I attached backtrace2.txt which is a backtrace of the program failing when calling the hexlify() function. I tried compiling with `--with-pydebug', but then I can't reproduce the core dump for some reason. As you mention, this could have something to do with FreeBSD's libc. However, does that explain why I only have this problem with 2.1.1? On the same system, Python 1.5.2, 2.0, and 2.2c1 compiled in the same manner (simply ./configure && gmake) don't produce a core dump. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=6380 See the repeated "(no debugging symbols found)..." in the gdb output? try recompiling with -g. I strongly suspect that the traceback is lying, and we're in fact not in PyString_AsStringAndSize() when we call sprintf -- there's no sprintf call in that function (I checked the 2.1.1 source) but there is one two static functions down, in string_repr(), which is indeed called when you pickle a string object. This would match the original gdb stacktrace you reported: there's no sprintf call in _PyString_FormatLong(), but there are two in the next static function, formatint(), and it does make sense that that function would be called by the %02x format. All this makes no sense, however, because I can see nothing wrong with the arguments to sprintf here! I've heard of problems on FreeBSD having to do with different (threaded and unthreaded?) versions of libc. Could that be the issue here? Can you rebuild Python 2.1.1 with debugg flags on? (./configure --with-pydebug should do it for 2.2; I don't recall if the 2.2.1 configure supports that though -- try --help first.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Mon Dec 17 22:08:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 14:08:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-494320 ] Memory leaks in 2.2c1? Message-ID: Bugs item #494320, was opened at 2001-12-17 13:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Escoto (bescoto) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leaks in 2.2c1? Initial Comment: Sorry, this won't be a very good bug report, but perhaps you can tell me how to make it better. I wrote a little python project (rdiff-backup at http://www.stanford.edu/~bescoto/rdiff-backup). On my computer it takes up about 7MB of memory even for large datasets, but several users have complained that it takes up so much memory on their systems (hundreds of MB) it is totally unusable. I suspect the problem is a memory leak in Python, but the only way I know of isolating the problem is pretty long, and none of the users affected know Python. I can't have them try an earlier version because the program depends on generators extensively. So, any advice? Do you think the problem could be in python? How could I go about trying to replicate this error? Of course, if I end up finding it is python, I'll try to submit a code snippet short enough to be helpful to you guys... ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-17 14:08 Message: Logged In: YES user_id=31435 I can't recall a case where a Python leak occurred on only some systems. Leaks are deterministic bugs: each time a leaking program is run, it generally leaks exactly the same amounts at exactly the same times. So what's different between your system and your users'? Presumably the inputs, i.e. the data getting backed up. Do you have data-dependent paths in your Python code that may not get executed on your system with your data, but would on others'? It's also possible that programs you're calling suffer data-dependent memory growth. Until you can reproduce a problem yourself, there's not much hope. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:01 Message: Logged In: YES user_id=6380 (I meant, I'll be the expert, and if it doesn't require me to load countless megabytes of data I'll even do step 2, but I need you to perform step 1, and I could use help with step 2.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 13:58 Message: Logged In: YES user_id=6380 Typically, the way to squash a leak is: 1. get a reproducible test case that grows unbounded when watched with "top" 2. try to whittle the test case down to something really simple by removing code until it no longer leaks (and then going back to the previous version :-) 3. show the test case to an expert who will make an educated guess at where in the C code to look Can you do this? ---------------------------------------------------------------------- Comment By: Ben Escoto (bescoto) Date: 2001-12-17 13:30 Message: Logged In: YES user_id=218965 I had been following some of the memory leak bugs, and had hoped that an upgrade to 2.2c1 would fix things. But I asked the affected users to upgrade, and at least one of them claims to have the same error with 2.2c1 (others haven't tried upgrading yet). I might be able to get more information out of them, but only if the procedure is relatively painless.. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 13:22 Message: Logged In: YES user_id=6380 Surely it could be Python. You're using all the latest features (nested scopes and generators, class and static methods, ...). We're not *aware* of current leaks (we stamped out a bunch a couple of weeks ago) but there probably are some. It's also possible that you are creating cycles that the garbage collector doesn't find (they would have to involve types that don't support GC; fortunately you don't use __del__ or __slots__). Are you sure they aren't using it with previous 2.2 beta versions? Some of the plugged leaks were pretty severe. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 13:17 Message: Logged In: YES user_id=38388 Since you are using * nested scopes * static methods and * generators I'd suggest to first try to find the group of features that's causing the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 From noreply@sourceforge.net Mon Dec 17 22:09:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 14:09:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-494320 ] Memory leaks in 2.2c1? Message-ID: Bugs item #494320, was opened at 2001-12-17 13:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Escoto (bescoto) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leaks in 2.2c1? Initial Comment: Sorry, this won't be a very good bug report, but perhaps you can tell me how to make it better. I wrote a little python project (rdiff-backup at http://www.stanford.edu/~bescoto/rdiff-backup). On my computer it takes up about 7MB of memory even for large datasets, but several users have complained that it takes up so much memory on their systems (hundreds of MB) it is totally unusable. I suspect the problem is a memory leak in Python, but the only way I know of isolating the problem is pretty long, and none of the users affected know Python. I can't have them try an earlier version because the program depends on generators extensively. So, any advice? Do you think the problem could be in python? How could I go about trying to replicate this error? Of course, if I end up finding it is python, I'll try to submit a code snippet short enough to be helpful to you guys... ---------------------------------------------------------------------- >Comment By: Ben Escoto (bescoto) Date: 2001-12-17 14:09 Message: Logged In: YES user_id=218965 I'd be willing to do all this, but, as I mentioned initially, I'm not sure how to replicate the problem. The systems that leak all seem similar to mine (which doesn't leak). For instance, people running Suse Linux 7.3 and Debian unstable have complained, but I seem to be fine under Redhat 7.2 (7.1 was also ok). Should I ask them what versions of various libraries they are using, and then try to link python to those versions on my system? Which are the likely culprits? Or is this the wrong track altogether? (Sorry, I don't know enough about C/manual memory management to understand how/why the same code would leak on one system and not on another.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 14:08 Message: Logged In: YES user_id=31435 I can't recall a case where a Python leak occurred on only some systems. Leaks are deterministic bugs: each time a leaking program is run, it generally leaks exactly the same amounts at exactly the same times. So what's different between your system and your users'? Presumably the inputs, i.e. the data getting backed up. Do you have data-dependent paths in your Python code that may not get executed on your system with your data, but would on others'? It's also possible that programs you're calling suffer data-dependent memory growth. Until you can reproduce a problem yourself, there's not much hope. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:01 Message: Logged In: YES user_id=6380 (I meant, I'll be the expert, and if it doesn't require me to load countless megabytes of data I'll even do step 2, but I need you to perform step 1, and I could use help with step 2.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 13:58 Message: Logged In: YES user_id=6380 Typically, the way to squash a leak is: 1. get a reproducible test case that grows unbounded when watched with "top" 2. try to whittle the test case down to something really simple by removing code until it no longer leaks (and then going back to the previous version :-) 3. show the test case to an expert who will make an educated guess at where in the C code to look Can you do this? ---------------------------------------------------------------------- Comment By: Ben Escoto (bescoto) Date: 2001-12-17 13:30 Message: Logged In: YES user_id=218965 I had been following some of the memory leak bugs, and had hoped that an upgrade to 2.2c1 would fix things. But I asked the affected users to upgrade, and at least one of them claims to have the same error with 2.2c1 (others haven't tried upgrading yet). I might be able to get more information out of them, but only if the procedure is relatively painless.. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 13:22 Message: Logged In: YES user_id=6380 Surely it could be Python. You're using all the latest features (nested scopes and generators, class and static methods, ...). We're not *aware* of current leaks (we stamped out a bunch a couple of weeks ago) but there probably are some. It's also possible that you are creating cycles that the garbage collector doesn't find (they would have to involve types that don't support GC; fortunately you don't use __del__ or __slots__). Are you sure they aren't using it with previous 2.2 beta versions? Some of the plugged leaks were pretty severe. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 13:17 Message: Logged In: YES user_id=38388 Since you are using * nested scopes * static methods and * generators I'd suggest to first try to find the group of features that's causing the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 From noreply@sourceforge.net Mon Dec 17 22:10:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 14:10:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:10 Message: Logged In: YES user_id=6380 So do you want me to keep this open? I don't expect we'll find the answer. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:07 Message: Logged In: YES user_id=85984 Your prediction is correct: [root@nightshade Python-2.1.1]# ./python df Python 2.1.1 (#1, Dec 17 2001, 15:01:24) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 21:13 Message: Logged In: YES user_id=6380 Add these three lines to Py_Main() in Modules/main.c, after the line saying "PyCompilerFlags cf;": char buffer[120]; sprintf(buffer, "%.1lx", 223L); printf("%s\n", buffer); and rebuild Python. When you run Python, it should print "df" before the standard banner. If it crashes, we've proved that Python is not the cause of the problem. But I predict that it'll work. :-( ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 21:01 Message: Logged In: YES user_id=85984 As far as the standalone program, I'm not a C programmer, (I've become Python-dependent :-), but if you can give me an idea of what it should contain, I'll give it a try. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 20:23 Message: Logged In: YES user_id=6380 Sigh. I think it's a dead end. What about a stand-alone program? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 19:09 Message: Logged In: YES user_id=85984 Tim asked whather I can verify whether I'm mixing the threaded and non-threaded versions of libc. Is the following enough to tell? $ ldd /usr/local/src/Python-2.1.1/python /usr/local/src/Python-2.1.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x280ca000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28182000) libm.so.2 => /usr/lib/libm.so.2 (0x2818b000) libc.so.4 => /usr/lib/libc.so.4 (0x281a7000) libc is the non-threaded library, and libc_r is the threaded version, so it looks like they are being mixed, yes? However, my Python 2.0.1 also looks the same way, and I'm not having any problems with it. $ ldd /usr/local/src/Python-2.0.1/python /usr/local/src/Python-2.0.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x2816c000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28224000) libm.so.2 => /usr/lib/libm.so.2 (0x2822d000) libc.so.4 => /usr/lib/libc.so.4 (0x28249000) Next, Guido asked me to check some local variables in that stack frame. See attached backtrace3.txt. And to answer your question, yes I built all the Python versions I'm testing myself. I even rebuilt 2.0.1 and 2.1.1 in the simplest manner to make sure I'm comparing them equally. (Just ./configure && make). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:47 Message: Logged In: YES user_id=31435 BTW, a google search on _thread_autoinit_dummy_decl turns up another FreeBSD bug report of a death deep in libc_r starting with a sprintf() call. It had to do with mysql, not with Python. The tracebacks in both cases look worthless to me, because (for example) _thread_autoinit_dummy_decl is an extern int in the FreeBSD source, not a function at all. This increases the suspicion that libc versions are getting mixed up (and that gdb is looking up addresses in "the wrong" libc). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 17:20 Message: Logged In: YES user_id=6380 OK, it's the second sprintf call in formatint. Can you check some local variables in that stack frame? I expect fmt to be "%.1lx", but would like to see that confirmed; x should be one of the values from your binary string: 206, 199, 166. Can you see which one? It would then be interesting to find out what a small C program with that same sprintf() does. Make sure that the C program is compiled and linked in exactly the same way as python. (What I do in such cases is I put the experimental statement in Python's main() and rebuild Python. :-) The build procedure of each Python version is somewhat different, and it's likely that each version picks slightly different compile/link options. Also, did you build all the Python versions you tried yourself? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:17 Message: Logged In: YES user_id=31435 The new backtrace is helpful (thanks!), but it just makes it harder to believe that Python is at fault. The segfault occurs four levels deep in system library functions, and from inspection there's nothing even remotely suspicious about the sprintf call that kicks it off. As Guido suggested, can you verify you're not mixing the threaded and non-threaded versions of libc? Short of that, you really need a FreeBSD libc author to help with this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 15:26 Message: Logged In: YES user_id=85984 Alright, I rebuilt Python 2.1.1 with -g, so the gdb backtrace now contains some more information. I attached backtrace2.txt which is a backtrace of the program failing when calling the hexlify() function. I tried compiling with `--with-pydebug', but then I can't reproduce the core dump for some reason. As you mention, this could have something to do with FreeBSD's libc. However, does that explain why I only have this problem with 2.1.1? On the same system, Python 1.5.2, 2.0, and 2.2c1 compiled in the same manner (simply ./configure && gmake) don't produce a core dump. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=6380 See the repeated "(no debugging symbols found)..." in the gdb output? try recompiling with -g. I strongly suspect that the traceback is lying, and we're in fact not in PyString_AsStringAndSize() when we call sprintf -- there's no sprintf call in that function (I checked the 2.1.1 source) but there is one two static functions down, in string_repr(), which is indeed called when you pickle a string object. This would match the original gdb stacktrace you reported: there's no sprintf call in _PyString_FormatLong(), but there are two in the next static function, formatint(), and it does make sense that that function would be called by the %02x format. All this makes no sense, however, because I can see nothing wrong with the arguments to sprintf here! I've heard of problems on FreeBSD having to do with different (threaded and unthreaded?) versions of libc. Could that be the issue here? Can you rebuild Python 2.1.1 with debugg flags on? (./configure --with-pydebug should do it for 2.2; I don't recall if the 2.2.1 configure supports that though -- try --help first.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Mon Dec 17 22:12:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 14:12:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-494320 ] Memory leaks in 2.2c1? Message-ID: Bugs item #494320, was opened at 2001-12-17 13:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Escoto (bescoto) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leaks in 2.2c1? Initial Comment: Sorry, this won't be a very good bug report, but perhaps you can tell me how to make it better. I wrote a little python project (rdiff-backup at http://www.stanford.edu/~bescoto/rdiff-backup). On my computer it takes up about 7MB of memory even for large datasets, but several users have complained that it takes up so much memory on their systems (hundreds of MB) it is totally unusable. I suspect the problem is a memory leak in Python, but the only way I know of isolating the problem is pretty long, and none of the users affected know Python. I can't have them try an earlier version because the program depends on generators extensively. So, any advice? Do you think the problem could be in python? How could I go about trying to replicate this error? Of course, if I end up finding it is python, I'll try to submit a code snippet short enough to be helpful to you guys... ---------------------------------------------------------------------- >Comment By: Ben Escoto (bescoto) Date: 2001-12-17 14:12 Message: Logged In: YES user_id=218965 Oops, I submitted my comment before seeing Tim's. As I understand it, my program does not depend on the data much, as it basically just copies files. But it is good to know that leaks are deterministic. I will stop bothering you guys and return iff I get a replicable useful leak example. ---------------------------------------------------------------------- Comment By: Ben Escoto (bescoto) Date: 2001-12-17 14:09 Message: Logged In: YES user_id=218965 I'd be willing to do all this, but, as I mentioned initially, I'm not sure how to replicate the problem. The systems that leak all seem similar to mine (which doesn't leak). For instance, people running Suse Linux 7.3 and Debian unstable have complained, but I seem to be fine under Redhat 7.2 (7.1 was also ok). Should I ask them what versions of various libraries they are using, and then try to link python to those versions on my system? Which are the likely culprits? Or is this the wrong track altogether? (Sorry, I don't know enough about C/manual memory management to understand how/why the same code would leak on one system and not on another.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 14:08 Message: Logged In: YES user_id=31435 I can't recall a case where a Python leak occurred on only some systems. Leaks are deterministic bugs: each time a leaking program is run, it generally leaks exactly the same amounts at exactly the same times. So what's different between your system and your users'? Presumably the inputs, i.e. the data getting backed up. Do you have data-dependent paths in your Python code that may not get executed on your system with your data, but would on others'? It's also possible that programs you're calling suffer data-dependent memory growth. Until you can reproduce a problem yourself, there's not much hope. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:01 Message: Logged In: YES user_id=6380 (I meant, I'll be the expert, and if it doesn't require me to load countless megabytes of data I'll even do step 2, but I need you to perform step 1, and I could use help with step 2.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 13:58 Message: Logged In: YES user_id=6380 Typically, the way to squash a leak is: 1. get a reproducible test case that grows unbounded when watched with "top" 2. try to whittle the test case down to something really simple by removing code until it no longer leaks (and then going back to the previous version :-) 3. show the test case to an expert who will make an educated guess at where in the C code to look Can you do this? ---------------------------------------------------------------------- Comment By: Ben Escoto (bescoto) Date: 2001-12-17 13:30 Message: Logged In: YES user_id=218965 I had been following some of the memory leak bugs, and had hoped that an upgrade to 2.2c1 would fix things. But I asked the affected users to upgrade, and at least one of them claims to have the same error with 2.2c1 (others haven't tried upgrading yet). I might be able to get more information out of them, but only if the procedure is relatively painless.. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 13:22 Message: Logged In: YES user_id=6380 Surely it could be Python. You're using all the latest features (nested scopes and generators, class and static methods, ...). We're not *aware* of current leaks (we stamped out a bunch a couple of weeks ago) but there probably are some. It's also possible that you are creating cycles that the garbage collector doesn't find (they would have to involve types that don't support GC; fortunately you don't use __del__ or __slots__). Are you sure they aren't using it with previous 2.2 beta versions? Some of the plugged leaks were pretty severe. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 13:17 Message: Logged In: YES user_id=38388 Since you are using * nested scopes * static methods and * generators I'd suggest to first try to find the group of features that's causing the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 From noreply@sourceforge.net Mon Dec 17 22:12:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 14:12:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-494320 ] Memory leaks in 2.2c1? Message-ID: Bugs item #494320, was opened at 2001-12-17 13:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Escoto (bescoto) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leaks in 2.2c1? Initial Comment: Sorry, this won't be a very good bug report, but perhaps you can tell me how to make it better. I wrote a little python project (rdiff-backup at http://www.stanford.edu/~bescoto/rdiff-backup). On my computer it takes up about 7MB of memory even for large datasets, but several users have complained that it takes up so much memory on their systems (hundreds of MB) it is totally unusable. I suspect the problem is a memory leak in Python, but the only way I know of isolating the problem is pretty long, and none of the users affected know Python. I can't have them try an earlier version because the program depends on generators extensively. So, any advice? Do you think the problem could be in python? How could I go about trying to replicate this error? Of course, if I end up finding it is python, I'll try to submit a code snippet short enough to be helpful to you guys... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:12 Message: Logged In: YES user_id=6380 Forget their system configuration, as long as you're *sure* that they're *in fact* using the same Python. As Tim says, the answer is in the path through your code, dependent on their data. Your program looks young and probably has lots of features you haven't really used yourself -- that's where you should look next. I know, it ain't easy. :-( ---------------------------------------------------------------------- Comment By: Ben Escoto (bescoto) Date: 2001-12-17 14:12 Message: Logged In: YES user_id=218965 Oops, I submitted my comment before seeing Tim's. As I understand it, my program does not depend on the data much, as it basically just copies files. But it is good to know that leaks are deterministic. I will stop bothering you guys and return iff I get a replicable useful leak example. ---------------------------------------------------------------------- Comment By: Ben Escoto (bescoto) Date: 2001-12-17 14:09 Message: Logged In: YES user_id=218965 I'd be willing to do all this, but, as I mentioned initially, I'm not sure how to replicate the problem. The systems that leak all seem similar to mine (which doesn't leak). For instance, people running Suse Linux 7.3 and Debian unstable have complained, but I seem to be fine under Redhat 7.2 (7.1 was also ok). Should I ask them what versions of various libraries they are using, and then try to link python to those versions on my system? Which are the likely culprits? Or is this the wrong track altogether? (Sorry, I don't know enough about C/manual memory management to understand how/why the same code would leak on one system and not on another.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 14:08 Message: Logged In: YES user_id=31435 I can't recall a case where a Python leak occurred on only some systems. Leaks are deterministic bugs: each time a leaking program is run, it generally leaks exactly the same amounts at exactly the same times. So what's different between your system and your users'? Presumably the inputs, i.e. the data getting backed up. Do you have data-dependent paths in your Python code that may not get executed on your system with your data, but would on others'? It's also possible that programs you're calling suffer data-dependent memory growth. Until you can reproduce a problem yourself, there's not much hope. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:01 Message: Logged In: YES user_id=6380 (I meant, I'll be the expert, and if it doesn't require me to load countless megabytes of data I'll even do step 2, but I need you to perform step 1, and I could use help with step 2.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 13:58 Message: Logged In: YES user_id=6380 Typically, the way to squash a leak is: 1. get a reproducible test case that grows unbounded when watched with "top" 2. try to whittle the test case down to something really simple by removing code until it no longer leaks (and then going back to the previous version :-) 3. show the test case to an expert who will make an educated guess at where in the C code to look Can you do this? ---------------------------------------------------------------------- Comment By: Ben Escoto (bescoto) Date: 2001-12-17 13:30 Message: Logged In: YES user_id=218965 I had been following some of the memory leak bugs, and had hoped that an upgrade to 2.2c1 would fix things. But I asked the affected users to upgrade, and at least one of them claims to have the same error with 2.2c1 (others haven't tried upgrading yet). I might be able to get more information out of them, but only if the procedure is relatively painless.. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 13:22 Message: Logged In: YES user_id=6380 Surely it could be Python. You're using all the latest features (nested scopes and generators, class and static methods, ...). We're not *aware* of current leaks (we stamped out a bunch a couple of weeks ago) but there probably are some. It's also possible that you are creating cycles that the garbage collector doesn't find (they would have to involve types that don't support GC; fortunately you don't use __del__ or __slots__). Are you sure they aren't using it with previous 2.2 beta versions? Some of the plugged leaks were pretty severe. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 13:17 Message: Logged In: YES user_id=38388 Since you are using * nested scopes * static methods and * generators I'd suggest to first try to find the group of features that's causing the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 From noreply@sourceforge.net Mon Dec 17 22:14:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 14:14:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:14 Message: Logged In: YES user_id=85984 I'd say just close it out and keep it in the back of your mind in case something similar pops up in the future. I'll do the same. The bug is obscure and easy to workaround anyway. Thanks for your help with this. At the very least it has been an educational experience for me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:10 Message: Logged In: YES user_id=6380 So do you want me to keep this open? I don't expect we'll find the answer. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:07 Message: Logged In: YES user_id=85984 Your prediction is correct: [root@nightshade Python-2.1.1]# ./python df Python 2.1.1 (#1, Dec 17 2001, 15:01:24) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 21:13 Message: Logged In: YES user_id=6380 Add these three lines to Py_Main() in Modules/main.c, after the line saying "PyCompilerFlags cf;": char buffer[120]; sprintf(buffer, "%.1lx", 223L); printf("%s\n", buffer); and rebuild Python. When you run Python, it should print "df" before the standard banner. If it crashes, we've proved that Python is not the cause of the problem. But I predict that it'll work. :-( ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 21:01 Message: Logged In: YES user_id=85984 As far as the standalone program, I'm not a C programmer, (I've become Python-dependent :-), but if you can give me an idea of what it should contain, I'll give it a try. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 20:23 Message: Logged In: YES user_id=6380 Sigh. I think it's a dead end. What about a stand-alone program? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 19:09 Message: Logged In: YES user_id=85984 Tim asked whather I can verify whether I'm mixing the threaded and non-threaded versions of libc. Is the following enough to tell? $ ldd /usr/local/src/Python-2.1.1/python /usr/local/src/Python-2.1.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x280ca000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28182000) libm.so.2 => /usr/lib/libm.so.2 (0x2818b000) libc.so.4 => /usr/lib/libc.so.4 (0x281a7000) libc is the non-threaded library, and libc_r is the threaded version, so it looks like they are being mixed, yes? However, my Python 2.0.1 also looks the same way, and I'm not having any problems with it. $ ldd /usr/local/src/Python-2.0.1/python /usr/local/src/Python-2.0.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x2816c000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28224000) libm.so.2 => /usr/lib/libm.so.2 (0x2822d000) libc.so.4 => /usr/lib/libc.so.4 (0x28249000) Next, Guido asked me to check some local variables in that stack frame. See attached backtrace3.txt. And to answer your question, yes I built all the Python versions I'm testing myself. I even rebuilt 2.0.1 and 2.1.1 in the simplest manner to make sure I'm comparing them equally. (Just ./configure && make). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:47 Message: Logged In: YES user_id=31435 BTW, a google search on _thread_autoinit_dummy_decl turns up another FreeBSD bug report of a death deep in libc_r starting with a sprintf() call. It had to do with mysql, not with Python. The tracebacks in both cases look worthless to me, because (for example) _thread_autoinit_dummy_decl is an extern int in the FreeBSD source, not a function at all. This increases the suspicion that libc versions are getting mixed up (and that gdb is looking up addresses in "the wrong" libc). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 17:20 Message: Logged In: YES user_id=6380 OK, it's the second sprintf call in formatint. Can you check some local variables in that stack frame? I expect fmt to be "%.1lx", but would like to see that confirmed; x should be one of the values from your binary string: 206, 199, 166. Can you see which one? It would then be interesting to find out what a small C program with that same sprintf() does. Make sure that the C program is compiled and linked in exactly the same way as python. (What I do in such cases is I put the experimental statement in Python's main() and rebuild Python. :-) The build procedure of each Python version is somewhat different, and it's likely that each version picks slightly different compile/link options. Also, did you build all the Python versions you tried yourself? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:17 Message: Logged In: YES user_id=31435 The new backtrace is helpful (thanks!), but it just makes it harder to believe that Python is at fault. The segfault occurs four levels deep in system library functions, and from inspection there's nothing even remotely suspicious about the sprintf call that kicks it off. As Guido suggested, can you verify you're not mixing the threaded and non-threaded versions of libc? Short of that, you really need a FreeBSD libc author to help with this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 15:26 Message: Logged In: YES user_id=85984 Alright, I rebuilt Python 2.1.1 with -g, so the gdb backtrace now contains some more information. I attached backtrace2.txt which is a backtrace of the program failing when calling the hexlify() function. I tried compiling with `--with-pydebug', but then I can't reproduce the core dump for some reason. As you mention, this could have something to do with FreeBSD's libc. However, does that explain why I only have this problem with 2.1.1? On the same system, Python 1.5.2, 2.0, and 2.2c1 compiled in the same manner (simply ./configure && gmake) don't produce a core dump. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=6380 See the repeated "(no debugging symbols found)..." in the gdb output? try recompiling with -g. I strongly suspect that the traceback is lying, and we're in fact not in PyString_AsStringAndSize() when we call sprintf -- there's no sprintf call in that function (I checked the 2.1.1 source) but there is one two static functions down, in string_repr(), which is indeed called when you pickle a string object. This would match the original gdb stacktrace you reported: there's no sprintf call in _PyString_FormatLong(), but there are two in the next static function, formatint(), and it does make sense that that function would be called by the %02x format. All this makes no sense, however, because I can see nothing wrong with the arguments to sprintf here! I've heard of problems on FreeBSD having to do with different (threaded and unthreaded?) versions of libc. Could that be the issue here? Can you rebuild Python 2.1.1 with debugg flags on? (./configure --with-pydebug should do it for 2.2; I don't recall if the 2.2.1 configure supports that though -- try --help first.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Mon Dec 17 22:17:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 14:17:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: Platform-specific >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:14 Message: Logged In: YES user_id=85984 I'd say just close it out and keep it in the back of your mind in case something similar pops up in the future. I'll do the same. The bug is obscure and easy to workaround anyway. Thanks for your help with this. At the very least it has been an educational experience for me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:10 Message: Logged In: YES user_id=6380 So do you want me to keep this open? I don't expect we'll find the answer. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:07 Message: Logged In: YES user_id=85984 Your prediction is correct: [root@nightshade Python-2.1.1]# ./python df Python 2.1.1 (#1, Dec 17 2001, 15:01:24) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 21:13 Message: Logged In: YES user_id=6380 Add these three lines to Py_Main() in Modules/main.c, after the line saying "PyCompilerFlags cf;": char buffer[120]; sprintf(buffer, "%.1lx", 223L); printf("%s\n", buffer); and rebuild Python. When you run Python, it should print "df" before the standard banner. If it crashes, we've proved that Python is not the cause of the problem. But I predict that it'll work. :-( ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 21:01 Message: Logged In: YES user_id=85984 As far as the standalone program, I'm not a C programmer, (I've become Python-dependent :-), but if you can give me an idea of what it should contain, I'll give it a try. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 20:23 Message: Logged In: YES user_id=6380 Sigh. I think it's a dead end. What about a stand-alone program? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 19:09 Message: Logged In: YES user_id=85984 Tim asked whather I can verify whether I'm mixing the threaded and non-threaded versions of libc. Is the following enough to tell? $ ldd /usr/local/src/Python-2.1.1/python /usr/local/src/Python-2.1.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x280ca000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28182000) libm.so.2 => /usr/lib/libm.so.2 (0x2818b000) libc.so.4 => /usr/lib/libc.so.4 (0x281a7000) libc is the non-threaded library, and libc_r is the threaded version, so it looks like they are being mixed, yes? However, my Python 2.0.1 also looks the same way, and I'm not having any problems with it. $ ldd /usr/local/src/Python-2.0.1/python /usr/local/src/Python-2.0.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x2816c000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28224000) libm.so.2 => /usr/lib/libm.so.2 (0x2822d000) libc.so.4 => /usr/lib/libc.so.4 (0x28249000) Next, Guido asked me to check some local variables in that stack frame. See attached backtrace3.txt. And to answer your question, yes I built all the Python versions I'm testing myself. I even rebuilt 2.0.1 and 2.1.1 in the simplest manner to make sure I'm comparing them equally. (Just ./configure && make). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:47 Message: Logged In: YES user_id=31435 BTW, a google search on _thread_autoinit_dummy_decl turns up another FreeBSD bug report of a death deep in libc_r starting with a sprintf() call. It had to do with mysql, not with Python. The tracebacks in both cases look worthless to me, because (for example) _thread_autoinit_dummy_decl is an extern int in the FreeBSD source, not a function at all. This increases the suspicion that libc versions are getting mixed up (and that gdb is looking up addresses in "the wrong" libc). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 17:20 Message: Logged In: YES user_id=6380 OK, it's the second sprintf call in formatint. Can you check some local variables in that stack frame? I expect fmt to be "%.1lx", but would like to see that confirmed; x should be one of the values from your binary string: 206, 199, 166. Can you see which one? It would then be interesting to find out what a small C program with that same sprintf() does. Make sure that the C program is compiled and linked in exactly the same way as python. (What I do in such cases is I put the experimental statement in Python's main() and rebuild Python. :-) The build procedure of each Python version is somewhat different, and it's likely that each version picks slightly different compile/link options. Also, did you build all the Python versions you tried yourself? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:17 Message: Logged In: YES user_id=31435 The new backtrace is helpful (thanks!), but it just makes it harder to believe that Python is at fault. The segfault occurs four levels deep in system library functions, and from inspection there's nothing even remotely suspicious about the sprintf call that kicks it off. As Guido suggested, can you verify you're not mixing the threaded and non-threaded versions of libc? Short of that, you really need a FreeBSD libc author to help with this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 15:26 Message: Logged In: YES user_id=85984 Alright, I rebuilt Python 2.1.1 with -g, so the gdb backtrace now contains some more information. I attached backtrace2.txt which is a backtrace of the program failing when calling the hexlify() function. I tried compiling with `--with-pydebug', but then I can't reproduce the core dump for some reason. As you mention, this could have something to do with FreeBSD's libc. However, does that explain why I only have this problem with 2.1.1? On the same system, Python 1.5.2, 2.0, and 2.2c1 compiled in the same manner (simply ./configure && gmake) don't produce a core dump. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=6380 See the repeated "(no debugging symbols found)..." in the gdb output? try recompiling with -g. I strongly suspect that the traceback is lying, and we're in fact not in PyString_AsStringAndSize() when we call sprintf -- there's no sprintf call in that function (I checked the 2.1.1 source) but there is one two static functions down, in string_repr(), which is indeed called when you pickle a string object. This would match the original gdb stacktrace you reported: there's no sprintf call in _PyString_FormatLong(), but there are two in the next static function, formatint(), and it does make sense that that function would be called by the %02x format. All this makes no sense, however, because I can see nothing wrong with the arguments to sprintf here! I've heard of problems on FreeBSD having to do with different (threaded and unthreaded?) versions of libc. Could that be the issue here? Can you rebuild Python 2.1.1 with debugg flags on? (./configure --with-pydebug should do it for 2.2; I don't recall if the 2.2.1 configure supports that though -- try --help first.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Mon Dec 17 22:28:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 14:28:04 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-494034 ] a smarter rfc822.dump_address_pair() Message-ID: Feature Requests item #494034, was opened at 2001-12-16 17:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494034&group_id=5470 Category: Python Library Group: None Status: Open Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Barry Warsaw (bwarsaw) Summary: a smarter rfc822.dump_address_pair() Initial Comment: Please see: http://mail.python.org/pipermail/python-list/2001-December/075881.html I'm turning this into a feature request since I didn't get any responses on comp.lang.python. ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:28 Message: Logged In: YES user_id=85984 Thanks Barry. If you don't think you'll have time to write the code for this, I can try and work on a patch. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-17 07:04 Message: Logged In: YES user_id=12800 Claiming this item. There appears to be no groups set for the feature request tracker, but I'll look at this for Python 2.3 (to late to add it to Python 2.2). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494034&group_id=5470 From noreply@sourceforge.net Mon Dec 17 22:34:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 14:34:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-494320 ] Memory leaks in 2.2c1? Message-ID: Bugs item #494320, was opened at 2001-12-17 13:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Escoto (bescoto) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leaks in 2.2c1? Initial Comment: Sorry, this won't be a very good bug report, but perhaps you can tell me how to make it better. I wrote a little python project (rdiff-backup at http://www.stanford.edu/~bescoto/rdiff-backup). On my computer it takes up about 7MB of memory even for large datasets, but several users have complained that it takes up so much memory on their systems (hundreds of MB) it is totally unusable. I suspect the problem is a memory leak in Python, but the only way I know of isolating the problem is pretty long, and none of the users affected know Python. I can't have them try an earlier version because the program depends on generators extensively. So, any advice? Do you think the problem could be in python? How could I go about trying to replicate this error? Of course, if I end up finding it is python, I'll try to submit a code snippet short enough to be helpful to you guys... ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-17 14:34 Message: Logged In: YES user_id=31435 Ben, there's a Big Hammer you should know about: in a debug build of Python (but not a release build), the sys module grows a new function, sys.getobjects(). It returns a (Python) list of all objects in existence at the time it's called. When there's a leak, this list gets bigger and bigger as time goes on; of course it may *also* grow bigger and bigger as time goes on if a program is simply forgetting that it's hanging on to stuff (e.g., appending to some bookkeeping list but forgetting to clean it up will make the getobjects() list grow without bound too). It can be useful to write a little function that invokes getobjects(), crawls over the list to build a dict mapping a type to the count of the number of objects of that type in the list, and prints the dict. Then call it periodically and stare at the output. If there's some sort of leak (whether Python's fault or not), the object types involved stick out like a sore thumb (their counts keep growing). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:12 Message: Logged In: YES user_id=6380 Forget their system configuration, as long as you're *sure* that they're *in fact* using the same Python. As Tim says, the answer is in the path through your code, dependent on their data. Your program looks young and probably has lots of features you haven't really used yourself -- that's where you should look next. I know, it ain't easy. :-( ---------------------------------------------------------------------- Comment By: Ben Escoto (bescoto) Date: 2001-12-17 14:12 Message: Logged In: YES user_id=218965 Oops, I submitted my comment before seeing Tim's. As I understand it, my program does not depend on the data much, as it basically just copies files. But it is good to know that leaks are deterministic. I will stop bothering you guys and return iff I get a replicable useful leak example. ---------------------------------------------------------------------- Comment By: Ben Escoto (bescoto) Date: 2001-12-17 14:09 Message: Logged In: YES user_id=218965 I'd be willing to do all this, but, as I mentioned initially, I'm not sure how to replicate the problem. The systems that leak all seem similar to mine (which doesn't leak). For instance, people running Suse Linux 7.3 and Debian unstable have complained, but I seem to be fine under Redhat 7.2 (7.1 was also ok). Should I ask them what versions of various libraries they are using, and then try to link python to those versions on my system? Which are the likely culprits? Or is this the wrong track altogether? (Sorry, I don't know enough about C/manual memory management to understand how/why the same code would leak on one system and not on another.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 14:08 Message: Logged In: YES user_id=31435 I can't recall a case where a Python leak occurred on only some systems. Leaks are deterministic bugs: each time a leaking program is run, it generally leaks exactly the same amounts at exactly the same times. So what's different between your system and your users'? Presumably the inputs, i.e. the data getting backed up. Do you have data-dependent paths in your Python code that may not get executed on your system with your data, but would on others'? It's also possible that programs you're calling suffer data-dependent memory growth. Until you can reproduce a problem yourself, there's not much hope. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:01 Message: Logged In: YES user_id=6380 (I meant, I'll be the expert, and if it doesn't require me to load countless megabytes of data I'll even do step 2, but I need you to perform step 1, and I could use help with step 2.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 13:58 Message: Logged In: YES user_id=6380 Typically, the way to squash a leak is: 1. get a reproducible test case that grows unbounded when watched with "top" 2. try to whittle the test case down to something really simple by removing code until it no longer leaks (and then going back to the previous version :-) 3. show the test case to an expert who will make an educated guess at where in the C code to look Can you do this? ---------------------------------------------------------------------- Comment By: Ben Escoto (bescoto) Date: 2001-12-17 13:30 Message: Logged In: YES user_id=218965 I had been following some of the memory leak bugs, and had hoped that an upgrade to 2.2c1 would fix things. But I asked the affected users to upgrade, and at least one of them claims to have the same error with 2.2c1 (others haven't tried upgrading yet). I might be able to get more information out of them, but only if the procedure is relatively painless.. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 13:22 Message: Logged In: YES user_id=6380 Surely it could be Python. You're using all the latest features (nested scopes and generators, class and static methods, ...). We're not *aware* of current leaks (we stamped out a bunch a couple of weeks ago) but there probably are some. It's also possible that you are creating cycles that the garbage collector doesn't find (they would have to involve types that don't support GC; fortunately you don't use __del__ or __slots__). Are you sure they aren't using it with previous 2.2 beta versions? Some of the plugged leaks were pretty severe. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 13:17 Message: Logged In: YES user_id=38388 Since you are using * nested scopes * static methods and * generators I'd suggest to first try to find the group of features that's causing the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 From noreply@sourceforge.net Mon Dec 17 22:41:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 14:41:04 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-494034 ] a smarter rfc822.dump_address_pair() Message-ID: Feature Requests item #494034, was opened at 2001-12-16 17:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494034&group_id=5470 Category: Python Library Group: None Status: Open Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Barry Warsaw (bwarsaw) Summary: a smarter rfc822.dump_address_pair() Initial Comment: Please see: http://mail.python.org/pipermail/python-list/2001-December/075881.html I'm turning this into a feature request since I didn't get any responses on comp.lang.python. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-17 14:41 Message: Logged In: YES user_id=12800 If you get to it before I do, upload it here... :) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:28 Message: Logged In: YES user_id=85984 Thanks Barry. If you don't think you'll have time to write the code for this, I can try and work on a patch. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-17 07:04 Message: Logged In: YES user_id=12800 Claiming this item. There appears to be no groups set for the feature request tracker, but I'll look at this for Python 2.3 (to late to add it to Python 2.2). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494034&group_id=5470 From noreply@sourceforge.net Mon Dec 17 22:46:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 14:46:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core >Group: 3rd Party Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-17 14:46 Message: Logged In: YES user_id=31435 Note that the same kind of mysterious bug was reported against mysql on FreeBSD (I mentioned this several notes ago). There's really no evidence of a Python bug here. Find someone knowledgeable about libc internals on FreeBSD: that's where the evidence points. They may also be able to help you figure out why you're getting a mix of threaded and non-threaded libcs; I can't say whether that's a problem, but it sure doesn't look right. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:14 Message: Logged In: YES user_id=85984 I'd say just close it out and keep it in the back of your mind in case something similar pops up in the future. I'll do the same. The bug is obscure and easy to workaround anyway. Thanks for your help with this. At the very least it has been an educational experience for me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:10 Message: Logged In: YES user_id=6380 So do you want me to keep this open? I don't expect we'll find the answer. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:07 Message: Logged In: YES user_id=85984 Your prediction is correct: [root@nightshade Python-2.1.1]# ./python df Python 2.1.1 (#1, Dec 17 2001, 15:01:24) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 21:13 Message: Logged In: YES user_id=6380 Add these three lines to Py_Main() in Modules/main.c, after the line saying "PyCompilerFlags cf;": char buffer[120]; sprintf(buffer, "%.1lx", 223L); printf("%s\n", buffer); and rebuild Python. When you run Python, it should print "df" before the standard banner. If it crashes, we've proved that Python is not the cause of the problem. But I predict that it'll work. :-( ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 21:01 Message: Logged In: YES user_id=85984 As far as the standalone program, I'm not a C programmer, (I've become Python-dependent :-), but if you can give me an idea of what it should contain, I'll give it a try. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 20:23 Message: Logged In: YES user_id=6380 Sigh. I think it's a dead end. What about a stand-alone program? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 19:09 Message: Logged In: YES user_id=85984 Tim asked whather I can verify whether I'm mixing the threaded and non-threaded versions of libc. Is the following enough to tell? $ ldd /usr/local/src/Python-2.1.1/python /usr/local/src/Python-2.1.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x280ca000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28182000) libm.so.2 => /usr/lib/libm.so.2 (0x2818b000) libc.so.4 => /usr/lib/libc.so.4 (0x281a7000) libc is the non-threaded library, and libc_r is the threaded version, so it looks like they are being mixed, yes? However, my Python 2.0.1 also looks the same way, and I'm not having any problems with it. $ ldd /usr/local/src/Python-2.0.1/python /usr/local/src/Python-2.0.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x2816c000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28224000) libm.so.2 => /usr/lib/libm.so.2 (0x2822d000) libc.so.4 => /usr/lib/libc.so.4 (0x28249000) Next, Guido asked me to check some local variables in that stack frame. See attached backtrace3.txt. And to answer your question, yes I built all the Python versions I'm testing myself. I even rebuilt 2.0.1 and 2.1.1 in the simplest manner to make sure I'm comparing them equally. (Just ./configure && make). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:47 Message: Logged In: YES user_id=31435 BTW, a google search on _thread_autoinit_dummy_decl turns up another FreeBSD bug report of a death deep in libc_r starting with a sprintf() call. It had to do with mysql, not with Python. The tracebacks in both cases look worthless to me, because (for example) _thread_autoinit_dummy_decl is an extern int in the FreeBSD source, not a function at all. This increases the suspicion that libc versions are getting mixed up (and that gdb is looking up addresses in "the wrong" libc). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 17:20 Message: Logged In: YES user_id=6380 OK, it's the second sprintf call in formatint. Can you check some local variables in that stack frame? I expect fmt to be "%.1lx", but would like to see that confirmed; x should be one of the values from your binary string: 206, 199, 166. Can you see which one? It would then be interesting to find out what a small C program with that same sprintf() does. Make sure that the C program is compiled and linked in exactly the same way as python. (What I do in such cases is I put the experimental statement in Python's main() and rebuild Python. :-) The build procedure of each Python version is somewhat different, and it's likely that each version picks slightly different compile/link options. Also, did you build all the Python versions you tried yourself? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:17 Message: Logged In: YES user_id=31435 The new backtrace is helpful (thanks!), but it just makes it harder to believe that Python is at fault. The segfault occurs four levels deep in system library functions, and from inspection there's nothing even remotely suspicious about the sprintf call that kicks it off. As Guido suggested, can you verify you're not mixing the threaded and non-threaded versions of libc? Short of that, you really need a FreeBSD libc author to help with this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 15:26 Message: Logged In: YES user_id=85984 Alright, I rebuilt Python 2.1.1 with -g, so the gdb backtrace now contains some more information. I attached backtrace2.txt which is a backtrace of the program failing when calling the hexlify() function. I tried compiling with `--with-pydebug', but then I can't reproduce the core dump for some reason. As you mention, this could have something to do with FreeBSD's libc. However, does that explain why I only have this problem with 2.1.1? On the same system, Python 1.5.2, 2.0, and 2.2c1 compiled in the same manner (simply ./configure && gmake) don't produce a core dump. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=6380 See the repeated "(no debugging symbols found)..." in the gdb output? try recompiling with -g. I strongly suspect that the traceback is lying, and we're in fact not in PyString_AsStringAndSize() when we call sprintf -- there's no sprintf call in that function (I checked the 2.1.1 source) but there is one two static functions down, in string_repr(), which is indeed called when you pickle a string object. This would match the original gdb stacktrace you reported: there's no sprintf call in _PyString_FormatLong(), but there are two in the next static function, formatint(), and it does make sense that that function would be called by the %02x format. All this makes no sense, however, because I can see nothing wrong with the arguments to sprintf here! I've heard of problems on FreeBSD having to do with different (threaded and unthreaded?) versions of libc. Could that be the issue here? Can you rebuild Python 2.1.1 with debugg flags on? (./configure --with-pydebug should do it for 2.2; I don't recall if the 2.2.1 configure supports that though -- try --help first.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Tue Dec 18 04:17:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 20:17:54 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-494240 ] str.reverse Message-ID: Feature Requests item #494240, was opened at 2001-12-17 08:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494240&group_id=5470 Category: Python Library Group: None Status: Open Priority: 5 Submitted By: Allan Crooks (amc1) Assigned to: Nobody/Anonymous (nobody) Summary: str.reverse Initial Comment: The str type should *really* have a reverse method. "How do I reverse a string?" crops up too often on tutor lists, and there should be a neater way to do it other than converting it to a list, reversing it, and then joining it... ---------------------------------------------------------------------- >Comment By: Allan Crooks (amc1) Date: 2001-12-17 20:17 Message: Logged In: YES user_id=39733 > Show me one real-life application of reversing a string. Ummm.... easy way to check for palindromes? > This comes from textbook exercises IMO, > and doesn't occur in real life. It may not occur in many serious applications, but there have been occasions where I've simply wanted to reverse a string just for the fun of it really (or just to check quickly what something is backwards). > Adding the method would reduce the > utility of the textbook exercise... Not unless you explicitly said not to use str.reverse... You could argue that doing l = list('something'); l.reverse (); ''.join(l) perhaps is still a bit too easy for a text book. Something more appropriate like for loops and ranges would be suitable for an exercise. I dunno, it just seems like it's the sort of method that should be part of str, and it doesn't seem like the method would be that huge or problematic to implement... If that doesn't convince you, then at least say you'll implement it if I figure out a worthwhile use for it. :)) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 08:57 Message: Logged In: YES user_id=6380 Show me one real-life application of reversing a string. This comes from textbook exercises IMO, and doesn't occur in real life. Adding the method would reduce the utility of the textbook exercise... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494240&group_id=5470 From noreply@sourceforge.net Tue Dec 18 04:22:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 20:22:31 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-494240 ] str.reverse Message-ID: Feature Requests item #494240, was opened at 2001-12-17 08:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494240&group_id=5470 Category: Python Library Group: None Status: Open Priority: 5 Submitted By: Allan Crooks (amc1) Assigned to: Nobody/Anonymous (nobody) Summary: str.reverse Initial Comment: The str type should *really* have a reverse method. "How do I reverse a string?" crops up too often on tutor lists, and there should be a neater way to do it other than converting it to a list, reversing it, and then joining it... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 20:22 Message: Logged In: YES user_id=6380 Write a PEP. :-) ---------------------------------------------------------------------- Comment By: Allan Crooks (amc1) Date: 2001-12-17 20:17 Message: Logged In: YES user_id=39733 > Show me one real-life application of reversing a string. Ummm.... easy way to check for palindromes? > This comes from textbook exercises IMO, > and doesn't occur in real life. It may not occur in many serious applications, but there have been occasions where I've simply wanted to reverse a string just for the fun of it really (or just to check quickly what something is backwards). > Adding the method would reduce the > utility of the textbook exercise... Not unless you explicitly said not to use str.reverse... You could argue that doing l = list('something'); l.reverse (); ''.join(l) perhaps is still a bit too easy for a text book. Something more appropriate like for loops and ranges would be suitable for an exercise. I dunno, it just seems like it's the sort of method that should be part of str, and it doesn't seem like the method would be that huge or problematic to implement... If that doesn't convince you, then at least say you'll implement it if I figure out a worthwhile use for it. :)) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 08:57 Message: Logged In: YES user_id=6380 Show me one real-life application of reversing a string. This comes from textbook exercises IMO, and doesn't occur in real life. Adding the method would reduce the utility of the textbook exercise... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494240&group_id=5470 From noreply@sourceforge.net Tue Dec 18 04:57:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 17 Dec 2001 20:57:32 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-494240 ] str.reverse Message-ID: Feature Requests item #494240, was opened at 2001-12-17 08:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494240&group_id=5470 Category: Python Library Group: None Status: Open Priority: 5 Submitted By: Allan Crooks (amc1) Assigned to: Nobody/Anonymous (nobody) Summary: str.reverse Initial Comment: The str type should *really* have a reverse method. "How do I reverse a string?" crops up too often on tutor lists, and there should be a neater way to do it other than converting it to a list, reversing it, and then joining it... ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-17 20:57 Message: Logged In: YES user_id=31435 Here's an application of (sub)string reversal in dartboard design: http://www.combinatorics.org/Volume_8/PDF/v8i2r4.pdf I'd hate to see Python fall behind in the lucrative dartboard designer market . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 20:22 Message: Logged In: YES user_id=6380 Write a PEP. :-) ---------------------------------------------------------------------- Comment By: Allan Crooks (amc1) Date: 2001-12-17 20:17 Message: Logged In: YES user_id=39733 > Show me one real-life application of reversing a string. Ummm.... easy way to check for palindromes? > This comes from textbook exercises IMO, > and doesn't occur in real life. It may not occur in many serious applications, but there have been occasions where I've simply wanted to reverse a string just for the fun of it really (or just to check quickly what something is backwards). > Adding the method would reduce the > utility of the textbook exercise... Not unless you explicitly said not to use str.reverse... You could argue that doing l = list('something'); l.reverse (); ''.join(l) perhaps is still a bit too easy for a text book. Something more appropriate like for loops and ranges would be suitable for an exercise. I dunno, it just seems like it's the sort of method that should be part of str, and it doesn't seem like the method would be that huge or problematic to implement... If that doesn't convince you, then at least say you'll implement it if I figure out a worthwhile use for it. :)) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 08:57 Message: Logged In: YES user_id=6380 Show me one real-life application of reversing a string. This comes from textbook exercises IMO, and doesn't occur in real life. Adding the method would reduce the utility of the textbook exercise... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494240&group_id=5470 From noreply@sourceforge.net Tue Dec 18 08:43:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 00:43:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-494320 ] Memory leaks in 2.2c1? Message-ID: Bugs item #494320, was opened at 2001-12-17 13:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Ben Escoto (bescoto) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leaks in 2.2c1? Initial Comment: Sorry, this won't be a very good bug report, but perhaps you can tell me how to make it better. I wrote a little python project (rdiff-backup at http://www.stanford.edu/~bescoto/rdiff-backup). On my computer it takes up about 7MB of memory even for large datasets, but several users have complained that it takes up so much memory on their systems (hundreds of MB) it is totally unusable. I suspect the problem is a memory leak in Python, but the only way I know of isolating the problem is pretty long, and none of the users affected know Python. I can't have them try an earlier version because the program depends on generators extensively. So, any advice? Do you think the problem could be in python? How could I go about trying to replicate this error? Of course, if I end up finding it is python, I'll try to submit a code snippet short enough to be helpful to you guys... ---------------------------------------------------------------------- >Comment By: Ben Escoto (bescoto) Date: 2001-12-18 00:43 Message: Logged In: YES user_id=218965 It turns out there was a miscommunication about the reported memory leak, and, just as you guys said, I got the problem when I ran it the right way. And the problem was ALL MY FAULT, and had nothing to do with any memory leaks 2.2c1 may or may not have. So, sorry for wasting your time, but thanks for your helpful advice which helped me find the problem in just a few hours. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 14:34 Message: Logged In: YES user_id=31435 Ben, there's a Big Hammer you should know about: in a debug build of Python (but not a release build), the sys module grows a new function, sys.getobjects(). It returns a (Python) list of all objects in existence at the time it's called. When there's a leak, this list gets bigger and bigger as time goes on; of course it may *also* grow bigger and bigger as time goes on if a program is simply forgetting that it's hanging on to stuff (e.g., appending to some bookkeeping list but forgetting to clean it up will make the getobjects() list grow without bound too). It can be useful to write a little function that invokes getobjects(), crawls over the list to build a dict mapping a type to the count of the number of objects of that type in the list, and prints the dict. Then call it periodically and stare at the output. If there's some sort of leak (whether Python's fault or not), the object types involved stick out like a sore thumb (their counts keep growing). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:12 Message: Logged In: YES user_id=6380 Forget their system configuration, as long as you're *sure* that they're *in fact* using the same Python. As Tim says, the answer is in the path through your code, dependent on their data. Your program looks young and probably has lots of features you haven't really used yourself -- that's where you should look next. I know, it ain't easy. :-( ---------------------------------------------------------------------- Comment By: Ben Escoto (bescoto) Date: 2001-12-17 14:12 Message: Logged In: YES user_id=218965 Oops, I submitted my comment before seeing Tim's. As I understand it, my program does not depend on the data much, as it basically just copies files. But it is good to know that leaks are deterministic. I will stop bothering you guys and return iff I get a replicable useful leak example. ---------------------------------------------------------------------- Comment By: Ben Escoto (bescoto) Date: 2001-12-17 14:09 Message: Logged In: YES user_id=218965 I'd be willing to do all this, but, as I mentioned initially, I'm not sure how to replicate the problem. The systems that leak all seem similar to mine (which doesn't leak). For instance, people running Suse Linux 7.3 and Debian unstable have complained, but I seem to be fine under Redhat 7.2 (7.1 was also ok). Should I ask them what versions of various libraries they are using, and then try to link python to those versions on my system? Which are the likely culprits? Or is this the wrong track altogether? (Sorry, I don't know enough about C/manual memory management to understand how/why the same code would leak on one system and not on another.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 14:08 Message: Logged In: YES user_id=31435 I can't recall a case where a Python leak occurred on only some systems. Leaks are deterministic bugs: each time a leaking program is run, it generally leaks exactly the same amounts at exactly the same times. So what's different between your system and your users'? Presumably the inputs, i.e. the data getting backed up. Do you have data-dependent paths in your Python code that may not get executed on your system with your data, but would on others'? It's also possible that programs you're calling suffer data-dependent memory growth. Until you can reproduce a problem yourself, there's not much hope. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:01 Message: Logged In: YES user_id=6380 (I meant, I'll be the expert, and if it doesn't require me to load countless megabytes of data I'll even do step 2, but I need you to perform step 1, and I could use help with step 2.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 13:58 Message: Logged In: YES user_id=6380 Typically, the way to squash a leak is: 1. get a reproducible test case that grows unbounded when watched with "top" 2. try to whittle the test case down to something really simple by removing code until it no longer leaks (and then going back to the previous version :-) 3. show the test case to an expert who will make an educated guess at where in the C code to look Can you do this? ---------------------------------------------------------------------- Comment By: Ben Escoto (bescoto) Date: 2001-12-17 13:30 Message: Logged In: YES user_id=218965 I had been following some of the memory leak bugs, and had hoped that an upgrade to 2.2c1 would fix things. But I asked the affected users to upgrade, and at least one of them claims to have the same error with 2.2c1 (others haven't tried upgrading yet). I might be able to get more information out of them, but only if the procedure is relatively painless.. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 13:22 Message: Logged In: YES user_id=6380 Surely it could be Python. You're using all the latest features (nested scopes and generators, class and static methods, ...). We're not *aware* of current leaks (we stamped out a bunch a couple of weeks ago) but there probably are some. It's also possible that you are creating cycles that the garbage collector doesn't find (they would have to involve types that don't support GC; fortunately you don't use __del__ or __slots__). Are you sure they aren't using it with previous 2.2 beta versions? Some of the plugged leaks were pretty severe. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 13:17 Message: Logged In: YES user_id=38388 Since you are using * nested scopes * static methods and * generators I'd suggest to first try to find the group of features that's causing the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 From noreply@sourceforge.net Tue Dec 18 13:32:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 05:32:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-494572 ] plugin project generation has problems Message-ID: Bugs item #494572, was opened at 2001-12-18 05:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494572&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: plugin project generation has problems Initial Comment: The generation of CW7 projects for plugins (and distutils too, probably) still has some problems that cause CW to say the project was created by an older version of CodeWarrior. The project does work, but this needs to be fixed before 2.2 final. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494572&group_id=5470 From noreply@sourceforge.net Tue Dec 18 14:29:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 06:29:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-494589 ] os.path.expandvars deletes things on w32 Message-ID: Bugs item #494589, was opened at 2001-12-18 06:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494589&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael McCandless (mikemccand) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.expandvars deletes things on w32 Initial Comment: Try this: import os.path print os.path.expandvars('foo$doesnotexist') On FreeBSD, Python 2.1, I get: 'foo$doesnotexist' But on WIN32, Python 2.1, I get: 'foo' The docs explicitly states that variables that are not found will be left in place ... but on win32 that appears to not be the case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494589&group_id=5470 From noreply@sourceforge.net Tue Dec 18 14:35:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 06:35:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-494589 ] os.path.expandvars deletes things on w32 Message-ID: Bugs item #494589, was opened at 2001-12-18 06:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494589&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael McCandless (mikemccand) >Assigned to: Tim Peters (tim_one) Summary: os.path.expandvars deletes things on w32 Initial Comment: Try this: import os.path print os.path.expandvars('foo$doesnotexist') On FreeBSD, Python 2.1, I get: 'foo$doesnotexist' But on WIN32, Python 2.1, I get: 'foo' The docs explicitly states that variables that are not found will be left in place ... but on win32 that appears to not be the case. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 06:35 Message: Logged In: YES user_id=6380 Confirmed, also in 2.2. I don't understand it, the code looks OK. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494589&group_id=5470 From noreply@sourceforge.net Tue Dec 18 14:43:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 06:43:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-494589 ] os.path.expandvars deletes things on w32 Message-ID: Bugs item #494589, was opened at 2001-12-18 06:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494589&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael McCandless (mikemccand) Assigned to: Tim Peters (tim_one) Summary: os.path.expandvars deletes things on w32 Initial Comment: Try this: import os.path print os.path.expandvars('foo$doesnotexist') On FreeBSD, Python 2.1, I get: 'foo$doesnotexist' But on WIN32, Python 2.1, I get: 'foo' The docs explicitly states that variables that are not found will be left in place ... but on win32 that appears to not be the case. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 06:43 Message: Logged In: YES user_id=6380 Hm, I do understand it, the code is broken (compared to the spec). No time to fix it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 06:35 Message: Logged In: YES user_id=6380 Confirmed, also in 2.2. I don't understand it, the code looks OK. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494589&group_id=5470 From noreply@sourceforge.net Tue Dec 18 16:07:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 08:07:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-494320 ] Memory leaks in 2.2c1? Message-ID: Bugs item #494320, was opened at 2001-12-17 13:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 Category: Python Interpreter Core >Group: Not a Bug Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Ben Escoto (bescoto) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leaks in 2.2c1? Initial Comment: Sorry, this won't be a very good bug report, but perhaps you can tell me how to make it better. I wrote a little python project (rdiff-backup at http://www.stanford.edu/~bescoto/rdiff-backup). On my computer it takes up about 7MB of memory even for large datasets, but several users have complained that it takes up so much memory on their systems (hundreds of MB) it is totally unusable. I suspect the problem is a memory leak in Python, but the only way I know of isolating the problem is pretty long, and none of the users affected know Python. I can't have them try an earlier version because the program depends on generators extensively. So, any advice? Do you think the problem could be in python? How could I go about trying to replicate this error? Of course, if I end up finding it is python, I'll try to submit a code snippet short enough to be helpful to you guys... ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-18 08:07 Message: Logged In: YES user_id=31435 Glad you're unstuck, Ben! You must use what you have learned only for good . ---------------------------------------------------------------------- Comment By: Ben Escoto (bescoto) Date: 2001-12-18 00:43 Message: Logged In: YES user_id=218965 It turns out there was a miscommunication about the reported memory leak, and, just as you guys said, I got the problem when I ran it the right way. And the problem was ALL MY FAULT, and had nothing to do with any memory leaks 2.2c1 may or may not have. So, sorry for wasting your time, but thanks for your helpful advice which helped me find the problem in just a few hours. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 14:34 Message: Logged In: YES user_id=31435 Ben, there's a Big Hammer you should know about: in a debug build of Python (but not a release build), the sys module grows a new function, sys.getobjects(). It returns a (Python) list of all objects in existence at the time it's called. When there's a leak, this list gets bigger and bigger as time goes on; of course it may *also* grow bigger and bigger as time goes on if a program is simply forgetting that it's hanging on to stuff (e.g., appending to some bookkeeping list but forgetting to clean it up will make the getobjects() list grow without bound too). It can be useful to write a little function that invokes getobjects(), crawls over the list to build a dict mapping a type to the count of the number of objects of that type in the list, and prints the dict. Then call it periodically and stare at the output. If there's some sort of leak (whether Python's fault or not), the object types involved stick out like a sore thumb (their counts keep growing). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:12 Message: Logged In: YES user_id=6380 Forget their system configuration, as long as you're *sure* that they're *in fact* using the same Python. As Tim says, the answer is in the path through your code, dependent on their data. Your program looks young and probably has lots of features you haven't really used yourself -- that's where you should look next. I know, it ain't easy. :-( ---------------------------------------------------------------------- Comment By: Ben Escoto (bescoto) Date: 2001-12-17 14:12 Message: Logged In: YES user_id=218965 Oops, I submitted my comment before seeing Tim's. As I understand it, my program does not depend on the data much, as it basically just copies files. But it is good to know that leaks are deterministic. I will stop bothering you guys and return iff I get a replicable useful leak example. ---------------------------------------------------------------------- Comment By: Ben Escoto (bescoto) Date: 2001-12-17 14:09 Message: Logged In: YES user_id=218965 I'd be willing to do all this, but, as I mentioned initially, I'm not sure how to replicate the problem. The systems that leak all seem similar to mine (which doesn't leak). For instance, people running Suse Linux 7.3 and Debian unstable have complained, but I seem to be fine under Redhat 7.2 (7.1 was also ok). Should I ask them what versions of various libraries they are using, and then try to link python to those versions on my system? Which are the likely culprits? Or is this the wrong track altogether? (Sorry, I don't know enough about C/manual memory management to understand how/why the same code would leak on one system and not on another.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 14:08 Message: Logged In: YES user_id=31435 I can't recall a case where a Python leak occurred on only some systems. Leaks are deterministic bugs: each time a leaking program is run, it generally leaks exactly the same amounts at exactly the same times. So what's different between your system and your users'? Presumably the inputs, i.e. the data getting backed up. Do you have data-dependent paths in your Python code that may not get executed on your system with your data, but would on others'? It's also possible that programs you're calling suffer data-dependent memory growth. Until you can reproduce a problem yourself, there's not much hope. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:01 Message: Logged In: YES user_id=6380 (I meant, I'll be the expert, and if it doesn't require me to load countless megabytes of data I'll even do step 2, but I need you to perform step 1, and I could use help with step 2.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 13:58 Message: Logged In: YES user_id=6380 Typically, the way to squash a leak is: 1. get a reproducible test case that grows unbounded when watched with "top" 2. try to whittle the test case down to something really simple by removing code until it no longer leaks (and then going back to the previous version :-) 3. show the test case to an expert who will make an educated guess at where in the C code to look Can you do this? ---------------------------------------------------------------------- Comment By: Ben Escoto (bescoto) Date: 2001-12-17 13:30 Message: Logged In: YES user_id=218965 I had been following some of the memory leak bugs, and had hoped that an upgrade to 2.2c1 would fix things. But I asked the affected users to upgrade, and at least one of them claims to have the same error with 2.2c1 (others haven't tried upgrading yet). I might be able to get more information out of them, but only if the procedure is relatively painless.. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 13:22 Message: Logged In: YES user_id=6380 Surely it could be Python. You're using all the latest features (nested scopes and generators, class and static methods, ...). We're not *aware* of current leaks (we stamped out a bunch a couple of weeks ago) but there probably are some. It's also possible that you are creating cycles that the garbage collector doesn't find (they would have to involve types that don't support GC; fortunately you don't use __del__ or __slots__). Are you sure they aren't using it with previous 2.2 beta versions? Some of the plugged leaks were pretty severe. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 13:17 Message: Logged In: YES user_id=38388 Since you are using * nested scopes * static methods and * generators I'd suggest to first try to find the group of features that's causing the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494320&group_id=5470 From noreply@sourceforge.net Tue Dec 18 16:36:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 08:36:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-420498 ] no docs for pydoc Message-ID: Bugs item #420498, was opened at 2001-05-01 10:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420498&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: David Goodger (goodger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: no docs for pydoc Initial Comment: The pydoc.py module lacks an entry in the Python Library Reference. There's no mention of pydoc anywhere else in the standard documentation (Doc/ dir) either. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-18 08:36 Message: Logged In: YES user_id=3066 Ping has contributed (preliminary) documentation for pydoc as patch #494622. This has been checked in for Python 2.2. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-05-02 13:26 Message: Logged In: YES user_id=3066 Raised the priority of this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420498&group_id=5470 From noreply@sourceforge.net Tue Dec 18 16:36:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 08:36:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: 3rd Party Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-18 08:36 Message: Logged In: YES user_id=85984 Tim, if you want me to pursue the issue with a FreeBSD libc internist for the good of Python, I'll do so. But otherwise, I'll let this one go as I don't plan on using Python 2.1.1 any longer. There is no evidence that this problem exists with Python 2.2. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 14:46 Message: Logged In: YES user_id=31435 Note that the same kind of mysterious bug was reported against mysql on FreeBSD (I mentioned this several notes ago). There's really no evidence of a Python bug here. Find someone knowledgeable about libc internals on FreeBSD: that's where the evidence points. They may also be able to help you figure out why you're getting a mix of threaded and non-threaded libcs; I can't say whether that's a problem, but it sure doesn't look right. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:14 Message: Logged In: YES user_id=85984 I'd say just close it out and keep it in the back of your mind in case something similar pops up in the future. I'll do the same. The bug is obscure and easy to workaround anyway. Thanks for your help with this. At the very least it has been an educational experience for me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:10 Message: Logged In: YES user_id=6380 So do you want me to keep this open? I don't expect we'll find the answer. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:07 Message: Logged In: YES user_id=85984 Your prediction is correct: [root@nightshade Python-2.1.1]# ./python df Python 2.1.1 (#1, Dec 17 2001, 15:01:24) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 21:13 Message: Logged In: YES user_id=6380 Add these three lines to Py_Main() in Modules/main.c, after the line saying "PyCompilerFlags cf;": char buffer[120]; sprintf(buffer, "%.1lx", 223L); printf("%s\n", buffer); and rebuild Python. When you run Python, it should print "df" before the standard banner. If it crashes, we've proved that Python is not the cause of the problem. But I predict that it'll work. :-( ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 21:01 Message: Logged In: YES user_id=85984 As far as the standalone program, I'm not a C programmer, (I've become Python-dependent :-), but if you can give me an idea of what it should contain, I'll give it a try. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 20:23 Message: Logged In: YES user_id=6380 Sigh. I think it's a dead end. What about a stand-alone program? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 19:09 Message: Logged In: YES user_id=85984 Tim asked whather I can verify whether I'm mixing the threaded and non-threaded versions of libc. Is the following enough to tell? $ ldd /usr/local/src/Python-2.1.1/python /usr/local/src/Python-2.1.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x280ca000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28182000) libm.so.2 => /usr/lib/libm.so.2 (0x2818b000) libc.so.4 => /usr/lib/libc.so.4 (0x281a7000) libc is the non-threaded library, and libc_r is the threaded version, so it looks like they are being mixed, yes? However, my Python 2.0.1 also looks the same way, and I'm not having any problems with it. $ ldd /usr/local/src/Python-2.0.1/python /usr/local/src/Python-2.0.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x2816c000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28224000) libm.so.2 => /usr/lib/libm.so.2 (0x2822d000) libc.so.4 => /usr/lib/libc.so.4 (0x28249000) Next, Guido asked me to check some local variables in that stack frame. See attached backtrace3.txt. And to answer your question, yes I built all the Python versions I'm testing myself. I even rebuilt 2.0.1 and 2.1.1 in the simplest manner to make sure I'm comparing them equally. (Just ./configure && make). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:47 Message: Logged In: YES user_id=31435 BTW, a google search on _thread_autoinit_dummy_decl turns up another FreeBSD bug report of a death deep in libc_r starting with a sprintf() call. It had to do with mysql, not with Python. The tracebacks in both cases look worthless to me, because (for example) _thread_autoinit_dummy_decl is an extern int in the FreeBSD source, not a function at all. This increases the suspicion that libc versions are getting mixed up (and that gdb is looking up addresses in "the wrong" libc). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 17:20 Message: Logged In: YES user_id=6380 OK, it's the second sprintf call in formatint. Can you check some local variables in that stack frame? I expect fmt to be "%.1lx", but would like to see that confirmed; x should be one of the values from your binary string: 206, 199, 166. Can you see which one? It would then be interesting to find out what a small C program with that same sprintf() does. Make sure that the C program is compiled and linked in exactly the same way as python. (What I do in such cases is I put the experimental statement in Python's main() and rebuild Python. :-) The build procedure of each Python version is somewhat different, and it's likely that each version picks slightly different compile/link options. Also, did you build all the Python versions you tried yourself? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:17 Message: Logged In: YES user_id=31435 The new backtrace is helpful (thanks!), but it just makes it harder to believe that Python is at fault. The segfault occurs four levels deep in system library functions, and from inspection there's nothing even remotely suspicious about the sprintf call that kicks it off. As Guido suggested, can you verify you're not mixing the threaded and non-threaded versions of libc? Short of that, you really need a FreeBSD libc author to help with this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 15:26 Message: Logged In: YES user_id=85984 Alright, I rebuilt Python 2.1.1 with -g, so the gdb backtrace now contains some more information. I attached backtrace2.txt which is a backtrace of the program failing when calling the hexlify() function. I tried compiling with `--with-pydebug', but then I can't reproduce the core dump for some reason. As you mention, this could have something to do with FreeBSD's libc. However, does that explain why I only have this problem with 2.1.1? On the same system, Python 1.5.2, 2.0, and 2.2c1 compiled in the same manner (simply ./configure && gmake) don't produce a core dump. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=6380 See the repeated "(no debugging symbols found)..." in the gdb output? try recompiling with -g. I strongly suspect that the traceback is lying, and we're in fact not in PyString_AsStringAndSize() when we call sprintf -- there's no sprintf call in that function (I checked the 2.1.1 source) but there is one two static functions down, in string_repr(), which is indeed called when you pickle a string object. This would match the original gdb stacktrace you reported: there's no sprintf call in _PyString_FormatLong(), but there are two in the next static function, formatint(), and it does make sense that that function would be called by the %02x format. All this makes no sense, however, because I can see nothing wrong with the arguments to sprintf here! I've heard of problems on FreeBSD having to do with different (threaded and unthreaded?) versions of libc. Could that be the issue here? Can you rebuild Python 2.1.1 with debugg flags on? (./configure --with-pydebug should do it for 2.2; I don't recall if the 2.2.1 configure supports that though -- try --help first.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Tue Dec 18 16:47:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 08:47:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: 3rd Party Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-18 08:47 Message: Logged In: YES user_id=31435 No, don't do it for Python's sake -- there's no reason to believe this has anything to do with Python, but is an obscure bug in the FreeBSD libc (which *has* been triggered by non-Python apps too, such as mysql). So I predict you'll see it again; if you pursued it, it would be for the benefit of FreeBSD users. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-18 08:36 Message: Logged In: YES user_id=85984 Tim, if you want me to pursue the issue with a FreeBSD libc internist for the good of Python, I'll do so. But otherwise, I'll let this one go as I don't plan on using Python 2.1.1 any longer. There is no evidence that this problem exists with Python 2.2. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 14:46 Message: Logged In: YES user_id=31435 Note that the same kind of mysterious bug was reported against mysql on FreeBSD (I mentioned this several notes ago). There's really no evidence of a Python bug here. Find someone knowledgeable about libc internals on FreeBSD: that's where the evidence points. They may also be able to help you figure out why you're getting a mix of threaded and non-threaded libcs; I can't say whether that's a problem, but it sure doesn't look right. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:14 Message: Logged In: YES user_id=85984 I'd say just close it out and keep it in the back of your mind in case something similar pops up in the future. I'll do the same. The bug is obscure and easy to workaround anyway. Thanks for your help with this. At the very least it has been an educational experience for me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:10 Message: Logged In: YES user_id=6380 So do you want me to keep this open? I don't expect we'll find the answer. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:07 Message: Logged In: YES user_id=85984 Your prediction is correct: [root@nightshade Python-2.1.1]# ./python df Python 2.1.1 (#1, Dec 17 2001, 15:01:24) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 21:13 Message: Logged In: YES user_id=6380 Add these three lines to Py_Main() in Modules/main.c, after the line saying "PyCompilerFlags cf;": char buffer[120]; sprintf(buffer, "%.1lx", 223L); printf("%s\n", buffer); and rebuild Python. When you run Python, it should print "df" before the standard banner. If it crashes, we've proved that Python is not the cause of the problem. But I predict that it'll work. :-( ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 21:01 Message: Logged In: YES user_id=85984 As far as the standalone program, I'm not a C programmer, (I've become Python-dependent :-), but if you can give me an idea of what it should contain, I'll give it a try. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 20:23 Message: Logged In: YES user_id=6380 Sigh. I think it's a dead end. What about a stand-alone program? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 19:09 Message: Logged In: YES user_id=85984 Tim asked whather I can verify whether I'm mixing the threaded and non-threaded versions of libc. Is the following enough to tell? $ ldd /usr/local/src/Python-2.1.1/python /usr/local/src/Python-2.1.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x280ca000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28182000) libm.so.2 => /usr/lib/libm.so.2 (0x2818b000) libc.so.4 => /usr/lib/libc.so.4 (0x281a7000) libc is the non-threaded library, and libc_r is the threaded version, so it looks like they are being mixed, yes? However, my Python 2.0.1 also looks the same way, and I'm not having any problems with it. $ ldd /usr/local/src/Python-2.0.1/python /usr/local/src/Python-2.0.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x2816c000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28224000) libm.so.2 => /usr/lib/libm.so.2 (0x2822d000) libc.so.4 => /usr/lib/libc.so.4 (0x28249000) Next, Guido asked me to check some local variables in that stack frame. See attached backtrace3.txt. And to answer your question, yes I built all the Python versions I'm testing myself. I even rebuilt 2.0.1 and 2.1.1 in the simplest manner to make sure I'm comparing them equally. (Just ./configure && make). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:47 Message: Logged In: YES user_id=31435 BTW, a google search on _thread_autoinit_dummy_decl turns up another FreeBSD bug report of a death deep in libc_r starting with a sprintf() call. It had to do with mysql, not with Python. The tracebacks in both cases look worthless to me, because (for example) _thread_autoinit_dummy_decl is an extern int in the FreeBSD source, not a function at all. This increases the suspicion that libc versions are getting mixed up (and that gdb is looking up addresses in "the wrong" libc). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 17:20 Message: Logged In: YES user_id=6380 OK, it's the second sprintf call in formatint. Can you check some local variables in that stack frame? I expect fmt to be "%.1lx", but would like to see that confirmed; x should be one of the values from your binary string: 206, 199, 166. Can you see which one? It would then be interesting to find out what a small C program with that same sprintf() does. Make sure that the C program is compiled and linked in exactly the same way as python. (What I do in such cases is I put the experimental statement in Python's main() and rebuild Python. :-) The build procedure of each Python version is somewhat different, and it's likely that each version picks slightly different compile/link options. Also, did you build all the Python versions you tried yourself? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:17 Message: Logged In: YES user_id=31435 The new backtrace is helpful (thanks!), but it just makes it harder to believe that Python is at fault. The segfault occurs four levels deep in system library functions, and from inspection there's nothing even remotely suspicious about the sprintf call that kicks it off. As Guido suggested, can you verify you're not mixing the threaded and non-threaded versions of libc? Short of that, you really need a FreeBSD libc author to help with this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 15:26 Message: Logged In: YES user_id=85984 Alright, I rebuilt Python 2.1.1 with -g, so the gdb backtrace now contains some more information. I attached backtrace2.txt which is a backtrace of the program failing when calling the hexlify() function. I tried compiling with `--with-pydebug', but then I can't reproduce the core dump for some reason. As you mention, this could have something to do with FreeBSD's libc. However, does that explain why I only have this problem with 2.1.1? On the same system, Python 1.5.2, 2.0, and 2.2c1 compiled in the same manner (simply ./configure && gmake) don't produce a core dump. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=6380 See the repeated "(no debugging symbols found)..." in the gdb output? try recompiling with -g. I strongly suspect that the traceback is lying, and we're in fact not in PyString_AsStringAndSize() when we call sprintf -- there's no sprintf call in that function (I checked the 2.1.1 source) but there is one two static functions down, in string_repr(), which is indeed called when you pickle a string object. This would match the original gdb stacktrace you reported: there's no sprintf call in _PyString_FormatLong(), but there are two in the next static function, formatint(), and it does make sense that that function would be called by the %02x format. All this makes no sense, however, because I can see nothing wrong with the arguments to sprintf here! I've heard of problems on FreeBSD having to do with different (threaded and unthreaded?) versions of libc. Could that be the issue here? Can you rebuild Python 2.1.1 with debugg flags on? (./configure --with-pydebug should do it for 2.2; I don't recall if the 2.2.1 configure supports that though -- try --help first.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Tue Dec 18 16:56:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 08:56:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-493628 ] import not pythonic in 2.1.1 Message-ID: Bugs item #493628, was opened at 2001-12-15 03:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: import not pythonic in 2.1.1 Initial Comment: Take a package 'aPackage', which contains a sub-package 'aSubPackage' that in turn contains a module 'aModule' that defines a class 'aClass'. If I do: import aPackage.aSubPackage print aPackage.aSubPackage.aModule I get: Traceback (most recent call last): File "x.py", line xx, in ? print aPackage.aSubPackage.aModule AttributeError: 'aPackage.aSubPackage' module has no attribute 'aModule' A yet, if I do: import aPackage.aSubPackage.aModule print aPackage.aSubPackage.aModule I get: ...as expected, which is very confusing and doesn't feel 'right' :-S ---------------------------------------------------------------------- >Comment By: Chris Withers (fresh) Date: 2001-12-18 08:56 Message: Logged In: YES user_id=24723 I've added this feature request to PEP 42. ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-18 08:56 Message: Logged In: YES user_id=24723 Thanks for the pointers :-) I would use pickling, but I'm not sure MySQL database connections would take too well to being pickled :-S (an attribute of the object to be stored is a mySQLdb database connection) And yeah, reading through this, it's __import__ not import that's confusing. Why is the m = sys.modules[module] needed? Also, when using syntax like import item.subitem.subsubitem, why that last subitem be a class or function? cheers, Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 06:35 Message: Logged In: YES user_id=6380 Yeah, Zope has many __init__.py files that I consider immoral. We're fixing this in Zope3. :-) What you're doing is similar to what pickle does, by the way. Can't you store pickles? Several tips: - instead of getting str(object.__class__) and then parsing the result, use module, klass = k.__class__.__name__, k.__class__.__module__ - __import__ *does* support packages, if you do it right: __import__(module) m = sys.modules[module] - Instead of exec("k ="...), use k = getattr(m, klass) So please don't blame this in import. :-) ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-17 03:41 Message: Logged In: YES user_id=24723 > OK, the motivation is that importing a package shouldn't > recursively import all its submodules -- else importing a > top-level package could do an immense amount of work. Fair enough, I guess I don't use any packages where this is true, apart from Zope, but "import Zope" certainly takes some time anyway ;-) To answer Tim's question, I need to store the minimum amount of information necessary to re-constitute an object in a MySQL database. The attributes that need to persist are easy, just shove 'em in columns. However, to actually create the object, I need to instantiate a class. With the above restrictions, I've ended doing: k = str(object.__class__) i = k.rindex('.') module = k[:i] klass = k[i+1:] ..and storing module and class in columns. Then, to reconstitute the object, I do: exec("import "+module) exec("k = "+module+'.'+klass) object=k() the second exec is needed because import fails if the last name isn't a module or package. the first exec is needed because: 1. __import__ doesn't handle . seperated names to import 2. If I use __import__ to import the top level package, none of the modules/packages below it are imported so getattr(module,klass) fails with an AttributeError Thinking about it, if (1) worked, then I probably wouldn't have a problem... That said, if there's a simpler way to do all this, I'd happily use that ;-) cheers, Chris ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-16 12:45 Message: Logged In: YES user_id=24723 > I'm not sure what to do with your whine about being one of > the many who find it counter-intuitive. Can you explain how > you would like it to behave? Sorry, that was me being unclear... I meant I am probably one of the few who finds it unintuitive ;-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:38 Message: Logged In: YES user_id=6380 OK, the motivation is that importing a package shouldn't recursively import all its submodules -- else importing a top-level package could do an immense amount of work. The motivation for the thing you quote is less clear -- it follows from the requirement that in "import ", "" refers to a module (where a package is a special case of a module). I'm not sure what to do with your whine about being one of the many who find it counter-intuitive. Can you explain how you would like it to behave? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 10:03 Message: Logged In: YES user_id=31435 Chris, why do you think you need to use an exec stmt? You haven't shown an example of why it's needed, and it sure isn't obvious. Modules must be imported, and importing a module M requires an import stmt whose last path component is M -- that's about all there is to it. ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-16 04:58 Message: Logged In: YES user_id=24723 Well, I read it, and it explains the history, but it doesn't give reasons, particularly for: > Contrarily, when using syntax like import item.subitem.subsubitem, each item except for the last must be a package; the last item can be a module > or a package but can't be a class or function or variable defined in the previous item. ...or for the above stuff. But, while I find it counter-intuitive (and means I have to use unpleasant exec statements), I am but one voice among many who probably feel differently so I'll just accept it as one of the things i don't like about python... thanks for your time :-) Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 09:46 Message: Logged In: YES user_id=6380 http://www.python.org/doc/essays/packages.html ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-15 09:15 Message: Logged In: YES user_id=24723 Okay, if it's intended, that means there's a good reason for it... ...where can I look for enlightenment as to what that is? cheers, Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 07:39 Message: Logged In: YES user_id=6380 Better adjust your intuition. :-) This is as intended. Attributes of packages that are *modules* are only loaded when the corresponding module is explicitly imported (by you, or by some other code, e.g. the package's __init__.py). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 From noreply@sourceforge.net Tue Dec 18 16:59:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 08:59:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-493628 ] import not pythonic in 2.1.1 Message-ID: Bugs item #493628, was opened at 2001-12-15 03:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: import not pythonic in 2.1.1 Initial Comment: Take a package 'aPackage', which contains a sub-package 'aSubPackage' that in turn contains a module 'aModule' that defines a class 'aClass'. If I do: import aPackage.aSubPackage print aPackage.aSubPackage.aModule I get: Traceback (most recent call last): File "x.py", line xx, in ? print aPackage.aSubPackage.aModule AttributeError: 'aPackage.aSubPackage' module has no attribute 'aModule' A yet, if I do: import aPackage.aSubPackage.aModule print aPackage.aSubPackage.aModule I get: ...as expected, which is very confusing and doesn't feel 'right' :-S ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 08:59 Message: Logged In: YES user_id=6380 > Comment By: Chris Withers (fresh) > > I've added this feature request to PEP 42. No you haven't. :-) ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-18 08:56 Message: Logged In: YES user_id=24723 I've added this feature request to PEP 42. ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-18 08:56 Message: Logged In: YES user_id=24723 Thanks for the pointers :-) I would use pickling, but I'm not sure MySQL database connections would take too well to being pickled :-S (an attribute of the object to be stored is a mySQLdb database connection) And yeah, reading through this, it's __import__ not import that's confusing. Why is the m = sys.modules[module] needed? Also, when using syntax like import item.subitem.subsubitem, why that last subitem be a class or function? cheers, Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 06:35 Message: Logged In: YES user_id=6380 Yeah, Zope has many __init__.py files that I consider immoral. We're fixing this in Zope3. :-) What you're doing is similar to what pickle does, by the way. Can't you store pickles? Several tips: - instead of getting str(object.__class__) and then parsing the result, use module, klass = k.__class__.__name__, k.__class__.__module__ - __import__ *does* support packages, if you do it right: __import__(module) m = sys.modules[module] - Instead of exec("k ="...), use k = getattr(m, klass) So please don't blame this in import. :-) ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-17 03:41 Message: Logged In: YES user_id=24723 > OK, the motivation is that importing a package shouldn't > recursively import all its submodules -- else importing a > top-level package could do an immense amount of work. Fair enough, I guess I don't use any packages where this is true, apart from Zope, but "import Zope" certainly takes some time anyway ;-) To answer Tim's question, I need to store the minimum amount of information necessary to re-constitute an object in a MySQL database. The attributes that need to persist are easy, just shove 'em in columns. However, to actually create the object, I need to instantiate a class. With the above restrictions, I've ended doing: k = str(object.__class__) i = k.rindex('.') module = k[:i] klass = k[i+1:] ..and storing module and class in columns. Then, to reconstitute the object, I do: exec("import "+module) exec("k = "+module+'.'+klass) object=k() the second exec is needed because import fails if the last name isn't a module or package. the first exec is needed because: 1. __import__ doesn't handle . seperated names to import 2. If I use __import__ to import the top level package, none of the modules/packages below it are imported so getattr(module,klass) fails with an AttributeError Thinking about it, if (1) worked, then I probably wouldn't have a problem... That said, if there's a simpler way to do all this, I'd happily use that ;-) cheers, Chris ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-16 12:45 Message: Logged In: YES user_id=24723 > I'm not sure what to do with your whine about being one of > the many who find it counter-intuitive. Can you explain how > you would like it to behave? Sorry, that was me being unclear... I meant I am probably one of the few who finds it unintuitive ;-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:38 Message: Logged In: YES user_id=6380 OK, the motivation is that importing a package shouldn't recursively import all its submodules -- else importing a top-level package could do an immense amount of work. The motivation for the thing you quote is less clear -- it follows from the requirement that in "import ", "" refers to a module (where a package is a special case of a module). I'm not sure what to do with your whine about being one of the many who find it counter-intuitive. Can you explain how you would like it to behave? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 10:03 Message: Logged In: YES user_id=31435 Chris, why do you think you need to use an exec stmt? You haven't shown an example of why it's needed, and it sure isn't obvious. Modules must be imported, and importing a module M requires an import stmt whose last path component is M -- that's about all there is to it. ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-16 04:58 Message: Logged In: YES user_id=24723 Well, I read it, and it explains the history, but it doesn't give reasons, particularly for: > Contrarily, when using syntax like import item.subitem.subsubitem, each item except for the last must be a package; the last item can be a module > or a package but can't be a class or function or variable defined in the previous item. ...or for the above stuff. But, while I find it counter-intuitive (and means I have to use unpleasant exec statements), I am but one voice among many who probably feel differently so I'll just accept it as one of the things i don't like about python... thanks for your time :-) Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 09:46 Message: Logged In: YES user_id=6380 http://www.python.org/doc/essays/packages.html ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-15 09:15 Message: Logged In: YES user_id=24723 Okay, if it's intended, that means there's a good reason for it... ...where can I look for enlightenment as to what that is? cheers, Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 07:39 Message: Logged In: YES user_id=6380 Better adjust your intuition. :-) This is as intended. Attributes of packages that are *modules* are only loaded when the corresponding module is explicitly imported (by you, or by some other code, e.g. the package's __init__.py). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 From noreply@sourceforge.net Tue Dec 18 17:04:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 09:04:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-493628 ] import not pythonic in 2.1.1 Message-ID: Bugs item #493628, was opened at 2001-12-15 03:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Closed >Resolution: Remind Priority: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: import not pythonic in 2.1.1 Initial Comment: Take a package 'aPackage', which contains a sub-package 'aSubPackage' that in turn contains a module 'aModule' that defines a class 'aClass'. If I do: import aPackage.aSubPackage print aPackage.aSubPackage.aModule I get: Traceback (most recent call last): File "x.py", line xx, in ? print aPackage.aSubPackage.aModule AttributeError: 'aPackage.aSubPackage' module has no attribute 'aModule' A yet, if I do: import aPackage.aSubPackage.aModule print aPackage.aSubPackage.aModule I get: ...as expected, which is very confusing and doesn't feel 'right' :-S ---------------------------------------------------------------------- >Comment By: Chris Withers (fresh) Date: 2001-12-18 09:04 Message: Logged In: YES user_id=24723 Indeed. Damn SF drop downs and M$ mouse wheels ;-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 08:59 Message: Logged In: YES user_id=6380 > Comment By: Chris Withers (fresh) > > I've added this feature request to PEP 42. No you haven't. :-) ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-18 08:56 Message: Logged In: YES user_id=24723 I've added this feature request to PEP 42. ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-18 08:56 Message: Logged In: YES user_id=24723 Thanks for the pointers :-) I would use pickling, but I'm not sure MySQL database connections would take too well to being pickled :-S (an attribute of the object to be stored is a mySQLdb database connection) And yeah, reading through this, it's __import__ not import that's confusing. Why is the m = sys.modules[module] needed? Also, when using syntax like import item.subitem.subsubitem, why that last subitem be a class or function? cheers, Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 06:35 Message: Logged In: YES user_id=6380 Yeah, Zope has many __init__.py files that I consider immoral. We're fixing this in Zope3. :-) What you're doing is similar to what pickle does, by the way. Can't you store pickles? Several tips: - instead of getting str(object.__class__) and then parsing the result, use module, klass = k.__class__.__name__, k.__class__.__module__ - __import__ *does* support packages, if you do it right: __import__(module) m = sys.modules[module] - Instead of exec("k ="...), use k = getattr(m, klass) So please don't blame this in import. :-) ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-17 03:41 Message: Logged In: YES user_id=24723 > OK, the motivation is that importing a package shouldn't > recursively import all its submodules -- else importing a > top-level package could do an immense amount of work. Fair enough, I guess I don't use any packages where this is true, apart from Zope, but "import Zope" certainly takes some time anyway ;-) To answer Tim's question, I need to store the minimum amount of information necessary to re-constitute an object in a MySQL database. The attributes that need to persist are easy, just shove 'em in columns. However, to actually create the object, I need to instantiate a class. With the above restrictions, I've ended doing: k = str(object.__class__) i = k.rindex('.') module = k[:i] klass = k[i+1:] ..and storing module and class in columns. Then, to reconstitute the object, I do: exec("import "+module) exec("k = "+module+'.'+klass) object=k() the second exec is needed because import fails if the last name isn't a module or package. the first exec is needed because: 1. __import__ doesn't handle . seperated names to import 2. If I use __import__ to import the top level package, none of the modules/packages below it are imported so getattr(module,klass) fails with an AttributeError Thinking about it, if (1) worked, then I probably wouldn't have a problem... That said, if there's a simpler way to do all this, I'd happily use that ;-) cheers, Chris ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-16 12:45 Message: Logged In: YES user_id=24723 > I'm not sure what to do with your whine about being one of > the many who find it counter-intuitive. Can you explain how > you would like it to behave? Sorry, that was me being unclear... I meant I am probably one of the few who finds it unintuitive ;-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:38 Message: Logged In: YES user_id=6380 OK, the motivation is that importing a package shouldn't recursively import all its submodules -- else importing a top-level package could do an immense amount of work. The motivation for the thing you quote is less clear -- it follows from the requirement that in "import ", "" refers to a module (where a package is a special case of a module). I'm not sure what to do with your whine about being one of the many who find it counter-intuitive. Can you explain how you would like it to behave? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 10:03 Message: Logged In: YES user_id=31435 Chris, why do you think you need to use an exec stmt? You haven't shown an example of why it's needed, and it sure isn't obvious. Modules must be imported, and importing a module M requires an import stmt whose last path component is M -- that's about all there is to it. ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-16 04:58 Message: Logged In: YES user_id=24723 Well, I read it, and it explains the history, but it doesn't give reasons, particularly for: > Contrarily, when using syntax like import item.subitem.subsubitem, each item except for the last must be a package; the last item can be a module > or a package but can't be a class or function or variable defined in the previous item. ...or for the above stuff. But, while I find it counter-intuitive (and means I have to use unpleasant exec statements), I am but one voice among many who probably feel differently so I'll just accept it as one of the things i don't like about python... thanks for your time :-) Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 09:46 Message: Logged In: YES user_id=6380 http://www.python.org/doc/essays/packages.html ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2001-12-15 09:15 Message: Logged In: YES user_id=24723 Okay, if it's intended, that means there's a good reason for it... ...where can I look for enlightenment as to what that is? cheers, Chris ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 07:39 Message: Logged In: YES user_id=6380 Better adjust your intuition. :-) This is as intended. Attributes of packages that are *modules* are only loaded when the corresponding module is explicitly imported (by you, or by some other code, e.g. the package's __init__.py). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493628&group_id=5470 From noreply@sourceforge.net Tue Dec 18 17:07:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 09:07:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: 3rd Party Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-18 09:06 Message: Logged In: YES user_id=85984 Well, this bug does have to do with Python if only in the configure scripts and such. There is something in Python 2.1.1 that is triggering this that isn't in Python 1.5.2, 2.0 or 2.2. I do agree though that the core of the problem is in FreeBSD, Python 2.1.1 is just bringing it to the surface. There is also some evidence that this problem is fixed in later FreeBSD releases. For example, I can't reproduce the problem on a 4.4-STABLE box (a couple months newer than my 4.4-RELEASE boxes). It would be interesting to see if this problem "dissapears" when I upgrade to 4.5-RELEASE next month. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-18 08:47 Message: Logged In: YES user_id=31435 No, don't do it for Python's sake -- there's no reason to believe this has anything to do with Python, but is an obscure bug in the FreeBSD libc (which *has* been triggered by non-Python apps too, such as mysql). So I predict you'll see it again; if you pursued it, it would be for the benefit of FreeBSD users. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-18 08:36 Message: Logged In: YES user_id=85984 Tim, if you want me to pursue the issue with a FreeBSD libc internist for the good of Python, I'll do so. But otherwise, I'll let this one go as I don't plan on using Python 2.1.1 any longer. There is no evidence that this problem exists with Python 2.2. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 14:46 Message: Logged In: YES user_id=31435 Note that the same kind of mysterious bug was reported against mysql on FreeBSD (I mentioned this several notes ago). There's really no evidence of a Python bug here. Find someone knowledgeable about libc internals on FreeBSD: that's where the evidence points. They may also be able to help you figure out why you're getting a mix of threaded and non-threaded libcs; I can't say whether that's a problem, but it sure doesn't look right. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:14 Message: Logged In: YES user_id=85984 I'd say just close it out and keep it in the back of your mind in case something similar pops up in the future. I'll do the same. The bug is obscure and easy to workaround anyway. Thanks for your help with this. At the very least it has been an educational experience for me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:10 Message: Logged In: YES user_id=6380 So do you want me to keep this open? I don't expect we'll find the answer. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:07 Message: Logged In: YES user_id=85984 Your prediction is correct: [root@nightshade Python-2.1.1]# ./python df Python 2.1.1 (#1, Dec 17 2001, 15:01:24) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 21:13 Message: Logged In: YES user_id=6380 Add these three lines to Py_Main() in Modules/main.c, after the line saying "PyCompilerFlags cf;": char buffer[120]; sprintf(buffer, "%.1lx", 223L); printf("%s\n", buffer); and rebuild Python. When you run Python, it should print "df" before the standard banner. If it crashes, we've proved that Python is not the cause of the problem. But I predict that it'll work. :-( ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 21:01 Message: Logged In: YES user_id=85984 As far as the standalone program, I'm not a C programmer, (I've become Python-dependent :-), but if you can give me an idea of what it should contain, I'll give it a try. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 20:23 Message: Logged In: YES user_id=6380 Sigh. I think it's a dead end. What about a stand-alone program? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 19:09 Message: Logged In: YES user_id=85984 Tim asked whather I can verify whether I'm mixing the threaded and non-threaded versions of libc. Is the following enough to tell? $ ldd /usr/local/src/Python-2.1.1/python /usr/local/src/Python-2.1.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x280ca000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28182000) libm.so.2 => /usr/lib/libm.so.2 (0x2818b000) libc.so.4 => /usr/lib/libc.so.4 (0x281a7000) libc is the non-threaded library, and libc_r is the threaded version, so it looks like they are being mixed, yes? However, my Python 2.0.1 also looks the same way, and I'm not having any problems with it. $ ldd /usr/local/src/Python-2.0.1/python /usr/local/src/Python-2.0.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x2816c000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28224000) libm.so.2 => /usr/lib/libm.so.2 (0x2822d000) libc.so.4 => /usr/lib/libc.so.4 (0x28249000) Next, Guido asked me to check some local variables in that stack frame. See attached backtrace3.txt. And to answer your question, yes I built all the Python versions I'm testing myself. I even rebuilt 2.0.1 and 2.1.1 in the simplest manner to make sure I'm comparing them equally. (Just ./configure && make). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:47 Message: Logged In: YES user_id=31435 BTW, a google search on _thread_autoinit_dummy_decl turns up another FreeBSD bug report of a death deep in libc_r starting with a sprintf() call. It had to do with mysql, not with Python. The tracebacks in both cases look worthless to me, because (for example) _thread_autoinit_dummy_decl is an extern int in the FreeBSD source, not a function at all. This increases the suspicion that libc versions are getting mixed up (and that gdb is looking up addresses in "the wrong" libc). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 17:20 Message: Logged In: YES user_id=6380 OK, it's the second sprintf call in formatint. Can you check some local variables in that stack frame? I expect fmt to be "%.1lx", but would like to see that confirmed; x should be one of the values from your binary string: 206, 199, 166. Can you see which one? It would then be interesting to find out what a small C program with that same sprintf() does. Make sure that the C program is compiled and linked in exactly the same way as python. (What I do in such cases is I put the experimental statement in Python's main() and rebuild Python. :-) The build procedure of each Python version is somewhat different, and it's likely that each version picks slightly different compile/link options. Also, did you build all the Python versions you tried yourself? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:17 Message: Logged In: YES user_id=31435 The new backtrace is helpful (thanks!), but it just makes it harder to believe that Python is at fault. The segfault occurs four levels deep in system library functions, and from inspection there's nothing even remotely suspicious about the sprintf call that kicks it off. As Guido suggested, can you verify you're not mixing the threaded and non-threaded versions of libc? Short of that, you really need a FreeBSD libc author to help with this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 15:26 Message: Logged In: YES user_id=85984 Alright, I rebuilt Python 2.1.1 with -g, so the gdb backtrace now contains some more information. I attached backtrace2.txt which is a backtrace of the program failing when calling the hexlify() function. I tried compiling with `--with-pydebug', but then I can't reproduce the core dump for some reason. As you mention, this could have something to do with FreeBSD's libc. However, does that explain why I only have this problem with 2.1.1? On the same system, Python 1.5.2, 2.0, and 2.2c1 compiled in the same manner (simply ./configure && gmake) don't produce a core dump. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=6380 See the repeated "(no debugging symbols found)..." in the gdb output? try recompiling with -g. I strongly suspect that the traceback is lying, and we're in fact not in PyString_AsStringAndSize() when we call sprintf -- there's no sprintf call in that function (I checked the 2.1.1 source) but there is one two static functions down, in string_repr(), which is indeed called when you pickle a string object. This would match the original gdb stacktrace you reported: there's no sprintf call in _PyString_FormatLong(), but there are two in the next static function, formatint(), and it does make sense that that function would be called by the %02x format. All this makes no sense, however, because I can see nothing wrong with the arguments to sprintf here! I've heard of problems on FreeBSD having to do with different (threaded and unthreaded?) versions of libc. Could that be the issue here? Can you rebuild Python 2.1.1 with debugg flags on? (./configure --with-pydebug should do it for 2.2; I don't recall if the 2.2.1 configure supports that though -- try --help first.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Tue Dec 18 17:23:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 09:23:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-494668 ] PUSH() should assert-fail on overflow Message-ID: Bugs item #494668, was opened at 2001-12-18 09:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494668&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: PUSH() should assert-fail on overflow Initial Comment: ceval's PUSH macro happily writes beyond the end of the eval stack if not enough space has been reserved for it. While there are no known instances of stack overflow under normal operation (it "should be" impossible), code objects produced by the Python compiler package have failed to reserve enough stack space, leading to the usual range of corrupted-memory problems. In a debug build the PUSH macro should verify that stack overflow doesn't occur. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494668&group_id=5470 From noreply@sourceforge.net Tue Dec 18 17:34:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 09:34:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-458447 ] New httplib lacks documentation Message-ID: Bugs item #458447, was opened at 2001-09-04 10:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=458447&group_id=5470 Category: Documentation Group: None >Status: Open Resolution: Fixed Priority: 6 Submitted By: Rich Salz (rsalz) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: New httplib lacks documentation Initial Comment: urllib should allow the user to set the content-type. This would allow applications to do more than just "forms posting" -- e.g., use it to make SOAP requests. The attached patch allows that. ---------------------------------------------------------------------- >Comment By: Rich Salz (rsalz) Date: 2001-12-18 09:34 Message: Logged In: YES user_id=36737 The **x509 parameter of HTTPSConnection needs to be documented. It's a dictionary with at most two keys. key_file specifies the PEM-fformat private key file and cert_file specifies contains the PEM-format certificate and optional list of CA's in the cert chain. (I believe there's an open defect for SSL sockets not being docuemented.) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-29 22:07 Message: Logged In: YES user_id=3066 Checked in as Doc/lib/libhttplib.tex revision 1.28. Updates contributed by Kalle Svensson. Thanks, Kalle! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-26 13:51 Message: Logged In: YES user_id=3066 I have contributed docs for the new version waiting for review in my inbox; these should be checked in this week. Bumping priority so this stays visible to me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 08:37 Message: Logged In: YES user_id=6380 Fred: it turns out the httplib docs still document the old version of the module. The new version is considerably more powerful, and is essentially undocumented. Maybe you can shame Greg Stein into providing some docs, or maybe you can convert the copious docstrings to LaTeX. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-09-04 20:45 Message: Logged In: YES user_id=44345 I'm not sure why you'd want to program SOAP (or XMLRPC, for that matter) directly. You would (normally) only use those protocols through special-purpose modules like SOAP.py or xmlrpclib.py, both of which talk to httplib I believe. I don't see that allowing the Content-Type: header to be overridden at the urllib level is all that necessary. If you're going to want to mess with Content-Type: you're probably going to want to mess with other headers as well. ---------------------------------------------------------------------- Comment By: Rich Salz (rsalz) Date: 2001-09-04 19:02 Message: Logged In: YES user_id=36737 I created this bug because urllib didn't let you set the content-type header. Guido pointed out that I should be using httplib. I didn't use httplib because I didn't know until I read the source, that httplib had an https object that used SSL. So I guess "document the https object" is what this has mutated into. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-09-04 14:03 Message: Logged In: YES user_id=3066 It's not at all clear what sort of documentation update is needed. What did you have in mind? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-04 12:20 Message: Logged In: YES user_id=6380 Please don't Delete requests. Please don't Close them unless you are a project manager (I consider it a SF bug that the submitter can decide to close a bug report if they happen to have admin perms on another project). I've reopened this and recategorized as Doc and assigned to Fred so he can see if the httplib docs need to be updated. ---------------------------------------------------------------------- Comment By: Rich Salz (rsalz) Date: 2001-09-04 12:16 Message: Logged In: YES user_id=36737 Okay, I'll accept that. Had HTTP documented that it included HTTPS I wouldn't have made the initial mistake. :) Let me know if you want the diff. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-04 11:20 Message: Logged In: YES user_id=6380 Isn't SOAP an HTTP application? Then you shouldn't be using urllib, but httplib. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-04 11:20 Message: Logged In: YES user_id=6380 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=458447&group_id=5470 From noreply@sourceforge.net Tue Dec 18 19:55:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 11:55:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-494738 ] binascii_b2a_base64 overwrites memory Message-ID: Bugs item #494738, was opened at 2001-12-18 11:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494738&group_id=5470 Category: Python Library Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: David Costanzo (david_costanzo) Assigned to: Nobody/Anonymous (nobody) Summary: binascii_b2a_base64 overwrites memory Initial Comment: I'm maintaining code that is based on the binascii.c found in Python-2.1.1/Modules directory (Python 2.1.. The code has a memory bounds overwrite when encoding binascii_b2a_base64 for small chunks of binary data. The bug in my code is that allocates an incorrect upper bound. For each byte of binary data, it allocates two bytes for the ascii format. It looks like it really needs four bytes of binary data for every three bytes of binary data, rounded up, plus one byte for the courtesy newline. The analogous line of code in binascii.c is line 425. As a test case, the ascii representation of the one byte binary string 'b' takes five characters 'Yg==\n', not twice the lenght of the original. (There are two two bytes of signal, two pad bytes, and a courtesy newline.) My code now uses ((bin_len + 2) / 3) * 4 + 1) as the buffer length. I ran Python 2.0 under a heap validator program called Purify and attempted to reproduce the memory overwrite, but I was unable to. This probably means that this bug does not exist in Python. I am submitting it as a bug anyway, in case Python is using a memory heap that confuses Purify. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494738&group_id=5470 From noreply@sourceforge.net Tue Dec 18 20:23:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 12:23:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-489709 ] Building Fails under Cygwin Message-ID: Bugs item #489709, was opened at 2001-12-05 20:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489709&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Michael Hudson (mwh) Summary: Building Fails under Cygwin Initial Comment: Even after applying the h2py patch, building under Cygwin ends with the following error: building 'gdbm' extension gcc -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT - I. -I/cygdrive/e/Python-2.2b2/./Include - I/usr/local/include -IInclude/ -c /cygdrive/e/Python- 2.2b2/Modules/gdbmmodule.c -o build/temp.cygwin-1.3. 5-i686-2.2/gdbmmodule.o e:\buildpy\python.exe: *** unable to remap C:\cygnus\bin\cygssl.dll to same address as parent -- 0x1A7C0000 0 [main] python 1292 sync_with_child: child 1108 (0xF0) died before initialization with status code 0x1 25901 [main] python 1292 sync_with_child: *** child state child loading dlls error: Resource temporarily unavailable make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- Comment By: Steve Holden (holdenweb) Date: 2001-12-18 12:23 Message: Logged In: YES user_id=88157 The same build failure is observed under Win98 for 2.2c1. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 09:02 Message: Logged In: YES user_id=6656 FWIW, it seems building _socket statically solves the problem. This may suffice to for 2.2. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 05:13 Message: Logged In: YES user_id=6656 (sf keeps logging me out every ten minutes, grr) This is being hashed out on the cygwin list. It's unfortunately not obvious that it will be fixed in the 2.2 timeframe. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-06 07:16 Message: Logged In: YES user_id=6656 Hmm. Seems pretty similar to mine. I'll bug Jason Tishler and see if he knows anything about it. ---------------------------------------------------------------------- Comment By: David Abrahams (david_abrahams) Date: 2001-12-06 07:12 Message: Logged In: YES user_id=52572 I'm using Win2K CYGWIN_NT-5.0 MOREPIE 1.3.5(0.47/3/2) 2001-11-13 23:16 i686 unknown And I've built and installed GCC 3.0.2, thought the Python build seems to use 2.95.x anyway. I am not on the cygwin mailing list, sorry ;-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-06 05:53 Message: Logged In: YES user_id=6656 Just to say that I'm seeing this too. What OS? I'm on NT4 SP6. Which cygwin? I'm [Administrator@MATHS-PC150 QUAKE]$ uname -a CYGWIN_NT-4.0 MATHS-PC150 1.3.6(0.47/3/2) 2001-12-03 15:41 i686 unknown I was actually assuming this was a cygwin bug. Are you on the cygwin mailing list? Maybe you could try raising it there? I would, but I *really* don't need another subscription to a high-volume mailing list right now. PS: can we add jason as a developer? then we can assign bugs to him . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489709&group_id=5470 From noreply@sourceforge.net Tue Dec 18 20:28:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 12:28:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-489709 ] Building Fails under Cygwin Message-ID: Bugs item #489709, was opened at 2001-12-05 20:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489709&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Michael Hudson (mwh) Summary: Building Fails under Cygwin Initial Comment: Even after applying the h2py patch, building under Cygwin ends with the following error: building 'gdbm' extension gcc -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT - I. -I/cygdrive/e/Python-2.2b2/./Include - I/usr/local/include -IInclude/ -c /cygdrive/e/Python- 2.2b2/Modules/gdbmmodule.c -o build/temp.cygwin-1.3. 5-i686-2.2/gdbmmodule.o e:\buildpy\python.exe: *** unable to remap C:\cygnus\bin\cygssl.dll to same address as parent -- 0x1A7C0000 0 [main] python 1292 sync_with_child: child 1108 (0xF0) died before initialization with status code 0x1 25901 [main] python 1292 sync_with_child: *** child state child loading dlls error: Resource temporarily unavailable make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-18 12:28 Message: Logged In: YES user_id=6656 Does the same workaround work? Is so, do all tests pass? ---------------------------------------------------------------------- Comment By: Steve Holden (holdenweb) Date: 2001-12-18 12:23 Message: Logged In: YES user_id=88157 The same build failure is observed under Win98 for 2.2c1. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 09:02 Message: Logged In: YES user_id=6656 FWIW, it seems building _socket statically solves the problem. This may suffice to for 2.2. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 05:13 Message: Logged In: YES user_id=6656 (sf keeps logging me out every ten minutes, grr) This is being hashed out on the cygwin list. It's unfortunately not obvious that it will be fixed in the 2.2 timeframe. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-06 07:16 Message: Logged In: YES user_id=6656 Hmm. Seems pretty similar to mine. I'll bug Jason Tishler and see if he knows anything about it. ---------------------------------------------------------------------- Comment By: David Abrahams (david_abrahams) Date: 2001-12-06 07:12 Message: Logged In: YES user_id=52572 I'm using Win2K CYGWIN_NT-5.0 MOREPIE 1.3.5(0.47/3/2) 2001-11-13 23:16 i686 unknown And I've built and installed GCC 3.0.2, thought the Python build seems to use 2.95.x anyway. I am not on the cygwin mailing list, sorry ;-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-06 05:53 Message: Logged In: YES user_id=6656 Just to say that I'm seeing this too. What OS? I'm on NT4 SP6. Which cygwin? I'm [Administrator@MATHS-PC150 QUAKE]$ uname -a CYGWIN_NT-4.0 MATHS-PC150 1.3.6(0.47/3/2) 2001-12-03 15:41 i686 unknown I was actually assuming this was a cygwin bug. Are you on the cygwin mailing list? Maybe you could try raising it there? I would, but I *really* don't need another subscription to a high-volume mailing list right now. PS: can we add jason as a developer? then we can assign bugs to him . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489709&group_id=5470 From noreply@sourceforge.net Tue Dec 18 21:21:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 13:21:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-483982 ] Python 2.2b2 bdist_wininst crashes Message-ID: Bugs item #483982, was opened at 2001-11-20 15:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=483982&group_id=5470 Category: Distutils Group: None Status: Open >Resolution: Fixed Priority: 7 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Thomas Heller (theller) Summary: Python 2.2b2 bdist_wininst crashes Initial Comment: The executable created by Python 2.2b2 bdist_wininst crashes on my system. Python 2.1's version works fine. This could just be my system and I can recompile the installer to test that, if that's needed, but after I looked into CVS I noted that it looks like wininst.exe has been checked in as a text file....hmmm I've attached a minimal dist which exhibits to problem. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2001-12-18 13:20 Message: Logged In: YES user_id=11105 Here is the full story: The distribution archive in zip-format contained an (empty) version of the zip-file itself. Since this has no prefix (PLATLIB, PURELIB, SCRIPTS, HEADERS, DATA), the loop in extract.c crashed with an access violation because of a bug in the C-code. I've fixed it in CVS. Still waiting for some positive reports on this fixed version, before I close the bug. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-17 09:42 Message: Logged In: YES user_id=11105 It seems all fields have to be updated after moving this... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-17 09:38 Message: Logged In: YES user_id=11105 Moved from patches to bugs. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-17 09:31 Message: Logged In: YES user_id=11105 Raised priority to 7 because this MUST be fixed before release (see PEP3). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-17 08:55 Message: Logged In: YES user_id=11105 Tarn, good work! I can now reproduce your problem here: It only appears when _no_ external zip.exe program is found somewhere on the PATH. In this case Python's zipfile.py is used, and this indeed creates an entry foo-1.0.win32.zip, leading to the crash. This entry is not present when an zip.exe is used. I will work on this. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-12-10 07:37 Message: Logged In: YES user_id=21784 This fails on the first file lookup. I agree that it shouldn't but you can see the file that it is failing on by looking in the Python root. In the case of a installer called "foo-1.0.win32-py2.2.exe" the first file appears to be "foo-1.0.win32.zip" which looks like the archive name. An empty file of this name also gets created by the installer. I don't know if this is a normal part of a zip file. If it is then adding if (n==0) continue; before line 228 which is pcomp = &data[pcdir->ofs_local_header will fix it. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-10 02:29 Message: Logged In: YES user_id=11105 Tarn, this is really a problem. Thanks for finding it. I still wonder how this bug lead to a crash. Usually the for-loop doesn't run up to beyond the end of the list, because the prefix *should* always be found. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-12-08 18:42 Message: Logged In: YES user_id=21784 Looks like I've found the problem: line 244 in misc/extract.c is currently this: for (i = 0; *scheme[i].name; ++i) { The scheme list is terminated by a NULL, so *NULL causes an exception at the end of the list. Instead this should be: for (i = 0; scheme[i].name; ++i) { ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-12-06 12:55 Message: Logged In: YES user_id=11375 Reassigning to Thomas Heller; I know nothing about bdist_wininst. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-11-21 16:16 Message: Logged In: YES user_id=21784 Looks like I put this under Patches instead of Bugs. Sorry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=483982&group_id=5470 From noreply@sourceforge.net Tue Dec 18 21:34:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 13:34:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-494762 ] urllib2 on python2.2 ssl bug Message-ID: Bugs item #494762, was opened at 2001-12-18 13:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494762&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Marcus Felipe Pereira (makim) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 on python2.2 ssl bug Initial Comment: urllib2 on python 2.2 can´t get some SSL pages. It seams that it´s dependent of the server and the issuer of the key. The server showed below (https://wwws.task.com.br) uses IIS 5.0 and 128 bits key issued by Thawte. I´ve tested on python 2.1 and it's OK. ******** Code ************* import os,urllib2 os.environ["http_proxy"]='' f = urllib2.urlopen("https://wwws.task.com.br/i.htm") print f.read() ******** Output ************ Traceback (most recent call last): File "./httpstest", line 6, in ? f = urllib2.urlopen ("https://wwws.task.com.br/i.htm") File "/usr/lib/python2.2/urllib2.py", line 138, in urlopen return _opener.open(url, data) File "/usr/lib/python2.2/urllib2.py", line 322, in open '_open', req) File "/usr/lib/python2.2/urllib2.py", line 301, in _call_chain result = func(*args) File "/usr/lib/python2.2/urllib2.py", line 792, in https_open return self.do_open(httplib.HTTPS, req) File "/usr/lib/python2.2/urllib2.py", line 774, in do_open code, msg, hdrs = h.getreply() File "/usr/lib/python2.2/httplib.py", line 728, in getreply response = self._conn.getresponse() File "/usr/lib/python2.2/httplib.py", line 572, in getresponse response = self.response_class(self.sock) File "/usr/lib/python2.2/httplib.py", line 98, in __init__ self.fp = sock.makefile('rb', 0) File "/usr/lib/python2.2/httplib.py", line 607, in makefile buf = self.__ssl.read() socket.sslerror: (5, 'EOF occurred in violation of protocol') ***************************************** ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494762&group_id=5470 From noreply@sourceforge.net Tue Dec 18 23:24:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 15:24:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-494668 ] PUSH() should assert-fail on overflow Message-ID: Bugs item #494668, was opened at 2001-12-18 09:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494668&group_id=5470 Category: Python Interpreter Core >Group: Python 2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Tim Peters (tim_one) >Assigned to: Tim Peters (tim_one) Summary: PUSH() should assert-fail on overflow Initial Comment: ceval's PUSH macro happily writes beyond the end of the eval stack if not enough space has been reserved for it. While there are no known instances of stack overflow under normal operation (it "should be" impossible), code objects produced by the Python compiler package have failed to reserve enough stack space, leading to the usual range of corrupted-memory problems. In a debug build the PUSH macro should verify that stack overflow doesn't occur. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-18 15:24 Message: Logged In: YES user_id=31435 Assigned to me and boosted priority. Rather than fiddle the PUSH macro, I intend to add some stack-limit asserts at the top of the eval loop (less potential for disruption because much less generated code, and should also catch stack underflows). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494668&group_id=5470 From noreply@sourceforge.net Wed Dec 19 01:16:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 17:16:43 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-494854 ] add platform.py Message-ID: Feature Requests item #494854, was opened at 2001-12-18 17:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494854&group_id=5470 Category: Python Library Group: None Status: Open Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: add platform.py Initial Comment: Here's a request to add Marc-Andre Lemburg's platform.py to the Python standard library. It provides more complete platform information than either sys.platform or distutils.util.get_platform() For more info, see: http://www.lemburg.com/files/python/platform.py ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494854&group_id=5470 From noreply@sourceforge.net Wed Dec 19 04:11:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 20:11:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-494668 ] PUSH() should assert-fail on overflow Message-ID: Bugs item #494668, was opened at 2001-12-18 09:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494668&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Tim Peters (tim_one) Summary: PUSH() should assert-fail on overflow Initial Comment: ceval's PUSH macro happily writes beyond the end of the eval stack if not enough space has been reserved for it. While there are no known instances of stack overflow under normal operation (it "should be" impossible), code objects produced by the Python compiler package have failed to reserve enough stack space, leading to the usual range of corrupted-memory problems. In a debug build the PUSH macro should verify that stack overflow doesn't occur. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-18 20:11 Message: Logged In: YES user_id=31435 Stack limit asserts were added to Python/ceval.c; new revision: 2.301 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-18 15:24 Message: Logged In: YES user_id=31435 Assigned to me and boosted priority. Rather than fiddle the PUSH macro, I intend to add some stack-limit asserts at the top of the eval loop (less potential for disruption because much less generated code, and should also catch stack underflows). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494668&group_id=5470 From noreply@sourceforge.net Wed Dec 19 04:44:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 20:44:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-494738 ] binascii_b2a_base64 overwrites memory Message-ID: Bugs item #494738, was opened at 2001-12-18 11:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494738&group_id=5470 Category: Python Library >Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Costanzo (david_costanzo) >Assigned to: Tim Peters (tim_one) Summary: binascii_b2a_base64 overwrites memory Initial Comment: I'm maintaining code that is based on the binascii.c found in Python-2.1.1/Modules directory (Python 2.1.. The code has a memory bounds overwrite when encoding binascii_b2a_base64 for small chunks of binary data. The bug in my code is that allocates an incorrect upper bound. For each byte of binary data, it allocates two bytes for the ascii format. It looks like it really needs four bytes of binary data for every three bytes of binary data, rounded up, plus one byte for the courtesy newline. The analogous line of code in binascii.c is line 425. As a test case, the ascii representation of the one byte binary string 'b' takes five characters 'Yg==\n', not twice the lenght of the original. (There are two two bytes of signal, two pad bytes, and a courtesy newline.) My code now uses ((bin_len + 2) / 3) * 4 + 1) as the buffer length. I ran Python 2.0 under a heap validator program called Purify and attempted to reproduce the memory overwrite, but I was unable to. This probably means that this bug does not exist in Python. I am submitting it as a bug anyway, in case Python is using a memory heap that confuses Purify. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-18 20:44 Message: Logged In: YES user_id=31435 Good eye! I agree the calculation is faulty for small inputs, and repaired it in Misc/ACKS; new revision: 1.146 Modules/binascii.c; new revision: 2.33 We haven't seen this trigger under Purify either. Offhand guess is that malloc rounds up to a multiple of 8 bytes regardless, and that hidden padding is enough to absorb the overwrite. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494738&group_id=5470 From noreply@sourceforge.net Wed Dec 19 04:52:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 20:52:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-494904 ] Cannot pickle a class with a metaclass Message-ID: Bugs item #494904, was opened at 2001-12-18 20:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494904&group_id=5470 Category: Type/class unification Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Dan Parisien (mathematician) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot pickle a class with a metaclass Initial Comment: when pickle retrieves the __reduce__ method of a new style class that has a metaclass, instead of returning the metaclass's __reduce__ method bound to the class, it returns an unbound __reduce__ method of that class. >>> class metaclass(type): ... def __reduce__(self): ... """This is metaclass.__reduce__ ... """ ... return type.__reduce__(self) ... >>> class newclass(object): ... __metaclass__ = metaclass ... def __reduce__(self): ... """This is newclass.__reduce__ ... """ ... return object.__reduce__(self) ... >>> print newclass.__reduce__.__doc__ This is newclass.__reduce__ when pickle calls object.__reduce__ on newclass, it returns an unbound newclass.__reduce__ and not a bound metaclass.__reduce__. This has the unfortunate side effect of not correctly 'reducing' the class. I'm trying to figure out a solution. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494904&group_id=5470 From noreply@sourceforge.net Wed Dec 19 05:00:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 21:00:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-494904 ] Cannot pickle a class with a metaclass Message-ID: Bugs item #494904, was opened at 2001-12-18 20:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494904&group_id=5470 Category: Type/class unification Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Dan Parisien (mathematician) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot pickle a class with a metaclass Initial Comment: when pickle retrieves the __reduce__ method of a new style class that has a metaclass, instead of returning the metaclass's __reduce__ method bound to the class, it returns an unbound __reduce__ method of that class. >>> class metaclass(type): ... def __reduce__(self): ... """This is metaclass.__reduce__ ... """ ... return type.__reduce__(self) ... >>> class newclass(object): ... __metaclass__ = metaclass ... def __reduce__(self): ... """This is newclass.__reduce__ ... """ ... return object.__reduce__(self) ... >>> print newclass.__reduce__.__doc__ This is newclass.__reduce__ when pickle calls object.__reduce__ on newclass, it returns an unbound newclass.__reduce__ and not a bound metaclass.__reduce__. This has the unfortunate side effect of not correctly 'reducing' the class. I'm trying to figure out a solution. ---------------------------------------------------------------------- >Comment By: Dan Parisien (mathematician) Date: 2001-12-18 21:00 Message: Logged In: YES user_id=118203 it's a shame the tabs do not appear above... --- Solution class metaclass(type): def __getattribute__(self, name): if name in ["__reduce__", "__getstate__", "__setstate__"]: return lambda s=self, f=getattr(type(self), name): f(s) return type.__getattribute__(self, name) this fixed my bug, but it may not work for everybody. My suggestion is if you are to pickle a new style class, you should call type(new_style_class).__reduce__(new_style_class) instead of new_style_class.__reduce__() ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494904&group_id=5470 From noreply@sourceforge.net Wed Dec 19 05:19:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 21:19:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-494904 ] Cannot pickle a class with a metaclass Message-ID: Bugs item #494904, was opened at 2001-12-18 20:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494904&group_id=5470 Category: Type/class unification >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Parisien (mathematician) >Assigned to: Guido van Rossum (gvanrossum) Summary: Cannot pickle a class with a metaclass Initial Comment: when pickle retrieves the __reduce__ method of a new style class that has a metaclass, instead of returning the metaclass's __reduce__ method bound to the class, it returns an unbound __reduce__ method of that class. >>> class metaclass(type): ... def __reduce__(self): ... """This is metaclass.__reduce__ ... """ ... return type.__reduce__(self) ... >>> class newclass(object): ... __metaclass__ = metaclass ... def __reduce__(self): ... """This is newclass.__reduce__ ... """ ... return object.__reduce__(self) ... >>> print newclass.__reduce__.__doc__ This is newclass.__reduce__ when pickle calls object.__reduce__ on newclass, it returns an unbound newclass.__reduce__ and not a bound metaclass.__reduce__. This has the unfortunate side effect of not correctly 'reducing' the class. I'm trying to figure out a solution. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-18 21:19 Message: Logged In: YES user_id=31435 Assigned to Guido. Dan, leading tabs vanish from the web view, but are visible in auto-emailed versions (it's a display issue, it's not that the database lost them) -- so don't worry about that. ---------------------------------------------------------------------- Comment By: Dan Parisien (mathematician) Date: 2001-12-18 21:00 Message: Logged In: YES user_id=118203 it's a shame the tabs do not appear above... --- Solution class metaclass(type): def __getattribute__(self, name): if name in ["__reduce__", "__getstate__", "__setstate__"]: return lambda s=self, f=getattr(type(self), name): f(s) return type.__getattribute__(self, name) this fixed my bug, but it may not work for everybody. My suggestion is if you are to pickle a new style class, you should call type(new_style_class).__reduce__(new_style_class) instead of new_style_class.__reduce__() ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494904&group_id=5470 From noreply@sourceforge.net Wed Dec 19 05:46:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 21:46:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-494904 ] Cannot pickle a class with a metaclass Message-ID: Bugs item #494904, was opened at 2001-12-18 20:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494904&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Parisien (mathematician) Assigned to: Guido van Rossum (gvanrossum) Summary: Cannot pickle a class with a metaclass Initial Comment: when pickle retrieves the __reduce__ method of a new style class that has a metaclass, instead of returning the metaclass's __reduce__ method bound to the class, it returns an unbound __reduce__ method of that class. >>> class metaclass(type): ... def __reduce__(self): ... """This is metaclass.__reduce__ ... """ ... return type.__reduce__(self) ... >>> class newclass(object): ... __metaclass__ = metaclass ... def __reduce__(self): ... """This is newclass.__reduce__ ... """ ... return object.__reduce__(self) ... >>> print newclass.__reduce__.__doc__ This is newclass.__reduce__ when pickle calls object.__reduce__ on newclass, it returns an unbound newclass.__reduce__ and not a bound metaclass.__reduce__. This has the unfortunate side effect of not correctly 'reducing' the class. I'm trying to figure out a solution. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 21:46 Message: Logged In: YES user_id=6380 Very interesting! Good analysis too (took me a while with pdb to come to verify it :-). But neither class needs to define __reduce__ -- the one they inherit from their bases, type and object, will do the trick just as well. The problem is that there are two things competing to be newclass.__reduce__: on the one hand, the unbound method __reduce__ of newclass instances; on the other hand, the bound method __reduce__ of newclass, seen as a metaclass instance. Unfortunately, the unbound method wins, but pickle is expecting the bound method. I've tried experimenting with a few ways of fixing this (e.g. forcing pickle to get the bound __reduce__ method) but there seem to be powerful forces preventing me from getting this to work (and I don't mean just a screaming baby :-). I think maybe the right solution is to make pickle realize that newclass is a class, and prevent it from pickling it at all -- it should just pickle a reference to it (i.e. the module and class name) rather than attempting to pickle its contents. Stay tuned. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-18 21:19 Message: Logged In: YES user_id=31435 Assigned to Guido. Dan, leading tabs vanish from the web view, but are visible in auto-emailed versions (it's a display issue, it's not that the database lost them) -- so don't worry about that. ---------------------------------------------------------------------- Comment By: Dan Parisien (mathematician) Date: 2001-12-18 21:00 Message: Logged In: YES user_id=118203 it's a shame the tabs do not appear above... --- Solution class metaclass(type): def __getattribute__(self, name): if name in ["__reduce__", "__getstate__", "__setstate__"]: return lambda s=self, f=getattr(type(self), name): f(s) return type.__getattribute__(self, name) this fixed my bug, but it may not work for everybody. My suggestion is if you are to pickle a new style class, you should call type(new_style_class).__reduce__(new_style_class) instead of new_style_class.__reduce__() ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494904&group_id=5470 From noreply@sourceforge.net Wed Dec 19 06:23:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 22:23:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-494904 ] Cannot pickle a class with a metaclass Message-ID: Bugs item #494904, was opened at 2001-12-18 20:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494904&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Parisien (mathematician) Assigned to: Guido van Rossum (gvanrossum) Summary: Cannot pickle a class with a metaclass Initial Comment: when pickle retrieves the __reduce__ method of a new style class that has a metaclass, instead of returning the metaclass's __reduce__ method bound to the class, it returns an unbound __reduce__ method of that class. >>> class metaclass(type): ... def __reduce__(self): ... """This is metaclass.__reduce__ ... """ ... return type.__reduce__(self) ... >>> class newclass(object): ... __metaclass__ = metaclass ... def __reduce__(self): ... """This is newclass.__reduce__ ... """ ... return object.__reduce__(self) ... >>> print newclass.__reduce__.__doc__ This is newclass.__reduce__ when pickle calls object.__reduce__ on newclass, it returns an unbound newclass.__reduce__ and not a bound metaclass.__reduce__. This has the unfortunate side effect of not correctly 'reducing' the class. I'm trying to figure out a solution. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 22:23 Message: Logged In: YES user_id=6380 I've got a patch for pickle.py; a similar patch needs to be developed for cPickle.c. I can't find a way to fix this purely by fixing the type object implementation -- pickle.py and cPickle.py just don't recognize classes with a custom metaclass as classes, because of their roots in pre-2.2 patterns. :-( Should we risk fixing this before 2.2 goes out? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 21:46 Message: Logged In: YES user_id=6380 Very interesting! Good analysis too (took me a while with pdb to come to verify it :-). But neither class needs to define __reduce__ -- the one they inherit from their bases, type and object, will do the trick just as well. The problem is that there are two things competing to be newclass.__reduce__: on the one hand, the unbound method __reduce__ of newclass instances; on the other hand, the bound method __reduce__ of newclass, seen as a metaclass instance. Unfortunately, the unbound method wins, but pickle is expecting the bound method. I've tried experimenting with a few ways of fixing this (e.g. forcing pickle to get the bound __reduce__ method) but there seem to be powerful forces preventing me from getting this to work (and I don't mean just a screaming baby :-). I think maybe the right solution is to make pickle realize that newclass is a class, and prevent it from pickling it at all -- it should just pickle a reference to it (i.e. the module and class name) rather than attempting to pickle its contents. Stay tuned. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-18 21:19 Message: Logged In: YES user_id=31435 Assigned to Guido. Dan, leading tabs vanish from the web view, but are visible in auto-emailed versions (it's a display issue, it's not that the database lost them) -- so don't worry about that. ---------------------------------------------------------------------- Comment By: Dan Parisien (mathematician) Date: 2001-12-18 21:00 Message: Logged In: YES user_id=118203 it's a shame the tabs do not appear above... --- Solution class metaclass(type): def __getattribute__(self, name): if name in ["__reduce__", "__getstate__", "__setstate__"]: return lambda s=self, f=getattr(type(self), name): f(s) return type.__getattribute__(self, name) this fixed my bug, but it may not work for everybody. My suggestion is if you are to pickle a new style class, you should call type(new_style_class).__reduce__(new_style_class) instead of new_style_class.__reduce__() ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494904&group_id=5470 From noreply@sourceforge.net Wed Dec 19 06:56:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 22:56:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-494589 ] os.path.expandvars deletes things on w32 Message-ID: Bugs item #494589, was opened at 2001-12-18 06:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494589&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael McCandless (mikemccand) >Assigned to: Nobody/Anonymous (nobody) Summary: os.path.expandvars deletes things on w32 Initial Comment: Try this: import os.path print os.path.expandvars('foo$doesnotexist') On FreeBSD, Python 2.1, I get: 'foo$doesnotexist' But on WIN32, Python 2.1, I get: 'foo' The docs explicitly states that variables that are not found will be left in place ... but on win32 that appears to not be the case. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-18 22:56 Message: Logged In: YES user_id=31435 Another bug: with two adjacent envars that do exist, only the first is expanded (on Windows): >>> os.path.expandvars('$TMP$TMP') 'c:\windows\TEMP$TMP' >>> Another bug: the Windows expandvars doesn't expand envars in single quotes, but the posixpath flavor does: >>> ntpath.expandvars("'$TMP'") "'$TMP'" >>> posixpath.expandvars("'$TMP'") "'c:\windows\TEMP'" >>> Another bug: $$ is an escape sequence (meaning a single $) on Windows but not on Unix: >>> ntpath.expandvars('$$') '$' >>> posixpath.expandvars('$$') '$$' >>> Unassigning from me, as this is a bottomless pit spanning platforms and bristling with backward-compatibility traps no matter what's done about it. Somebody who cares enough should write a PEPlet to sort out the mess, else I'd just leave it alone. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 06:43 Message: Logged In: YES user_id=6380 Hm, I do understand it, the code is broken (compared to the spec). No time to fix it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 06:35 Message: Logged In: YES user_id=6380 Confirmed, also in 2.2. I don't understand it, the code looks OK. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494589&group_id=5470 From noreply@sourceforge.net Wed Dec 19 07:00:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 23:00:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-494904 ] Cannot pickle a class with a metaclass Message-ID: Bugs item #494904, was opened at 2001-12-18 20:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494904&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Parisien (mathematician) Assigned to: Guido van Rossum (gvanrossum) Summary: Cannot pickle a class with a metaclass Initial Comment: when pickle retrieves the __reduce__ method of a new style class that has a metaclass, instead of returning the metaclass's __reduce__ method bound to the class, it returns an unbound __reduce__ method of that class. >>> class metaclass(type): ... def __reduce__(self): ... """This is metaclass.__reduce__ ... """ ... return type.__reduce__(self) ... >>> class newclass(object): ... __metaclass__ = metaclass ... def __reduce__(self): ... """This is newclass.__reduce__ ... """ ... return object.__reduce__(self) ... >>> print newclass.__reduce__.__doc__ This is newclass.__reduce__ when pickle calls object.__reduce__ on newclass, it returns an unbound newclass.__reduce__ and not a bound metaclass.__reduce__. This has the unfortunate side effect of not correctly 'reducing' the class. I'm trying to figure out a solution. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-18 23:00 Message: Logged In: YES user_id=31435 Sounds like I'd risk it, Guido: it's not like you could break 2.1's pickle behavior for new-style classes with a custom metaclass . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 22:23 Message: Logged In: YES user_id=6380 I've got a patch for pickle.py; a similar patch needs to be developed for cPickle.c. I can't find a way to fix this purely by fixing the type object implementation -- pickle.py and cPickle.py just don't recognize classes with a custom metaclass as classes, because of their roots in pre-2.2 patterns. :-( Should we risk fixing this before 2.2 goes out? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 21:46 Message: Logged In: YES user_id=6380 Very interesting! Good analysis too (took me a while with pdb to come to verify it :-). But neither class needs to define __reduce__ -- the one they inherit from their bases, type and object, will do the trick just as well. The problem is that there are two things competing to be newclass.__reduce__: on the one hand, the unbound method __reduce__ of newclass instances; on the other hand, the bound method __reduce__ of newclass, seen as a metaclass instance. Unfortunately, the unbound method wins, but pickle is expecting the bound method. I've tried experimenting with a few ways of fixing this (e.g. forcing pickle to get the bound __reduce__ method) but there seem to be powerful forces preventing me from getting this to work (and I don't mean just a screaming baby :-). I think maybe the right solution is to make pickle realize that newclass is a class, and prevent it from pickling it at all -- it should just pickle a reference to it (i.e. the module and class name) rather than attempting to pickle its contents. Stay tuned. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-18 21:19 Message: Logged In: YES user_id=31435 Assigned to Guido. Dan, leading tabs vanish from the web view, but are visible in auto-emailed versions (it's a display issue, it's not that the database lost them) -- so don't worry about that. ---------------------------------------------------------------------- Comment By: Dan Parisien (mathematician) Date: 2001-12-18 21:00 Message: Logged In: YES user_id=118203 it's a shame the tabs do not appear above... --- Solution class metaclass(type): def __getattribute__(self, name): if name in ["__reduce__", "__getstate__", "__setstate__"]: return lambda s=self, f=getattr(type(self), name): f(s) return type.__getattribute__(self, name) this fixed my bug, but it may not work for everybody. My suggestion is if you are to pickle a new style class, you should call type(new_style_class).__reduce__(new_style_class) instead of new_style_class.__reduce__() ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494904&group_id=5470 From noreply@sourceforge.net Wed Dec 19 07:27:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 18 Dec 2001 23:27:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-483982 ] Python 2.2b2 bdist_wininst crashes Message-ID: Bugs item #483982, was opened at 2001-11-20 15:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=483982&group_id=5470 Category: Distutils Group: None >Status: Closed Resolution: Fixed Priority: 7 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Thomas Heller (theller) Summary: Python 2.2b2 bdist_wininst crashes Initial Comment: The executable created by Python 2.2b2 bdist_wininst crashes on my system. Python 2.1's version works fine. This could just be my system and I can recompile the installer to test that, if that's needed, but after I looked into CVS I noted that it looks like wininst.exe has been checked in as a text file....hmmm I've attached a minimal dist which exhibits to problem. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2001-12-18 23:27 Message: Logged In: YES user_id=11105 I've got positive reports, so this can be closed. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-18 13:20 Message: Logged In: YES user_id=11105 Here is the full story: The distribution archive in zip-format contained an (empty) version of the zip-file itself. Since this has no prefix (PLATLIB, PURELIB, SCRIPTS, HEADERS, DATA), the loop in extract.c crashed with an access violation because of a bug in the C-code. I've fixed it in CVS. Still waiting for some positive reports on this fixed version, before I close the bug. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-17 09:42 Message: Logged In: YES user_id=11105 It seems all fields have to be updated after moving this... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-17 09:38 Message: Logged In: YES user_id=11105 Moved from patches to bugs. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-17 09:31 Message: Logged In: YES user_id=11105 Raised priority to 7 because this MUST be fixed before release (see PEP3). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-17 08:55 Message: Logged In: YES user_id=11105 Tarn, good work! I can now reproduce your problem here: It only appears when _no_ external zip.exe program is found somewhere on the PATH. In this case Python's zipfile.py is used, and this indeed creates an entry foo-1.0.win32.zip, leading to the crash. This entry is not present when an zip.exe is used. I will work on this. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-12-10 07:37 Message: Logged In: YES user_id=21784 This fails on the first file lookup. I agree that it shouldn't but you can see the file that it is failing on by looking in the Python root. In the case of a installer called "foo-1.0.win32-py2.2.exe" the first file appears to be "foo-1.0.win32.zip" which looks like the archive name. An empty file of this name also gets created by the installer. I don't know if this is a normal part of a zip file. If it is then adding if (n==0) continue; before line 228 which is pcomp = &data[pcdir->ofs_local_header will fix it. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-10 02:29 Message: Logged In: YES user_id=11105 Tarn, this is really a problem. Thanks for finding it. I still wonder how this bug lead to a crash. Usually the for-loop doesn't run up to beyond the end of the list, because the prefix *should* always be found. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-12-08 18:42 Message: Logged In: YES user_id=21784 Looks like I've found the problem: line 244 in misc/extract.c is currently this: for (i = 0; *scheme[i].name; ++i) { The scheme list is terminated by a NULL, so *NULL causes an exception at the end of the list. Instead this should be: for (i = 0; scheme[i].name; ++i) { ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-12-06 12:55 Message: Logged In: YES user_id=11375 Reassigning to Thomas Heller; I know nothing about bdist_wininst. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-11-21 16:16 Message: Logged In: YES user_id=21784 Looks like I put this under Patches instead of Bugs. Sorry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=483982&group_id=5470 From noreply@sourceforge.net Wed Dec 19 09:25:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Dec 2001 01:25:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-493959 ] 2.2c1 configure bug Message-ID: Bugs item #493959, was opened at 2001-12-16 12:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493959&group_id=5470 Category: Installation Group: Python 2.2 >Status: Closed Resolution: None Priority: 8 Submitted By: Jeff Whitaker (jswhit) Assigned to: Jack Jansen (jackjansen) Summary: 2.2c1 configure bug Initial Comment: Hi: Found a small bug in the configure script for 2.2c1 that manifests itself on case-insensitive filesystems (like HFS+) when --with-suffix= is given, and is not set to ".exe". EXEEXT is set to (in my case "x") and BUILDEXEEXT is set to ".exe", leading to the following error during the install: /usr/bin/install -c python.exe /sw/src/root-python-unstable-2.2c1-1/sw/bin/ python2.2x if test -f libpython2.2.so; then \ /usr/bin/install -c -m 644 libpython2.2.so /sw/src/root-python-unstable-2.2c1-1/sw/lib; \ else true; \ fi if test -f ""; then \ /usr/bin/install -c -m 555 /sw/src/root-python-unstable-2.2c1-1/sw/bin; \ else true; \ fi mkdir ./Lib/plat-darwin cp ./Lib/plat-generic/regen ./Lib/plat-darwin/regen export PATH; PATH="`pwd`:$PATH"; \ export PYTHONPATH; PYTHONPATH="`pwd`/Lib"; \ export DYLD_FRAMEWORK_PATH; DYLD_FRAMEWORK_PATH="`pwd`"; \ export EXE; EXE="x"; \ cd ./Lib/plat-darwin; ./regen python$EXE ../../Tools/scripts/h2py.py -i '(u_long)' /usr/include/netinet/in.h Traceback (most recent call last): File "../../Tools/scripts/h2py.py", line 24, in ? import sys, re, getopt, os File "/sw/src/python-unstable-2.2c1-1/Python- 2.2c1/Lib/re.py", line 27, in ? from sre import * File "/sw/src/python-unstable-2.2c1-1/Python- 2.2c1/Lib/sre.py", line 97, in ? import sre_compile File "/sw/src/python-unstable-2.2c1-1/Python- 2.2c1/Lib/sre_compile.py", line 17, in ? assert _sre.MAGIC == MAGIC, "SRE module mismatch" AssertionError: SRE module mismatch make: *** [Lib/plat-darwin] Error 1 ### make failed, exit code 2 Failed: installing python-unstable-2.2c1-1 failed The only way to make it build correctly is to use -- with-suffix=.exe, leaving --with-suffix out entirely doesn't work since EXEEXT is then null, and BUILDEXEEXT is still .exe. Seems like BUILDEXEEXT and EXEEXT need to be the same. -Jeff ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-19 01:25 Message: Logged In: YES user_id=45365 Fixed in the repository, Makefile.pre.in rev. 1.73. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493959&group_id=5470 From noreply@sourceforge.net Wed Dec 19 09:27:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Dec 2001 01:27:49 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-494854 ] add platform.py Message-ID: Feature Requests item #494854, was opened at 2001-12-18 17:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494854&group_id=5470 Category: Python Library Group: None Status: Open Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: add platform.py Initial Comment: Here's a request to add Marc-Andre Lemburg's platform.py to the Python standard library. It provides more complete platform information than either sys.platform or distutils.util.get_platform() For more info, see: http://www.lemburg.com/files/python/platform.py ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-19 01:27 Message: Logged In: YES user_id=38388 No problem from here :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494854&group_id=5470 From noreply@sourceforge.net Wed Dec 19 12:49:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Dec 2001 04:49:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-495021 ] Crash calling os.stat with a trailing Message-ID: Bugs item #495021, was opened at 2001-12-19 04:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495021&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 9 Submitted By: Mark Hammond (mhammond) Assigned to: Tim Peters (tim_one) Summary: Crash calling os.stat with a trailing Initial Comment: >>> import os [7206 refs] >>> os.stat("c:\temp\") [Assertion failure in debug builds] We are freeing a pointer to a buffer on the stack!!! Dumb error (mine - sorry :( ) in posixmodule.c. Attaching patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495021&group_id=5470 From noreply@sourceforge.net Wed Dec 19 14:34:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Dec 2001 06:34:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-494904 ] Cannot pickle a class with a metaclass Message-ID: Bugs item #494904, was opened at 2001-12-18 20:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494904&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Dan Parisien (mathematician) Assigned to: Guido van Rossum (gvanrossum) Summary: Cannot pickle a class with a metaclass Initial Comment: when pickle retrieves the __reduce__ method of a new style class that has a metaclass, instead of returning the metaclass's __reduce__ method bound to the class, it returns an unbound __reduce__ method of that class. >>> class metaclass(type): ... def __reduce__(self): ... """This is metaclass.__reduce__ ... """ ... return type.__reduce__(self) ... >>> class newclass(object): ... __metaclass__ = metaclass ... def __reduce__(self): ... """This is newclass.__reduce__ ... """ ... return object.__reduce__(self) ... >>> print newclass.__reduce__.__doc__ This is newclass.__reduce__ when pickle calls object.__reduce__ on newclass, it returns an unbound newclass.__reduce__ and not a bound metaclass.__reduce__. This has the unfortunate side effect of not correctly 'reducing' the class. I'm trying to figure out a solution. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-18 23:00 Message: Logged In: YES user_id=31435 Sounds like I'd risk it, Guido: it's not like you could break 2.1's pickle behavior for new-style classes with a custom metaclass . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 22:23 Message: Logged In: YES user_id=6380 I've got a patch for pickle.py; a similar patch needs to be developed for cPickle.c. I can't find a way to fix this purely by fixing the type object implementation -- pickle.py and cPickle.py just don't recognize classes with a custom metaclass as classes, because of their roots in pre-2.2 patterns. :-( Should we risk fixing this before 2.2 goes out? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 21:46 Message: Logged In: YES user_id=6380 Very interesting! Good analysis too (took me a while with pdb to come to verify it :-). But neither class needs to define __reduce__ -- the one they inherit from their bases, type and object, will do the trick just as well. The problem is that there are two things competing to be newclass.__reduce__: on the one hand, the unbound method __reduce__ of newclass instances; on the other hand, the bound method __reduce__ of newclass, seen as a metaclass instance. Unfortunately, the unbound method wins, but pickle is expecting the bound method. I've tried experimenting with a few ways of fixing this (e.g. forcing pickle to get the bound __reduce__ method) but there seem to be powerful forces preventing me from getting this to work (and I don't mean just a screaming baby :-). I think maybe the right solution is to make pickle realize that newclass is a class, and prevent it from pickling it at all -- it should just pickle a reference to it (i.e. the module and class name) rather than attempting to pickle its contents. Stay tuned. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-18 21:19 Message: Logged In: YES user_id=31435 Assigned to Guido. Dan, leading tabs vanish from the web view, but are visible in auto-emailed versions (it's a display issue, it's not that the database lost them) -- so don't worry about that. ---------------------------------------------------------------------- Comment By: Dan Parisien (mathematician) Date: 2001-12-18 21:00 Message: Logged In: YES user_id=118203 it's a shame the tabs do not appear above... --- Solution class metaclass(type): def __getattribute__(self, name): if name in ["__reduce__", "__getstate__", "__setstate__"]: return lambda s=self, f=getattr(type(self), name): f(s) return type.__getattribute__(self, name) this fixed my bug, but it may not work for everybody. My suggestion is if you are to pickle a new style class, you should call type(new_style_class).__reduce__(new_style_class) instead of new_style_class.__reduce__() ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494904&group_id=5470 From noreply@sourceforge.net Wed Dec 19 16:26:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Dec 2001 08:26:36 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-495086 ] dict.popitem(key=None) Message-ID: Feature Requests item #495086, was opened at 2001-12-19 08:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=495086&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Priority: 5 Submitted By: Dan Parisien (mathematician) Assigned to: Nobody/Anonymous (nobody) Summary: dict.popitem(key=None) Initial Comment: Would it be possible to add an extra argument to the popitem method of DictionaryType so one can both retrieve a dict item and delete it at the same time? It would be so handy. Without the optional argument, it would work the same way dict.popitem works now example:: >>> d = dict([(x,x) for x in range(10)]) >>> d {0: 0, 1: 1, 2: 2, 3: 3, 4: 4, 5: 5, 6: 6, 7: 7, 8: 8, 9: 9} >>> d.popitem() # retrieves "random" key->val pair (0, 0) >>> d.popitem(4) # val=d[4]; del d[4]; return val 4 >>> d.popitem(6) # val=d[6]; del d[6]; return val 6 >>> d # missing keys [0, 4, 6] {1: 1, 2: 2, 3: 3, 5: 5, 7: 7, 8: 8, 9: 9} ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=495086&group_id=5470 From noreply@sourceforge.net Wed Dec 19 16:44:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Dec 2001 08:44:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-495094 ] evaluating integers inconsistently Message-ID: Bugs item #495094, was opened at 2001-12-19 08:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495094&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Fahri Basegmez (basegmez) Assigned to: Nobody/Anonymous (nobody) Summary: evaluating integers inconsistently Initial Comment: Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> eval('01234') 668 >>> for i in range(10):print eval('0' + str(i)) 0 1 2 3 4 5 6 7 Traceback (most recent call last): File "", line 1, in ? for i in range(10):print eval('0' + str(i)) File "", line 1 08 ^ SyntaxError: unexpected EOF while parsing >>> 08 SyntaxError: invalid syntax >>> 01 1 >>> 0123456 42798 >>> 0123456L 42798L >>> eval function and Python interpreter evaluates integers/long integers inconsistenly. It should be an error either for all cases or for none. Fahri Basegmez ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495094&group_id=5470 From noreply@sourceforge.net Wed Dec 19 16:53:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Dec 2001 08:53:20 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-494854 ] add platform.py Message-ID: Feature Requests item #494854, was opened at 2001-12-18 17:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494854&group_id=5470 Category: Python Library Group: None Status: Open Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) >Assigned to: M.-A. Lemburg (lemburg) Summary: add platform.py Initial Comment: Here's a request to add Marc-Andre Lemburg's platform.py to the Python standard library. It provides more complete platform information than either sys.platform or distutils.util.get_platform() For more info, see: http://www.lemburg.com/files/python/platform.py ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-19 01:27 Message: Logged In: YES user_id=38388 No problem from here :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494854&group_id=5470 From noreply@sourceforge.net Wed Dec 19 16:58:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Dec 2001 08:58:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-494904 ] Cannot pickle a class with a metaclass Message-ID: Bugs item #494904, was opened at 2001-12-18 20:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494904&group_id=5470 Category: Type/class unification >Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Dan Parisien (mathematician) Assigned to: Guido van Rossum (gvanrossum) Summary: Cannot pickle a class with a metaclass Initial Comment: when pickle retrieves the __reduce__ method of a new style class that has a metaclass, instead of returning the metaclass's __reduce__ method bound to the class, it returns an unbound __reduce__ method of that class. >>> class metaclass(type): ... def __reduce__(self): ... """This is metaclass.__reduce__ ... """ ... return type.__reduce__(self) ... >>> class newclass(object): ... __metaclass__ = metaclass ... def __reduce__(self): ... """This is newclass.__reduce__ ... """ ... return object.__reduce__(self) ... >>> print newclass.__reduce__.__doc__ This is newclass.__reduce__ when pickle calls object.__reduce__ on newclass, it returns an unbound newclass.__reduce__ and not a bound metaclass.__reduce__. This has the unfortunate side effect of not correctly 'reducing' the class. I'm trying to figure out a solution. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-19 08:58 Message: Logged In: YES user_id=6380 Thanks for reporting! Fixed in CVS, with a simpler version of the patch below; also for cPickle. Adding tests too... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-18 23:00 Message: Logged In: YES user_id=31435 Sounds like I'd risk it, Guido: it's not like you could break 2.1's pickle behavior for new-style classes with a custom metaclass . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 22:23 Message: Logged In: YES user_id=6380 I've got a patch for pickle.py; a similar patch needs to be developed for cPickle.c. I can't find a way to fix this purely by fixing the type object implementation -- pickle.py and cPickle.py just don't recognize classes with a custom metaclass as classes, because of their roots in pre-2.2 patterns. :-( Should we risk fixing this before 2.2 goes out? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-18 21:46 Message: Logged In: YES user_id=6380 Very interesting! Good analysis too (took me a while with pdb to come to verify it :-). But neither class needs to define __reduce__ -- the one they inherit from their bases, type and object, will do the trick just as well. The problem is that there are two things competing to be newclass.__reduce__: on the one hand, the unbound method __reduce__ of newclass instances; on the other hand, the bound method __reduce__ of newclass, seen as a metaclass instance. Unfortunately, the unbound method wins, but pickle is expecting the bound method. I've tried experimenting with a few ways of fixing this (e.g. forcing pickle to get the bound __reduce__ method) but there seem to be powerful forces preventing me from getting this to work (and I don't mean just a screaming baby :-). I think maybe the right solution is to make pickle realize that newclass is a class, and prevent it from pickling it at all -- it should just pickle a reference to it (i.e. the module and class name) rather than attempting to pickle its contents. Stay tuned. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-18 21:19 Message: Logged In: YES user_id=31435 Assigned to Guido. Dan, leading tabs vanish from the web view, but are visible in auto-emailed versions (it's a display issue, it's not that the database lost them) -- so don't worry about that. ---------------------------------------------------------------------- Comment By: Dan Parisien (mathematician) Date: 2001-12-18 21:00 Message: Logged In: YES user_id=118203 it's a shame the tabs do not appear above... --- Solution class metaclass(type): def __getattribute__(self, name): if name in ["__reduce__", "__getstate__", "__setstate__"]: return lambda s=self, f=getattr(type(self), name): f(s) return type.__getattribute__(self, name) this fixed my bug, but it may not work for everybody. My suggestion is if you are to pickle a new style class, you should call type(new_style_class).__reduce__(new_style_class) instead of new_style_class.__reduce__() ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494904&group_id=5470 From noreply@sourceforge.net Wed Dec 19 18:57:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Dec 2001 10:57:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-495094 ] evaluating integers inconsistently Message-ID: Bugs item #495094, was opened at 2001-12-19 08:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495094&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Fahri Basegmez (basegmez) >Assigned to: Tim Peters (tim_one) Summary: evaluating integers inconsistently Initial Comment: Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> eval('01234') 668 >>> for i in range(10):print eval('0' + str(i)) 0 1 2 3 4 5 6 7 Traceback (most recent call last): File "", line 1, in ? for i in range(10):print eval('0' + str(i)) File "", line 1 08 ^ SyntaxError: unexpected EOF while parsing >>> 08 SyntaxError: invalid syntax >>> 01 1 >>> 0123456 42798 >>> 0123456L 42798L >>> eval function and Python interpreter evaluates integers/long integers inconsistenly. It should be an error either for all cases or for none. Fahri Basegmez ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-19 10:57 Message: Logged In: YES user_id=31435 Hmm. What is your complaint here, exactly? You showed a bunch of code but didn't point out anything that surprised me. Do you know that integer literals beginning with "0" are in octal notation (so that the digits '8' and '9' aren't legal then, and 010 is decimal 8?). Similarly, integer literals beginning with "0x" are in hex notation. A decimal integer literal cannot begin with 0. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495094&group_id=5470 From noreply@sourceforge.net Wed Dec 19 19:07:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Dec 2001 11:07:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-495021 ] Crash calling os.stat with a trailing Message-ID: Bugs item #495021, was opened at 2001-12-19 04:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495021&group_id=5470 Category: Windows Group: None >Status: Closed >Resolution: Accepted Priority: 9 Submitted By: Mark Hammond (mhammond) Assigned to: Tim Peters (tim_one) Summary: Crash calling os.stat with a trailing Initial Comment: >>> import os [7206 refs] >>> os.stat("c:\temp\") [Assertion failure in debug builds] We are freeing a pointer to a buffer on the stack!!! Dumb error (mine - sorry :( ) in posixmodule.c. Attaching patch. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-19 11:07 Message: Logged In: YES user_id=31435 Thanks, Mark! I saw the report on c.l.py but it didn't crash when I tried it, so I ignored it . I rearranged the code and added some comments; please sanity- check Modules/posixmodule.c; new revision: 2.216 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495021&group_id=5470 From noreply@sourceforge.net Wed Dec 19 19:50:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Dec 2001 11:50:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-495094 ] evaluating integers inconsistently Message-ID: Bugs item #495094, was opened at 2001-12-19 08:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495094&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 >Status: Deleted Resolution: None Priority: 5 Submitted By: Fahri Basegmez (basegmez) Assigned to: Tim Peters (tim_one) Summary: evaluating integers inconsistently Initial Comment: Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> eval('01234') 668 >>> for i in range(10):print eval('0' + str(i)) 0 1 2 3 4 5 6 7 Traceback (most recent call last): File "", line 1, in ? for i in range(10):print eval('0' + str(i)) File "", line 1 08 ^ SyntaxError: unexpected EOF while parsing >>> 08 SyntaxError: invalid syntax >>> 01 1 >>> 0123456 42798 >>> 0123456L 42798L >>> eval function and Python interpreter evaluates integers/long integers inconsistenly. It should be an error either for all cases or for none. Fahri Basegmez ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-19 10:57 Message: Logged In: YES user_id=31435 Hmm. What is your complaint here, exactly? You showed a bunch of code but didn't point out anything that surprised me. Do you know that integer literals beginning with "0" are in octal notation (so that the digits '8' and '9' aren't legal then, and 010 is decimal 8?). Similarly, integer literals beginning with "0x" are in hex notation. A decimal integer literal cannot begin with 0. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495094&group_id=5470 From noreply@sourceforge.net Wed Dec 19 20:34:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Dec 2001 12:34:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-494572 ] plugin project generation has problems Message-ID: Bugs item #494572, was opened at 2001-12-18 05:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494572&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: plugin project generation has problems Initial Comment: The generation of CW7 projects for plugins (and distutils too, probably) still has some problems that cause CW to say the project was created by an older version of CodeWarrior. The project does work, but this needs to be fixed before 2.2 final. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-19 12:34 Message: Logged In: YES user_id=21627 Any idea as to when a patch might be forthcoming? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494572&group_id=5470 From noreply@sourceforge.net Wed Dec 19 20:38:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Dec 2001 12:38:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-494762 ] urllib2 on python2.2 ssl bug Message-ID: Bugs item #494762, was opened at 2001-12-18 13:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494762&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Marcus Felipe Pereira (makim) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 on python2.2 ssl bug Initial Comment: urllib2 on python 2.2 can´t get some SSL pages. It seams that it´s dependent of the server and the issuer of the key. The server showed below (https://wwws.task.com.br) uses IIS 5.0 and 128 bits key issued by Thawte. I´ve tested on python 2.1 and it's OK. ******** Code ************* import os,urllib2 os.environ["http_proxy"]='' f = urllib2.urlopen("https://wwws.task.com.br/i.htm") print f.read() ******** Output ************ Traceback (most recent call last): File "./httpstest", line 6, in ? f = urllib2.urlopen ("https://wwws.task.com.br/i.htm") File "/usr/lib/python2.2/urllib2.py", line 138, in urlopen return _opener.open(url, data) File "/usr/lib/python2.2/urllib2.py", line 322, in open '_open', req) File "/usr/lib/python2.2/urllib2.py", line 301, in _call_chain result = func(*args) File "/usr/lib/python2.2/urllib2.py", line 792, in https_open return self.do_open(httplib.HTTPS, req) File "/usr/lib/python2.2/urllib2.py", line 774, in do_open code, msg, hdrs = h.getreply() File "/usr/lib/python2.2/httplib.py", line 728, in getreply response = self._conn.getresponse() File "/usr/lib/python2.2/httplib.py", line 572, in getresponse response = self.response_class(self.sock) File "/usr/lib/python2.2/httplib.py", line 98, in __init__ self.fp = sock.makefile('rb', 0) File "/usr/lib/python2.2/httplib.py", line 607, in makefile buf = self.__ssl.read() socket.sslerror: (5, 'EOF occurred in violation of protocol') ***************************************** ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-19 12:38 Message: Logged In: YES user_id=21627 If OpenSSL says the server violates the protocol, I'm pretty sure OpenSSL is right. So I fail to see the problem in Python. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494762&group_id=5470 From noreply@sourceforge.net Wed Dec 19 20:50:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Dec 2001 12:50:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-495094 ] evaluating integers inconsistently Message-ID: Bugs item #495094, was opened at 2001-12-19 08:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495094&group_id=5470 Category: Python Interpreter Core >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Fahri Basegmez (basegmez) Assigned to: Tim Peters (tim_one) Summary: evaluating integers inconsistently Initial Comment: Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> eval('01234') 668 >>> for i in range(10):print eval('0' + str(i)) 0 1 2 3 4 5 6 7 Traceback (most recent call last): File "", line 1, in ? for i in range(10):print eval('0' + str(i)) File "", line 1 08 ^ SyntaxError: unexpected EOF while parsing >>> 08 SyntaxError: invalid syntax >>> 01 1 >>> 0123456 42798 >>> 0123456L 42798L >>> eval function and Python interpreter evaluates integers/long integers inconsistenly. It should be an error either for all cases or for none. Fahri Basegmez ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-19 12:50 Message: Logged In: YES user_id=31435 Looks like the OP tried to delete this report, so closing as invalid. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-19 10:57 Message: Logged In: YES user_id=31435 Hmm. What is your complaint here, exactly? You showed a bunch of code but didn't point out anything that surprised me. Do you know that integer literals beginning with "0" are in octal notation (so that the digits '8' and '9' aren't legal then, and 010 is decimal 8?). Similarly, integer literals beginning with "0x" are in hex notation. A decimal integer literal cannot begin with 0. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495094&group_id=5470 From noreply@sourceforge.net Wed Dec 19 22:12:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Dec 2001 14:12:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-495191 ] os.spawnlp not supported under Windows Message-ID: Bugs item #495191, was opened at 2001-12-19 14:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495191&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: os.spawnlp not supported under Windows Initial Comment: os.spawnlp and os.spawnlpe are not supported under Windows, but the documentation (6.1.5 -- Process Management) fails to mention this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495191&group_id=5470 From noreply@sourceforge.net Wed Dec 19 22:40:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Dec 2001 14:40:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-494762 ] urllib2 on python2.2 ssl bug Message-ID: Bugs item #494762, was opened at 2001-12-18 13:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494762&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Marcus Felipe Pereira (makim) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 on python2.2 ssl bug Initial Comment: urllib2 on python 2.2 can´t get some SSL pages. It seams that it´s dependent of the server and the issuer of the key. The server showed below (https://wwws.task.com.br) uses IIS 5.0 and 128 bits key issued by Thawte. I´ve tested on python 2.1 and it's OK. ******** Code ************* import os,urllib2 os.environ["http_proxy"]='' f = urllib2.urlopen("https://wwws.task.com.br/i.htm") print f.read() ******** Output ************ Traceback (most recent call last): File "./httpstest", line 6, in ? f = urllib2.urlopen ("https://wwws.task.com.br/i.htm") File "/usr/lib/python2.2/urllib2.py", line 138, in urlopen return _opener.open(url, data) File "/usr/lib/python2.2/urllib2.py", line 322, in open '_open', req) File "/usr/lib/python2.2/urllib2.py", line 301, in _call_chain result = func(*args) File "/usr/lib/python2.2/urllib2.py", line 792, in https_open return self.do_open(httplib.HTTPS, req) File "/usr/lib/python2.2/urllib2.py", line 774, in do_open code, msg, hdrs = h.getreply() File "/usr/lib/python2.2/httplib.py", line 728, in getreply response = self._conn.getresponse() File "/usr/lib/python2.2/httplib.py", line 572, in getresponse response = self.response_class(self.sock) File "/usr/lib/python2.2/httplib.py", line 98, in __init__ self.fp = sock.makefile('rb', 0) File "/usr/lib/python2.2/httplib.py", line 607, in makefile buf = self.__ssl.read() socket.sslerror: (5, 'EOF occurred in violation of protocol') ***************************************** ---------------------------------------------------------------------- >Comment By: Marcus Felipe Pereira (makim) Date: 2001-12-19 14:40 Message: Logged In: YES user_id=405476 Strange is that the same code works in python 2.1 on the same machine. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-19 12:38 Message: Logged In: YES user_id=21627 If OpenSSL says the server violates the protocol, I'm pretty sure OpenSSL is right. So I fail to see the problem in Python. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494762&group_id=5470 From noreply@sourceforge.net Wed Dec 19 23:11:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Dec 2001 15:11:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-495221 ] httplib example typo Message-ID: Bugs item #495221, was opened at 2001-12-19 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495221&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason Erickson (jre) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: httplib example typo Initial Comment: In section 11.6.3 Examples, the second example showing the use of the HTTPConnection class has a typo somewhat left over from the older HTTP class example in previous versions of the documentation: >>> response = h.getresponse() should be >>> response = conn.getresponse() This was noticed on documentation updated on December 18, 2001 at the following url: http://python.sourceforge.net/devel-docs/lib/httplib- examples.html ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495221&group_id=5470 From noreply@sourceforge.net Thu Dec 20 06:15:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 19 Dec 2001 22:15:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-495021 ] Crash calling os.stat with a trailing Message-ID: Bugs item #495021, was opened at 2001-12-19 04:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495021&group_id=5470 Category: Windows Group: None Status: Closed >Resolution: Fixed Priority: 9 Submitted By: Mark Hammond (mhammond) Assigned to: Tim Peters (tim_one) Summary: Crash calling os.stat with a trailing Initial Comment: >>> import os [7206 refs] >>> os.stat("c:\temp\") [Assertion failure in debug builds] We are freeing a pointer to a buffer on the stack!!! Dumb error (mine - sorry :( ) in posixmodule.c. Attaching patch. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2001-12-19 22:15 Message: Logged In: YES user_id=14198 Looks and works OK to me! Thanks. Resolving as fixed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-19 11:07 Message: Logged In: YES user_id=31435 Thanks, Mark! I saw the report on c.l.py but it didn't crash when I tried it, so I ignored it . I rearranged the code and added some comments; please sanity- check Modules/posixmodule.c; new revision: 2.216 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495021&group_id=5470 From noreply@sourceforge.net Thu Dec 20 11:00:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 03:00:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-495358 ] rfc822.AddressList and "<>" address Message-ID: Bugs item #495358, was opened at 2001-12-20 03:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495358&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Artur Zaprzala (zybi) Assigned to: Nobody/Anonymous (nobody) Summary: rfc822.AddressList and "<>" address Initial Comment: rfc822.AddressList incorrectly handles empty address. "<>" is converted to None and should be "". AddressList.__str__() fails on None. I got an email with such an address and my program failed processing it. Example: >>> import rfc822 >>> rfc822.AddressList("<>").addresslist [('', None)] >>> str(rfc822.AddressList("<>")) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/rfc822.py", line 753, in __str__ return ", ".join(map(dump_address_pair, self.addresslist)) TypeError: sequence item 0: expected string, None found Patch is attached. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495358&group_id=5470 From noreply@sourceforge.net Thu Dec 20 11:52:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 03:52:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-495369 ] 2.2c1 framework install incomplete Message-ID: Bugs item #495369, was opened at 2001-12-20 03:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495369&group_id=5470 Category: Macintosh Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jonathan Hogg (jhogg) Assigned to: Jack Jansen (jackjansen) Summary: 2.2c1 framework install incomplete Initial Comment: I just pulled down 2.2c1 and configured/compiled it on Mac OS X 10.1.1 (w/ December 2001 Developer Tools) as follows: % ./configure --enable-framework --with-cycle-gc --with- pymalloc % make Then installed as follows: % sudo make install The Framework that has been installed doesn't have the 'Current' symlink and, worse, doesn't have the library itself! % ls /Library/Frameworks/Python.framework/Versions/ 2.2 % ls /Library/Frameworks/Python.framework/Versions/2.2/ bin include lib man I checked back over the log of what happened and I can't see any obvious errors in either the build or the installation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495369&group_id=5470 From noreply@sourceforge.net Thu Dec 20 12:02:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 04:02:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-495369 ] 2.2c1 framework install incomplete Message-ID: Bugs item #495369, was opened at 2001-12-20 03:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495369&group_id=5470 Category: Macintosh Group: Python 2.2 >Status: Deleted Resolution: None Priority: 5 Submitted By: Jonathan Hogg (jhogg) Assigned to: Jack Jansen (jackjansen) Summary: 2.2c1 framework install incomplete Initial Comment: I just pulled down 2.2c1 and configured/compiled it on Mac OS X 10.1.1 (w/ December 2001 Developer Tools) as follows: % ./configure --enable-framework --with-cycle-gc --with- pymalloc % make Then installed as follows: % sudo make install The Framework that has been installed doesn't have the 'Current' symlink and, worse, doesn't have the library itself! % ls /Library/Frameworks/Python.framework/Versions/ 2.2 % ls /Library/Frameworks/Python.framework/Versions/2.2/ bin include lib man I checked back over the log of what happened and I can't see any obvious errors in either the build or the installation. ---------------------------------------------------------------------- >Comment By: Jonathan Hogg (jhogg) Date: 2001-12-20 04:02 Message: Logged In: YES user_id=10036 Hah! Forget this - forgot that it needs the special 'make frameworkinstall' command! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495369&group_id=5470 From noreply@sourceforge.net Thu Dec 20 13:06:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 05:06:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-493826 ] Finder Tool Move not working on MOSX Message-ID: Bugs item #493826, was opened at 2001-12-15 23:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493826&group_id=5470 Category: Macintosh Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Benjamin Schollnick (bscholln) Assigned to: Jack Jansen (jackjansen) Summary: Finder Tool Move not working on MOSX Initial Comment: Under Mac OS X v10.1.1, Mac Python does not seem to handle a findertool move command. old: Macintosh HD:Desktop Folder:downloads: new: Macintosh HD:Desktop Folder:downloads:Achikatactics filename: ACHIKA_TACTICS_2_00.JPG old + file: Macintosh HD:Desktop Folder:downloads:ACHIKA_TACTICS_2_00.JPG Traceback (most recent call last): File "OS v9.1:Desktop Folder:python work:re-dup-file.py", line 104, in ? File "OS v9.1:Desktop Folder:python work:re-dup-file.py", line 53, in move_file File "OS v9.1:Applications (Mac OS 9):Python 2.1.1:Mac:Lib:findertools.py", line 74, in move File "OS v9.1:Applications (Mac OS 9):Python 2.1.1:Mac:Lib:lib-scriptpackages:Finder:Standard_Suite.py", line 293, in move aetools.Error: (0, 'component result = no error', None) The file *does* get moved, but the above trace is reported. I'll append the actual code, once I boot back to OS 9. The same code *DOES* work under OS 9... (So it is restricted to Mac OS X 10.1.1). I do not *REMEMBER* seeing the problem in earlier versions of Mac OS X, but that is suspect. (I can't say for certain that it doesn't appear). - Benjamin ---------------------------------------------------------------------- >Comment By: Benjamin Schollnick (bscholln) Date: 2001-12-20 05:06 Message: Logged In: YES user_id=3811 This is the code that is producing the error... Please keep in mind, it works fine in OS 9.x.x or earlier under MacPython. Only under MOSX does it appear to fail. (Even then the file does get moved, but an exception is raised). def move_file ( old_path, new_path, filename ): # try: print "--------------------- ----------------" print "old: ",old_path print "new:",new_path print "filename:",filename print "old + file:", old_path + filename if os.path.exists (new_path + os.sep + filename): Ask = EasyDialogs.AskYesNoCancel("Duplicate File Detected (%s), Overwrite?" % filename, default = 1, yes=None, no=None, cancel=None, id=262) if Ask == 1: if mac_mode: # Overwrite, by removing the old file # os.remove(new_path + os.sep + filename) elif Ask == 0: # # Do not overwrite, end routine, by returning # return 0 elif Ask == -1: # # Abort program, return error code # return -1 if mac_mode: findertools.move (old_path + filename, new_path) # except: # pass # return None ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493826&group_id=5470 From noreply@sourceforge.net Thu Dec 20 13:03:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 05:03:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-495358 ] rfc822.AddressList and "<>" address Message-ID: Bugs item #495358, was opened at 2001-12-20 03:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495358&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None >Priority: 7 Submitted By: Artur Zaprzala (zybi) Assigned to: Nobody/Anonymous (nobody) >Summary: rfc822.AddressList and "<>" address Initial Comment: rfc822.AddressList incorrectly handles empty address. "<>" is converted to None and should be "". AddressList.__str__() fails on None. I got an email with such an address and my program failed processing it. Example: >>> import rfc822 >>> rfc822.AddressList("<>").addresslist [('', None)] >>> str(rfc822.AddressList("<>")) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/rfc822.py", line 753, in __str__ return ", ".join(map(dump_address_pair, self.addresslist)) TypeError: sequence item 0: expected string, None found Patch is attached. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-20 05:03 Message: Logged In: YES user_id=6380 I want this reviewed before Python 2.2 goes out tomorrow. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495358&group_id=5470 From noreply@sourceforge.net Thu Dec 20 13:24:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 05:24:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-495401 ] Build troubles: --with-pymalloc Message-ID: Bugs item #495401, was opened at 2001-12-20 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Build troubles: --with-pymalloc Initial Comment: The build process segfaults with the current CVS version when using --with-pymalloc System is SuSE Linux 7.0 > uname -a Linux amazonas 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 GMT 2000 i686 unknown > gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse- linux/2.95.2/specs gcc version 2.95.2 19991024 (release) Attached is the complete build log. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 From noreply@sourceforge.net Thu Dec 20 14:25:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 06:25:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-493243 ] ext call doco warts Message-ID: Bugs item #493243, was opened at 2001-12-14 02:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493243&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ext call doco warts Initial Comment: Now they've been compiled , I notice that there are some warts in my docs for the *- and **-style call syntax. 1) the "argument_list" production is really, really confusing. there must be a better BNF-style way of saying that. I don't think vertically centering the production name against the production helps. 2) For some reason, where I say It is unusual for both keyword arguments and the "*expression"syntax to be used in the same call, so in practice this confusion does not arise. there's no space between `"*expression"' and `syntax'. I'd guess that this is because in the source, the \samp{} macro is the last thing on the line, but why that should lead to a missing space is beyond me -- more latex2html bugs? (just noticed the same thing a bit higher up too -- the "**expression"argument, if any No hurry with these. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-20 06:25 Message: Logged In: YES user_id=6656 Another problem with the pseudo-EBNF: it's wrong. Oops. It suggests that f(a, **b) isn't legal, for example. I've attached an attempt I think it right, but I'm not sure and haven't compiled it (& so don't know if it looks any less confusing than last time). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-14 09:01 Message: Logged In: YES user_id=3066 Fixed table cell alignment in Doc/perl/python.perl revision 1.115. Fixed item 2: Worked around spaces problem in Doc/ref/ref5.tex 1.53 This bug remains open; I still need to address the basic problem in item 1 (confusing pseudo-EBNF). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493243&group_id=5470 From noreply@sourceforge.net Thu Dec 20 15:27:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 07:27:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-495358 ] rfc822.AddressList and "<>" address Message-ID: Bugs item #495358, was opened at 2001-12-20 03:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495358&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open >Resolution: Accepted Priority: 7 Submitted By: Artur Zaprzala (zybi) Assigned to: Nobody/Anonymous (nobody) >Summary: rfc822.AddressList and "<>" address Initial Comment: rfc822.AddressList incorrectly handles empty address. "<>" is converted to None and should be "". AddressList.__str__() fails on None. I got an email with such an address and my program failed processing it. Example: >>> import rfc822 >>> rfc822.AddressList("<>").addresslist [('', None)] >>> str(rfc822.AddressList("<>")) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/rfc822.py", line 753, in __str__ return ", ".join(map(dump_address_pair, self.addresslist)) TypeError: sequence item 0: expected string, None found Patch is attached. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-20 07:27 Message: Logged In: YES user_id=12800 Looks okay to me. Accepted the patch, but I'll leave it to Guido to commit. +1 for Py2.2. test_email.py and test_rfc822.py both continue to pass (which tells me they really don't test this case ;). Or assign the patch to me and I'll commit it, update the test suite and docs. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-20 05:03 Message: Logged In: YES user_id=6380 I want this reviewed before Python 2.2 goes out tomorrow. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495358&group_id=5470 From noreply@sourceforge.net Thu Dec 20 15:55:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 07:55:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-495358 ] rfc822.AddressList and "<>" address Message-ID: Bugs item #495358, was opened at 2001-12-20 03:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495358&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: Accepted >Priority: 5 Submitted By: Artur Zaprzala (zybi) >Assigned to: Anthony Baxter (anthonybaxter) >Summary: rfc822.AddressList and "<>" address Initial Comment: rfc822.AddressList incorrectly handles empty address. "<>" is converted to None and should be "". AddressList.__str__() fails on None. I got an email with such an address and my program failed processing it. Example: >>> import rfc822 >>> rfc822.AddressList("<>").addresslist [('', None)] >>> str(rfc822.AddressList("<>")) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/rfc822.py", line 753, in __str__ return ", ".join(map(dump_address_pair, self.addresslist)) TypeError: sequence item 0: expected string, None found Patch is attached. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-20 07:55 Message: Logged In: YES user_id=6380 Thanks! Applied to Python 2.2 in CVS. Assigned to Anthony as a 2.1.2 candidate. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-20 07:27 Message: Logged In: YES user_id=12800 Looks okay to me. Accepted the patch, but I'll leave it to Guido to commit. +1 for Py2.2. test_email.py and test_rfc822.py both continue to pass (which tells me they really don't test this case ;). Or assign the patch to me and I'll commit it, update the test suite and docs. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-20 05:03 Message: Logged In: YES user_id=6380 I want this reviewed before Python 2.2 goes out tomorrow. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495358&group_id=5470 From noreply@sourceforge.net Thu Dec 20 17:24:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 09:24:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-495191 ] os.spawnlp not supported under Windows Message-ID: Bugs item #495191, was opened at 2001-12-19 14:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495191&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: os.spawnlp not supported under Windows Initial Comment: os.spawnlp and os.spawnlpe are not supported under Windows, but the documentation (6.1.5 -- Process Management) fails to mention this. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-20 09:24 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/libos.tex revision 1.74. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495191&group_id=5470 From noreply@sourceforge.net Thu Dec 20 19:06:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 11:06:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-495548 ] troublesome #define in pyport.h Message-ID: Bugs item #495548, was opened at 2001-12-20 11:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495548&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Norman Vine (nhv) Assigned to: Nobody/Anonymous (nobody) Summary: troublesome #define in pyport.h Initial Comment: In include/pyport.h at line 36 the #define ANY void causes conflicts with several other packages Do we really need this any more ? A quick grep of the distribution didn't show that it was used anywhere ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495548&group_id=5470 From noreply@sourceforge.net Thu Dec 20 20:46:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 12:46:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-495601 ] Documentation strings should end with a Message-ID: Bugs item #495601, was opened at 2001-12-20 12:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495601&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Documentation strings should end with a Initial Comment: [please CC 94770@bugs.debian.org on replies. The original bug report can be found at http://bugs.debian.org/94770] Submitted by Sebastian Rittau The examples in chapter 4.6 of the Python tutorial contain docstrings that don't end with periods, even though in chapter 4.7.5 it says: "[The first docstring] line should begin with a capital letter and end with a period." (I know that I'm really nitpicking, but I think examples should be as correct as possible.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495601&group_id=5470 From noreply@sourceforge.net Thu Dec 20 20:51:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 12:51:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-495603 ] CDROM module woefully out of date Message-ID: Bugs item #495603, was opened at 2001-12-20 12:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495603&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: CDROM module woefully out of date Initial Comment: [please CC 125785@bugs.debian.org on replies, bug reported at http://bugs.debian.org/125785 ] CDROM.py The above-referenced file apparently predates the Linux 2.2 kernel; it omits the defines required for the uniform CD-ROM driver ioctls, which are useful for detecting whether a CD is in the drive and for other various and sundry tasks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495603&group_id=5470 From noreply@sourceforge.net Thu Dec 20 21:02:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 13:02:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-495609 ] python doesn't define SIG* Message-ID: Bugs item #495609, was opened at 2001-12-20 13:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495609&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: python doesn't define SIG* Initial Comment: [please CC 109292@bugs.debian.org on replies. the original report can be found at http://bugs.debian.org/109292] There is a function, os.kill( , ). However, there are no symbolic name definitions for . The values for signals can vary by arch and by operating system. Please add some definitions. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495609&group_id=5470 From noreply@sourceforge.net Thu Dec 20 21:40:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 13:40:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-495624 ] Error building info docs Message-ID: Bugs item #495624, was opened at 2001-12-20 13:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495624&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: Error building info docs Initial Comment: make info fails ... Element.pm is from the (Debian) package libhtml-tree- perl, version 3.11. Any hints, what's wrong? $ make info cd info && make make[1]: Entering directory `/export/swt- dev/users/doko/packages/python2.2/python2.2- 2.1.99c1/Doc/info' ../tools/mkinfo ../html/api/api.html perl - I/home/swt/doko/export/packages/python2.2/python2.2- 2.1.99c1/Doc/tools /home/swt/doko/export/packages/pytho n2.2/python2.2- 2.1.99c1/Doc/tools/html2texi.pl /home/swt/doko/export/p ackages/python2.2/python2.2- 2.1.99c1/Doc/html/api/api.html /usr/share/perl5/HTML/Element.pm:2091: function main::output_body expected 3 arguments, got 5: Guido van Rossum 1 4 HTML::Element=HASH(0x82c479c) 0 make[1]: *** [python-api.info] Error 255 make[1]: Leaving directory `/export/swt- dev/users/doko/packages/python2.2/python2.2- 2.1.99c1/Doc/info' make: *** [info] Error 2 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495624&group_id=5470 From noreply@sourceforge.net Thu Dec 20 21:46:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 13:46:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-493826 ] Finder Tool Move not working on MOSX Message-ID: Bugs item #493826, was opened at 2001-12-15 23:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493826&group_id=5470 Category: Macintosh Group: Platform-specific Status: Open Resolution: None >Priority: 3 Submitted By: Benjamin Schollnick (bscholln) Assigned to: Jack Jansen (jackjansen) Summary: Finder Tool Move not working on MOSX Initial Comment: Under Mac OS X v10.1.1, Mac Python does not seem to handle a findertool move command. old: Macintosh HD:Desktop Folder:downloads: new: Macintosh HD:Desktop Folder:downloads:Achikatactics filename: ACHIKA_TACTICS_2_00.JPG old + file: Macintosh HD:Desktop Folder:downloads:ACHIKA_TACTICS_2_00.JPG Traceback (most recent call last): File "OS v9.1:Desktop Folder:python work:re-dup-file.py", line 104, in ? File "OS v9.1:Desktop Folder:python work:re-dup-file.py", line 53, in move_file File "OS v9.1:Applications (Mac OS 9):Python 2.1.1:Mac:Lib:findertools.py", line 74, in move File "OS v9.1:Applications (Mac OS 9):Python 2.1.1:Mac:Lib:lib-scriptpackages:Finder:Standard_Suite.py", line 293, in move aetools.Error: (0, 'component result = no error', None) The file *does* get moved, but the above trace is reported. I'll append the actual code, once I boot back to OS 9. The same code *DOES* work under OS 9... (So it is restricted to Mac OS X 10.1.1). I do not *REMEMBER* seeing the problem in earlier versions of Mac OS X, but that is suspect. (I can't say for certain that it doesn't appear). - Benjamin ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-20 13:46 Message: Logged In: YES user_id=45365 My feeling is that the problem is with the finder, not with Python. The 10.1.1 finder apparently returns an 'errn' parameter (keyErrorNumber) with value 0. My interpretation (and every other scriptable app in the world) does not return any 'errn' parameter in the no-error case. I suggest you file this as a bug with Apple. If they won't fix it I'll do so (reluctantly;-). In the mean time you can work around the problem by replacing all the if has_key(_arguments, 'errn'): with if has_key(_arguments, 'errn') and _arguments['errn'] != 0: ---------------------------------------------------------------------- Comment By: Benjamin Schollnick (bscholln) Date: 2001-12-20 05:06 Message: Logged In: YES user_id=3811 This is the code that is producing the error... Please keep in mind, it works fine in OS 9.x.x or earlier under MacPython. Only under MOSX does it appear to fail. (Even then the file does get moved, but an exception is raised). def move_file ( old_path, new_path, filename ): # try: print "--------------------- ----------------" print "old: ",old_path print "new:",new_path print "filename:",filename print "old + file:", old_path + filename if os.path.exists (new_path + os.sep + filename): Ask = EasyDialogs.AskYesNoCancel("Duplicate File Detected (%s), Overwrite?" % filename, default = 1, yes=None, no=None, cancel=None, id=262) if Ask == 1: if mac_mode: # Overwrite, by removing the old file # os.remove(new_path + os.sep + filename) elif Ask == 0: # # Do not overwrite, end routine, by returning # return 0 elif Ask == -1: # # Abort program, return error code # return -1 if mac_mode: findertools.move (old_path + filename, new_path) # except: # pass # return None ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493826&group_id=5470 From noreply@sourceforge.net Thu Dec 20 23:37:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 15:37:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-495548 ] troublesome #define in pyport.h Message-ID: Bugs item #495548, was opened at 2001-12-20 11:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495548&group_id=5470 Category: Python Interpreter Core >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Norman Vine (nhv) >Assigned to: Tim Peters (tim_one) Summary: troublesome #define in pyport.h Initial Comment: In include/pyport.h at line 36 the #define ANY void causes conflicts with several other packages Do we really need this any more ? A quick grep of the distribution didn't show that it was used anywhere ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-20 15:37 Message: Logged In: YES user_id=31435 It's left over from pre-ANSIsification. The problem with old crap like this is that, while the core never uses it anymore, its exposure via Python.h means extension authors may be relying on it. So taking it out is dangerous (certainly too dangerous remove from 2.2 at this point). I'll get rid of it for the first 2.3 alpha, though. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495548&group_id=5470 From noreply@sourceforge.net Thu Dec 20 23:40:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 15:40:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-495609 ] python doesn't define SIG* Message-ID: Bugs item #495609, was opened at 2001-12-20 13:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495609&group_id=5470 Category: Python Library Group: Feature Request >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Tim Peters (tim_one) Summary: python doesn't define SIG* Initial Comment: [please CC 109292@bugs.debian.org on replies. the original report can be found at http://bugs.debian.org/109292] There is a function, os.kill( , ). However, there are no symbolic name definitions for . The values for signals can vary by arch and by operating system. Please add some definitions. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-20 15:40 Message: Logged In: YES user_id=31435 Import signal to get the SIG* names appropriate for your platform; e.g., try import signal dir(signal) at an interactive prompt to see what's there. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495609&group_id=5470 From noreply@sourceforge.net Thu Dec 20 23:46:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 15:46:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-495672 ] xml.AttributesImpl: __setitem__ undef. Message-ID: Bugs item #495672, was opened at 2001-12-20 15:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495672&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: xml.AttributesImpl: __setitem__ undef. Initial Comment: [please CC 120343@bugs.debian.org on replies; the complete report can be seen at http://bugs.debian.org/120343] xml.sax.xmlreader.AttributesImpl does not have a __setitem__ defined. The definition is trivial (or AttributesImpl could be written to extend UserDict), but its lack is a minor annoyance when writing an XML filter. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495672&group_id=5470 From noreply@sourceforge.net Thu Dec 20 23:57:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 15:57:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-495609 ] python doesn't define SIG* Message-ID: Bugs item #495609, was opened at 2001-12-20 13:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495609&group_id=5470 Category: Python Library Group: Feature Request Status: Closed Resolution: Invalid Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Tim Peters (tim_one) Summary: python doesn't define SIG* Initial Comment: [please CC 109292@bugs.debian.org on replies. the original report can be found at http://bugs.debian.org/109292] There is a function, os.kill( , ). However, there are no symbolic name definitions for . The values for signals can vary by arch and by operating system. Please add some definitions. ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2001-12-20 15:57 Message: Logged In: YES user_id=60903 Thanks. IMO a cross reference in the library docs for os.kill would be apropriate. should another report be opened for this request? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-20 15:40 Message: Logged In: YES user_id=31435 Import signal to get the SIG* names appropriate for your platform; e.g., try import signal dir(signal) at an interactive prompt to see what's there. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495609&group_id=5470 From noreply@sourceforge.net Fri Dec 21 00:18:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 16:18:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-495680 ] include TCP_CORK in socket module Message-ID: Bugs item #495680, was opened at 2001-12-20 16:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495680&group_id=5470 Category: Extension Modules Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: include TCP_CORK in socket module Initial Comment: [please CC 84340@bugs.debian.org on replies; the original report can be found at http://bugs.debian.org/84340] File: /usr/lib/python2.0/plat-linux2/SOCKET.py The TCP_CORK option's value is not included in the SOCKET.py and IN.py files, which is slightly inconvenient if a user program wants to request this socket option (useful for network servers). (This is on the borderline between minor or wishlist. If needed it can be solved as needed at the application level with some exception handling...) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495680&group_id=5470 From noreply@sourceforge.net Fri Dec 21 00:22:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 16:22:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-495682 ] cannot handle http_proxy with user:pass@ Message-ID: Bugs item #495682, was opened at 2001-12-20 16:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495682&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: cannot handle http_proxy with user:pass@ Initial Comment: [please CC 120013@bugs.debian.org; the original report can be found at http://bugs.debian.org/120013 ] I tried to use an http_proxy variable which looks like: http://user:pass@proxy:3128/ with pass like \jkIoPd{ And I got this error : Traceback (most recent call last): File "/usr/bin/reportbug", line 1146, in ? main() File "/usr/bin/reportbug", line 628, in main http_proxy) File "/usr/lib/site-python/reportbug_ui_text.py", line 314, in handle_bts_query archived=archived) File "/usr/lib/site-python/debianbts.py", line 575, in get_reports result = get_cgi_reports(package, system, http_proxy, archived) File "/usr/lib/site-python/debianbts.py", line 494, in get_cgi_reports page = urlopen(url, proxies=proxies) File "/usr/lib/site-python/debianbts.py", line 382, in urlopen return _urlopener.open(url) File "/usr/lib/python2.1/urllib.py", line 176, in open return getattr(self, name)(url) File "/usr/lib/python2.1/urllib.py", line 277, in open_http h = httplib.HTTP(host) File "/usr/lib/python2.1/httplib.py", line 663, in __init__ self._conn = self._connection_class(host, port) File "/usr/lib/python2.1/httplib.py", line 342, in __init__ self._set_hostport(host, port) File "/usr/lib/python2.1/httplib.py", line 348, in _set_hostport port = int(host[i+1:]) ValueError: invalid literal for int(): \jkIoPd {@proxy:3128 But if I use http_proxy=http://10.0.0.1:3128/, it works well. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495682&group_id=5470 From noreply@sourceforge.net Fri Dec 21 00:34:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 16:34:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-495609 ] python doesn't define SIG* Message-ID: Bugs item #495609, was opened at 2001-12-20 13:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495609&group_id=5470 >Category: Documentation >Group: None >Status: Open Resolution: Invalid Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: python doesn't define SIG* Initial Comment: [please CC 109292@bugs.debian.org on replies. the original report can be found at http://bugs.debian.org/109292] There is a function, os.kill( , ). However, there are no symbolic name definitions for . The values for signals can vary by arch and by operating system. Please add some definitions. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-20 16:34 Message: Logged In: YES user_id=31435 Na, reopened this, changed the Category to Docs, and reassigned to Fred. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2001-12-20 15:57 Message: Logged In: YES user_id=60903 Thanks. IMO a cross reference in the library docs for os.kill would be apropriate. should another report be opened for this request? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-20 15:40 Message: Logged In: YES user_id=31435 Import signal to get the SIG* names appropriate for your platform; e.g., try import signal dir(signal) at an interactive prompt to see what's there. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495609&group_id=5470 From noreply@sourceforge.net Fri Dec 21 00:38:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 16:38:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-219486 ] fcntl.lockf() is broken Message-ID: Bugs item #219486, was opened at 2000-10-26 14:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=219486&group_id=5470 Category: Extension Modules Group: Not a Bug Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Gregor Hoffleit (flight) Assigned to: Guido van Rossum (gvanrossum) Summary: fcntl.lockf() is broken Initial Comment: Another observation by James Troup : fcntl.lockf() seems to be severly `broken': it's acting like flock, not like lockf, and the code seems to be a copy/paste of flock. (registered in the Debian Bug Tracking System as bug #74777, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=74777). James includes a first start at filling in a correct lockf function. Looks like it needs some more work, therefore I don't submit it as patch. The patch is against 1.5.2, though there seem to be no changes in 2.0. These are James' words: fcntl.lockf() doesn't work as expected. fcntl.lockf(fd, FCNTL.F_TLOCK); will block.. looking at the source is exteremly confusing. fcntl.lockf() appears to want flock() style arguments?! It almost looks like someone cut'n'wasted from the fcntl_flock() function just above... Anyway, here is a patch which is IMO the Right Thing, i.e. fcnt.lockf() acting like libc lockf() and like it's documented to do... --- python-1.5.2/Modules/fcntlmodule.c.orig Sat Oct 14 15:46:40 2000 +++ python-1.5.2/Modules/fcntlmodule.c Sat Oct 14 18:31:44 2000 @@ -233,30 +233,12 @@ { int fd, code, ret, whence = 0; PyObject *lenobj = NULL, *startobj = NULL; + struct flock l; if (!PyArg_ParseTuple(args, "ii|OOi", &fd, &code, &lenobj, &startobj, &whence)) return NULL; -#ifndef LOCK_SH -#define LOCK_SH 1 /* shared lock */ -#define LOCK_EX 2 /* exclusive lock */ -#define LOCK_NB 4 /* don't block when locking */ -#define LOCK_UN 8 /* unlock */ -#endif - { - struct flock l; - if (code == LOCK_UN) - l.l_type = F_UNLCK; - else if (code & LOCK_SH) - l.l_type = F_RDLCK; - else if (code & LOCK_EX) - l.l_type = F_WRLCK; - else { - PyErr_SetString(PyExc_ValueError, - "unrecognized flock argument"); - return NULL; - } l.l_start = l.l_len = 0; if (startobj != NULL) { #if !defined(HAVE_LARGEFILE_SUPPORT) @@ -281,10 +263,48 @@ return NULL; } l.l_whence = whence; + switch (code) + { + case F_TEST: + /* Test the lock: return 0 if FD is unlocked or locked by this process; + return -1, set errno to EACCES, if another process holds the lock. */ + if (fcntl (fd, F_GETLK, &l) < 0) { + fprintf(stderr, "andrea: 1"); + PyErr_SetFromErrno(PyExc_IOError); + return NULL; + } + if (l.l_type == F_UNLCK || l.l_pid == getpid ()) { + fprintf(stderr, "andrea: 2"); + Py_INCREF(Py_None); + return Py_None; + } + fprintf(stderr, "andrea: 3"); + errno = EACCES; + PyErr_SetFromErrno(PyExc_IOError); + return NULL; + + case F_ULOCK: + l.l_type = F_UNLCK; + code = F_SETLK; + break; + case F_LOCK: + l.l_type = F_WRLCK; + code = F_SETLKW; + break; + case F_TLOCK: + l.l_type = F_WRLCK; + code = F_SETLK; + break; + + default: + PyErr_SetString(PyExc_ValueError, + "unrecognized flock argument"); + return NULL; + } Py_BEGIN_ALLOW_THREADS - ret = fcntl(fd, (code & LOCK_NB) ? F_SETLK : F_SETLKW, &l); + ret = fcntl(fd, code, &l); Py_END_ALLOW_THREADS - } + if (ret < 0) { PyErr_SetFromErrno(PyExc_IOError); return NULL; ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2001-12-20 16:38 Message: Logged In: YES user_id=60903 [repeat a final (?) comment from the bug submitter. please CC 74777-submitter@bugs.debian.org on replies. 74777-submitter writes: So... Executive summary: o yes, python's lockf() is fucked o no, there's not a good reason for it, just the lame ass excuse that they were tying to make things easier (??) o No, they won't fix it because that would mean breaking backward compatibility (?? from the people who are changing the meaning of / ??) Conclusion: o python upstream sucks hairy mammoths. Bah! Anyway, thanks for chasing this up Matthias, feel free to close the bug, I guess I'll just have to work around upstream stupidity. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 13:33 Message: Logged In: YES user_id=6380 I've looked into this, and I finally have an idea what's the matter here. The similarity with flock is intentional; the lockf and flock calls are an abstraction level away from the fcntl locking call. By using the same arguments in both cases we hoped to make things easier for the Python user. We may not have succeeded there, but I prefer to document the status quo over "fixing" the interface and breaking code that uses it. Therefore, I'm rejecting the patch. The documentation has been updated, see the working docs: http://python.sourceforge.net/devel-docs/lib/module-fcntl.html ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-18 19:37 Message: I apologize. I should've looked into this earlier. Now I won't have time to look at it before releasing 2.1a1. I promise I'll come back to it later. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2000-12-19 17:19 Message: Note that the docs say that lockf "is a wrapper around the \constant{FCNTL.F_SETLK} and \constant{FCNTL.F_SETLKW} \function{fcntl()} calls." Stevens's "Advanced Programming in the Unix Env." concurs, on page 367: "The System V lockf() is just an interface to fcntl()." However, none of us are serious Unix weenies. Unfortunately, the documented Python lockf() provides features above the libc lockf(), so using the system lockf() seems impossible unless we break backwards compatibility. Unfortunately none of us are serious Unix weenies, so writing a lockf() emulation that's completely correct everywhere might be very difficult. Troup's patch attempts to fix the emulation; I haven't looked at it closely. I'd suggest breaking backwards compatibility; if that's out, we should take a close look at the patch. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2000-11-24 01:32 Message: Yeah, I looked at it. In 1996. I don't think I looked at flock since then. Anyway, it compiles on my system (IRIX 6.5.2), and I don't think I will have time in the near future to look any further into this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-26 14:29 Message: Sjoerd, you once looked at this code. Can you comment on this? If you don't have time, please assign back to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=219486&group_id=5470 From noreply@sourceforge.net Fri Dec 21 00:51:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 16:51:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-495693 ] urllib doesn't support passive FTP Message-ID: Bugs item #495693, was opened at 2001-12-20 16:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495693&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: urllib doesn't support passive FTP Initial Comment: [please CC 40981@bugs.debian.org on replies; complete report can be found at http://bugs.debian.org/40981] urllib.urlopen/urlretrieve doesn't support passive FTP urllib doesn't support passive FTP, even though the underlying ftplib module does. I dunno what the right approach is (perhaps a urllib module global variable). I know some tools (I'm aware of at least ncftp and wget) autodetect whether PASV is supported by FTP servers; perhaps that intelligence could be added to ftplib. (Also: the FTP class's set_pasv() method isn't documented in my version of python-docs; I haven't checked the new 1.5.2 docs yet however.) At the moment, I'm using this ugly hack to get around it: # Really ugly hack; don't try this at home: def ftpwrapper_init(self): import ftplib self.busy = 0 self.ftp = ftplib.FTP() self.ftp.set_pasv(1) self.ftp.connect(self.host, self.port) self.ftp.login(self.user, self.passwd) for dir in self.dirs: self.ftp.cwd(dir) urllib.ftpwrapper.init = ftpwrapper_init # End really ugly hack ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495693&group_id=5470 From noreply@sourceforge.net Fri Dec 21 00:56:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 16:56:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-495695 ] webbrowser.py: selection of browser Message-ID: Bugs item #495695, was opened at 2001-12-20 16:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495695&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser.py: selection of browser Initial Comment: [please CC 121737@bugs.debian.org on replies; complete report can be found at http://bugs.debian.org/121737 ] webbrowser.py tries hard to select correct browsers and then wastes it The culprit is the last loop, registering everything possible. I'm not sure, but wasn't it supposed to run only in the environ["BROWSER"] case like this?: -----diff start----- --- /usr/lib/python2.1/webbrowser.py Sun Nov 11 18:23:54 2001 +++ /tmp/webbrowser.py Thu Nov 29 17:40:46 2001 @@ -305,11 +305,10 @@ # It's the user's responsibility to register handlers for any unknown # browser referenced by this value, before calling open(). _tryorder = os.environ["BROWSER"].split(":") - -for cmd in _tryorder: - if not _browsers.has_key(cmd.lower()): - if _iscommand(cmd.lower()): - register(cmd.lower(), None, GenericBrowser ("%s %%s" % cmd.lower())) + for cmd in _tryorder: + if not _browsers.has_key(cmd.lower()): + if _iscommand(cmd.lower()): + register(cmd.lower(), None, GenericBrowser("%s %%s" % cmd.lower())) _tryorder = filter(lambda x: _browsers.has_key(x.lower ()) or x.find("%s") > -1, _tryorder) -----diff end----- ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495695&group_id=5470 From noreply@sourceforge.net Fri Dec 21 03:49:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 19:49:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-495601 ] Documentation strings should end with a Message-ID: Bugs item #495601, was opened at 2001-12-20 12:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495601&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Documentation strings should end with a Initial Comment: [please CC 94770@bugs.debian.org on replies. The original bug report can be found at http://bugs.debian.org/94770] Submitted by Sebastian Rittau The examples in chapter 4.6 of the Python tutorial contain docstrings that don't end with periods, even though in chapter 4.7.5 it says: "[The first docstring] line should begin with a capital letter and end with a period." (I know that I'm really nitpicking, but I think examples should be as correct as possible.) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-20 19:49 Message: Logged In: YES user_id=3066 Fixed in Doc/tut/tut.tex revisions 1.157 and 1.156.4.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495601&group_id=5470 From noreply@sourceforge.net Fri Dec 21 03:52:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 19:52:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-495221 ] httplib example typo Message-ID: Bugs item #495221, was opened at 2001-12-19 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495221&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jason Erickson (jre) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: httplib example typo Initial Comment: In section 11.6.3 Examples, the second example showing the use of the HTTPConnection class has a typo somewhat left over from the older HTTP class example in previous versions of the documentation: >>> response = h.getresponse() should be >>> response = conn.getresponse() This was noticed on documentation updated on December 18, 2001 at the following url: http://python.sourceforge.net/devel-docs/lib/httplib- examples.html ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-20 19:52 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/libhttplib.tex revisions 1.29 and 1.28.4.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495221&group_id=5470 From noreply@sourceforge.net Fri Dec 21 03:59:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 19:59:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-495609 ] python doesn't define SIG* Message-ID: Bugs item #495609, was opened at 2001-12-20 13:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495609&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: python doesn't define SIG* Initial Comment: [please CC 109292@bugs.debian.org on replies. the original report can be found at http://bugs.debian.org/109292] There is a function, os.kill( , ). However, there are no symbolic name definitions for . The values for signals can vary by arch and by operating system. Please add some definitions. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-20 19:59 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/libos.tex revisions 1.75 and 1.74.2.1. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-20 16:34 Message: Logged In: YES user_id=31435 Na, reopened this, changed the Category to Docs, and reassigned to Fred. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2001-12-20 15:57 Message: Logged In: YES user_id=60903 Thanks. IMO a cross reference in the library docs for os.kill would be apropriate. should another report be opened for this request? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-20 15:40 Message: Logged In: YES user_id=31435 Import signal to get the SIG* names appropriate for your platform; e.g., try import signal dir(signal) at an interactive prompt to see what's there. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495609&group_id=5470 From noreply@sourceforge.net Fri Dec 21 04:36:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 20 Dec 2001 20:36:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-219486 ] fcntl.lockf() is broken Message-ID: Bugs item #219486, was opened at 2000-10-26 14:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=219486&group_id=5470 Category: Extension Modules Group: Not a Bug >Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Gregor Hoffleit (flight) Assigned to: Guido van Rossum (gvanrossum) Summary: fcntl.lockf() is broken Initial Comment: Another observation by James Troup : fcntl.lockf() seems to be severly `broken': it's acting like flock, not like lockf, and the code seems to be a copy/paste of flock. (registered in the Debian Bug Tracking System as bug #74777, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=74777). James includes a first start at filling in a correct lockf function. Looks like it needs some more work, therefore I don't submit it as patch. The patch is against 1.5.2, though there seem to be no changes in 2.0. These are James' words: fcntl.lockf() doesn't work as expected. fcntl.lockf(fd, FCNTL.F_TLOCK); will block.. looking at the source is exteremly confusing. fcntl.lockf() appears to want flock() style arguments?! It almost looks like someone cut'n'wasted from the fcntl_flock() function just above... Anyway, here is a patch which is IMO the Right Thing, i.e. fcnt.lockf() acting like libc lockf() and like it's documented to do... --- python-1.5.2/Modules/fcntlmodule.c.orig Sat Oct 14 15:46:40 2000 +++ python-1.5.2/Modules/fcntlmodule.c Sat Oct 14 18:31:44 2000 @@ -233,30 +233,12 @@ { int fd, code, ret, whence = 0; PyObject *lenobj = NULL, *startobj = NULL; + struct flock l; if (!PyArg_ParseTuple(args, "ii|OOi", &fd, &code, &lenobj, &startobj, &whence)) return NULL; -#ifndef LOCK_SH -#define LOCK_SH 1 /* shared lock */ -#define LOCK_EX 2 /* exclusive lock */ -#define LOCK_NB 4 /* don't block when locking */ -#define LOCK_UN 8 /* unlock */ -#endif - { - struct flock l; - if (code == LOCK_UN) - l.l_type = F_UNLCK; - else if (code & LOCK_SH) - l.l_type = F_RDLCK; - else if (code & LOCK_EX) - l.l_type = F_WRLCK; - else { - PyErr_SetString(PyExc_ValueError, - "unrecognized flock argument"); - return NULL; - } l.l_start = l.l_len = 0; if (startobj != NULL) { #if !defined(HAVE_LARGEFILE_SUPPORT) @@ -281,10 +263,48 @@ return NULL; } l.l_whence = whence; + switch (code) + { + case F_TEST: + /* Test the lock: return 0 if FD is unlocked or locked by this process; + return -1, set errno to EACCES, if another process holds the lock. */ + if (fcntl (fd, F_GETLK, &l) < 0) { + fprintf(stderr, "andrea: 1"); + PyErr_SetFromErrno(PyExc_IOError); + return NULL; + } + if (l.l_type == F_UNLCK || l.l_pid == getpid ()) { + fprintf(stderr, "andrea: 2"); + Py_INCREF(Py_None); + return Py_None; + } + fprintf(stderr, "andrea: 3"); + errno = EACCES; + PyErr_SetFromErrno(PyExc_IOError); + return NULL; + + case F_ULOCK: + l.l_type = F_UNLCK; + code = F_SETLK; + break; + case F_LOCK: + l.l_type = F_WRLCK; + code = F_SETLKW; + break; + case F_TLOCK: + l.l_type = F_WRLCK; + code = F_SETLK; + break; + + default: + PyErr_SetString(PyExc_ValueError, + "unrecognized flock argument"); + return NULL; + } Py_BEGIN_ALLOW_THREADS - ret = fcntl(fd, (code & LOCK_NB) ? F_SETLK : F_SETLKW, &l); + ret = fcntl(fd, code, &l); Py_END_ALLOW_THREADS - } + if (ret < 0) { PyErr_SetFromErrno(PyExc_IOError); return NULL; ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-20 20:36 Message: Logged In: YES user_id=6380 doko, what's going on here? I don't appreciate your inserting foul language in our tracker. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2001-12-20 16:38 Message: Logged In: YES user_id=60903 [repeat a final (?) comment from the bug submitter. please CC 74777-submitter@bugs.debian.org on replies. 74777-submitter writes: So... Executive summary: o yes, python's lockf() is fucked o no, there's not a good reason for it, just the lame ass excuse that they were tying to make things easier (??) o No, they won't fix it because that would mean breaking backward compatibility (?? from the people who are changing the meaning of / ??) Conclusion: o python upstream sucks hairy mammoths. Bah! Anyway, thanks for chasing this up Matthias, feel free to close the bug, I guess I'll just have to work around upstream stupidity. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 13:33 Message: Logged In: YES user_id=6380 I've looked into this, and I finally have an idea what's the matter here. The similarity with flock is intentional; the lockf and flock calls are an abstraction level away from the fcntl locking call. By using the same arguments in both cases we hoped to make things easier for the Python user. We may not have succeeded there, but I prefer to document the status quo over "fixing" the interface and breaking code that uses it. Therefore, I'm rejecting the patch. The documentation has been updated, see the working docs: http://python.sourceforge.net/devel-docs/lib/module-fcntl.html ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-18 19:37 Message: I apologize. I should've looked into this earlier. Now I won't have time to look at it before releasing 2.1a1. I promise I'll come back to it later. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2000-12-19 17:19 Message: Note that the docs say that lockf "is a wrapper around the \constant{FCNTL.F_SETLK} and \constant{FCNTL.F_SETLKW} \function{fcntl()} calls." Stevens's "Advanced Programming in the Unix Env." concurs, on page 367: "The System V lockf() is just an interface to fcntl()." However, none of us are serious Unix weenies. Unfortunately, the documented Python lockf() provides features above the libc lockf(), so using the system lockf() seems impossible unless we break backwards compatibility. Unfortunately none of us are serious Unix weenies, so writing a lockf() emulation that's completely correct everywhere might be very difficult. Troup's patch attempts to fix the emulation; I haven't looked at it closely. I'd suggest breaking backwards compatibility; if that's out, we should take a close look at the patch. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2000-11-24 01:32 Message: Yeah, I looked at it. In 1996. I don't think I looked at flock since then. Anyway, it compiles on my system (IRIX 6.5.2), and I don't think I will have time in the near future to look any further into this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-26 14:29 Message: Sjoerd, you once looked at this code. Can you comment on this? If you don't have time, please assign back to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=219486&group_id=5470 From noreply@sourceforge.net Fri Dec 21 15:43:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Dec 2001 07:43:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-495875 ] pgen fails with unresolved symbols Message-ID: Bugs item #495875, was opened at 2001-12-21 07:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495875&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Richard Moseley (rpmoseley) Assigned to: Nobody/Anonymous (nobody) Summary: pgen fails with unresolved symbols Initial Comment: When compiling the release candidate 1 of version 2.2 (2.2c1) on Tru64 4.x which does not have a version of snprintf natively. Attempting to compile the pgen program which generates the graminit.[hc] files results in unresolved PyMem_Malloc and PyMem_Free since the mysnprintf makes an assumption that the symbols are always available. This successfully worked in previous versions of 2.2. Attempting to include the relavent object for the symbol then results in other unresolved symbols. Making a change to conditionally use PyMem_* or the standard malloc/free calls resolves the problem. However this may lead to using two different memory heaps one used by the PyMem and one by the malloc routines. The problem does not occur when the underlying O/S libraries provide support of the snprintf() routines. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495875&group_id=5470 From noreply@sourceforge.net Fri Dec 21 16:09:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Dec 2001 08:09:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-495875 ] pgen fails with unresolved symbols Message-ID: Bugs item #495875, was opened at 2001-12-21 07:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495875&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None >Priority: 8 Submitted By: Richard Moseley (rpmoseley) >Assigned to: Barry Warsaw (bwarsaw) Summary: pgen fails with unresolved symbols Initial Comment: When compiling the release candidate 1 of version 2.2 (2.2c1) on Tru64 4.x which does not have a version of snprintf natively. Attempting to compile the pgen program which generates the graminit.[hc] files results in unresolved PyMem_Malloc and PyMem_Free since the mysnprintf makes an assumption that the symbols are always available. This successfully worked in previous versions of 2.2. Attempting to include the relavent object for the symbol then results in other unresolved symbols. Making a change to conditionally use PyMem_* or the standard malloc/free calls resolves the problem. However this may lead to using two different memory heaps one used by the PyMem and one by the malloc routines. The problem does not occur when the underlying O/S libraries provide support of the snprintf() routines. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-21 08:09 Message: Logged In: YES user_id=31435 Whew! This was *just* in time for 2.2 final. This is very easy to fix, and assigned to Barry who is doing so. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495875&group_id=5470 From noreply@sourceforge.net Fri Dec 21 16:20:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Dec 2001 08:20:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-495875 ] pgen fails with unresolved symbols Message-ID: Bugs item #495875, was opened at 2001-12-21 07:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495875&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 8 Submitted By: Richard Moseley (rpmoseley) Assigned to: Barry Warsaw (bwarsaw) Summary: pgen fails with unresolved symbols Initial Comment: When compiling the release candidate 1 of version 2.2 (2.2c1) on Tru64 4.x which does not have a version of snprintf natively. Attempting to compile the pgen program which generates the graminit.[hc] files results in unresolved PyMem_Malloc and PyMem_Free since the mysnprintf makes an assumption that the symbols are always available. This successfully worked in previous versions of 2.2. Attempting to include the relavent object for the symbol then results in other unresolved symbols. Making a change to conditionally use PyMem_* or the standard malloc/free calls resolves the problem. However this may lead to using two different memory heaps one used by the PyMem and one by the malloc routines. The problem does not occur when the underlying O/S libraries provide support of the snprintf() routines. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-21 08:20 Message: Logged In: YES user_id=12800 Attached is the patch that fixes the problem, which I reproduced by commenting out HAS_SNPRINTF in pyconfig.h on my Linux box. All tests pass. If you can test this immediately, please let us know asap. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-21 08:09 Message: Logged In: YES user_id=31435 Whew! This was *just* in time for 2.2 final. This is very easy to fix, and assigned to Barry who is doing so. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495875&group_id=5470 From noreply@sourceforge.net Fri Dec 21 16:23:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Dec 2001 08:23:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-495875 ] pgen fails with unresolved symbols Message-ID: Bugs item #495875, was opened at 2001-12-21 07:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495875&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 8 Submitted By: Richard Moseley (rpmoseley) Assigned to: Barry Warsaw (bwarsaw) Summary: pgen fails with unresolved symbols Initial Comment: When compiling the release candidate 1 of version 2.2 (2.2c1) on Tru64 4.x which does not have a version of snprintf natively. Attempting to compile the pgen program which generates the graminit.[hc] files results in unresolved PyMem_Malloc and PyMem_Free since the mysnprintf makes an assumption that the symbols are always available. This successfully worked in previous versions of 2.2. Attempting to include the relavent object for the symbol then results in other unresolved symbols. Making a change to conditionally use PyMem_* or the standard malloc/free calls resolves the problem. However this may lead to using two different memory heaps one used by the PyMem and one by the malloc routines. The problem does not occur when the underlying O/S libraries provide support of the snprintf() routines. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-21 08:23 Message: Logged In: YES user_id=31435 Barry, this is fine -- check it in. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-21 08:20 Message: Logged In: YES user_id=12800 Attached is the patch that fixes the problem, which I reproduced by commenting out HAS_SNPRINTF in pyconfig.h on my Linux box. All tests pass. If you can test this immediately, please let us know asap. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-21 08:09 Message: Logged In: YES user_id=31435 Whew! This was *just* in time for 2.2 final. This is very easy to fix, and assigned to Barry who is doing so. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495875&group_id=5470 From noreply@sourceforge.net Fri Dec 21 16:32:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Dec 2001 08:32:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-495875 ] pgen fails with unresolved symbols Message-ID: Bugs item #495875, was opened at 2001-12-21 07:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495875&group_id=5470 Category: Build Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Richard Moseley (rpmoseley) Assigned to: Barry Warsaw (bwarsaw) Summary: pgen fails with unresolved symbols Initial Comment: When compiling the release candidate 1 of version 2.2 (2.2c1) on Tru64 4.x which does not have a version of snprintf natively. Attempting to compile the pgen program which generates the graminit.[hc] files results in unresolved PyMem_Malloc and PyMem_Free since the mysnprintf makes an assumption that the symbols are always available. This successfully worked in previous versions of 2.2. Attempting to include the relavent object for the symbol then results in other unresolved symbols. Making a change to conditionally use PyMem_* or the standard malloc/free calls resolves the problem. However this may lead to using two different memory heaps one used by the PyMem and one by the malloc routines. The problem does not occur when the underlying O/S libraries provide support of the snprintf() routines. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-21 08:32 Message: Logged In: YES user_id=12800 Patch applied to both the trunk and release-22 branch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-21 08:23 Message: Logged In: YES user_id=31435 Barry, this is fine -- check it in. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-21 08:20 Message: Logged In: YES user_id=12800 Attached is the patch that fixes the problem, which I reproduced by commenting out HAS_SNPRINTF in pyconfig.h on my Linux box. All tests pass. If you can test this immediately, please let us know asap. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-21 08:09 Message: Logged In: YES user_id=31435 Whew! This was *just* in time for 2.2 final. This is very easy to fix, and assigned to Barry who is doing so. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495875&group_id=5470 From noreply@sourceforge.net Fri Dec 21 16:50:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Dec 2001 08:50:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-495896 ] socket.fromfd not available in Windows Message-ID: Bugs item #495896, was opened at 2001-12-21 08:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495896&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ng Pheng Siong (ngps) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: socket.fromfd not available in Windows Initial Comment: Hi, On a Python 2.1.1 Windows binary installation, socket.fromfd is not available. It is available on a 2-month old Cygwin installation and also on my 2.0 from-source installation on FreeBSD. The docu that comes with a/m 2.1.1 doesn't say that fromfd is (possibly) Unix-only. Cheers. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495896&group_id=5470 From noreply@sourceforge.net Fri Dec 21 16:55:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Dec 2001 08:55:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-494572 ] plugin project generation has problems Message-ID: Bugs item #494572, was opened at 2001-12-18 05:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494572&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: plugin project generation has problems Initial Comment: The generation of CW7 projects for plugins (and distutils too, probably) still has some problems that cause CW to say the project was created by an older version of CodeWarrior. The project does work, but this needs to be fixed before 2.2 final. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-21 08:55 Message: Logged In: YES user_id=12800 Sorry Jack, bumping this down to priority 6 and deferring for post-2.2 final (although you have permission to make any Mac-only changes that might be necessary for the Mac 2.2 final release). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-19 12:34 Message: Logged In: YES user_id=21627 Any idea as to when a patch might be forthcoming? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494572&group_id=5470 From noreply@sourceforge.net Fri Dec 21 16:58:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Dec 2001 08:58:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-494572 ] plugin project generation has problems Message-ID: Bugs item #494572, was opened at 2001-12-18 05:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494572&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: plugin project generation has problems Initial Comment: The generation of CW7 projects for plugins (and distutils too, probably) still has some problems that cause CW to say the project was created by an older version of CodeWarrior. The project does work, but this needs to be fixed before 2.2 final. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-21 08:58 Message: Logged In: YES user_id=12800 Back to priority 7 so Jack doesn't forget, but it still will not hold up the source or windows release. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-21 08:55 Message: Logged In: YES user_id=12800 Sorry Jack, bumping this down to priority 6 and deferring for post-2.2 final (although you have permission to make any Mac-only changes that might be necessary for the Mac 2.2 final release). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-19 12:34 Message: Logged In: YES user_id=21627 Any idea as to when a patch might be forthcoming? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494572&group_id=5470 From noreply@sourceforge.net Fri Dec 21 17:46:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Dec 2001 09:46:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-495896 ] socket.fromfd not available in Windows Message-ID: Bugs item #495896, was opened at 2001-12-21 08:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495896&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ng Pheng Siong (ngps) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: socket.fromfd not available in Windows Initial Comment: Hi, On a Python 2.1.1 Windows binary installation, socket.fromfd is not available. It is available on a 2-month old Cygwin installation and also on my 2.0 from-source installation on FreeBSD. The docu that comes with a/m 2.1.1 doesn't say that fromfd is (possibly) Unix-only. Cheers. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-21 09:46 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/libsocket.tex revisions 1.59 and 1.51.4.1. This was not reported in time to make it into the Python 2.2 release; sorry! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495896&group_id=5470 From noreply@sourceforge.net Fri Dec 21 18:19:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Dec 2001 10:19:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-223616 ] compiler package needs better documentation. Message-ID: Bugs item #223616, was opened at 2000-11-27 10:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=223616&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 6 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Jeremy Hylton (jhylton) >Summary: compiler package needs better documentation. Initial Comment: The compiler package is not documented; this needs to be done before tools are likely to be written on top of it. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-21 10:19 Message: Logged In: YES user_id=3066 I'll note that Jeremy has written basic docs, and they are in the Library Reference. But he really needs to polish them a bit as well, so this stays open but gets a new summary. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-10 14:56 Message: Logged In: YES user_id=3066 Jeremy said he'd work on this next week, so I'm bumping the priority as a reminder. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-01-07 19:48 Message: Jeremy -- is there anything that can be done to make it easier for you to get this done? I think these should really be documented and moved into the library. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=223616&group_id=5470 From noreply@sourceforge.net Fri Dec 21 22:17:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Dec 2001 14:17:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-495978 ] It's the future for generators Message-ID: Bugs item #495978, was opened at 2001-12-21 14:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495978&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: It's the future for generators Initial Comment: "from __future__ import generators" should no longer be required in 2.3a1. Such stmts should also be removed from the Python library (there's a script under Tools to automate this). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495978&group_id=5470 From noreply@sourceforge.net Fri Dec 21 23:31:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 21 Dec 2001 15:31:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-494572 ] plugin project generation has problems Message-ID: Bugs item #494572, was opened at 2001-12-18 05:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494572&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None >Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: plugin project generation has problems Initial Comment: The generation of CW7 projects for plugins (and distutils too, probably) still has some problems that cause CW to say the project was created by an older version of CodeWarrior. The project does work, but this needs to be fixed before 2.2 final. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-12-21 15:31 Message: Logged In: YES user_id=45365 Ah, what! Lowering this to 5, as it's really only a problem for people who have CodeWarrior, who'll have to press "OK" to the "update from older project version?" question when they're building a distutils package. (of course, the real reason for lowering the priority is that I want to get 2.2 out the door, AND NOTHING WILL STOP ME, HAHAHAHAHA!!!) ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-21 08:58 Message: Logged In: YES user_id=12800 Back to priority 7 so Jack doesn't forget, but it still will not hold up the source or windows release. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-21 08:55 Message: Logged In: YES user_id=12800 Sorry Jack, bumping this down to priority 6 and deferring for post-2.2 final (although you have permission to make any Mac-only changes that might be necessary for the Mac 2.2 final release). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-19 12:34 Message: Logged In: YES user_id=21627 Any idea as to when a patch might be forthcoming? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494572&group_id=5470 From noreply@sourceforge.net Sat Dec 22 11:30:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 22 Dec 2001 03:30:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-496084 ] unicode, tkfiledialog.py Message-ID: Bugs item #496084, was opened at 2001-12-22 03:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496084&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Klaus-G. Meyer (kgm) Assigned to: M.-A. Lemburg (lemburg) Summary: unicode, tkfiledialog.py Initial Comment: The file tkfiledialog.py from python/lib/lib-tk contains some test code: if __name__ == "__main__": print "open", askopenfilename(filetypes=[("all filez", "*")]) print "saveas", asksaveasfilename() I tried it, but it won't work, if i select filenames with umlaut: C:\Programme\Python\Lib\lib-tk>python tkfiledialog.py open Traceback (most recent call last): File "tkfiledialog.py", line 128, in ? print "open", askopenfilename(filetypes=[("all filez", "*")]) UnicodeError: ASCII encoding error: ordinal not in range(128) The reason is (i think), that askopenfilename surprisingly returns unicode string instead of string. If functions return sometimes unicode strings, how should this be done? Is this a bug or a design problem? It would be nice, if the test code contains a working example. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496084&group_id=5470 From noreply@sourceforge.net Sat Dec 22 14:33:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 22 Dec 2001 06:33:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-496104 ] FP behaviour changed from 2.1.1 Message-ID: Bugs item #496104, was opened at 2001-12-22 06:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496104&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andreas Dietrich (quasi) Assigned to: Nobody/Anonymous (nobody) Summary: FP behaviour changed from 2.1.1 Initial Comment: Python2.2 floating point behaviour is different from 2.1.1 on Linux. Instead of Inf and nan an OverflowError is raised. (sometimes): Python 2.2 (#5, Dec 22 2001, 14:57:12) [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.68mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import math >>> 1e308**10 Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Numerical result out of range') >>> math.tan(1e308**10) Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Numerical result out of range') >>> 1e308*10 inf >>> math.tan(1e308*10) nan Python 2.1.1 (#1, Oct 24 2001, 13:07:11) [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.66mdk)] on linux-i386 Type "copyright", "credits" or "license" for more information. >>> import math >>> 1e308**10 inf >>> math.tan(1e308**10) nan >>> 1e308*10 inf >>> math.tan(1e308*10) nan ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496104&group_id=5470 From noreply@sourceforge.net Sat Dec 22 14:42:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 22 Dec 2001 06:42:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-495401 ] Build troubles: --with-pymalloc Message-ID: Bugs item #495401, was opened at 2001-12-20 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Build troubles: --with-pymalloc Initial Comment: The build process segfaults with the current CVS version when using --with-pymalloc System is SuSE Linux 7.0 > uname -a Linux amazonas 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 GMT 2000 i686 unknown > gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse- linux/2.95.2/specs gcc version 2.95.2 19991024 (release) Attached is the complete build log. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:42 Message: Logged In: YES user_id=21627 Did that produce a core file? If so, can you attach a gdb backtrace as well? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 From noreply@sourceforge.net Sat Dec 22 14:51:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 22 Dec 2001 06:51:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-495693 ] urllib doesn't support passive FTP Message-ID: Bugs item #495693, was opened at 2001-12-20 16:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495693&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: urllib doesn't support passive FTP Initial Comment: [please CC 40981@bugs.debian.org on replies; complete report can be found at http://bugs.debian.org/40981] urllib.urlopen/urlretrieve doesn't support passive FTP urllib doesn't support passive FTP, even though the underlying ftplib module does. I dunno what the right approach is (perhaps a urllib module global variable). I know some tools (I'm aware of at least ncftp and wget) autodetect whether PASV is supported by FTP servers; perhaps that intelligence could be added to ftplib. (Also: the FTP class's set_pasv() method isn't documented in my version of python-docs; I haven't checked the new 1.5.2 docs yet however.) At the moment, I'm using this ugly hack to get around it: # Really ugly hack; don't try this at home: def ftpwrapper_init(self): import ftplib self.busy = 0 self.ftp = ftplib.FTP() self.ftp.set_pasv(1) self.ftp.connect(self.host, self.port) self.ftp.login(self.user, self.passwd) for dir in self.dirs: self.ftp.cwd(dir) urllib.ftpwrapper.init = ftpwrapper_init # End really ugly hack ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:51 Message: Logged In: YES user_id=21627 Is the debian bug number correct? The URL gives "An error occurred. Dammit. Error was: Couldn't get bug status: No such file or directory." Also, CC'ing the Debian BTS is not easy through SF, would it be feasible that you forward all comments to the BTS yourself? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495693&group_id=5470 From noreply@sourceforge.net Sat Dec 22 15:07:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 22 Dec 2001 07:07:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-495680 ] include TCP_CORK in socket module Message-ID: Bugs item #495680, was opened at 2001-12-20 16:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495680&group_id=5470 Category: Extension Modules Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: include TCP_CORK in socket module Initial Comment: [please CC 84340@bugs.debian.org on replies; the original report can be found at http://bugs.debian.org/84340] File: /usr/lib/python2.0/plat-linux2/SOCKET.py The TCP_CORK option's value is not included in the SOCKET.py and IN.py files, which is slightly inconvenient if a user program wants to request this socket option (useful for network servers). (This is on the borderline between minor or wishlist. If needed it can be solved as needed at the application level with some exception handling...) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 07:07 Message: Logged In: YES user_id=21627 The SOCKET.py module is obsolete; access to system constants is now solely through the socket module. TCP_CORK and other TCP socket options have been added to socketmodule.c 1.201, to appear in Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495680&group_id=5470 From noreply@sourceforge.net Sat Dec 22 15:08:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 22 Dec 2001 07:08:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-495693 ] urllib doesn't support passive FTP Message-ID: Bugs item #495693, was opened at 2001-12-20 16:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495693&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: urllib doesn't support passive FTP Initial Comment: [please CC 40981@bugs.debian.org on replies; complete report can be found at http://bugs.debian.org/40981] urllib.urlopen/urlretrieve doesn't support passive FTP urllib doesn't support passive FTP, even though the underlying ftplib module does. I dunno what the right approach is (perhaps a urllib module global variable). I know some tools (I'm aware of at least ncftp and wget) autodetect whether PASV is supported by FTP servers; perhaps that intelligence could be added to ftplib. (Also: the FTP class's set_pasv() method isn't documented in my version of python-docs; I haven't checked the new 1.5.2 docs yet however.) At the moment, I'm using this ugly hack to get around it: # Really ugly hack; don't try this at home: def ftpwrapper_init(self): import ftplib self.busy = 0 self.ftp = ftplib.FTP() self.ftp.set_pasv(1) self.ftp.connect(self.host, self.port) self.ftp.login(self.user, self.passwd) for dir in self.dirs: self.ftp.cwd(dir) urllib.ftpwrapper.init = ftpwrapper_init # End really ugly hack ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-22 07:08 Message: Logged In: YES user_id=6380 Martin, in ftplib.py, there's a self.passiveserver = 0" in the connect method that overrides the default "passiveserver = 1" at the class level. This was introduced in rev. 1.54 when you integrated IPV6 support. Shouldn't this be taken out? Rev 1.48 announces "default to passive mode". The IPV6 patch must have broken this. (I'm sorry I didn't look at this before the release; this is an unfortunate glitch in 2.2!) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:51 Message: Logged In: YES user_id=21627 Is the debian bug number correct? The URL gives "An error occurred. Dammit. Error was: Couldn't get bug status: No such file or directory." Also, CC'ing the Debian BTS is not easy through SF, would it be feasible that you forward all comments to the BTS yourself? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495693&group_id=5470 From noreply@sourceforge.net Sat Dec 22 15:13:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 22 Dec 2001 07:13:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-495672 ] xml.AttributesImpl: __setitem__ undef. Message-ID: Bugs item #495672, was opened at 2001-12-20 15:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495672&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: xml.AttributesImpl: __setitem__ undef. Initial Comment: [please CC 120343@bugs.debian.org on replies; the complete report can be seen at http://bugs.debian.org/120343] xml.sax.xmlreader.AttributesImpl does not have a __setitem__ defined. The definition is trivial (or AttributesImpl could be written to extend UserDict), but its lack is a minor annoyance when writing an XML filter. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 07:13 Message: Logged In: YES user_id=21627 Why is this a bug? The Attributes interface in SAX is inherently read-only, both in Java and in Python. For a filter, write a new dictionary containing all the values that you want to forward, and create an AttributesImpl instance from this dictionary. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495672&group_id=5470 From noreply@sourceforge.net Sat Dec 22 15:24:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 22 Dec 2001 07:24:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-495603 ] CDROM module woefully out of date Message-ID: Bugs item #495603, was opened at 2001-12-20 12:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495603&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: CDROM module woefully out of date Initial Comment: [please CC 125785@bugs.debian.org on replies, bug reported at http://bugs.debian.org/125785 ] CDROM.py The above-referenced file apparently predates the Linux 2.2 kernel; it omits the defines required for the uniform CD-ROM driver ioctls, which are useful for detecting whether a CD is in the drive and for other various and sundry tasks. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 07:24 Message: Logged In: YES user_id=21627 Fixed in CDROM.py 1.2 (generated from Linux 2.2.4). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495603&group_id=5470 From noreply@sourceforge.net Sat Dec 22 16:35:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 22 Dec 2001 08:35:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-496104 ] FP behaviour changed from 2.1.1 Message-ID: Bugs item #496104, was opened at 2001-12-22 06:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496104&group_id=5470 >Category: Python Interpreter Core >Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Dietrich (quasi) >Assigned to: Tim Peters (tim_one) Summary: FP behaviour changed from 2.1.1 Initial Comment: Python2.2 floating point behaviour is different from 2.1.1 on Linux. Instead of Inf and nan an OverflowError is raised. (sometimes): Python 2.2 (#5, Dec 22 2001, 14:57:12) [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.68mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import math >>> 1e308**10 Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Numerical result out of range') >>> math.tan(1e308**10) Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Numerical result out of range') >>> 1e308*10 inf >>> math.tan(1e308*10) nan Python 2.1.1 (#1, Oct 24 2001, 13:07:11) [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.66mdk)] on linux-i386 Type "copyright", "credits" or "license" for more information. >>> import math >>> 1e308**10 inf >>> math.tan(1e308**10) nan >>> 1e308*10 inf >>> math.tan(1e308*10) nan ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-22 08:35 Message: Logged In: YES user_id=31435 Python doesn't define what happens in such cases, and it varied across platforms (depending on vagaries of the platform C compiler and libraries). It should be more consistent in 2.2 than in 2.1. For example, under 2.1 (Windows here): C:\Python21>python Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> x = 1e308 >>> x ** 10 # as you saw on Linux 1.#INF >>> x ** 9.99 # but a smaller exponent as a float blows up Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Result too large') >>> import math >>> math.pow(x, 10) # ditto spelling it pow() instead of ** Traceback (most recent call last): File "", line 1, in ? OverflowError: math range error >>> Under 2.2, though, they're all OverflowErrors: C:\Python22>python Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> x = 1e308 >>> x ** 10 Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Result too large') >>> x ** 9.9 Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Result too large') >>> import math >>> math.pow(x, 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: math range error >>> If the results in all 3 cases are OverflowError on Linux too in 2.2, I have to count that as an improvement (but regretting that it changed -- Python's fp behavior is often accidental, and making it more predictable is difficult for implementers and frustrating for users). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496104&group_id=5470 From noreply@sourceforge.net Sat Dec 22 19:47:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 22 Dec 2001 11:47:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-496154 ] Typos in dynload_beos.c Message-ID: Bugs item #496154, was opened at 2001-12-22 11:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496154&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Mark Perrego (mperrego) Assigned to: Nobody/Anonymous (nobody) Summary: Typos in dynload_beos.c Initial Comment: There are two typos in dynload_beos.c: Line 210 : PyOs_snprintf should be PyOS_snprintf (capital "S") Line 237 : PyOS_snprintf( buff, sizeof(buf) should be PyOS_snprintf( buff, sizeof(buff) (two "f"s) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496154&group_id=5470 From noreply@sourceforge.net Sat Dec 22 21:33:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 22 Dec 2001 13:33:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-496171 ] FD_CLOEXEC no longer available Message-ID: Bugs item #496171, was opened at 2001-12-22 13:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496171&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Per Cederqvist (ceder) Assigned to: Nobody/Anonymous (nobody) Summary: FD_CLOEXEC no longer available Initial Comment: In at least Python 1.6 through 2.1, the FD_CLOEXEC constant was available as FCNTL.FD_CLOEXEC. Starting with Python 2.2, the constant isn't available from any module, as far as I (and grep) can tell. The fsh project (http://www.lysator.liu.se/fsh) needs access to the FD_CLOEXEC flag. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496171&group_id=5470 From noreply@sourceforge.net Sat Dec 22 21:40:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 22 Dec 2001 13:40:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-496171 ] FD_CLOEXEC no longer available Message-ID: Bugs item #496171, was opened at 2001-12-22 13:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496171&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Per Cederqvist (ceder) Assigned to: Nobody/Anonymous (nobody) Summary: FD_CLOEXEC no longer available Initial Comment: In at least Python 1.6 through 2.1, the FD_CLOEXEC constant was available as FCNTL.FD_CLOEXEC. Starting with Python 2.2, the constant isn't available from any module, as far as I (and grep) can tell. The fsh project (http://www.lysator.liu.se/fsh) needs access to the FD_CLOEXEC flag. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496171&group_id=5470 From noreply@sourceforge.net Sun Dec 23 00:24:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 22 Dec 2001 16:24:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-496171 ] FD_CLOEXEC no longer available Message-ID: Bugs item #496171, was opened at 2001-12-22 13:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496171&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Per Cederqvist (ceder) >Assigned to: Barry Warsaw (bwarsaw) Summary: FD_CLOEXEC no longer available Initial Comment: In at least Python 1.6 through 2.1, the FD_CLOEXEC constant was available as FCNTL.FD_CLOEXEC. Starting with Python 2.2, the constant isn't available from any module, as far as I (and grep) can tell. The fsh project (http://www.lysator.liu.se/fsh) needs access to the FD_CLOEXEC flag. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-22 16:24 Message: Logged In: YES user_id=31435 Assigned to Barry because he's working this week . Digging thru the mass of old FCNTL.py files in the Lib/plat- xxx/ Attics, it looks to me like the current fcntlmodule is missing oodles of symbols that used to be available, some that were defined on most platforms (like FD_CLOEXEC), and many platform-unique. We should probably try the union of all of them in fcntlmodule.c. Per, sorry, looks like you'll have to wait for 2.2.1 (assuming a bugfix release manager volunteers to produce one). For 2.3, how about trying one of the beta releases before it's too late? Thousands of people downloaded the 2.2 betas, but I'm afraid nobody noticed the FD_CLOEXEC disappearance. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496171&group_id=5470 From noreply@sourceforge.net Sun Dec 23 01:48:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 22 Dec 2001 17:48:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-496215 ] Unclosed verbatim environment Message-ID: Bugs item #496215, was opened at 2001-12-22 17:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496215&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dave Cole (davecole) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Unclosed verbatim environment Initial Comment: There is an unclosed verbatim environment in api/abstract.tex There is an attached patch to fix the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496215&group_id=5470 From noreply@sourceforge.net Sun Dec 23 02:13:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 22 Dec 2001 18:13:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-211710 ] socket.send() can do partial writes on some systems. Message-ID: Bugs item #211710, was opened at 2000-08-11 13:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=211710&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: scott cotton (scottc) Assigned to: Jeremy Hylton (jhylton) Summary: socket.send() can do partial writes on some systems. Initial Comment: 0811 15:57 chronis:~% uname -a FreeBSD chronis.pobox.com 4.0-STABLE FreeBSD 4.0-STABLE #0: Tue Mar 21 01:05:14 EST 2000 root@chronis.pobox.com:/usr/src/sys/compile/MYBSD i386 0811 15:57 chronis:~% 0811 15:57 chronis:~% cat scratch/sendtstsrv.py import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind("chronis.pobox.com", 8010) while 1: s.listen(1) conn, addr = s.accept() print "connected from", addr while 1: data = conn.recv(1024) if not data: break print "done" conn.close() 0811 15:58 chronis:~% python scratch/sendtstsrv.py & [2] 76562 0811 15:58 chronis:~% cat scratch/sendtst.py #!/usr/bin/env python s = "0" * 10000000 import socket sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect("chronis.pobox.com", 8010) sent = sock.send(s) if sent != len(s): print "sent %d/%d chars" % (sent, len(s)) else: print "sent all chars" 0811 15:58 chronis:~% python !$ python scratch/sendtst.py connected from ('208.210.124.49', 1258) sent 17520/10000000 chars done 0811 15:58 chronis:~% NOTE: there is nothing in any man page for send() under linux (RH 6.1), Solaris (SunOS 5.5.1), OSF1 V4.0, or FreeBSD{3,4} that states that send() must not perform a partial write, though of those systems, it only seems to reproducibly do partial writes under FreeBSD4.0 Stable. Additionally, W.Richard Stevens' Unix Network Programming Vol 1, second edition states that """ A read or write on a stream socket might input or output fewer bytes than requested, but this is not an error condition.""" (page 77). Later, Stevens says of send() and recv() "These two functions are similar to the standard read and write functions, but one additional argument is required". (page 354). scott ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2001-12-22 18:13 Message: Logged In: YES user_id=371366 I disagree with changing the behavior of socket.py. The API is clear and Python is not in the wrong for being a very thin wrapper over the underlying implementation. Failing to check the return value of send() is a common socket programming error in all languages. Just change the libs that make this mistake. There is probably a use case for seeing the returns from partial writes. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-21 18:02 Message: Logged In: YES user_id=6380 Please go slowly here. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-21 00:46 Message: Logged In: YES user_id=29957 On second (or is this third?) thoughts, patching socket.py to make it wrap the _socketmodule send code is an alternative approach that may be safer. Pity about the _fileobject, tho - it needs considerably more help. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-21 00:07 Message: Logged In: YES user_id=29957 The two approaches would seem to be: patch the socketmodule to make sure send() actually sends all the bytes. or patch the offending std library calls. The latter preserves the std unix semantics, but possibly violates the principle of Least Suprise. For 2.1.2, I'm patching the std library. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-19 05:20 Message: Logged In: YES user_id=6380 Reopened. You have a point. (I think we closed it becase we couldn't reproduce it. Our fault for not having access to FreeBSD. :-) ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-10-18 23:43 Message: Logged In: YES user_id=6405 This problem is only seen on FreeBSD, it seems. Not even OSX, the BSD derivative, has this problem. However, my FreeBSD (4.3-RELEASE) socket(2) man page states: If no messages space is available at the socket to hold the message to be transmitted, then send() normally blocks, unless the socket has been placed in non-blocking I/O mode. The select(2) call may be used to de- termine when it is possible to send more data. Linux (2.4.7) has a similar message: When the message does not fit into the send buffer of the socket, send normally blocks, unless the socket has been placed in non-blocking I/O mode. In non-blocking mode it would return EAGAIN in this case. The select(2) call may be used to determine when it is possible to send more data. So "normally" is being interpreted loosly by FreeBSD in this case, it seems. A solution might be to have socket.send() try to send all the data. At a minimum, the standard library should be fixed so it works on FreeBSD. >From the Lib directory of 2.1.1: [richard@ike /usr/local/src/Python-2.1.1]% grep -r '\.send(' Lib Lib/ftplib.py: self.sock.send(line) Lib/ftplib.py: self.sock.send(line, MSG_OOB) Lib/ftplib.py: conn.send(buf) Lib/ftplib.py: conn.send(buf) Lib/gopherlib.py: s.send(selector + CRLF) Lib/httplib.py: self.sock.send(str) Lib/httplib.py: self.send(str) Lib/httplib.py: self.send(str) Lib/httplib.py: self.send(str) Lib/httplib.py: self.send('\r\n') Lib/httplib.py: self.send(body) Lib/imaplib.py: self.sock.send('%s%s' % (data, CRLF)) Lib/imaplib.py: self.sock.send(literal) Lib/imaplib.py: self.sock.send(CRLF) Lib/nntplib.py: self.sock.send(line) Lib/poplib.py: self.sock.send('%s%s' % (line, CRLF)) Lib/smtplib.py: sendptr = sendptr + self.sock.send(str[sendptr:]) Lib/smtplib.py: self.send(str) Lib/smtplib.py: self.send(q) Lib/socket.py: self._sock.send(self._wbuf) Lib/telnetlib.py: self.sock.send(buffer) Lib/telnetlib.py: self.sock.send(IAC + WONT + opt) Lib/telnetlib.py: self.sock.send(IAC + DONT + opt) Lib/urllib.py: h.send(data) Lib/urllib.py: h.send(data) Lib/urllib2.py: h.send(data) Lib/webbrowser.py: s.send(action) Lib/test/test_asynchat.py: n = conn.send(buffer) Lib/test/test_socket.py: conn.send(data) Lib/test/test_socket.py: s.send(msg) Lib/test/test_socketserver.py: s.send(teststring) Note that smtplib handles send()'s return, where nothing else does. Note also that the above grep does not include our patch. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-10-18 23:04 Message: Logged In: YES user_id=6405 We have patched httplib.HTTPConnection.send() so it does the following: sent = 0 while sent < len(str): sent = sent + self.sock.send(str[sent:]) Could this be the default behaviour in the socket module perhaps? ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-10-18 22:57 Message: Logged In: YES user_id=6405 Why is this bug closed? The standard library uses send() in a number of places - we've just run up against it in httplib. Again, on FreeBSD, we're seeing that send() is only sending a part of the data we want it to. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2000-09-15 11:50 Message: scott-- Is there a bug here? It seems clear that the send system call is not required to send all the bytes you asked it to send. It returns the number of bytes it did send. If you want to make sure all your data is sent, you can wrap send in a while loop that calls send until all the data is consumed. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2000-09-07 15:01 Message: Please do triage on this bug. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=211710&group_id=5470 From noreply@sourceforge.net Sun Dec 23 02:26:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 22 Dec 2001 18:26:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-211710 ] socket.send() can do partial writes on some systems. Message-ID: Bugs item #211710, was opened at 2000-08-11 13:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=211710&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: scott cotton (scottc) Assigned to: Jeremy Hylton (jhylton) Summary: socket.send() can do partial writes on some systems. Initial Comment: 0811 15:57 chronis:~% uname -a FreeBSD chronis.pobox.com 4.0-STABLE FreeBSD 4.0-STABLE #0: Tue Mar 21 01:05:14 EST 2000 root@chronis.pobox.com:/usr/src/sys/compile/MYBSD i386 0811 15:57 chronis:~% 0811 15:57 chronis:~% cat scratch/sendtstsrv.py import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind("chronis.pobox.com", 8010) while 1: s.listen(1) conn, addr = s.accept() print "connected from", addr while 1: data = conn.recv(1024) if not data: break print "done" conn.close() 0811 15:58 chronis:~% python scratch/sendtstsrv.py & [2] 76562 0811 15:58 chronis:~% cat scratch/sendtst.py #!/usr/bin/env python s = "0" * 10000000 import socket sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect("chronis.pobox.com", 8010) sent = sock.send(s) if sent != len(s): print "sent %d/%d chars" % (sent, len(s)) else: print "sent all chars" 0811 15:58 chronis:~% python !$ python scratch/sendtst.py connected from ('208.210.124.49', 1258) sent 17520/10000000 chars done 0811 15:58 chronis:~% NOTE: there is nothing in any man page for send() under linux (RH 6.1), Solaris (SunOS 5.5.1), OSF1 V4.0, or FreeBSD{3,4} that states that send() must not perform a partial write, though of those systems, it only seems to reproducibly do partial writes under FreeBSD4.0 Stable. Additionally, W.Richard Stevens' Unix Network Programming Vol 1, second edition states that """ A read or write on a stream socket might input or output fewer bytes than requested, but this is not an error condition.""" (page 77). Later, Stevens says of send() and recv() "These two functions are similar to the standard read and write functions, but one additional argument is required". (page 354). scott ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-22 18:26 Message: Logged In: YES user_id=29957 Ah - should have gone back and closed this. The eventual design that was taken was to add a socket.sendall() call, and make the various libs call this. This was added to 2.2, and is also in 2.1.2-to-be. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2001-12-22 18:13 Message: Logged In: YES user_id=371366 I disagree with changing the behavior of socket.py. The API is clear and Python is not in the wrong for being a very thin wrapper over the underlying implementation. Failing to check the return value of send() is a common socket programming error in all languages. Just change the libs that make this mistake. There is probably a use case for seeing the returns from partial writes. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-21 18:02 Message: Logged In: YES user_id=6380 Please go slowly here. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-21 00:46 Message: Logged In: YES user_id=29957 On second (or is this third?) thoughts, patching socket.py to make it wrap the _socketmodule send code is an alternative approach that may be safer. Pity about the _fileobject, tho - it needs considerably more help. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-21 00:07 Message: Logged In: YES user_id=29957 The two approaches would seem to be: patch the socketmodule to make sure send() actually sends all the bytes. or patch the offending std library calls. The latter preserves the std unix semantics, but possibly violates the principle of Least Suprise. For 2.1.2, I'm patching the std library. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-19 05:20 Message: Logged In: YES user_id=6380 Reopened. You have a point. (I think we closed it becase we couldn't reproduce it. Our fault for not having access to FreeBSD. :-) ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-10-18 23:43 Message: Logged In: YES user_id=6405 This problem is only seen on FreeBSD, it seems. Not even OSX, the BSD derivative, has this problem. However, my FreeBSD (4.3-RELEASE) socket(2) man page states: If no messages space is available at the socket to hold the message to be transmitted, then send() normally blocks, unless the socket has been placed in non-blocking I/O mode. The select(2) call may be used to de- termine when it is possible to send more data. Linux (2.4.7) has a similar message: When the message does not fit into the send buffer of the socket, send normally blocks, unless the socket has been placed in non-blocking I/O mode. In non-blocking mode it would return EAGAIN in this case. The select(2) call may be used to determine when it is possible to send more data. So "normally" is being interpreted loosly by FreeBSD in this case, it seems. A solution might be to have socket.send() try to send all the data. At a minimum, the standard library should be fixed so it works on FreeBSD. >From the Lib directory of 2.1.1: [richard@ike /usr/local/src/Python-2.1.1]% grep -r '\.send(' Lib Lib/ftplib.py: self.sock.send(line) Lib/ftplib.py: self.sock.send(line, MSG_OOB) Lib/ftplib.py: conn.send(buf) Lib/ftplib.py: conn.send(buf) Lib/gopherlib.py: s.send(selector + CRLF) Lib/httplib.py: self.sock.send(str) Lib/httplib.py: self.send(str) Lib/httplib.py: self.send(str) Lib/httplib.py: self.send(str) Lib/httplib.py: self.send('\r\n') Lib/httplib.py: self.send(body) Lib/imaplib.py: self.sock.send('%s%s' % (data, CRLF)) Lib/imaplib.py: self.sock.send(literal) Lib/imaplib.py: self.sock.send(CRLF) Lib/nntplib.py: self.sock.send(line) Lib/poplib.py: self.sock.send('%s%s' % (line, CRLF)) Lib/smtplib.py: sendptr = sendptr + self.sock.send(str[sendptr:]) Lib/smtplib.py: self.send(str) Lib/smtplib.py: self.send(q) Lib/socket.py: self._sock.send(self._wbuf) Lib/telnetlib.py: self.sock.send(buffer) Lib/telnetlib.py: self.sock.send(IAC + WONT + opt) Lib/telnetlib.py: self.sock.send(IAC + DONT + opt) Lib/urllib.py: h.send(data) Lib/urllib.py: h.send(data) Lib/urllib2.py: h.send(data) Lib/webbrowser.py: s.send(action) Lib/test/test_asynchat.py: n = conn.send(buffer) Lib/test/test_socket.py: conn.send(data) Lib/test/test_socket.py: s.send(msg) Lib/test/test_socketserver.py: s.send(teststring) Note that smtplib handles send()'s return, where nothing else does. Note also that the above grep does not include our patch. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-10-18 23:04 Message: Logged In: YES user_id=6405 We have patched httplib.HTTPConnection.send() so it does the following: sent = 0 while sent < len(str): sent = sent + self.sock.send(str[sent:]) Could this be the default behaviour in the socket module perhaps? ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-10-18 22:57 Message: Logged In: YES user_id=6405 Why is this bug closed? The standard library uses send() in a number of places - we've just run up against it in httplib. Again, on FreeBSD, we're seeing that send() is only sending a part of the data we want it to. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2000-09-15 11:50 Message: scott-- Is there a bug here? It seems clear that the send system call is not required to send all the bytes you asked it to send. It returns the number of bytes it did send. If you want to make sure all your data is sent, you can wrap send in a while loop that calls send until all the data is consumed. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2000-09-07 15:01 Message: Please do triage on this bug. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=211710&group_id=5470 From noreply@sourceforge.net Sun Dec 23 02:26:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 22 Dec 2001 18:26:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-211710 ] socket.send() can do partial writes on some systems. Message-ID: Bugs item #211710, was opened at 2000-08-11 13:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=211710&group_id=5470 Category: Python Library Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: scott cotton (scottc) Assigned to: Jeremy Hylton (jhylton) Summary: socket.send() can do partial writes on some systems. Initial Comment: 0811 15:57 chronis:~% uname -a FreeBSD chronis.pobox.com 4.0-STABLE FreeBSD 4.0-STABLE #0: Tue Mar 21 01:05:14 EST 2000 root@chronis.pobox.com:/usr/src/sys/compile/MYBSD i386 0811 15:57 chronis:~% 0811 15:57 chronis:~% cat scratch/sendtstsrv.py import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind("chronis.pobox.com", 8010) while 1: s.listen(1) conn, addr = s.accept() print "connected from", addr while 1: data = conn.recv(1024) if not data: break print "done" conn.close() 0811 15:58 chronis:~% python scratch/sendtstsrv.py & [2] 76562 0811 15:58 chronis:~% cat scratch/sendtst.py #!/usr/bin/env python s = "0" * 10000000 import socket sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect("chronis.pobox.com", 8010) sent = sock.send(s) if sent != len(s): print "sent %d/%d chars" % (sent, len(s)) else: print "sent all chars" 0811 15:58 chronis:~% python !$ python scratch/sendtst.py connected from ('208.210.124.49', 1258) sent 17520/10000000 chars done 0811 15:58 chronis:~% NOTE: there is nothing in any man page for send() under linux (RH 6.1), Solaris (SunOS 5.5.1), OSF1 V4.0, or FreeBSD{3,4} that states that send() must not perform a partial write, though of those systems, it only seems to reproducibly do partial writes under FreeBSD4.0 Stable. Additionally, W.Richard Stevens' Unix Network Programming Vol 1, second edition states that """ A read or write on a stream socket might input or output fewer bytes than requested, but this is not an error condition.""" (page 77). Later, Stevens says of send() and recv() "These two functions are similar to the standard read and write functions, but one additional argument is required". (page 354). scott ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-22 18:26 Message: Logged In: YES user_id=29957 Ah - should have gone back and closed this. The eventual design that was taken was to add a socket.sendall() call, and make the various libs call this. This was added to 2.2, and is also in 2.1.2-to-be. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-22 18:26 Message: Logged In: YES user_id=29957 Ah - should have gone back and closed this. The eventual design that was taken was to add a socket.sendall() call, and make the various libs call this. This was added to 2.2, and is also in 2.1.2-to-be. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2001-12-22 18:13 Message: Logged In: YES user_id=371366 I disagree with changing the behavior of socket.py. The API is clear and Python is not in the wrong for being a very thin wrapper over the underlying implementation. Failing to check the return value of send() is a common socket programming error in all languages. Just change the libs that make this mistake. There is probably a use case for seeing the returns from partial writes. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-21 18:02 Message: Logged In: YES user_id=6380 Please go slowly here. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-21 00:46 Message: Logged In: YES user_id=29957 On second (or is this third?) thoughts, patching socket.py to make it wrap the _socketmodule send code is an alternative approach that may be safer. Pity about the _fileobject, tho - it needs considerably more help. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-21 00:07 Message: Logged In: YES user_id=29957 The two approaches would seem to be: patch the socketmodule to make sure send() actually sends all the bytes. or patch the offending std library calls. The latter preserves the std unix semantics, but possibly violates the principle of Least Suprise. For 2.1.2, I'm patching the std library. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-19 05:20 Message: Logged In: YES user_id=6380 Reopened. You have a point. (I think we closed it becase we couldn't reproduce it. Our fault for not having access to FreeBSD. :-) ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-10-18 23:43 Message: Logged In: YES user_id=6405 This problem is only seen on FreeBSD, it seems. Not even OSX, the BSD derivative, has this problem. However, my FreeBSD (4.3-RELEASE) socket(2) man page states: If no messages space is available at the socket to hold the message to be transmitted, then send() normally blocks, unless the socket has been placed in non-blocking I/O mode. The select(2) call may be used to de- termine when it is possible to send more data. Linux (2.4.7) has a similar message: When the message does not fit into the send buffer of the socket, send normally blocks, unless the socket has been placed in non-blocking I/O mode. In non-blocking mode it would return EAGAIN in this case. The select(2) call may be used to determine when it is possible to send more data. So "normally" is being interpreted loosly by FreeBSD in this case, it seems. A solution might be to have socket.send() try to send all the data. At a minimum, the standard library should be fixed so it works on FreeBSD. >From the Lib directory of 2.1.1: [richard@ike /usr/local/src/Python-2.1.1]% grep -r '\.send(' Lib Lib/ftplib.py: self.sock.send(line) Lib/ftplib.py: self.sock.send(line, MSG_OOB) Lib/ftplib.py: conn.send(buf) Lib/ftplib.py: conn.send(buf) Lib/gopherlib.py: s.send(selector + CRLF) Lib/httplib.py: self.sock.send(str) Lib/httplib.py: self.send(str) Lib/httplib.py: self.send(str) Lib/httplib.py: self.send(str) Lib/httplib.py: self.send('\r\n') Lib/httplib.py: self.send(body) Lib/imaplib.py: self.sock.send('%s%s' % (data, CRLF)) Lib/imaplib.py: self.sock.send(literal) Lib/imaplib.py: self.sock.send(CRLF) Lib/nntplib.py: self.sock.send(line) Lib/poplib.py: self.sock.send('%s%s' % (line, CRLF)) Lib/smtplib.py: sendptr = sendptr + self.sock.send(str[sendptr:]) Lib/smtplib.py: self.send(str) Lib/smtplib.py: self.send(q) Lib/socket.py: self._sock.send(self._wbuf) Lib/telnetlib.py: self.sock.send(buffer) Lib/telnetlib.py: self.sock.send(IAC + WONT + opt) Lib/telnetlib.py: self.sock.send(IAC + DONT + opt) Lib/urllib.py: h.send(data) Lib/urllib.py: h.send(data) Lib/urllib2.py: h.send(data) Lib/webbrowser.py: s.send(action) Lib/test/test_asynchat.py: n = conn.send(buffer) Lib/test/test_socket.py: conn.send(data) Lib/test/test_socket.py: s.send(msg) Lib/test/test_socketserver.py: s.send(teststring) Note that smtplib handles send()'s return, where nothing else does. Note also that the above grep does not include our patch. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-10-18 23:04 Message: Logged In: YES user_id=6405 We have patched httplib.HTTPConnection.send() so it does the following: sent = 0 while sent < len(str): sent = sent + self.sock.send(str[sent:]) Could this be the default behaviour in the socket module perhaps? ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-10-18 22:57 Message: Logged In: YES user_id=6405 Why is this bug closed? The standard library uses send() in a number of places - we've just run up against it in httplib. Again, on FreeBSD, we're seeing that send() is only sending a part of the data we want it to. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2000-09-15 11:50 Message: scott-- Is there a bug here? It seems clear that the send system call is not required to send all the bytes you asked it to send. It returns the number of bytes it did send. If you want to make sure all your data is sent, you can wrap send in a while loop that calls send until all the data is consumed. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2000-09-07 15:01 Message: Please do triage on this bug. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=211710&group_id=5470 From noreply@sourceforge.net Sun Dec 23 03:09:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 22 Dec 2001 19:09:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-471942 ] python2.1.1 SEGV in GC on Solaris 2.7 Message-ID: Bugs item #471942, was opened at 2001-10-16 19:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Anthony Baxter (anthonybaxter) Summary: python2.1.1 SEGV in GC on Solaris 2.7 Initial Comment: I've got a Zope installation where python2.1.1 is segfaulting on Solaris2.7 - it's running a largish ZEO server. The tail of the gdb output is: #128 0x26164 in PyEval_CallObjectWithKeywords () #129 0x264c0 in PyEval_CallObjectWithKeywords () #130 0x26140 in PyEval_CallObjectWithKeywords () #131 0x25fc0 in PyEval_CallObjectWithKeywords () #132 0x517bc in PyInstance_New () #133 0x261a4 in PyEval_CallObjectWithKeywords () #134 0x25fc0 in PyEval_CallObjectWithKeywords () #135 0x42c90 in initgc () It's built with $ gcc -v Reading specs from /opt/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs gcc version 2.95.2 19991024 (release) which is a bit old. I'm going to rebuild with gcc3.0 and also try turning off the GC. Unfortunately I can't get this to happen on a smaller test system - it's only under load that it plows into the ground. I'll also leave symbols in this time... :/ ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-22 19:09 Message: Logged In: YES user_id=29957 It seems very likely that the recent compiler stack calculation fixes are responsible for this - I plan to look into this when I get back into work on the 3rd. ---------------------------------------------------------------------- Comment By: Joseph Wayne Norton (natsukashi) Date: 2001-12-16 16:31 Message: Logged In: YES user_id=358486 No, I haven't tried the ceval.c patch. Do know of any documentation regarding this bug and the bug fix? I'm just curious before applying this patch. There also is an update from the folks at ZC. They located a source of trouble with respect to python 2.1 and the restricted dtml engine. See the zope-dev mailing list for futher details. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-14 02:46 Message: Logged In: YES user_id=21627 natsukashi, have you applied 2.277 of ceval.c? ---------------------------------------------------------------------- Comment By: Joseph Wayne Norton (natsukashi) Date: 2001-12-13 16:41 Message: Logged In: YES user_id=358486 Here is an excerpt from one debugging session ... > (gdb) info threads > 17 Thread 10 0xef5b9810 in _lwp_sema_wait () > 16 Thread 9 0xef647cac in _swtch () > 15 Thread 8 0xef5b9810 in _lwp_sema_wait () > 14 Thread 7 (LWP 5) 0xcaeb50 in ?? () > 13 Thread 6 0xef647cac in _swtch () > 12 Thread 5 0xef5b9810 in _lwp_sema_wait () > 11 Thread 4 0xef647cac in _swtch () > 10 Thread 3 0xef647cac in _swtch () > 9 Thread 2 (LWP 2) 0xef5b9958 in _signotifywait () > 8 Thread 1 (LWP 6) 0xef5b7488 in _poll () > 7 LWP 8 0xef5b6a24 in door_restart () > 6 LWP 6 0xef5b7488 in _poll () > 5 LWP 5 0xcaeb50 in ?? () > 4 LWP 4 0xef5b9810 in _lwp_sema_wait () > 3 LWP 3 0xef5b9810 in _lwp_sema_wait () > 2 LWP 2 0xef5b9958 in _signotifywait () > * 1 LWP 1 0xef5b9810 in _lwp_sema_wait () > > (gdb) thread 14 > [Switching to Thread 7 (LWP 5)] > #0 0xcaeb50 in ?? () > > (gdb) where > #0 0xcaeb50 in ?? () > #1 0x516bc in collect (young=0x13dec8, old=0x13ded4) > at ./Modules/gcmodule.c:379 > #2 0x51984 in collect_generations () at ./Modules/gcmodule.c:484 > #3 0x519fc in _PyGC_Insert (op=0xecf7d4) at ./Modules/gcmodule.c:507 > #4 0x664ec in PyMethod_New (func=0x3f796c, self=0x11c0d44, > class=0x3c7e5c) > at Objects/classobject.c:1834 > #5 0x63850 in instance_getattr2 (inst=0x11c0d44, name=0x3d5378) > at Objects/classobject.c:642 > #6 0x63750 in instance_getattr1 (inst=0x11c0d44, name=0x3d5378) > at Objects/classobject.c:608 > #7 0x63898 in instance_getattr (inst=0x11c0d44, name=0x3d5378) > at Objects/classobject.c:656 > #8 0x78330 in PyObject_GetAttr (v=0x11c0d44, name=0x3d5378) > at Objects/object.c:1052 > #9 0x895ec in builtin_hasattr (self=0x0, args=0x12ed944) > at Python/bltinmodule.c:886 > #10 0x35a44 in call_cfunction (func=0x1609b0, arg=0x12ed944, kw=0x0) > at Python/ceval.c:2854 Unfortunately, I do not have any specific information at the moment. There is also portions of a discussion that can be viewed with the following url: http://lists.zope.org/pipermail/zope-dev/2001-December/014541.html Look for messages having the same subject. Basically, we are running python 2.1.1 and zope 2.4.3 on the solaris platform. We have 3 servers each having the same installed software except one server is solaris 5.6 and the other two are solaris 5.7. The zope process running on the solaris 5.6 machine is restarting at least a couple times a day due to a SIGSEGV or SIGILL signal. I can generate a core file using the truss command. The problem appears to be related to garbage collection. Unfortunately, this behavior only occurs on our production site and depends on the site load -- higher system load, more frequent restarts. We are not facing any restart troubles on the solaris 5.7 machines or on our linux and solaris development machines. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-13 12:12 Message: Logged In: YES user_id=31435 Just noting that the function names reported in the traceback in the original writeup are bogus: PyEval_CallObjectWithKeywords() doesn't call itself. Looks like gdb doesn't have enough info to report the true function name, so picks a function it does know about at an earlier address (or something ). I'm told this doesn't happen on Linux, but don't grasp why it might on Solaris. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-13 07:45 Message: Logged In: YES user_id=21627 What do you mean with "the same trouble"? Merely that Python crashes, or do you have some more specific information to contribute? ---------------------------------------------------------------------- Comment By: Joseph Wayne Norton (natsukashi) Date: 2001-12-11 18:37 Message: Logged In: YES user_id=358486 Do you have any updates on this issue? I'm facing the same trouble on the following solaris platform: SunOS i04sv2008 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-80 regards, - j ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-04 23:38 Message: Logged In: YES user_id=29957 Nah, this is a separate one to the frame bug. I'm still seeing it on a regular regular basis, but haven't narrowed it done to what's causing it. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-04 08:48 Message: Logged In: YES user_id=31392 This was the bug that was tracked down to a problem in try/except/finally, wasn't it? If this is fixed, can you close the bug report? If not, can you provide an udpate on its current status? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-07 14:13 Message: Logged In: YES user_id=21627 Any news on this report: did the problem disappear after backporting changes? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 04:32 Message: Logged In: YES user_id=21627 Looking at the changes since 2.1.1, I can see one bugfix that might explain strange behaviour, namely ceval.c 2.277. If you want to try it out, you can get the change here http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Python/ceval.c.diff?r1=2.276&r2=2.277 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 03:59 Message: Logged In: YES user_id=29957 What's the appropriate way to ask this? drop a line to python-dev? purify's showing a UMR in strop_expandtabs (from memory - don't have it on screen right now) when python starts up. Yeah, the realloc bug concerns me - I have to wonder if something's a little bit/lot screwy. I just don't know where. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 03:46 Message: Logged In: YES user_id=21627 This is something to ask the pythonlabs folks; I believe Python has been purified once in a while - perhaps even with Zope extensions. I'd still suspect a bug in the Zope extensions instead of a Python bug, though: if malloc crashes, chances are high that somebody was overwriting free memory. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 03:31 Message: Logged In: YES user_id=29957 It's not a GC object. I'm positive all the extension objects are correct - I just recompiled, without the 1.5/2.0 headers around. It's a different pointer each time round, unfortunately. It also takes anything from 5 minutes to 2 hours to reproduce. I've got about 4 copies of it running now, and I've got a bunch of different core files. I've grabbed purify and an eval license, and I'm feeding it the binary. The printf approach is probably not going to work - these are busy busy Zope servers. Instead, my plan, assuming that purify doesn't immediately spot a problem, is to change the code so that if it gets a dud GC object, it will just bust it out of the tree and let it leak, and print a message saying so. Then I can quit the program, and purify will tell me 'hey, you leaked!' and also tell me where it was allocated. More concerning, about half the segfaults are not from the GC at all, but from realloc in PyFrame_New (line 161 of frameobject). These are the only two I'm getting - it's split 50-50 amongst the 10 coredumps I have now. I'm not sure whether to open a seperate bug for this. Has python2.1.1 been purified? With Zope and zope's extensions? Wow - it's amazing how this SF bug thing is so painful for conversations :) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 03:11 Message: Logged In: YES user_id=21627 There are two options: a) the object isn't really a GC object, i.e. has no GC header. In gdb, you can try to cast gc to PyObject*, then see if the resulting pointer has a better ob_type (this is unlikely, though, since the logic entering the object was already using fromgc/togc) b) somebody has cleared the ob_type field. Can you guarantee that all extension modules have been compiled with the 2.1.1 header files? Is the problem repeatable in the sense that gc will have the same pointer value on each crash? If so, it is relatively easy to track down: just set a gdb change watchpoint on the address on the ob_type field of that address (note that setting watchpoints is not possible until there is really mapped memory on that address). If you can't analyse it through change breakpoints, I recommend to annotate the interpreter in the following way: in pyobject_init, put a printf that prints the address and the tp_name of the type. In subtract_refs, if the ob_type slot is null, print the address of the object and abort. Then analyse the log to see whether a object really has been allocated on that address, and what its type was (make sure you consider the possibility that address are off by the delta that FROM_GC adds). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-17 21:58 Message: Logged In: YES user_id=29957 Ok, I have an intact core file, and a matching binary, no optimisations, nothing. This crash is showing the crash at line 166 of gcmodule.c traverse = PyObject_FROM_GC(gc)->ob_type->tp_traverse; PyObject_FROM_GC(gc)->ob_type in this case is $24 = {ob_refcnt = 1, ob_type = 0x0} To check my logic, I checked gc_next and gc_prev using the same GDB magic, and they correctly show up as a tuple and an instance method. Some fiddling around seems to rule out stack space as the problem, as well. We're going to try and see if purify helps here, but the problem looks to be a junk object - I have no idea how to track this down further. Help? Would taking the horrible horrible hack of removing the object from the gc linked list if ob_type is null help? Well, it'd stop the crashes, anyway. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-17 13:44 Message: Logged In: YES user_id=21627 It would be interesting what the value of "gc" is at the time of the crash. It looks like you got an object that claims to support GC but has a null tp_traverse. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-17 06:08 Message: Logged In: YES user_id=29957 I'm a doofus who read the gdb trace from the wrong end - too much python lately :) Nonetheless, the other end of the trace failed in gc as well - and building without GC enabled worked. Here's the trace with debugging enabled: #0 0xff00 in ?? () #1 0x402f0 in collect (young=0x9b538, old=0x9b544) at ./Modules/gcmodule.c:379 #2 0x405a8 in collect_generations () at ./Modules/gcmodule.c:484 #3 0x40624 in _PyGC_Insert (op=0xbc1f24) at ./Modules/gcmodule.c:507 #4 0x5a224 in PyList_New (size=0) at Objects/listobject.c:61 #5 0x21bc8 in eval_code2 (co=0x1cb370, globals=0x21bc0, locals=0x67, args=0x0, argcount=1, kws=0xf89b24, kwcount=0, defs=0x0, defcount=0, closure=0xbc1f24) at Python/ceval.c:1741 Next trick is to rebuild without any optimisation (sigh) as I suspect that it's inlined subtract_refs(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 From noreply@sourceforge.net Sun Dec 23 07:02:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 22 Dec 2001 23:02:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-495358 ] rfc822.AddressList and "<>" address Message-ID: Bugs item #495358, was opened at 2001-12-20 03:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495358&group_id=5470 Category: Python Library Group: Python 2.1.1 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Artur Zaprzala (zybi) Assigned to: Anthony Baxter (anthonybaxter) >Summary: rfc822.AddressList and "<>" address Initial Comment: rfc822.AddressList incorrectly handles empty address. "<>" is converted to None and should be "". AddressList.__str__() fails on None. I got an email with such an address and my program failed processing it. Example: >>> import rfc822 >>> rfc822.AddressList("<>").addresslist [('', None)] >>> str(rfc822.AddressList("<>")) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/rfc822.py", line 753, in __str__ return ", ".join(map(dump_address_pair, self.addresslist)) TypeError: sequence item 0: expected string, None found Patch is attached. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-22 23:02 Message: Logged In: YES user_id=29957 this is checked in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-20 07:55 Message: Logged In: YES user_id=6380 Thanks! Applied to Python 2.2 in CVS. Assigned to Anthony as a 2.1.2 candidate. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-12-20 07:27 Message: Logged In: YES user_id=12800 Looks okay to me. Accepted the patch, but I'll leave it to Guido to commit. +1 for Py2.2. test_email.py and test_rfc822.py both continue to pass (which tells me they really don't test this case ;). Or assign the patch to me and I'll commit it, update the test suite and docs. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-20 05:03 Message: Logged In: YES user_id=6380 I want this reviewed before Python 2.2 goes out tomorrow. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495358&group_id=5470 From noreply@sourceforge.net Sun Dec 23 07:06:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 22 Dec 2001 23:06:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-496240 ] __slots__ does not iterate over a string Message-ID: Bugs item #496240, was opened at 2001-12-22 23:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496240&group_id=5470 Category: Parser/Compiler Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Clarence Gardner (cgardner) Assigned to: Nobody/Anonymous (nobody) Summary: __slots__ does not iterate over a string Initial Comment: According to Guido's writeup, the value given to __slots__ can be any iterable object. If you give it a string value, however, e.g. __slots__ = 'abc', instead of getting three valid attributes named 'a', 'b', and 'c', you get one named 'abc'. Priority: Low. No, even lower :) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496240&group_id=5470 From noreply@sourceforge.net Sun Dec 23 07:17:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 22 Dec 2001 23:17:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-496240 ] __slots__ does not iterate over a string Message-ID: Bugs item #496240, was opened at 2001-12-22 23:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496240&group_id=5470 >Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Clarence Gardner (cgardner) >Assigned to: Guido van Rossum (gvanrossum) Summary: __slots__ does not iterate over a string Initial Comment: According to Guido's writeup, the value given to __slots__ can be any iterable object. If you give it a string value, however, e.g. __slots__ = 'abc', instead of getting three valid attributes named 'a', 'b', and 'c', you get one named 'abc'. Priority: Low. No, even lower :) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-22 23:17 Message: Logged In: YES user_id=31435 Heh. For a reason I can't guess, the implementation goes out of its way to special-case a bare string. However, Guido's writeup also says "the effect of using something that's not a list renders the meaning of your program undefined", and getting one attribute named 'abc' is the very definition of undefinedness . Assigned to Guido. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496240&group_id=5470 From noreply@sourceforge.net Sun Dec 23 10:27:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 23 Dec 2001 02:27:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-496171 ] FD_CLOEXEC no longer available Message-ID: Bugs item #496171, was opened at 2001-12-22 13:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496171&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Per Cederqvist (ceder) Assigned to: Barry Warsaw (bwarsaw) Summary: FD_CLOEXEC no longer available Initial Comment: In at least Python 1.6 through 2.1, the FD_CLOEXEC constant was available as FCNTL.FD_CLOEXEC. Starting with Python 2.2, the constant isn't available from any module, as far as I (and grep) can tell. The fsh project (http://www.lysator.liu.se/fsh) needs access to the FD_CLOEXEC flag. ---------------------------------------------------------------------- >Comment By: Per Cederqvist (ceder) Date: 2001-12-23 02:27 Message: Logged In: YES user_id=129207 It's been a hectic autumn. On december 21st, I finally got time to test the Python 2.2c1 beta. I found that there was a problem with fsh, but didn't have time to find out what the problem was. Hours later, the news reached me that Python 2.2 final was released. Bad timing, I guess. It turns out that FD_CLOEXEC is set to 1 on every platform in the known universe (including AIX), so I can work around the problem. My code won't look pretty, though: Use fcntl.FD_CLOEXEC, if available. Otherwise, use FCNTL.FD_CLOEXEC, if available, but make sure to turn off the warnings for importing FCNTL (if the warnings module is available). Otherwise, use 1. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-22 16:24 Message: Logged In: YES user_id=31435 Assigned to Barry because he's working this week . Digging thru the mass of old FCNTL.py files in the Lib/plat- xxx/ Attics, it looks to me like the current fcntlmodule is missing oodles of symbols that used to be available, some that were defined on most platforms (like FD_CLOEXEC), and many platform-unique. We should probably try the union of all of them in fcntlmodule.c. Per, sorry, looks like you'll have to wait for 2.2.1 (assuming a bugfix release manager volunteers to produce one). For 2.3, how about trying one of the beta releases before it's too late? Thousands of people downloaded the 2.2 betas, but I'm afraid nobody noticed the FD_CLOEXEC disappearance. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496171&group_id=5470 From noreply@sourceforge.net Sun Dec 23 11:16:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 23 Dec 2001 03:16:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-495693 ] urllib doesn't support passive FTP Message-ID: Bugs item #495693, was opened at 2001-12-20 16:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495693&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: urllib doesn't support passive FTP Initial Comment: [please CC 40981@bugs.debian.org on replies; complete report can be found at http://bugs.debian.org/40981] urllib.urlopen/urlretrieve doesn't support passive FTP urllib doesn't support passive FTP, even though the underlying ftplib module does. I dunno what the right approach is (perhaps a urllib module global variable). I know some tools (I'm aware of at least ncftp and wget) autodetect whether PASV is supported by FTP servers; perhaps that intelligence could be added to ftplib. (Also: the FTP class's set_pasv() method isn't documented in my version of python-docs; I haven't checked the new 1.5.2 docs yet however.) At the moment, I'm using this ugly hack to get around it: # Really ugly hack; don't try this at home: def ftpwrapper_init(self): import ftplib self.busy = 0 self.ftp = ftplib.FTP() self.ftp.set_pasv(1) self.ftp.connect(self.host, self.port) self.ftp.login(self.user, self.passwd) for dir in self.dirs: self.ftp.cwd(dir) urllib.ftpwrapper.init = ftpwrapper_init # End really ugly hack ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-23 03:16 Message: Logged In: YES user_id=21627 Yes, that is quite unfortunate, and an error. In itojun's original patch, there was still self.passiveserver=0 in the context (it was against 1.46). That patch did not apply after your changes (in 1.48 and 1.52) anymore, so I asked him to regenerate the patches, but neither of us noticed that particular change. I'll attach the obvious change below; perhaps we should revive the MoinMoin pages to distribute hotfixes? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-22 07:08 Message: Logged In: YES user_id=6380 Martin, in ftplib.py, there's a self.passiveserver = 0" in the connect method that overrides the default "passiveserver = 1" at the class level. This was introduced in rev. 1.54 when you integrated IPV6 support. Shouldn't this be taken out? Rev 1.48 announces "default to passive mode". The IPV6 patch must have broken this. (I'm sorry I didn't look at this before the release; this is an unfortunate glitch in 2.2!) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:51 Message: Logged In: YES user_id=21627 Is the debian bug number correct? The URL gives "An error occurred. Dammit. Error was: Couldn't get bug status: No such file or directory." Also, CC'ing the Debian BTS is not easy through SF, would it be feasible that you forward all comments to the BTS yourself? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495693&group_id=5470 From noreply@sourceforge.net Sun Dec 23 12:24:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 23 Dec 2001 04:24:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-495401 ] Build troubles: --with-pymalloc Message-ID: Bugs item #495401, was opened at 2001-12-20 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Build troubles: --with-pymalloc Initial Comment: The build process segfaults with the current CVS version when using --with-pymalloc System is SuSE Linux 7.0 > uname -a Linux amazonas 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 GMT 2000 i686 unknown > gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse- linux/2.95.2/specs gcc version 2.95.2 19991024 (release) Attached is the complete build log. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2001-12-23 04:24 Message: Logged In: YES user_id=89016 Unfortunately no core file was generated. Can I somehow force core file generation? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:42 Message: Logged In: YES user_id=21627 Did that produce a core file? If so, can you attach a gdb backtrace as well? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 From noreply@sourceforge.net Sun Dec 23 13:56:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 23 Dec 2001 05:56:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-495693 ] urllib doesn't support passive FTP Message-ID: Bugs item #495693, was opened at 2001-12-20 16:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495693&group_id=5470 Category: Python Library >Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: urllib doesn't support passive FTP Initial Comment: [please CC 40981@bugs.debian.org on replies; complete report can be found at http://bugs.debian.org/40981] urllib.urlopen/urlretrieve doesn't support passive FTP urllib doesn't support passive FTP, even though the underlying ftplib module does. I dunno what the right approach is (perhaps a urllib module global variable). I know some tools (I'm aware of at least ncftp and wget) autodetect whether PASV is supported by FTP servers; perhaps that intelligence could be added to ftplib. (Also: the FTP class's set_pasv() method isn't documented in my version of python-docs; I haven't checked the new 1.5.2 docs yet however.) At the moment, I'm using this ugly hack to get around it: # Really ugly hack; don't try this at home: def ftpwrapper_init(self): import ftplib self.busy = 0 self.ftp = ftplib.FTP() self.ftp.set_pasv(1) self.ftp.connect(self.host, self.port) self.ftp.login(self.user, self.passwd) for dir in self.dirs: self.ftp.cwd(dir) urllib.ftpwrapper.init = ftpwrapper_init # End really ugly hack ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-23 05:56 Message: Logged In: YES user_id=6380 Right now I have this listed as a bug, with fix, in python.org/2.2/bugs.html. When we get more, I agree that MoinMoin would be a good idea. I've checked in the fix on the trunk. This is definitely a 2.2.1 release candidate. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-23 03:16 Message: Logged In: YES user_id=21627 Yes, that is quite unfortunate, and an error. In itojun's original patch, there was still self.passiveserver=0 in the context (it was against 1.46). That patch did not apply after your changes (in 1.48 and 1.52) anymore, so I asked him to regenerate the patches, but neither of us noticed that particular change. I'll attach the obvious change below; perhaps we should revive the MoinMoin pages to distribute hotfixes? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-22 07:08 Message: Logged In: YES user_id=6380 Martin, in ftplib.py, there's a self.passiveserver = 0" in the connect method that overrides the default "passiveserver = 1" at the class level. This was introduced in rev. 1.54 when you integrated IPV6 support. Shouldn't this be taken out? Rev 1.48 announces "default to passive mode". The IPV6 patch must have broken this. (I'm sorry I didn't look at this before the release; this is an unfortunate glitch in 2.2!) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:51 Message: Logged In: YES user_id=21627 Is the debian bug number correct? The URL gives "An error occurred. Dammit. Error was: Couldn't get bug status: No such file or directory." Also, CC'ing the Debian BTS is not easy through SF, would it be feasible that you forward all comments to the BTS yourself? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495693&group_id=5470 From noreply@sourceforge.net Sun Dec 23 13:57:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 23 Dec 2001 05:57:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-496154 ] Typos in dynload_beos.c Message-ID: Bugs item #496154, was opened at 2001-12-22 11:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496154&group_id=5470 Category: Build >Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 5 Submitted By: Mark Perrego (mperrego) Assigned to: Nobody/Anonymous (nobody) Summary: Typos in dynload_beos.c Initial Comment: There are two typos in dynload_beos.c: Line 210 : PyOs_snprintf should be PyOS_snprintf (capital "S") Line 237 : PyOS_snprintf( buff, sizeof(buf) should be PyOS_snprintf( buff, sizeof(buff) (two "f"s) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496154&group_id=5470 From noreply@sourceforge.net Sun Dec 23 13:57:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 23 Dec 2001 05:57:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-496171 ] FD_CLOEXEC no longer available Message-ID: Bugs item #496171, was opened at 2001-12-22 13:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496171&group_id=5470 Category: Python Library >Group: Python 2.2.1 candidate Status: Open Resolution: None >Priority: 5 Submitted By: Per Cederqvist (ceder) Assigned to: Barry Warsaw (bwarsaw) Summary: FD_CLOEXEC no longer available Initial Comment: In at least Python 1.6 through 2.1, the FD_CLOEXEC constant was available as FCNTL.FD_CLOEXEC. Starting with Python 2.2, the constant isn't available from any module, as far as I (and grep) can tell. The fsh project (http://www.lysator.liu.se/fsh) needs access to the FD_CLOEXEC flag. ---------------------------------------------------------------------- Comment By: Per Cederqvist (ceder) Date: 2001-12-23 02:27 Message: Logged In: YES user_id=129207 It's been a hectic autumn. On december 21st, I finally got time to test the Python 2.2c1 beta. I found that there was a problem with fsh, but didn't have time to find out what the problem was. Hours later, the news reached me that Python 2.2 final was released. Bad timing, I guess. It turns out that FD_CLOEXEC is set to 1 on every platform in the known universe (including AIX), so I can work around the problem. My code won't look pretty, though: Use fcntl.FD_CLOEXEC, if available. Otherwise, use FCNTL.FD_CLOEXEC, if available, but make sure to turn off the warnings for importing FCNTL (if the warnings module is available). Otherwise, use 1. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-22 16:24 Message: Logged In: YES user_id=31435 Assigned to Barry because he's working this week . Digging thru the mass of old FCNTL.py files in the Lib/plat- xxx/ Attics, it looks to me like the current fcntlmodule is missing oodles of symbols that used to be available, some that were defined on most platforms (like FD_CLOEXEC), and many platform-unique. We should probably try the union of all of them in fcntlmodule.c. Per, sorry, looks like you'll have to wait for 2.2.1 (assuming a bugfix release manager volunteers to produce one). For 2.3, how about trying one of the beta releases before it's too late? Thousands of people downloaded the 2.2 betas, but I'm afraid nobody noticed the FD_CLOEXEC disappearance. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496171&group_id=5470 From noreply@sourceforge.net Mon Dec 24 13:16:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 24 Dec 2001 05:16:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-433775 ] module build dir first in test import Message-ID: Bugs item #433775, was opened at 2001-06-16 10:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433775&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) >Assigned to: Michael Hudson (mwh) Summary: module build dir first in test import Initial Comment: This problem was found on a Linux (RedHat 7.1) system, but applies to all Unix systems. In the step "python setup.py build", after a shared module is built, setup checks whether it can import the module. During this test, the build directory should be at the beginning of sys.path to make sure you get the module that was actually built. Currently, the build directory is at the end. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-24 05:16 Message: Logged In: YES user_id=6656 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433775&group_id=5470 From noreply@sourceforge.net Mon Dec 24 13:32:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 24 Dec 2001 05:32:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-433775 ] module build dir first in test import Message-ID: Bugs item #433775, was opened at 2001-06-16 10:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433775&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Michael Hudson (mwh) Summary: module build dir first in test import Initial Comment: This problem was found on a Linux (RedHat 7.1) system, but applies to all Unix systems. In the step "python setup.py build", after a shared module is built, setup checks whether it can import the module. During this test, the build directory should be at the beginning of sys.path to make sure you get the module that was actually built. Currently, the build directory is at the end. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-24 05:32 Message: Logged In: YES user_id=6656 Um. Is this actually a problem now we have python -E? (this would be easy enough to fix, though, after I actually found the code that puts the build dir in sys.path -- it's in site.py, of all places). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-24 05:16 Message: Logged In: YES user_id=6656 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433775&group_id=5470 From noreply@sourceforge.net Mon Dec 24 21:02:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 24 Dec 2001 13:02:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-496549 ] -Qnew and in-place division "/=" Message-ID: Bugs item #496549, was opened at 2001-12-24 13:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496549&group_id=5470 Category: Parser/Compiler Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Nobody/Anonymous (nobody) Summary: -Qnew and in-place division "/=" Initial Comment: (Closed bug report #488514 may be related to this bug, as it mentions some tests failing.) If I invoke Python 2.2 with -Qnew, there is the following failure with in-place division: print 5/2 a = 5 a /= 2 print a # gives 2, should give 2.5 If I insert an explicit "from __future_ import division", the program works correctly. Bruce Sherwood ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496549&group_id=5470 From noreply@sourceforge.net Mon Dec 24 23:28:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 24 Dec 2001 15:28:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-496549 ] -Qnew and in-place division "/=" Message-ID: Bugs item #496549, was opened at 2001-12-24 13:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496549&group_id=5470 >Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Bruce Sherwood (bsherwood) >Assigned to: Tim Peters (tim_one) >Summary: -Qnew and in-place division "/=" Initial Comment: (Closed bug report #488514 may be related to this bug, as it mentions some tests failing.) If I invoke Python 2.2 with -Qnew, there is the following failure with in-place division: print 5/2 a = 5 a /= 2 print a # gives 2, should give 2.5 If I insert an explicit "from __future_ import division", the program works correctly. Bruce Sherwood ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-24 15:28 Message: Logged In: YES user_id=31435 Fudge -- this is my oversight. I think a missing piece of info here is that you were running IDLE, right? It gives 2.5 under a native (DOS box; cmdline) shell. If that's correct, it should be easy to repair, but requires code changes in the core. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496549&group_id=5470 From noreply@sourceforge.net Mon Dec 24 23:38:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 24 Dec 2001 15:38:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-496104 ] FP behaviour changed from 2.1.1 Message-ID: Bugs item #496104, was opened at 2001-12-22 06:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496104&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Dietrich (quasi) >Assigned to: Guido van Rossum (gvanrossum) Summary: FP behaviour changed from 2.1.1 Initial Comment: Python2.2 floating point behaviour is different from 2.1.1 on Linux. Instead of Inf and nan an OverflowError is raised. (sometimes): Python 2.2 (#5, Dec 22 2001, 14:57:12) [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.68mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import math >>> 1e308**10 Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Numerical result out of range') >>> math.tan(1e308**10) Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Numerical result out of range') >>> 1e308*10 inf >>> math.tan(1e308*10) nan Python 2.1.1 (#1, Oct 24 2001, 13:07:11) [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.66mdk)] on linux-i386 Type "copyright", "credits" or "license" for more information. >>> import math >>> 1e308**10 inf >>> math.tan(1e308**10) nan >>> 1e308*10 inf >>> math.tan(1e308*10) nan ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-24 15:38 Message: Logged In: YES user_id=31435 Guido, can you try this on Linux under 2.2? """ import math x = 1e308 x ** 10 x ** 9.99 pow(x, 10) """ Assign the bug back to me regardless. If the last three lines all raise OverflowError on Linux, I intend to close the bug (as WontFix). But if one or more of those doesn't raise OverflowError, my rationale sucks so I'd need to think harder. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-22 08:35 Message: Logged In: YES user_id=31435 Python doesn't define what happens in such cases, and it varied across platforms (depending on vagaries of the platform C compiler and libraries). It should be more consistent in 2.2 than in 2.1. For example, under 2.1 (Windows here): C:\Python21>python Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> x = 1e308 >>> x ** 10 # as you saw on Linux 1.#INF >>> x ** 9.99 # but a smaller exponent as a float blows up Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Result too large') >>> import math >>> math.pow(x, 10) # ditto spelling it pow() instead of ** Traceback (most recent call last): File "", line 1, in ? OverflowError: math range error >>> Under 2.2, though, they're all OverflowErrors: C:\Python22>python Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> x = 1e308 >>> x ** 10 Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Result too large') >>> x ** 9.9 Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Result too large') >>> import math >>> math.pow(x, 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: math range error >>> If the results in all 3 cases are OverflowError on Linux too in 2.2, I have to count that as an improvement (but regretting that it changed -- Python's fp behavior is often accidental, and making it more predictable is difficult for implementers and frustrating for users). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496104&group_id=5470 From noreply@sourceforge.net Tue Dec 25 00:06:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 24 Dec 2001 16:06:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-496549 ] -Qnew and in-place division "/=" Message-ID: Bugs item #496549, was opened at 2001-12-24 13:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496549&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Tim Peters (tim_one) >Summary: -Qnew and in-place division "/=" Initial Comment: (Closed bug report #488514 may be related to this bug, as it mentions some tests failing.) If I invoke Python 2.2 with -Qnew, there is the following failure with in-place division: print 5/2 a = 5 a /= 2 print a # gives 2, should give 2.5 If I insert an explicit "from __future_ import division", the program works correctly. Bruce Sherwood ---------------------------------------------------------------------- >Comment By: Bruce Sherwood (bsherwood) Date: 2001-12-24 16:06 Message: Logged In: YES user_id=34881 You're correct that I was running from IDLE (on Windows). In the idlefork version of IDLE, I experimented with spawning a run with the -Qnew option and got the result I reported. It didn't occur to me to try it from a command line, thinking that the spawn was equivalent. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-24 15:28 Message: Logged In: YES user_id=31435 Fudge -- this is my oversight. I think a missing piece of info here is that you were running IDLE, right? It gives 2.5 under a native (DOS box; cmdline) shell. If that's correct, it should be easy to repair, but requires code changes in the core. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496549&group_id=5470 From noreply@sourceforge.net Tue Dec 25 00:47:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 24 Dec 2001 16:47:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-496104 ] FP behaviour changed from 2.1.1 Message-ID: Bugs item #496104, was opened at 2001-12-22 06:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496104&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Dietrich (quasi) Assigned to: Guido van Rossum (gvanrossum) Summary: FP behaviour changed from 2.1.1 Initial Comment: Python2.2 floating point behaviour is different from 2.1.1 on Linux. Instead of Inf and nan an OverflowError is raised. (sometimes): Python 2.2 (#5, Dec 22 2001, 14:57:12) [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.68mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import math >>> 1e308**10 Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Numerical result out of range') >>> math.tan(1e308**10) Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Numerical result out of range') >>> 1e308*10 inf >>> math.tan(1e308*10) nan Python 2.1.1 (#1, Oct 24 2001, 13:07:11) [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.66mdk)] on linux-i386 Type "copyright", "credits" or "license" for more information. >>> import math >>> 1e308**10 inf >>> math.tan(1e308**10) nan >>> 1e308*10 inf >>> math.tan(1e308*10) nan ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-24 16:47 Message: Logged In: YES user_id=29957 I'm not Guido, but on RH7.1 here: >>> import math >>> x = 1e308 >>> x ** 10 Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Numerical result out of range') >>> x ** 9.99 Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Numerical result out of range') >>> pow(x, 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Numerical result out of range') >>> ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-24 15:38 Message: Logged In: YES user_id=31435 Guido, can you try this on Linux under 2.2? """ import math x = 1e308 x ** 10 x ** 9.99 pow(x, 10) """ Assign the bug back to me regardless. If the last three lines all raise OverflowError on Linux, I intend to close the bug (as WontFix). But if one or more of those doesn't raise OverflowError, my rationale sucks so I'd need to think harder. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-22 08:35 Message: Logged In: YES user_id=31435 Python doesn't define what happens in such cases, and it varied across platforms (depending on vagaries of the platform C compiler and libraries). It should be more consistent in 2.2 than in 2.1. For example, under 2.1 (Windows here): C:\Python21>python Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> x = 1e308 >>> x ** 10 # as you saw on Linux 1.#INF >>> x ** 9.99 # but a smaller exponent as a float blows up Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Result too large') >>> import math >>> math.pow(x, 10) # ditto spelling it pow() instead of ** Traceback (most recent call last): File "", line 1, in ? OverflowError: math range error >>> Under 2.2, though, they're all OverflowErrors: C:\Python22>python Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> x = 1e308 >>> x ** 10 Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Result too large') >>> x ** 9.9 Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Result too large') >>> import math >>> math.pow(x, 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: math range error >>> If the results in all 3 cases are OverflowError on Linux too in 2.2, I have to count that as an improvement (but regretting that it changed -- Python's fp behavior is often accidental, and making it more predictable is difficult for implementers and frustrating for users). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496104&group_id=5470 From noreply@sourceforge.net Tue Dec 25 01:04:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 24 Dec 2001 17:04:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-496104 ] FP behaviour changed from 2.1.1 Message-ID: Bugs item #496104, was opened at 2001-12-22 06:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496104&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Dietrich (quasi) Assigned to: Guido van Rossum (gvanrossum) Summary: FP behaviour changed from 2.1.1 Initial Comment: Python2.2 floating point behaviour is different from 2.1.1 on Linux. Instead of Inf and nan an OverflowError is raised. (sometimes): Python 2.2 (#5, Dec 22 2001, 14:57:12) [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.68mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import math >>> 1e308**10 Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Numerical result out of range') >>> math.tan(1e308**10) Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Numerical result out of range') >>> 1e308*10 inf >>> math.tan(1e308*10) nan Python 2.1.1 (#1, Oct 24 2001, 13:07:11) [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.66mdk)] on linux-i386 Type "copyright", "credits" or "license" for more information. >>> import math >>> 1e308**10 inf >>> math.tan(1e308**10) nan >>> 1e308*10 inf >>> math.tan(1e308*10) nan ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-24 17:04 Message: Logged In: YES user_id=6380 Anthony is channeling me correctly. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-24 16:47 Message: Logged In: YES user_id=29957 I'm not Guido, but on RH7.1 here: >>> import math >>> x = 1e308 >>> x ** 10 Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Numerical result out of range') >>> x ** 9.99 Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Numerical result out of range') >>> pow(x, 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Numerical result out of range') >>> ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-24 15:38 Message: Logged In: YES user_id=31435 Guido, can you try this on Linux under 2.2? """ import math x = 1e308 x ** 10 x ** 9.99 pow(x, 10) """ Assign the bug back to me regardless. If the last three lines all raise OverflowError on Linux, I intend to close the bug (as WontFix). But if one or more of those doesn't raise OverflowError, my rationale sucks so I'd need to think harder. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-22 08:35 Message: Logged In: YES user_id=31435 Python doesn't define what happens in such cases, and it varied across platforms (depending on vagaries of the platform C compiler and libraries). It should be more consistent in 2.2 than in 2.1. For example, under 2.1 (Windows here): C:\Python21>python Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> x = 1e308 >>> x ** 10 # as you saw on Linux 1.#INF >>> x ** 9.99 # but a smaller exponent as a float blows up Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Result too large') >>> import math >>> math.pow(x, 10) # ditto spelling it pow() instead of ** Traceback (most recent call last): File "", line 1, in ? OverflowError: math range error >>> Under 2.2, though, they're all OverflowErrors: C:\Python22>python Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> x = 1e308 >>> x ** 10 Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Result too large') >>> x ** 9.9 Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Result too large') >>> import math >>> math.pow(x, 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: math range error >>> If the results in all 3 cases are OverflowError on Linux too in 2.2, I have to count that as an improvement (but regretting that it changed -- Python's fp behavior is often accidental, and making it more predictable is difficult for implementers and frustrating for users). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496104&group_id=5470 From noreply@sourceforge.net Tue Dec 25 02:25:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 24 Dec 2001 18:25:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-496104 ] FP behaviour changed from 2.1.1 Message-ID: Bugs item #496104, was opened at 2001-12-22 06:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496104&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Andreas Dietrich (quasi) >Assigned to: Tim Peters (tim_one) Summary: FP behaviour changed from 2.1.1 Initial Comment: Python2.2 floating point behaviour is different from 2.1.1 on Linux. Instead of Inf and nan an OverflowError is raised. (sometimes): Python 2.2 (#5, Dec 22 2001, 14:57:12) [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.68mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import math >>> 1e308**10 Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Numerical result out of range') >>> math.tan(1e308**10) Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Numerical result out of range') >>> 1e308*10 inf >>> math.tan(1e308*10) nan Python 2.1.1 (#1, Oct 24 2001, 13:07:11) [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.66mdk)] on linux-i386 Type "copyright", "credits" or "license" for more information. >>> import math >>> 1e308**10 inf >>> math.tan(1e308**10) nan >>> 1e308*10 inf >>> math.tan(1e308*10) nan ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-24 18:25 Message: Logged In: YES user_id=31435 Thanks, Anthony. Closing as threatened. The only remaining x-platform difference is that the OverflowError details differ. This is due to libc differences, but the high-order bit is that Python is detecting the overflow in all cases on both platforms now (with or without a cooperative platform libm). So this is consistent and explainable in 2.2; I don't want to go back to platform accidents, inconsistent across platforms and also between minor spelling variations on a single platform. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-24 17:04 Message: Logged In: YES user_id=6380 Anthony is channeling me correctly. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-24 16:47 Message: Logged In: YES user_id=29957 I'm not Guido, but on RH7.1 here: >>> import math >>> x = 1e308 >>> x ** 10 Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Numerical result out of range') >>> x ** 9.99 Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Numerical result out of range') >>> pow(x, 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Numerical result out of range') >>> ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-24 15:38 Message: Logged In: YES user_id=31435 Guido, can you try this on Linux under 2.2? """ import math x = 1e308 x ** 10 x ** 9.99 pow(x, 10) """ Assign the bug back to me regardless. If the last three lines all raise OverflowError on Linux, I intend to close the bug (as WontFix). But if one or more of those doesn't raise OverflowError, my rationale sucks so I'd need to think harder. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-22 08:35 Message: Logged In: YES user_id=31435 Python doesn't define what happens in such cases, and it varied across platforms (depending on vagaries of the platform C compiler and libraries). It should be more consistent in 2.2 than in 2.1. For example, under 2.1 (Windows here): C:\Python21>python Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> x = 1e308 >>> x ** 10 # as you saw on Linux 1.#INF >>> x ** 9.99 # but a smaller exponent as a float blows up Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Result too large') >>> import math >>> math.pow(x, 10) # ditto spelling it pow() instead of ** Traceback (most recent call last): File "", line 1, in ? OverflowError: math range error >>> Under 2.2, though, they're all OverflowErrors: C:\Python22>python Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> x = 1e308 >>> x ** 10 Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Result too large') >>> x ** 9.9 Traceback (most recent call last): File "", line 1, in ? OverflowError: (34, 'Result too large') >>> import math >>> math.pow(x, 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: math range error >>> If the results in all 3 cases are OverflowError on Linux too in 2.2, I have to count that as an improvement (but regretting that it changed -- Python's fp behavior is often accidental, and making it more predictable is difficult for implementers and frustrating for users). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496104&group_id=5470 From noreply@sourceforge.net Tue Dec 25 18:49:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 25 Dec 2001 10:49:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-496549 ] -Qnew and in-place division "/=" Message-ID: Bugs item #496549, was opened at 2001-12-24 13:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496549&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Tim Peters (tim_one) >Summary: -Qnew and in-place division "/=" Initial Comment: (Closed bug report #488514 may be related to this bug, as it mentions some tests failing.) If I invoke Python 2.2 with -Qnew, there is the following failure with in-place division: print 5/2 a = 5 a /= 2 print a # gives 2, should give 2.5 If I insert an explicit "from __future_ import division", the program works correctly. Bruce Sherwood ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-25 10:49 Message: Logged In: YES user_id=31435 Fixed in Python/ceval.c; new revision: 2.302 ---------------------------------------------------------------------- Comment By: Bruce Sherwood (bsherwood) Date: 2001-12-24 16:06 Message: Logged In: YES user_id=34881 You're correct that I was running from IDLE (on Windows). In the idlefork version of IDLE, I experimented with spawning a run with the -Qnew option and got the result I reported. It didn't occur to me to try it from a command line, thinking that the spawn was equivalent. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-24 15:28 Message: Logged In: YES user_id=31435 Fudge -- this is my oversight. I think a missing piece of info here is that you were running IDLE, right? It gives 2.5 under a native (DOS box; cmdline) shell. If that's correct, it should be easy to repair, but requires code changes in the core. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496549&group_id=5470 From noreply@sourceforge.net Tue Dec 25 19:08:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 25 Dec 2001 11:08:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-495548 ] troublesome #define in pyport.h Message-ID: Bugs item #495548, was opened at 2001-12-20 11:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495548&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Norman Vine (nhv) Assigned to: Tim Peters (tim_one) Summary: troublesome #define in pyport.h Initial Comment: In include/pyport.h at line 36 the #define ANY void causes conflicts with several other packages Do we really need this any more ? A quick grep of the distribution didn't show that it was used anywhere ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-25 11:08 Message: Logged In: YES user_id=31435 The #define was removed in Include/pyport.h; new revision: 2.41 Misc/NEWS; new revision: 1.340 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-20 15:37 Message: Logged In: YES user_id=31435 It's left over from pre-ANSIsification. The problem with old crap like this is that, while the core never uses it anymore, its exposure via Python.h means extension authors may be relying on it. So taking it out is dangerous (certainly too dangerous remove from 2.2 at this point). I'll get rid of it for the first 2.3 alpha, though. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495548&group_id=5470 From noreply@sourceforge.net Wed Dec 26 16:55:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 26 Dec 2001 08:55:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-496215 ] Unclosed verbatim environment Message-ID: Bugs item #496215, was opened at 2001-12-22 17:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496215&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dave Cole (davecole) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Unclosed verbatim environment Initial Comment: There is an unclosed verbatim environment in api/abstract.tex There is an attached patch to fix the problem. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-26 08:55 Message: Logged In: YES user_id=3066 Fixed in Doc/api/abstract.tex revision 1.9. The "final patch" (attached) is what was actually used to close this report; that should be applied to the Python 2.2.1 branch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496215&group_id=5470 From noreply@sourceforge.net Wed Dec 26 20:09:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 26 Dec 2001 12:09:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-487165 ] difficult to find string interpolation Message-ID: Bugs item #487165, was opened at 2001-11-29 10:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487165&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gábor BORGULYA (borgulya) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: difficult to find string interpolation Initial Comment: I tried to look up the possibilities how to formulate expressions like 'Hello %s\n' % name After a long search I found out that this is "string interpolation". But searching for the word 'interpolation' resulted only in pages about interpolation errors. Finally I found the page: Python library reference, 2.1.5.2 String Formatting Operations. This is what I wanted to see. This page does not contain the word "interpolation". I think this part of the documentation should be made easier to find. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-26 12:09 Message: Logged In: YES user_id=3066 Added index entries similar to Skip's, and use the word "interpolation" in the text, in Doc/lib/libstdtypes.tex revision 1.81. Fixed labelling of "%" as "<" in the index generator (Doc/tools/buildindex.py revision 1.12). The "final patch" (attached) should also be applied for Python 2.1.2 and 2.2.1 as well. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-11-30 08:30 Message: Logged In: YES user_id=44345 I just tried adding the following extra index entries to the string formatting section in libstdtypes.tex: \index{\% formatting} \index{string interpolation} \index{string!interpolation} \index{interpolation, string} All but the first one worked. The first sort of worked, but the "% formatting" entry came up in the index under the character "<" for some reason. Perhaps Fred knows how to work around that problem. Skip ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487165&group_id=5470 From noreply@sourceforge.net Wed Dec 26 20:10:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 26 Dec 2001 12:10:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-487165 ] difficult to find string interpolation Message-ID: Bugs item #487165, was opened at 2001-11-29 10:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487165&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gábor BORGULYA (borgulya) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: difficult to find string interpolation Initial Comment: I tried to look up the possibilities how to formulate expressions like 'Hello %s\n' % name After a long search I found out that this is "string interpolation". But searching for the word 'interpolation' resulted only in pages about interpolation errors. Finally I found the page: Python library reference, 2.1.5.2 String Formatting Operations. This is what I wanted to see. This page does not contain the word "interpolation". I think this part of the documentation should be made easier to find. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-26 12:09 Message: Logged In: YES user_id=3066 Added index entries similar to Skip's, and use the word "interpolation" in the text, in Doc/lib/libstdtypes.tex revision 1.81. Fixed labelling of "%" as "<" in the index generator (Doc/tools/buildindex.py revision 1.12). The "final patch" (attached) should also be applied for Python 2.1.2 and 2.2.1 as well. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-11-30 08:30 Message: Logged In: YES user_id=44345 I just tried adding the following extra index entries to the string formatting section in libstdtypes.tex: \index{\% formatting} \index{string interpolation} \index{string!interpolation} \index{interpolation, string} All but the first one worked. The first sort of worked, but the "% formatting" entry came up in the index under the character "<" for some reason. Perhaps Fred knows how to work around that problem. Skip ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487165&group_id=5470 From noreply@sourceforge.net Wed Dec 26 21:18:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 26 Dec 2001 13:18:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-496873 ] cPickle / time.struct_time loop Message-ID: Bugs item #496873, was opened at 2001-12-26 13:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496873&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Vicente Rey Bakaikoa (bixentxo) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle / time.struct_time loop Initial Comment: The following code produces and endless loop on python 2.2 ( ok on python 2.1 ). The file being saved by cPickle.dump grows indefinetely. ----------------------------- import time, cPickle created = time.localtime() fd = open('/tmp/bla.pickle','w') cPickle.dump(created,fd) [...endless loop... ] ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496873&group_id=5470 From noreply@sourceforge.net Wed Dec 26 23:42:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 26 Dec 2001 15:42:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-496922 ] Integrate "What's new in Python x.y" Message-ID: Bugs item #496922, was opened at 2001-12-26 15:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496922&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 4 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Integrate "What's new in Python x.y" Initial Comment: We should find a way to integrate Andrew Kuchling's "What's new in Python X.Y?" documents with the corresponding Python documentation to make it easier to locate for users. This could be done either by incorporating the document into the standard documentation package (preferred for off-line users) or by adding a link to the online version of the document. This should be done in time for Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496922&group_id=5470 From noreply@sourceforge.net Thu Dec 27 04:24:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 26 Dec 2001 20:24:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-459007 ] Document sys.path on Windows Message-ID: Bugs item #459007, was opened at 2001-09-05 19:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459007&group_id=5470 Category: Documentation Group: Platform-specific Status: Open Resolution: None >Priority: 6 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: Document sys.path on Windows Initial Comment: I keep promising to document how Python builds the sys.path. Please-holder so Tim has a consistent place to hassle me :) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-26 20:24 Message: Logged In: YES user_id=3066 Raised priority since we keep answering questions about this, and there's now a chance that it'll get done. ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459007&group_id=5470 From noreply@sourceforge.net Thu Dec 27 04:26:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 26 Dec 2001 20:26:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-450803 ] smtpd.py needs documentation Message-ID: Bugs item #450803, was opened at 2001-08-14 07:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450803&group_id=5470 Category: Documentation >Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Barry Warsaw (bwarsaw) Assigned to: Barry Warsaw (bwarsaw) Summary: smtpd.py needs documentation Initial Comment: smtpd.py needs documentation for the standard library ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450803&group_id=5470 From noreply@sourceforge.net Thu Dec 27 05:35:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 26 Dec 2001 21:35:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-459007 ] Document sys.path on Windows Message-ID: Bugs item #459007, was opened at 2001-09-05 19:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459007&group_id=5470 Category: Documentation Group: Platform-specific Status: Open Resolution: None Priority: 6 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: Document sys.path on Windows Initial Comment: I keep promising to document how Python builds the sys.path. Please-holder so Tim has a consistent place to hassle me :) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-26 21:35 Message: Logged In: YES user_id=31435 Nice try, Fred -- but I figure Mark knows that if he does this, we'll just ask him to document the registry on Windows too . ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-26 20:24 Message: Logged In: YES user_id=3066 Raised priority since we keep answering questions about this, and there's now a chance that it'll get done. ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459007&group_id=5470 From noreply@sourceforge.net Thu Dec 27 05:45:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 26 Dec 2001 21:45:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-459007 ] Document sys.path on Windows Message-ID: Bugs item #459007, was opened at 2001-09-05 19:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459007&group_id=5470 Category: Documentation Group: Platform-specific Status: Open Resolution: None Priority: 6 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: Document sys.path on Windows Initial Comment: I keep promising to document how Python builds the sys.path. Please-holder so Tim has a consistent place to hassle me :) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-26 21:45 Message: Logged In: YES user_id=3066 Only so far as we use it! The _winreg module already has documentation, and no one has filed a bug report on it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-26 21:35 Message: Logged In: YES user_id=31435 Nice try, Fred -- but I figure Mark knows that if he does this, we'll just ask him to document the registry on Windows too . ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-26 20:24 Message: Logged In: YES user_id=3066 Raised priority since we keep answering questions about this, and there's now a chance that it'll get done. ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459007&group_id=5470 From noreply@sourceforge.net Thu Dec 27 06:06:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 26 Dec 2001 22:06:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-496873 ] cPickle / time.struct_time loop Message-ID: Bugs item #496873, was opened at 2001-12-26 13:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496873&group_id=5470 >Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Vicente Rey Bakaikoa (bixentxo) >Assigned to: Guido van Rossum (gvanrossum) Summary: cPickle / time.struct_time loop Initial Comment: The following code produces and endless loop on python 2.2 ( ok on python 2.1 ). The file being saved by cPickle.dump grows indefinetely. ----------------------------- import time, cPickle created = time.localtime() fd = open('/tmp/bla.pickle','w') cPickle.dump(created,fd) [...endless loop... ] ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-26 22:06 Message: Logged In: YES user_id=31435 Boosted priority, assigned to Guido. A stack fault is faster to produce via the one-liner cPickle.dumps(time.localtime()) There's unbounded recursion. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496873&group_id=5470 From noreply@sourceforge.net Thu Dec 27 10:02:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 02:02:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-497005 ] __cmp__ method returns unexpected result Message-ID: Bugs item #497005, was opened at 2001-12-27 02:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497005&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Russell (mattsurf76) Assigned to: Nobody/Anonymous (nobody) Summary: __cmp__ method returns unexpected result Initial Comment: There seems to be a problem overriding the __cmp__ metaclass method in the new release : class A : def __init__(self, x, y) self.x=x self.y=y def __cmp__(self, other) : return (self.x==other.x and self.y==other.y) a=A(1,2) aa=A(1,2) Where : a==aa is false and cmp(a,aa) is true? this is also the behaviour if the __cmp__ method is *not* overriden, i.e class Test : def __init__(self, *args) : self.args = args aTest = Test(1) aTest1 = Test(1) aTest==aTest1 (returns 0) cmp(aTest, aTest1) (returns 1) Is this intended? Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497005&group_id=5470 From noreply@sourceforge.net Thu Dec 27 11:50:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 03:50:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-496873 ] cPickle / time.struct_time loop Message-ID: Bugs item #496873, was opened at 2001-12-26 13:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496873&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Vicente Rey Bakaikoa (bixentxo) Assigned to: Guido van Rossum (gvanrossum) Summary: cPickle / time.struct_time loop Initial Comment: The following code produces and endless loop on python 2.2 ( ok on python 2.1 ). The file being saved by cPickle.dump grows indefinetely. ----------------------------- import time, cPickle created = time.localtime() fd = open('/tmp/bla.pickle','w') cPickle.dump(created,fd) [...endless loop... ] ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-27 03:50 Message: Logged In: YES user_id=6656 Another factoid: if you back out the change that renamed the "struct_time" type to "time.struct_time", the crash goes away, to be replaced with cPickle.PicklingError: Can't pickle : it's not found as __builtin__.struct_time so I suspect this bug has been lurking for some time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-26 22:06 Message: Logged In: YES user_id=31435 Boosted priority, assigned to Guido. A stack fault is faster to produce via the one-liner cPickle.dumps(time.localtime()) There's unbounded recursion. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496873&group_id=5470 From noreply@sourceforge.net Thu Dec 27 13:36:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 05:36:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-497005 ] __cmp__ method returns unexpected result Message-ID: Bugs item #497005, was opened at 2001-12-27 02:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497005&group_id=5470 >Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Matthew Russell (mattsurf76) >Assigned to: Guido van Rossum (gvanrossum) Summary: __cmp__ method returns unexpected result Initial Comment: There seems to be a problem overriding the __cmp__ metaclass method in the new release : class A : def __init__(self, x, y) self.x=x self.y=y def __cmp__(self, other) : return (self.x==other.x and self.y==other.y) a=A(1,2) aa=A(1,2) Where : a==aa is false and cmp(a,aa) is true? this is also the behaviour if the __cmp__ method is *not* overriden, i.e class Test : def __init__(self, *args) : self.args = args aTest = Test(1) aTest1 = Test(1) aTest==aTest1 (returns 0) cmp(aTest, aTest1) (returns 1) Is this intended? Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 05:36 Message: Logged In: YES user_id=6380 You have misunderstood __cmp__. It should return 0 if equal. See the docs. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497005&group_id=5470 From noreply@sourceforge.net Thu Dec 27 14:06:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 06:06:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-496873 ] cPickle / time.struct_time loop Message-ID: Bugs item #496873, was opened at 2001-12-26 13:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496873&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Vicente Rey Bakaikoa (bixentxo) Assigned to: Guido van Rossum (gvanrossum) Summary: cPickle / time.struct_time loop Initial Comment: The following code produces and endless loop on python 2.2 ( ok on python 2.1 ). The file being saved by cPickle.dump grows indefinetely. ----------------------------- import time, cPickle created = time.localtime() fd = open('/tmp/bla.pickle','w') cPickle.dump(created,fd) [...endless loop... ] ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 06:06 Message: Logged In: YES user_id=6380 It gets in an infinite loop with pickle too, so I think this is definitely a bug in the magical type used for localtime. The stacktrack looks like this: File "/usr/local/lib/python2.2/pickle.py", line 370, in save_tuple save(element) File "/usr/local/lib/python2.2/pickle.py", line 215, in save self.save_reduce(callable, arg_tup, state) File "/usr/local/lib/python2.2/pickle.py", line 241, in save_reduce save(arg_tup) File "/usr/local/lib/python2.2/pickle.py", line 221, in save f(self, object) repeated an infinite number of times. Note that we should look at the other objects that use structseq.c/h too. pickle.dumps(os.stat("/")) gives TypeError: constructor takes exactly 13 arguments (10 given) pickle.dumps(os.statvfs("/")) gives pickle.PicklingError: Can't pickle : it's not the same object as posix.statvfs_result Looks like a variety of bugs. :-( ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-27 03:50 Message: Logged In: YES user_id=6656 Another factoid: if you back out the change that renamed the "struct_time" type to "time.struct_time", the crash goes away, to be replaced with cPickle.PicklingError: Can't pickle : it's not found as __builtin__.struct_time so I suspect this bug has been lurking for some time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-26 22:06 Message: Logged In: YES user_id=31435 Boosted priority, assigned to Guido. A stack fault is faster to produce via the one-liner cPickle.dumps(time.localtime()) There's unbounded recursion. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496873&group_id=5470 From noreply@sourceforge.net Thu Dec 27 14:33:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 06:33:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-497042 ] 2.2 is missing Misc/Makefile.pre.in? Message-ID: Bugs item #497042, was opened at 2001-12-27 06:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497042&group_id=5470 Category: Demos and Tools Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Joseph VanAndel (vanandel) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2 is missing Misc/Makefile.pre.in? Initial Comment: If I try to build Python-2.2/Demo/extend using make_shared, I get the message: % make_shared cp: cannot stat `../../Misc/Makefile.pre.in': No such file or directory make: Makefile.pre.in: No such file or directory make: *** No rule to make target `Makefile.pre.in'. Stop. make: *** No targets specified and no makefile found. Stop. Since we're trying to encourage using distutils for building extensions, I have updated the "extending demo". I've attached a tar file containing: setup.py # simple distutils script README # revised instructions test_xx.py # a simple test script for the 'xx' module ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497042&group_id=5470 From noreply@sourceforge.net Thu Dec 27 15:18:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 07:18:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-496922 ] Integrate "What's new in Python x.y" Message-ID: Bugs item #496922, was opened at 2001-12-26 15:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496922&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 4 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: Integrate "What's new in Python x.y" Initial Comment: We should find a way to integrate Andrew Kuchling's "What's new in Python X.Y?" documents with the corresponding Python documentation to make it easier to locate for users. This could be done either by incorporating the document into the standard documentation package (preferred for off-line users) or by adding a link to the online version of the document. This should be done in time for Python 2.3. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 07:18 Message: Logged In: YES user_id=6380 Could you do this for 2.2.1 too? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496922&group_id=5470 From noreply@sourceforge.net Thu Dec 27 16:14:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 08:14:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-497067 ] Allow traceback analysis from C/C++... Message-ID: Bugs item #497067, was opened at 2001-12-27 08:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497067&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Marcin Kasperski (marcinkasperski) Assigned to: Nobody/Anonymous (nobody) Summary: Allow traceback analysis from C/C++... Initial Comment: I write C++ applications which embed python interpreter as script engine. And I would like to perform traceback analysis during error handling (imagine for instance that I would like to include python traceback info inside some exception which will be handled outside library I write, maybe by sending error description to log server via network) What I found? PyErr_Fetch gets traceback object and gives it to me. There are methods which print traceback to standard error. But if I want to do something different ... there is no way to analyze traceback without utilizing some dirty tricks. Two main problems: - struct tracebackobject is not present in python headers, it is only in traceback.c - it is of course not documented at all. I finally managed to do what I wanted by copying tracebackobject definition from traceback.c and by copying tb_printinternal and suiting it to my needs. But what will happen if you change this structure some time in the future? What exactly do I request? Choose one of the two: 1) Either publish struct tracebackobject inside some Python headers (traceback.h?), mention in PyErr_Fetch documentation that the last parameter is of this type and describe its structure somewhere in python-embed 2) Or keep it secret but add some API which would allow to navigate traceback without presenting its internals, say the function like PyTrace_AnalyzeTraceBack which - given traceback object - would return file, line, name and next traceback (or the flag telling that there is no more). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497067&group_id=5470 From noreply@sourceforge.net Thu Dec 27 16:32:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 08:32:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-496873 ] cPickle / time.struct_time loop Message-ID: Bugs item #496873, was opened at 2001-12-26 13:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496873&group_id=5470 Category: Type/class unification >Group: Python 2.2.1 candidate Status: Open Resolution: None >Priority: 5 Submitted By: Vicente Rey Bakaikoa (bixentxo) >Assigned to: Anthony Baxter (anthonybaxter) Summary: cPickle / time.struct_time loop Initial Comment: The following code produces and endless loop on python 2.2 ( ok on python 2.1 ). The file being saved by cPickle.dump grows indefinetely. ----------------------------- import time, cPickle created = time.localtime() fd = open('/tmp/bla.pickle','w') cPickle.dump(created,fd) [...endless loop... ] ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 08:32 Message: Logged In: YES user_id=6380 Actually, the bug was in copy_reg._reduce: it was possible that this would not make any progress, returning an instance of the same type that it was passed, thus causing the infinite recursion. I've checked in a fix that raises an exception when this situation is detected. (copy_reg.py:1.10) Now, the question is, does anybody need to pickle time structs? I would recommend converting them into a tuple before pickling: pickle.dumps(tuple(time.localtime())) works fine. The statvfs issue was an unrelated bug; I've checked in a fix for that too. (posixmodule.c:2.217) Both are 2.2.1 candidates (I only noted this in the posixmodule.c CVS checkin message by mistake). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 06:06 Message: Logged In: YES user_id=6380 It gets in an infinite loop with pickle too, so I think this is definitely a bug in the magical type used for localtime. The stacktrack looks like this: File "/usr/local/lib/python2.2/pickle.py", line 370, in save_tuple save(element) File "/usr/local/lib/python2.2/pickle.py", line 215, in save self.save_reduce(callable, arg_tup, state) File "/usr/local/lib/python2.2/pickle.py", line 241, in save_reduce save(arg_tup) File "/usr/local/lib/python2.2/pickle.py", line 221, in save f(self, object) repeated an infinite number of times. Note that we should look at the other objects that use structseq.c/h too. pickle.dumps(os.stat("/")) gives TypeError: constructor takes exactly 13 arguments (10 given) pickle.dumps(os.statvfs("/")) gives pickle.PicklingError: Can't pickle : it's not the same object as posix.statvfs_result Looks like a variety of bugs. :-( ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-27 03:50 Message: Logged In: YES user_id=6656 Another factoid: if you back out the change that renamed the "struct_time" type to "time.struct_time", the crash goes away, to be replaced with cPickle.PicklingError: Can't pickle : it's not found as __builtin__.struct_time so I suspect this bug has been lurking for some time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-26 22:06 Message: Logged In: YES user_id=31435 Boosted priority, assigned to Guido. A stack fault is faster to produce via the one-liner cPickle.dumps(time.localtime()) There's unbounded recursion. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496873&group_id=5470 From noreply@sourceforge.net Thu Dec 27 16:35:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 08:35:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-497067 ] Allow traceback analysis from C/C++... Message-ID: Bugs item #497067, was opened at 2001-12-27 08:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497067&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None >Priority: 3 Submitted By: Marcin Kasperski (marcinkasperski) Assigned to: Nobody/Anonymous (nobody) Summary: Allow traceback analysis from C/C++... Initial Comment: I write C++ applications which embed python interpreter as script engine. And I would like to perform traceback analysis during error handling (imagine for instance that I would like to include python traceback info inside some exception which will be handled outside library I write, maybe by sending error description to log server via network) What I found? PyErr_Fetch gets traceback object and gives it to me. There are methods which print traceback to standard error. But if I want to do something different ... there is no way to analyze traceback without utilizing some dirty tricks. Two main problems: - struct tracebackobject is not present in python headers, it is only in traceback.c - it is of course not documented at all. I finally managed to do what I wanted by copying tracebackobject definition from traceback.c and by copying tb_printinternal and suiting it to my needs. But what will happen if you change this structure some time in the future? What exactly do I request? Choose one of the two: 1) Either publish struct tracebackobject inside some Python headers (traceback.h?), mention in PyErr_Fetch documentation that the last parameter is of this type and describe its structure somewhere in python-embed 2) Or keep it secret but add some API which would allow to navigate traceback without presenting its internals, say the function like PyTrace_AnalyzeTraceBack which - given traceback object - would return file, line, name and next traceback (or the flag telling that there is no more). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 08:35 Message: Logged In: YES user_id=6380 I agree that this API should be published in a header file. The Python API to the traceback object is documented so you can always use PyObject_GetAttrString(tb, "tb_frame") and so on. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497067&group_id=5470 From noreply@sourceforge.net Thu Dec 27 17:02:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 09:02:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-497042 ] 2.2 is missing Misc/Makefile.pre.in? Message-ID: Bugs item #497042, was opened at 2001-12-27 06:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497042&group_id=5470 Category: Demos and Tools >Group: Python 2.2.1 candidate >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Joseph VanAndel (vanandel) >Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2 is missing Misc/Makefile.pre.in? Initial Comment: If I try to build Python-2.2/Demo/extend using make_shared, I get the message: % make_shared cp: cannot stat `../../Misc/Makefile.pre.in': No such file or directory make: Makefile.pre.in: No such file or directory make: *** No rule to make target `Makefile.pre.in'. Stop. make: *** No targets specified and no makefile found. Stop. Since we're trying to encourage using distutils for building extensions, I have updated the "extending demo". I've attached a tar file containing: setup.py # simple distutils script README # revised instructions test_xx.py # a simple test script for the 'xx' module ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 09:02 Message: Logged In: YES user_id=6380 Thanks for noticing. The removal of Misc/Makefile.pre.in is intentional -- indeed we recommend using distutils and setup.py. But rather than using your setup.py, I decided that we don't need a demo -- there's plenty of doco for distutils. So I've just erased the Demo/extend directory. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497042&group_id=5470 From noreply@sourceforge.net Thu Dec 27 17:29:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 09:29:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-497042 ] 2.2 is missing Misc/Makefile.pre.in? Message-ID: Bugs item #497042, was opened at 2001-12-27 06:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497042&group_id=5470 Category: Demos and Tools Group: Python 2.2.1 candidate Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Joseph VanAndel (vanandel) Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2 is missing Misc/Makefile.pre.in? Initial Comment: If I try to build Python-2.2/Demo/extend using make_shared, I get the message: % make_shared cp: cannot stat `../../Misc/Makefile.pre.in': No such file or directory make: Makefile.pre.in: No such file or directory make: *** No rule to make target `Makefile.pre.in'. Stop. make: *** No targets specified and no makefile found. Stop. Since we're trying to encourage using distutils for building extensions, I have updated the "extending demo". I've attached a tar file containing: setup.py # simple distutils script README # revised instructions test_xx.py # a simple test script for the 'xx' module ---------------------------------------------------------------------- >Comment By: Joseph VanAndel (vanandel) Date: 2001-12-27 09:29 Message: Logged In: YES user_id=6581 I understand that there is plenty of documentation for distutils, but are there (enough) other examples of extending, including defining objects and methods? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 09:02 Message: Logged In: YES user_id=6380 Thanks for noticing. The removal of Misc/Makefile.pre.in is intentional -- indeed we recommend using distutils and setup.py. But rather than using your setup.py, I decided that we don't need a demo -- there's plenty of doco for distutils. So I've just erased the Demo/extend directory. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497042&group_id=5470 From noreply@sourceforge.net Thu Dec 27 17:54:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 09:54:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-495693 ] urllib doesn't support passive FTP Message-ID: Bugs item #495693, was opened at 2001-12-20 16:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495693&group_id=5470 Category: Python Library Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: urllib doesn't support passive FTP Initial Comment: [please CC 40981@bugs.debian.org on replies; complete report can be found at http://bugs.debian.org/40981] urllib.urlopen/urlretrieve doesn't support passive FTP urllib doesn't support passive FTP, even though the underlying ftplib module does. I dunno what the right approach is (perhaps a urllib module global variable). I know some tools (I'm aware of at least ncftp and wget) autodetect whether PASV is supported by FTP servers; perhaps that intelligence could be added to ftplib. (Also: the FTP class's set_pasv() method isn't documented in my version of python-docs; I haven't checked the new 1.5.2 docs yet however.) At the moment, I'm using this ugly hack to get around it: # Really ugly hack; don't try this at home: def ftpwrapper_init(self): import ftplib self.busy = 0 self.ftp = ftplib.FTP() self.ftp.set_pasv(1) self.ftp.connect(self.host, self.port) self.ftp.login(self.user, self.passwd) for dir in self.dirs: self.ftp.cwd(dir) urllib.ftpwrapper.init = ftpwrapper_init # End really ugly hack ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2001-12-27 09:54 Message: Logged In: YES user_id=60903 [Martin, I'll summarize in the Debian BTS, typo in bug number, it's #40891] The original report (as I read it),wanted to have a configurable urllib.ftpwrapper. So probably adding another argument "mode" to ftpwrapper.__init__ ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-23 05:56 Message: Logged In: YES user_id=6380 Right now I have this listed as a bug, with fix, in python.org/2.2/bugs.html. When we get more, I agree that MoinMoin would be a good idea. I've checked in the fix on the trunk. This is definitely a 2.2.1 release candidate. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-23 03:16 Message: Logged In: YES user_id=21627 Yes, that is quite unfortunate, and an error. In itojun's original patch, there was still self.passiveserver=0 in the context (it was against 1.46). That patch did not apply after your changes (in 1.48 and 1.52) anymore, so I asked him to regenerate the patches, but neither of us noticed that particular change. I'll attach the obvious change below; perhaps we should revive the MoinMoin pages to distribute hotfixes? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-22 07:08 Message: Logged In: YES user_id=6380 Martin, in ftplib.py, there's a self.passiveserver = 0" in the connect method that overrides the default "passiveserver = 1" at the class level. This was introduced in rev. 1.54 when you integrated IPV6 support. Shouldn't this be taken out? Rev 1.48 announces "default to passive mode". The IPV6 patch must have broken this. (I'm sorry I didn't look at this before the release; this is an unfortunate glitch in 2.2!) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:51 Message: Logged In: YES user_id=21627 Is the debian bug number correct? The URL gives "An error occurred. Dammit. Error was: Couldn't get bug status: No such file or directory." Also, CC'ing the Debian BTS is not easy through SF, would it be feasible that you forward all comments to the BTS yourself? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495693&group_id=5470 From noreply@sourceforge.net Thu Dec 27 18:02:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 10:02:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-496873 ] cPickle / time.struct_time loop Message-ID: Bugs item #496873, was opened at 2001-12-26 13:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496873&group_id=5470 Category: Type/class unification Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 5 Submitted By: Vicente Rey Bakaikoa (bixentxo) Assigned to: Anthony Baxter (anthonybaxter) Summary: cPickle / time.struct_time loop Initial Comment: The following code produces and endless loop on python 2.2 ( ok on python 2.1 ). The file being saved by cPickle.dump grows indefinetely. ----------------------------- import time, cPickle created = time.localtime() fd = open('/tmp/bla.pickle','w') cPickle.dump(created,fd) [...endless loop... ] ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-27 10:02 Message: Logged In: YES user_id=31435 Re "does anybody need to pickle time structs?", I think a better question is "does anybody pickle time.localtime() results?". The existence of the bug report suggests yes, and the OP is right that this worked in 2.1 (and 2.0, and ...). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 08:32 Message: Logged In: YES user_id=6380 Actually, the bug was in copy_reg._reduce: it was possible that this would not make any progress, returning an instance of the same type that it was passed, thus causing the infinite recursion. I've checked in a fix that raises an exception when this situation is detected. (copy_reg.py:1.10) Now, the question is, does anybody need to pickle time structs? I would recommend converting them into a tuple before pickling: pickle.dumps(tuple(time.localtime())) works fine. The statvfs issue was an unrelated bug; I've checked in a fix for that too. (posixmodule.c:2.217) Both are 2.2.1 candidates (I only noted this in the posixmodule.c CVS checkin message by mistake). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 06:06 Message: Logged In: YES user_id=6380 It gets in an infinite loop with pickle too, so I think this is definitely a bug in the magical type used for localtime. The stacktrack looks like this: File "/usr/local/lib/python2.2/pickle.py", line 370, in save_tuple save(element) File "/usr/local/lib/python2.2/pickle.py", line 215, in save self.save_reduce(callable, arg_tup, state) File "/usr/local/lib/python2.2/pickle.py", line 241, in save_reduce save(arg_tup) File "/usr/local/lib/python2.2/pickle.py", line 221, in save f(self, object) repeated an infinite number of times. Note that we should look at the other objects that use structseq.c/h too. pickle.dumps(os.stat("/")) gives TypeError: constructor takes exactly 13 arguments (10 given) pickle.dumps(os.statvfs("/")) gives pickle.PicklingError: Can't pickle : it's not the same object as posix.statvfs_result Looks like a variety of bugs. :-( ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-27 03:50 Message: Logged In: YES user_id=6656 Another factoid: if you back out the change that renamed the "struct_time" type to "time.struct_time", the crash goes away, to be replaced with cPickle.PicklingError: Can't pickle : it's not found as __builtin__.struct_time so I suspect this bug has been lurking for some time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-26 22:06 Message: Logged In: YES user_id=31435 Boosted priority, assigned to Guido. A stack fault is faster to produce via the one-liner cPickle.dumps(time.localtime()) There's unbounded recursion. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496873&group_id=5470 From noreply@sourceforge.net Thu Dec 27 19:07:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 11:07:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-497109 ] 'lambda' documentation in strange place Message-ID: Bugs item #497109, was opened at 2001-12-27 11:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497109&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: 'lambda' documentation in strange place Initial Comment: The (Python 2.2) documentation for 'lambda' is in section 5.10, "Boolean operations". This makes it hard to find. I suggest putting it in an indexed section of its own. I originally suggested a 5.3.x section under "Primaries", but now I'm not so sure that is appropriate. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497109&group_id=5470 From noreply@sourceforge.net Thu Dec 27 19:12:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 11:12:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-497111 ] active_limbo_lock error at program exit Message-ID: Bugs item #497111, was opened at 2001-12-27 11:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497111&group_id=5470 Category: Threads Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Simo Salminen (frangen) Assigned to: Nobody/Anonymous (nobody) Summary: active_limbo_lock error at program exit Initial Comment: I'm running my threaded application, and now and then I get following error at exit. I'm using python 2.2 final, but I have had the same error with python 2.1. Unfortunately I cannot reproduce it. This bug has only occured when I've run the program under win2ksp2, tried to produce it under linux but without luck. My program is pure python application. I guess saving reference to _active_limbo_lock at Thread-class could solve the problem.. Traceback (most recent call last): File "C:\utils\PYTHON22\lib\threading.py", line 424, in __bootstrap self.__delete() File "C:\utils\PYTHON22\lib\threading.py", line 433, in __delete _active_limbo_lock.acquire() AttributeError: 'NoneType' object has no attribute 'acquire' ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497111&group_id=5470 From noreply@sourceforge.net Thu Dec 27 19:51:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 11:51:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-497111 ] active_limbo_lock error at program exit Message-ID: Bugs item #497111, was opened at 2001-12-27 11:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497111&group_id=5470 Category: Threads Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Simo Salminen (frangen) Assigned to: Nobody/Anonymous (nobody) Summary: active_limbo_lock error at program exit Initial Comment: I'm running my threaded application, and now and then I get following error at exit. I'm using python 2.2 final, but I have had the same error with python 2.1. Unfortunately I cannot reproduce it. This bug has only occured when I've run the program under win2ksp2, tried to produce it under linux but without luck. My program is pure python application. I guess saving reference to _active_limbo_lock at Thread-class could solve the problem.. Traceback (most recent call last): File "C:\utils\PYTHON22\lib\threading.py", line 424, in __bootstrap self.__delete() File "C:\utils\PYTHON22\lib\threading.py", line 433, in __delete _active_limbo_lock.acquire() AttributeError: 'NoneType' object has no attribute 'acquire' ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 11:51 Message: Logged In: YES user_id=6380 Hm, this looks like it could happen when the treading module is deleted while there are still threads running. But that can only happen with daemon threads. Does your program have daemon threads? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497111&group_id=5470 From noreply@sourceforge.net Thu Dec 27 19:58:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 11:58:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-497126 ] dl module and flags Message-ID: Bugs item #497126, was opened at 2001-12-27 11:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497126&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Nobody/Anonymous (nobody) Summary: dl module and flags Initial Comment: With the introduction of sys.setdlopenflags, the dl module got some special usefulness, carrying the flags used in this function. On the other hand, the dl module is not available on every platform where dlopen is. Alpha, for example, is not able to import the dl module because sizeof(int) is not equal to sizeof(long), as the assertion in initdl() ensures. I can think about two obvious solutions: a) Move RTLD_* flags to some standard module (sys?) b) Make some of the functionality in dlmodule.c optional, instead of the whole module. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497126&group_id=5470 From noreply@sourceforge.net Thu Dec 27 20:31:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 12:31:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-496873 ] cPickle / time.struct_time loop Message-ID: Bugs item #496873, was opened at 2001-12-26 13:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496873&group_id=5470 Category: Type/class unification Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 5 Submitted By: Vicente Rey Bakaikoa (bixentxo) Assigned to: Anthony Baxter (anthonybaxter) Summary: cPickle / time.struct_time loop Initial Comment: The following code produces and endless loop on python 2.2 ( ok on python 2.1 ). The file being saved by cPickle.dump grows indefinetely. ----------------------------- import time, cPickle created = time.localtime() fd = open('/tmp/bla.pickle','w') cPickle.dump(created,fd) [...endless loop... ] ---------------------------------------------------------------------- >Comment By: Vicente Rey Bakaikoa (bixentxo) Date: 2001-12-27 12:31 Message: Logged In: YES user_id=395354 As for me, it is not a problem anymore as I found the 'tuple' solution straight away. It is not that I needed pickling struct_time is that I had no reason why not doing it. Only that it DID break my code. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-27 10:02 Message: Logged In: YES user_id=31435 Re "does anybody need to pickle time structs?", I think a better question is "does anybody pickle time.localtime() results?". The existence of the bug report suggests yes, and the OP is right that this worked in 2.1 (and 2.0, and ...). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 08:32 Message: Logged In: YES user_id=6380 Actually, the bug was in copy_reg._reduce: it was possible that this would not make any progress, returning an instance of the same type that it was passed, thus causing the infinite recursion. I've checked in a fix that raises an exception when this situation is detected. (copy_reg.py:1.10) Now, the question is, does anybody need to pickle time structs? I would recommend converting them into a tuple before pickling: pickle.dumps(tuple(time.localtime())) works fine. The statvfs issue was an unrelated bug; I've checked in a fix for that too. (posixmodule.c:2.217) Both are 2.2.1 candidates (I only noted this in the posixmodule.c CVS checkin message by mistake). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 06:06 Message: Logged In: YES user_id=6380 It gets in an infinite loop with pickle too, so I think this is definitely a bug in the magical type used for localtime. The stacktrack looks like this: File "/usr/local/lib/python2.2/pickle.py", line 370, in save_tuple save(element) File "/usr/local/lib/python2.2/pickle.py", line 215, in save self.save_reduce(callable, arg_tup, state) File "/usr/local/lib/python2.2/pickle.py", line 241, in save_reduce save(arg_tup) File "/usr/local/lib/python2.2/pickle.py", line 221, in save f(self, object) repeated an infinite number of times. Note that we should look at the other objects that use structseq.c/h too. pickle.dumps(os.stat("/")) gives TypeError: constructor takes exactly 13 arguments (10 given) pickle.dumps(os.statvfs("/")) gives pickle.PicklingError: Can't pickle : it's not the same object as posix.statvfs_result Looks like a variety of bugs. :-( ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-27 03:50 Message: Logged In: YES user_id=6656 Another factoid: if you back out the change that renamed the "struct_time" type to "time.struct_time", the crash goes away, to be replaced with cPickle.PicklingError: Can't pickle : it's not found as __builtin__.struct_time so I suspect this bug has been lurking for some time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-26 22:06 Message: Logged In: YES user_id=31435 Boosted priority, assigned to Guido. A stack fault is faster to produce via the one-liner cPickle.dumps(time.localtime()) There's unbounded recursion. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496873&group_id=5470 From noreply@sourceforge.net Thu Dec 27 21:38:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 13:38:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-497160 ] test_commands assumes ls is in /bin Message-ID: Bugs item #497160, was opened at 2001-12-27 13:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497160&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Nobody/Anonymous (nobody) Summary: test_commands assumes ls is in /bin Initial Comment: I got this test failure while building Python 2.2: test test_commands failed -- Traceback (most recent call last): File "./Lib/test/test_commands.py", line 43, in test_getstatus self.assert_(re.match(pat, getstatus("/bin/ls"), re.VERBOSE)) File "/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py", line 262, in failUnless if not expr: raise self.failureException, msg AssertionError My ls happens to be somewhere other than /bin. It would be nice if the test used a different file, such as "/", ".", or even "./Lib/test/test_commands.py". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497160&group_id=5470 From noreply@sourceforge.net Thu Dec 27 21:44:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 13:44:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-497162 ] test_email assumes Unix uses NTP scale Message-ID: Bugs item #497162, was opened at 2001-12-27 13:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Nobody/Anonymous (nobody) Summary: test_email assumes Unix uses NTP scale Initial Comment: I got this test failure while building Python 2.2: test test_email failed -- Traceback (most recent call last): File "./Lib/test/test_email.py", line 935, in test_formatdate self.assertEqual(gdate, matchdate) File "/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py", line 286, in failUnlessEqual raise self.failureException, \ AssertionError: 'Fri, 09 Nov 2001 17:33:30 -0000' != 'Fri, 09 Nov 2001 17:33:52 -0000' This happens because the test assumes that the system clock is a count of non-leap seconds since the epoch. This is a common configuration, but it renders some clock values ambiguous, and complicates interval calculations. So my clock counts *all* seconds since the epoch. It would be nice if the test could handle both cases, by checking the broken-down values around a leap second, or by checking that the calculated string matches either of the two possibilities. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470 From noreply@sourceforge.net Thu Dec 27 22:21:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 14:21:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-497111 ] active_limbo_lock error at program exit Message-ID: Bugs item #497111, was opened at 2001-12-27 11:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497111&group_id=5470 Category: Threads Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Simo Salminen (frangen) Assigned to: Nobody/Anonymous (nobody) Summary: active_limbo_lock error at program exit Initial Comment: I'm running my threaded application, and now and then I get following error at exit. I'm using python 2.2 final, but I have had the same error with python 2.1. Unfortunately I cannot reproduce it. This bug has only occured when I've run the program under win2ksp2, tried to produce it under linux but without luck. My program is pure python application. I guess saving reference to _active_limbo_lock at Thread-class could solve the problem.. Traceback (most recent call last): File "C:\utils\PYTHON22\lib\threading.py", line 424, in __bootstrap self.__delete() File "C:\utils\PYTHON22\lib\threading.py", line 433, in __delete _active_limbo_lock.acquire() AttributeError: 'NoneType' object has no attribute 'acquire' ---------------------------------------------------------------------- >Comment By: Simo Salminen (frangen) Date: 2001-12-27 14:21 Message: Logged In: YES user_id=291461 Yes, program is running a mainthread and two daemon threads. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 11:51 Message: Logged In: YES user_id=6380 Hm, this looks like it could happen when the treading module is deleted while there are still threads running. But that can only happen with daemon threads. Does your program have daemon threads? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497111&group_id=5470 From noreply@sourceforge.net Fri Dec 28 06:05:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 22:05:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-495693 ] urllib doesn't support passive FTP Message-ID: Bugs item #495693, was opened at 2001-12-20 16:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495693&group_id=5470 Category: Python Library Group: Python 2.2.1 candidate Status: Open >Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Guido van Rossum (gvanrossum) Summary: urllib doesn't support passive FTP Initial Comment: [please CC 40981@bugs.debian.org on replies; complete report can be found at http://bugs.debian.org/40981] urllib.urlopen/urlretrieve doesn't support passive FTP urllib doesn't support passive FTP, even though the underlying ftplib module does. I dunno what the right approach is (perhaps a urllib module global variable). I know some tools (I'm aware of at least ncftp and wget) autodetect whether PASV is supported by FTP servers; perhaps that intelligence could be added to ftplib. (Also: the FTP class's set_pasv() method isn't documented in my version of python-docs; I haven't checked the new 1.5.2 docs yet however.) At the moment, I'm using this ugly hack to get around it: # Really ugly hack; don't try this at home: def ftpwrapper_init(self): import ftplib self.busy = 0 self.ftp = ftplib.FTP() self.ftp.set_pasv(1) self.ftp.connect(self.host, self.port) self.ftp.login(self.user, self.passwd) for dir in self.dirs: self.ftp.cwd(dir) urllib.ftpwrapper.init = ftpwrapper_init # End really ugly hack ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 22:05 Message: Logged In: YES user_id=6380 For a more configurable urllib, try urllib2. If that doesn't what you want, please submit a new bug report or feature request. I'm leaving this open only because the bugfix is a 2.2.1 candidate; the problem is fixed in CVS. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2001-12-27 09:54 Message: Logged In: YES user_id=60903 [Martin, I'll summarize in the Debian BTS, typo in bug number, it's #40891] The original report (as I read it),wanted to have a configurable urllib.ftpwrapper. So probably adding another argument "mode" to ftpwrapper.__init__ ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-23 05:56 Message: Logged In: YES user_id=6380 Right now I have this listed as a bug, with fix, in python.org/2.2/bugs.html. When we get more, I agree that MoinMoin would be a good idea. I've checked in the fix on the trunk. This is definitely a 2.2.1 release candidate. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-23 03:16 Message: Logged In: YES user_id=21627 Yes, that is quite unfortunate, and an error. In itojun's original patch, there was still self.passiveserver=0 in the context (it was against 1.46). That patch did not apply after your changes (in 1.48 and 1.52) anymore, so I asked him to regenerate the patches, but neither of us noticed that particular change. I'll attach the obvious change below; perhaps we should revive the MoinMoin pages to distribute hotfixes? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-22 07:08 Message: Logged In: YES user_id=6380 Martin, in ftplib.py, there's a self.passiveserver = 0" in the connect method that overrides the default "passiveserver = 1" at the class level. This was introduced in rev. 1.54 when you integrated IPV6 support. Shouldn't this be taken out? Rev 1.48 announces "default to passive mode". The IPV6 patch must have broken this. (I'm sorry I didn't look at this before the release; this is an unfortunate glitch in 2.2!) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:51 Message: Logged In: YES user_id=21627 Is the debian bug number correct? The URL gives "An error occurred. Dammit. Error was: Couldn't get bug status: No such file or directory." Also, CC'ing the Debian BTS is not easy through SF, would it be feasible that you forward all comments to the BTS yourself? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495693&group_id=5470 From noreply@sourceforge.net Fri Dec 28 06:06:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 27 Dec 2001 22:06:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-497042 ] 2.2 is missing Misc/Makefile.pre.in? Message-ID: Bugs item #497042, was opened at 2001-12-27 06:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497042&group_id=5470 Category: Demos and Tools Group: Python 2.2.1 candidate Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Joseph VanAndel (vanandel) Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2 is missing Misc/Makefile.pre.in? Initial Comment: If I try to build Python-2.2/Demo/extend using make_shared, I get the message: % make_shared cp: cannot stat `../../Misc/Makefile.pre.in': No such file or directory make: Makefile.pre.in: No such file or directory make: *** No rule to make target `Makefile.pre.in'. Stop. make: *** No targets specified and no makefile found. Stop. Since we're trying to encourage using distutils for building extensions, I have updated the "extending demo". I've attached a tar file containing: setup.py # simple distutils script README # revised instructions test_xx.py # a simple test script for the 'xx' module ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 22:06 Message: Logged In: YES user_id=6380 If you find the distutil docs lacking, please submit a new bug report in the Documentation category. ---------------------------------------------------------------------- Comment By: Joseph VanAndel (vanandel) Date: 2001-12-27 09:29 Message: Logged In: YES user_id=6581 I understand that there is plenty of documentation for distutils, but are there (enough) other examples of extending, including defining objects and methods? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 09:02 Message: Logged In: YES user_id=6380 Thanks for noticing. The removal of Misc/Makefile.pre.in is intentional -- indeed we recommend using distutils and setup.py. But rather than using your setup.py, I decided that we don't need a demo -- there's plenty of doco for distutils. So I've just erased the Demo/extend directory. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497042&group_id=5470 From noreply@sourceforge.net Fri Dec 28 14:35:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 06:35:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-497111 ] active_limbo_lock error at program exit Message-ID: Bugs item #497111, was opened at 2001-12-27 11:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497111&group_id=5470 Category: Threads Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Simo Salminen (frangen) >Assigned to: Guido van Rossum (gvanrossum) Summary: active_limbo_lock error at program exit Initial Comment: I'm running my threaded application, and now and then I get following error at exit. I'm using python 2.2 final, but I have had the same error with python 2.1. Unfortunately I cannot reproduce it. This bug has only occured when I've run the program under win2ksp2, tried to produce it under linux but without luck. My program is pure python application. I guess saving reference to _active_limbo_lock at Thread-class could solve the problem.. Traceback (most recent call last): File "C:\utils\PYTHON22\lib\threading.py", line 424, in __bootstrap self.__delete() File "C:\utils\PYTHON22\lib\threading.py", line 433, in __delete _active_limbo_lock.acquire() AttributeError: 'NoneType' object has no attribute 'acquire' ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 06:35 Message: Logged In: YES user_id=6380 Good. I saw the same thing in a program, also one using daemon threads. The daemon threads make this thing understandable. I'll think of a fix. ---------------------------------------------------------------------- Comment By: Simo Salminen (frangen) Date: 2001-12-27 14:21 Message: Logged In: YES user_id=291461 Yes, program is running a mainthread and two daemon threads. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 11:51 Message: Logged In: YES user_id=6380 Hm, this looks like it could happen when the treading module is deleted while there are still threads running. But that can only happen with daemon threads. Does your program have daemon threads? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497111&group_id=5470 From noreply@sourceforge.net Fri Dec 28 19:41:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 11:41:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-497410 ] Builtin min()/max() semantic changed Message-ID: Bugs item #497410, was opened at 2001-12-28 11:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497410&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Taylor (stu9480) Assigned to: Nobody/Anonymous (nobody) Summary: Builtin min()/max() semantic changed Initial Comment: In python2.0 min(None, x) returns x max(None, x) returns None In python.2.2 min(None, x) returns None. max(None, x) returns x. Bug is old code will break if min() receives a None argument - as may be the case in loop initialization. Before: Python 2.0 (#2, Oct 26 2000, 17:01:14) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> min(None,4) 4 Now: Python 2.2c1 (#2, Dec 16 2001, 19:12:17) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print min(None,4) None >>> ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497410&group_id=5470 From noreply@sourceforge.net Fri Dec 28 19:59:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 11:59:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-497126 ] dl module and flags Message-ID: Bugs item #497126, was opened at 2001-12-27 11:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497126&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Nobody/Anonymous (nobody) Summary: dl module and flags Initial Comment: With the introduction of sys.setdlopenflags, the dl module got some special usefulness, carrying the flags used in this function. On the other hand, the dl module is not available on every platform where dlopen is. Alpha, for example, is not able to import the dl module because sizeof(int) is not equal to sizeof(long), as the assertion in initdl() ensures. I can think about two obvious solutions: a) Move RTLD_* flags to some standard module (sys?) b) Make some of the functionality in dlmodule.c optional, instead of the whole module. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 11:59 Message: Logged In: YES user_id=21627 If you need dlfcn.h constants without having the dl module, you need to run h2py for dlfcn.h. Moving the constants to sys is not acceptable. OTOH, allowing to use dlmodule on all systems seems reasonable. I believe the problem is that dl.call uses a function type that has all arguments "long", and still allows to pass char* and int. So moving the test into dl_call might be appropriate. Would you like to prepare a patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497126&group_id=5470 From noreply@sourceforge.net Fri Dec 28 20:01:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 12:01:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-497410 ] Builtin min()/max() semantic changed Message-ID: Bugs item #497410, was opened at 2001-12-28 11:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497410&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Stuart Taylor (stu9480) >Assigned to: Guido van Rossum (gvanrossum) Summary: Builtin min()/max() semantic changed Initial Comment: In python2.0 min(None, x) returns x max(None, x) returns None In python.2.2 min(None, x) returns None. max(None, x) returns x. Bug is old code will break if min() receives a None argument - as may be the case in loop initialization. Before: Python 2.0 (#2, Oct 26 2000, 17:01:14) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> min(None,4) 4 Now: Python 2.2c1 (#2, Dec 16 2001, 19:12:17) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print min(None,4) None >>> ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 12:01 Message: Logged In: YES user_id=6380 This was changed in 2.1 already. The new behavior is better. Code that relies on the relative ordering of objects of different (non-numerical) types should be shot, anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497410&group_id=5470 From noreply@sourceforge.net Fri Dec 28 20:12:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 12:12:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-497410 ] Builtin min()/max() semantic changed Message-ID: Bugs item #497410, was opened at 2001-12-28 11:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497410&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Stuart Taylor (stu9480) >Assigned to: Nobody/Anonymous (nobody) Summary: Builtin min()/max() semantic changed Initial Comment: In python2.0 min(None, x) returns x max(None, x) returns None In python.2.2 min(None, x) returns None. max(None, x) returns x. Bug is old code will break if min() receives a None argument - as may be the case in loop initialization. Before: Python 2.0 (#2, Oct 26 2000, 17:01:14) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> min(None,4) 4 Now: Python 2.2c1 (#2, Dec 16 2001, 19:12:17) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print min(None,4) None >>> ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 12:12 Message: Logged In: YES user_id=21627 This is not a bug. Python never guaranteed any specific order of objects of different types; the documentation says # Objects of different types, except different numeric # types, never compare equal; such objects are ordered # consistently but arbitrarily (so that sorting a # heterogeneous array yields a consistent result). # Furthermore, some types (for example, file objects) # support only a degenerate notion of comparison where any # two objects of that type are unequal. Again, such objects # are ordered arbitrarily but consistently. It is not a bug if Python compares objects of different types differently between versions, it is not even a bug if it does so between different runs of the same Python version. In Python 2.2, the implementation sorts None to be smaller than any other object; that removes some of the arbitrariness (but relying on this is still not portable). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 12:01 Message: Logged In: YES user_id=6380 This was changed in 2.1 already. The new behavior is better. Code that relies on the relative ordering of objects of different (non-numerical) types should be shot, anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497410&group_id=5470 From noreply@sourceforge.net Fri Dec 28 20:35:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 12:35:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-497126 ] dl module and flags Message-ID: Bugs item #497126, was opened at 2001-12-27 11:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497126&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Nobody/Anonymous (nobody) Summary: dl module and flags Initial Comment: With the introduction of sys.setdlopenflags, the dl module got some special usefulness, carrying the flags used in this function. On the other hand, the dl module is not available on every platform where dlopen is. Alpha, for example, is not able to import the dl module because sizeof(int) is not equal to sizeof(long), as the assertion in initdl() ensures. I can think about two obvious solutions: a) Move RTLD_* flags to some standard module (sys?) b) Make some of the functionality in dlmodule.c optional, instead of the whole module. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-12-28 12:35 Message: Logged In: YES user_id=7887 Sure... I'll build a patch and let you know. Thanks! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 11:59 Message: Logged In: YES user_id=21627 If you need dlfcn.h constants without having the dl module, you need to run h2py for dlfcn.h. Moving the constants to sys is not acceptable. OTOH, allowing to use dlmodule on all systems seems reasonable. I believe the problem is that dl.call uses a function type that has all arguments "long", and still allows to pass char* and int. So moving the test into dl_call might be appropriate. Would you like to prepare a patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497126&group_id=5470 From noreply@sourceforge.net Fri Dec 28 21:10:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 13:10:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-496171 ] FD_CLOEXEC no longer available Message-ID: Bugs item #496171, was opened at 2001-12-22 13:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496171&group_id=5470 Category: Python Library Group: Python 2.2.1 candidate >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Per Cederqvist (ceder) Assigned to: Barry Warsaw (bwarsaw) Summary: FD_CLOEXEC no longer available Initial Comment: In at least Python 1.6 through 2.1, the FD_CLOEXEC constant was available as FCNTL.FD_CLOEXEC. Starting with Python 2.2, the constant isn't available from any module, as far as I (and grep) can tell. The fsh project (http://www.lysator.liu.se/fsh) needs access to the FD_CLOEXEC flag. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 13:10 Message: Logged In: YES user_id=21627 I've added this and other constants as fcntl.h 2.32 and 2.31.18.1 (release22-maint). ---------------------------------------------------------------------- Comment By: Per Cederqvist (ceder) Date: 2001-12-23 02:27 Message: Logged In: YES user_id=129207 It's been a hectic autumn. On december 21st, I finally got time to test the Python 2.2c1 beta. I found that there was a problem with fsh, but didn't have time to find out what the problem was. Hours later, the news reached me that Python 2.2 final was released. Bad timing, I guess. It turns out that FD_CLOEXEC is set to 1 on every platform in the known universe (including AIX), so I can work around the problem. My code won't look pretty, though: Use fcntl.FD_CLOEXEC, if available. Otherwise, use FCNTL.FD_CLOEXEC, if available, but make sure to turn off the warnings for importing FCNTL (if the warnings module is available). Otherwise, use 1. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-22 16:24 Message: Logged In: YES user_id=31435 Assigned to Barry because he's working this week . Digging thru the mass of old FCNTL.py files in the Lib/plat- xxx/ Attics, it looks to me like the current fcntlmodule is missing oodles of symbols that used to be available, some that were defined on most platforms (like FD_CLOEXEC), and many platform-unique. We should probably try the union of all of them in fcntlmodule.c. Per, sorry, looks like you'll have to wait for 2.2.1 (assuming a bugfix release manager volunteers to produce one). For 2.3, how about trying one of the beta releases before it's too late? Thousands of people downloaded the 2.2 betas, but I'm afraid nobody noticed the FD_CLOEXEC disappearance. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496171&group_id=5470 From noreply@sourceforge.net Fri Dec 28 21:29:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 13:29:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-497426 ] can't deepcopy recursive new objects Message-ID: Bugs item #497426, was opened at 2001-12-28 13:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497426&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: can't deepcopy recursive new objects Initial Comment: (This was reported on c.l.py by Oliver Hartman, using a more elaborate example.) Take this simple recursive data structure: | class Node(object): | pass | a = Node(); b = Node() | a.b = b; b.a = a | import copy | c = copy.deepcopy(a) This raises RuntimeError: maximum recursion depth exceeded ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497426&group_id=5470 From noreply@sourceforge.net Fri Dec 28 21:35:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 13:35:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-497426 ] can't deepcopy recursive new objects Message-ID: Bugs item #497426, was opened at 2001-12-28 13:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497426&group_id=5470 Category: Type/class unification >Group: Python 2.2.1 candidate Status: Open >Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: can't deepcopy recursive new objects Initial Comment: (This was reported on c.l.py by Oliver Hartman, using a more elaborate example.) Take this simple recursive data structure: | class Node(object): | pass | a = Node(); b = Node() | a.b = b; b.a = a | import copy | c = copy.deepcopy(a) This raises RuntimeError: maximum recursion depth exceeded ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 13:35 Message: Logged In: YES user_id=6380 Cause: The code in deepcopy() and _reconstruct() was naive -- they didn't pass the memo to each other. I've checked in a fix as copy.py rev. 1.23. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497426&group_id=5470 From noreply@sourceforge.net Fri Dec 28 21:54:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 13:54:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-497162 ] test_email assumes Unix uses NTP scale Message-ID: Bugs item #497162, was opened at 2001-12-27 13:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470 Category: Build Group: Python 2.2 Status: Open >Resolution: Wont Fix Priority: 5 Submitted By: Paul Jarc (prjsf) >Assigned to: Guido van Rossum (gvanrossum) Summary: test_email assumes Unix uses NTP scale Initial Comment: I got this test failure while building Python 2.2: test test_email failed -- Traceback (most recent call last): File "./Lib/test/test_email.py", line 935, in test_formatdate self.assertEqual(gdate, matchdate) File "/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py", line 286, in failUnlessEqual raise self.failureException, \ AssertionError: 'Fri, 09 Nov 2001 17:33:30 -0000' != 'Fri, 09 Nov 2001 17:33:52 -0000' This happens because the test assumes that the system clock is a count of non-leap seconds since the epoch. This is a common configuration, but it renders some clock values ambiguous, and complicates interval calculations. So my clock counts *all* seconds since the epoch. It would be nice if the test could handle both cases, by checking the broken-down values around a leap second, or by checking that the calculated string matches either of the two possibilities. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 13:54 Message: Logged In: YES user_id=6380 I think a lot of other software will fail too if you set your clock this way. What's the point? I don't want to argume too much about this, but I believe that this idea has been tried before and rejected. So I'm closing this as a won't fix. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470 From noreply@sourceforge.net Fri Dec 28 21:54:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 13:54:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-497162 ] test_email assumes Unix uses NTP scale Message-ID: Bugs item #497162, was opened at 2001-12-27 13:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470 Category: Build Group: Python 2.2 >Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Guido van Rossum (gvanrossum) Summary: test_email assumes Unix uses NTP scale Initial Comment: I got this test failure while building Python 2.2: test test_email failed -- Traceback (most recent call last): File "./Lib/test/test_email.py", line 935, in test_formatdate self.assertEqual(gdate, matchdate) File "/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py", line 286, in failUnlessEqual raise self.failureException, \ AssertionError: 'Fri, 09 Nov 2001 17:33:30 -0000' != 'Fri, 09 Nov 2001 17:33:52 -0000' This happens because the test assumes that the system clock is a count of non-leap seconds since the epoch. This is a common configuration, but it renders some clock values ambiguous, and complicates interval calculations. So my clock counts *all* seconds since the epoch. It would be nice if the test could handle both cases, by checking the broken-down values around a leap second, or by checking that the calculated string matches either of the two possibilities. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 13:54 Message: Logged In: YES user_id=6380 I think a lot of other software will fail too if you set your clock this way. What's the point? I don't want to argume too much about this, but I believe that this idea has been tried before and rejected. So I'm closing this as a won't fix. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470 From noreply@sourceforge.net Fri Dec 28 21:56:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 13:56:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-497160 ] test_commands assumes ls is in /bin Message-ID: Bugs item #497160, was opened at 2001-12-27 13:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497160&group_id=5470 Category: Build Group: Python 2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Paul Jarc (prjsf) >Assigned to: Guido van Rossum (gvanrossum) Summary: test_commands assumes ls is in /bin Initial Comment: I got this test failure while building Python 2.2: test test_commands failed -- Traceback (most recent call last): File "./Lib/test/test_commands.py", line 43, in test_getstatus self.assert_(re.match(pat, getstatus("/bin/ls"), re.VERBOSE)) File "/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py", line 262, in failUnless if not expr: raise self.failureException, msg AssertionError My ls happens to be somewhere other than /bin. It would be nice if the test used a different file, such as "/", ".", or even "./Lib/test/test_commands.py". ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 13:56 Message: Logged In: YES user_id=6380 I think you are going to get in a lot of trouble when /bin/ls doesn't exist. It's not worth fixing the test suite for this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497160&group_id=5470 From noreply@sourceforge.net Fri Dec 28 21:57:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 13:57:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-496240 ] __slots__ does not iterate over a string Message-ID: Bugs item #496240, was opened at 2001-12-22 23:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496240&group_id=5470 Category: Type/class unification Group: Python 2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Clarence Gardner (cgardner) Assigned to: Guido van Rossum (gvanrossum) Summary: __slots__ does not iterate over a string Initial Comment: According to Guido's writeup, the value given to __slots__ can be any iterable object. If you give it a string value, however, e.g. __slots__ = 'abc', instead of getting three valid attributes named 'a', 'b', and 'c', you get one named 'abc'. Priority: Low. No, even lower :) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 13:57 Message: Logged In: YES user_id=6380 It's a feature! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-22 23:17 Message: Logged In: YES user_id=31435 Heh. For a reason I can't guess, the implementation goes out of its way to special-case a bare string. However, Guido's writeup also says "the effect of using something that's not a list renders the meaning of your program undefined", and getting one attribute named 'abc' is the very definition of undefinedness . Assigned to Guido. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496240&group_id=5470 From noreply@sourceforge.net Fri Dec 28 22:08:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 14:08:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-497111 ] active_limbo_lock error at program exit Message-ID: Bugs item #497111, was opened at 2001-12-27 11:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497111&group_id=5470 Category: Threads >Group: Python 2.1.2 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Simo Salminen (frangen) Assigned to: Guido van Rossum (gvanrossum) Summary: active_limbo_lock error at program exit Initial Comment: I'm running my threaded application, and now and then I get following error at exit. I'm using python 2.2 final, but I have had the same error with python 2.1. Unfortunately I cannot reproduce it. This bug has only occured when I've run the program under win2ksp2, tried to produce it under linux but without luck. My program is pure python application. I guess saving reference to _active_limbo_lock at Thread-class could solve the problem.. Traceback (most recent call last): File "C:\utils\PYTHON22\lib\threading.py", line 424, in __bootstrap self.__delete() File "C:\utils\PYTHON22\lib\threading.py", line 433, in __delete _active_limbo_lock.acquire() AttributeError: 'NoneType' object has no attribute 'acquire' ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:07 Message: Logged In: YES user_id=6380 I've checked in a fix that simply ignores the error in this case: threading.py rev. 1.20. This is a 2.1.2 and 2.2.1 bugfix candidate! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 06:35 Message: Logged In: YES user_id=6380 Good. I saw the same thing in a program, also one using daemon threads. The daemon threads make this thing understandable. I'll think of a fix. ---------------------------------------------------------------------- Comment By: Simo Salminen (frangen) Date: 2001-12-27 14:21 Message: Logged In: YES user_id=291461 Yes, program is running a mainthread and two daemon threads. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 11:51 Message: Logged In: YES user_id=6380 Hm, this looks like it could happen when the treading module is deleted while there are still threads running. But that can only happen with daemon threads. Does your program have daemon threads? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497111&group_id=5470 From noreply@sourceforge.net Fri Dec 28 22:12:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 14:12:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-497162 ] test_email assumes Unix uses NTP scale Message-ID: Bugs item #497162, was opened at 2001-12-27 13:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470 Category: Build Group: Python 2.2 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Guido van Rossum (gvanrossum) Summary: test_email assumes Unix uses NTP scale Initial Comment: I got this test failure while building Python 2.2: test test_email failed -- Traceback (most recent call last): File "./Lib/test/test_email.py", line 935, in test_formatdate self.assertEqual(gdate, matchdate) File "/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py", line 286, in failUnlessEqual raise self.failureException, \ AssertionError: 'Fri, 09 Nov 2001 17:33:30 -0000' != 'Fri, 09 Nov 2001 17:33:52 -0000' This happens because the test assumes that the system clock is a count of non-leap seconds since the epoch. This is a common configuration, but it renders some clock values ambiguous, and complicates interval calculations. So my clock counts *all* seconds since the epoch. It would be nice if the test could handle both cases, by checking the broken-down values around a leap second, or by checking that the calculated string matches either of the two possibilities. ---------------------------------------------------------------------- >Comment By: Paul Jarc (prjsf) Date: 2001-12-28 14:12 Message: Logged In: YES user_id=412110 Most software will trust localtime() and gmtime() to interpret the clock. It's only a problem here because you're testing (and thus doubting) the Python bindings to those functions, and rather than check it against some other use of the C functions, you check it against a precomputed string, thus doubting the C functions. C's localtime and gmtime give correct results on my system, because I'm using a time zone designed for a clock that counts all seconds. Don't doubt the C functions; they aren't what you're trying to test. I already explained the point of keeping the clock this way (the TAI scale): it simplifies interval calculations (the difference t1-t0 actually tells you how many seconds passed between those times), and it makes no clock values ambiguous. The NTP scale (counting only non-leap seconds) is a horrible bit of backward compatibility. By depending on it, you punish those with well-configured systems to reward those with badly-configured systems. I mentioned an easy fix, which is to compare the computed string to each of the values seen above, and to pass the test if it matches either of them. This will still fail for people who use even more exotic setups, but I don't know of any such. Is there anything wrong with this? I think the benefit easily outweighs the cost. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 13:54 Message: Logged In: YES user_id=6380 I think a lot of other software will fail too if you set your clock this way. What's the point? I don't want to argume too much about this, but I believe that this idea has been tried before and rejected. So I'm closing this as a won't fix. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470 From noreply@sourceforge.net Fri Dec 28 22:19:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 14:19:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-495695 ] webbrowser.py: selection of browser Message-ID: Bugs item #495695, was opened at 2001-12-20 16:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495695&group_id=5470 Category: Python Library >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Guido van Rossum (gvanrossum) Summary: webbrowser.py: selection of browser Initial Comment: [please CC 121737@bugs.debian.org on replies; complete report can be found at http://bugs.debian.org/121737 ] webbrowser.py tries hard to select correct browsers and then wastes it The culprit is the last loop, registering everything possible. I'm not sure, but wasn't it supposed to run only in the environ["BROWSER"] case like this?: -----diff start----- --- /usr/lib/python2.1/webbrowser.py Sun Nov 11 18:23:54 2001 +++ /tmp/webbrowser.py Thu Nov 29 17:40:46 2001 @@ -305,11 +305,10 @@ # It's the user's responsibility to register handlers for any unknown # browser referenced by this value, before calling open(). _tryorder = os.environ["BROWSER"].split(":") - -for cmd in _tryorder: - if not _browsers.has_key(cmd.lower()): - if _iscommand(cmd.lower()): - register(cmd.lower(), None, GenericBrowser ("%s %%s" % cmd.lower())) + for cmd in _tryorder: + if not _browsers.has_key(cmd.lower()): + if _iscommand(cmd.lower()): + register(cmd.lower(), None, GenericBrowser("%s %%s" % cmd.lower())) _tryorder = filter(lambda x: _browsers.has_key(x.lower ()) or x.find("%s") > -1, _tryorder) -----diff end----- ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:19 Message: Logged In: YES user_id=6380 I don't think this is a bug. The report doesn't explain what undesirable behavior follows, and it looks like some platforms need the registration. Note that the registry is independent from the try order -- the registry may contain browsers that are not in the try order, but they won't be used unless you add them to the try order yourself. Closing this as Invalid. BTW, please encourage your users to interact with SF directly rather than forwarding bugs from Debian here. It is too painful. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495695&group_id=5470 From noreply@sourceforge.net Fri Dec 28 22:20:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 14:20:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-497160 ] test_commands assumes ls is in /bin Message-ID: Bugs item #497160, was opened at 2001-12-27 13:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497160&group_id=5470 Category: Build Group: Python 2.2 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Guido van Rossum (gvanrossum) Summary: test_commands assumes ls is in /bin Initial Comment: I got this test failure while building Python 2.2: test test_commands failed -- Traceback (most recent call last): File "./Lib/test/test_commands.py", line 43, in test_getstatus self.assert_(re.match(pat, getstatus("/bin/ls"), re.VERBOSE)) File "/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py", line 262, in failUnless if not expr: raise self.failureException, msg AssertionError My ls happens to be somewhere other than /bin. It would be nice if the test used a different file, such as "/", ".", or even "./Lib/test/test_commands.py". ---------------------------------------------------------------------- >Comment By: Paul Jarc (prjsf) Date: 2001-12-28 14:20 Message: Logged In: YES user_id=412110 The test suite already uses $PATH to *run* ls (as does other software, which is why I don't get into a lot of trouble). It merely uses /bin/ls as a filename to pass to ls so it can check the output. Any other filename will do just as well here, and the fix is extremely simple; what's the benefit of listing /bin/ls in particular that makes it worth risk breaking on systems like this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 13:56 Message: Logged In: YES user_id=6380 I think you are going to get in a lot of trouble when /bin/ls doesn't exist. It's not worth fixing the test suite for this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497160&group_id=5470 From noreply@sourceforge.net Fri Dec 28 22:28:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 14:28:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-495682 ] cannot handle http_proxy with user:pass@ Message-ID: Bugs item #495682, was opened at 2001-12-20 16:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495682&group_id=5470 Category: Python Library >Group: Feature Request Status: Open Resolution: None >Priority: 3 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: cannot handle http_proxy with user:pass@ Initial Comment: [please CC 120013@bugs.debian.org; the original report can be found at http://bugs.debian.org/120013 ] I tried to use an http_proxy variable which looks like: http://user:pass@proxy:3128/ with pass like \jkIoPd{ And I got this error : Traceback (most recent call last): File "/usr/bin/reportbug", line 1146, in ? main() File "/usr/bin/reportbug", line 628, in main http_proxy) File "/usr/lib/site-python/reportbug_ui_text.py", line 314, in handle_bts_query archived=archived) File "/usr/lib/site-python/debianbts.py", line 575, in get_reports result = get_cgi_reports(package, system, http_proxy, archived) File "/usr/lib/site-python/debianbts.py", line 494, in get_cgi_reports page = urlopen(url, proxies=proxies) File "/usr/lib/site-python/debianbts.py", line 382, in urlopen return _urlopener.open(url) File "/usr/lib/python2.1/urllib.py", line 176, in open return getattr(self, name)(url) File "/usr/lib/python2.1/urllib.py", line 277, in open_http h = httplib.HTTP(host) File "/usr/lib/python2.1/httplib.py", line 663, in __init__ self._conn = self._connection_class(host, port) File "/usr/lib/python2.1/httplib.py", line 342, in __init__ self._set_hostport(host, port) File "/usr/lib/python2.1/httplib.py", line 348, in _set_hostport port = int(host[i+1:]) ValueError: invalid literal for int(): \jkIoPd {@proxy:3128 But if I use http_proxy=http://10.0.0.1:3128/, it works well. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:28 Message: Logged In: YES user_id=6380 This is a feature request. If someone submits a patch, we'll happily apply it. It looks like urllib2 already supports this feature; you could try using that. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495682&group_id=5470 From noreply@sourceforge.net Fri Dec 28 22:28:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 14:28:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-493631 ] Problem with mpz module (gmp4) Message-ID: Bugs item #493631, was opened at 2001-12-15 04:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 Category: Extension Modules Group: Python 2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Damien Wyart (chlick) >Assigned to: Guido van Rossum (gvanrossum) Summary: Problem with mpz module (gmp4) Initial Comment: Trying to compile latest Python-2.2 (rc1), I found the following problem : I can't compile mpzmodule.c without modifying it. I use gcc-3.0.2 and gmp-4.0. I am not a gmp not a Python expert, but the problems seems to come mainly from lack of clear support of gmp-4 in mpzmodule.c. MPZ_GET_STR_BUG is obsolete now, and should not be used with gmp-4. #ifdef cases with MPZ_GET_STR_BUG defined uses obsolete struct field calls and leads to compilation problems. In fact, gmp-mparam.h should be included in all cases (not only when MPZ_GET_STR_BUG defined), and the whole file should be cleaned a bit to fully support gmp4. including longlong.h is not necessary. For now, there are two alternatives : gmp is gmp-2 and is really bogus, or gmp is not 2 and is bogus with respect to MPZ_GET_STR_BUG. The alternative "gmp-4" (not bogus) should be added. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:28 Message: Logged In: YES user_id=6380 Closing as a won't fix... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:02 Message: Logged In: YES user_id=6380 chlick, I think we're deciding to deprecate mpz, so you won't have to put any effort in it. Thanks! ---------------------------------------------------------------------- Comment By: Damien Wyart (chlick) Date: 2001-12-15 13:59 Message: Logged In: YES user_id=402822 So, Guido, could you tell what you think about all this ? Should I start digging into mpz or is it droppable right now ? Thanks in advance for any thoughts... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-15 11:19 Message: Logged In: YES user_id=31435 We should phase out mpz, because we can't support it (== nobody wants it enough to maintain it -- and don't look at me, unless it comes out of paid time and even then under protest ). There are (at least) two more-current GMP wrappers for Python: 1) http://gmpy.sourceforge.net/ 2) http://www.lemburg.com/files/python/mxNumber.html I'd recommend the latter for a casual user, as Marc-Andre is still actively developing his mxNumber package. ---------------------------------------------------------------------- Comment By: Damien Wyart (chlick) Date: 2001-12-15 09:45 Message: Logged In: YES user_id=402822 OK, I will have a look at it and also contact gmp main author. I will let you know about it asap... Thanks for your kindness and patience. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 09:26 Message: Logged In: YES user_id=6380 You're right, Python does not depend on GMP or MPZ for its long arithmetic. There's no mpz maintainer that I know of, so a patch would be much appreciated! ---------------------------------------------------------------------- Comment By: Damien Wyart (chlick) Date: 2001-12-15 08:48 Message: Logged In: YES user_id=402822 In fact, I was quite afraid by this bug at first (I'm not a Python expert, as already said), because I knew arbitrary length integers support had changed in 2.2, and thought the mp support module was directly used for bignum calculations! This is not the case, because you said this bug hasn't to be killed before official 2.2. I could provide a patch bypassing the MPZ_GET_STR thing for gmp-4, but as I do not know the situation about gmp versions between 2 and 4, this is not really safe. I have been able to compile fine, but this was more a hack than a clean patching, and not suitable for all versions of gmp. If there is an official mpz maintainer, I think it would be better he handles the job. If there is no maintainer at all, I can try to provide a fix, but will have to get in touch with gmp author and act calmly. So this could take a while. Thanks for your answers. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:26 Message: Logged In: YES user_id=6380 However there's gmpy.sf.net, which appears a more recent GMP wrapper for Python. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:18 Message: Logged In: YES user_id=6380 I apologize, pympz.sf.net doesn't exist (anymore?). I don't know what happened to it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 08:08 Message: Logged In: YES user_id=6380 I'm afraid we won't have time to fix the mpz module before the planned final release of 2.2 next week, although I'll see if we have someone on call who understands the issues. If you want to help by providing a patch, that would work too! According to some comments in setup.py, there's an improved mpz wrapper for Python here: pympz.sf.net. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493631&group_id=5470 From noreply@sourceforge.net Fri Dec 28 22:30:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 14:30:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-495401 ] Build troubles: --with-pymalloc Message-ID: Bugs item #495401, was opened at 2001-12-20 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None >Priority: 3 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Build troubles: --with-pymalloc Initial Comment: The build process segfaults with the current CVS version when using --with-pymalloc System is SuSE Linux 7.0 > uname -a Linux amazonas 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 GMT 2000 i686 unknown > gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse- linux/2.95.2/specs gcc version 2.95.2 19991024 (release) Attached is the complete build log. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:30 Message: Logged In: YES user_id=6380 My prediction: this is irreproducible. Lowering the priority accordingly. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-23 04:24 Message: Logged In: YES user_id=89016 Unfortunately no core file was generated. Can I somehow force core file generation? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:42 Message: Logged In: YES user_id=21627 Did that produce a core file? If so, can you attach a gdb backtrace as well? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 From noreply@sourceforge.net Fri Dec 28 22:37:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 14:37:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-494762 ] urllib2 on python2.2 ssl bug Message-ID: Bugs item #494762, was opened at 2001-12-18 13:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494762&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Marcus Felipe Pereira (makim) >Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 on python2.2 ssl bug Initial Comment: urllib2 on python 2.2 can´t get some SSL pages. It seams that it´s dependent of the server and the issuer of the key. The server showed below (https://wwws.task.com.br) uses IIS 5.0 and 128 bits key issued by Thawte. I´ve tested on python 2.1 and it's OK. ******** Code ************* import os,urllib2 os.environ["http_proxy"]='' f = urllib2.urlopen("https://wwws.task.com.br/i.htm") print f.read() ******** Output ************ Traceback (most recent call last): File "./httpstest", line 6, in ? f = urllib2.urlopen ("https://wwws.task.com.br/i.htm") File "/usr/lib/python2.2/urllib2.py", line 138, in urlopen return _opener.open(url, data) File "/usr/lib/python2.2/urllib2.py", line 322, in open '_open', req) File "/usr/lib/python2.2/urllib2.py", line 301, in _call_chain result = func(*args) File "/usr/lib/python2.2/urllib2.py", line 792, in https_open return self.do_open(httplib.HTTPS, req) File "/usr/lib/python2.2/urllib2.py", line 774, in do_open code, msg, hdrs = h.getreply() File "/usr/lib/python2.2/httplib.py", line 728, in getreply response = self._conn.getresponse() File "/usr/lib/python2.2/httplib.py", line 572, in getresponse response = self.response_class(self.sock) File "/usr/lib/python2.2/httplib.py", line 98, in __init__ self.fp = sock.makefile('rb', 0) File "/usr/lib/python2.2/httplib.py", line 607, in makefile buf = self.__ssl.read() socket.sslerror: (5, 'EOF occurred in violation of protocol') ***************************************** ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:37 Message: Logged In: YES user_id=6380 Hm, I do get the same outcome: Python 2.1.1 gives a valid result, while Python 2.2 gives socket.sslerror: (5, 'EOF occurred in violation of protocol'). There have been a few changes in the SSL support in 2.2. I'm assigning this to Jeremy Hylton, who made some of those changes thinking they were for the better. :-) ---------------------------------------------------------------------- Comment By: Marcus Felipe Pereira (makim) Date: 2001-12-19 14:40 Message: Logged In: YES user_id=405476 Strange is that the same code works in python 2.1 on the same machine. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-19 12:38 Message: Logged In: YES user_id=21627 If OpenSSL says the server violates the protocol, I'm pretty sure OpenSSL is right. So I fail to see the problem in Python. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494762&group_id=5470 From noreply@sourceforge.net Fri Dec 28 22:37:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 14:37:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-494762 ] urllib2 on python2.2 ssl bug Message-ID: Bugs item #494762, was opened at 2001-12-18 13:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494762&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Marcus Felipe Pereira (makim) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 on python2.2 ssl bug Initial Comment: urllib2 on python 2.2 can´t get some SSL pages. It seams that it´s dependent of the server and the issuer of the key. The server showed below (https://wwws.task.com.br) uses IIS 5.0 and 128 bits key issued by Thawte. I´ve tested on python 2.1 and it's OK. ******** Code ************* import os,urllib2 os.environ["http_proxy"]='' f = urllib2.urlopen("https://wwws.task.com.br/i.htm") print f.read() ******** Output ************ Traceback (most recent call last): File "./httpstest", line 6, in ? f = urllib2.urlopen ("https://wwws.task.com.br/i.htm") File "/usr/lib/python2.2/urllib2.py", line 138, in urlopen return _opener.open(url, data) File "/usr/lib/python2.2/urllib2.py", line 322, in open '_open', req) File "/usr/lib/python2.2/urllib2.py", line 301, in _call_chain result = func(*args) File "/usr/lib/python2.2/urllib2.py", line 792, in https_open return self.do_open(httplib.HTTPS, req) File "/usr/lib/python2.2/urllib2.py", line 774, in do_open code, msg, hdrs = h.getreply() File "/usr/lib/python2.2/httplib.py", line 728, in getreply response = self._conn.getresponse() File "/usr/lib/python2.2/httplib.py", line 572, in getresponse response = self.response_class(self.sock) File "/usr/lib/python2.2/httplib.py", line 98, in __init__ self.fp = sock.makefile('rb', 0) File "/usr/lib/python2.2/httplib.py", line 607, in makefile buf = self.__ssl.read() socket.sslerror: (5, 'EOF occurred in violation of protocol') ***************************************** ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:37 Message: Logged In: YES user_id=6380 BTW it's not specific to urllib2, regular old urllib has the same problem on 2.2 but not on 2.1.1. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:37 Message: Logged In: YES user_id=6380 Hm, I do get the same outcome: Python 2.1.1 gives a valid result, while Python 2.2 gives socket.sslerror: (5, 'EOF occurred in violation of protocol'). There have been a few changes in the SSL support in 2.2. I'm assigning this to Jeremy Hylton, who made some of those changes thinking they were for the better. :-) ---------------------------------------------------------------------- Comment By: Marcus Felipe Pereira (makim) Date: 2001-12-19 14:40 Message: Logged In: YES user_id=405476 Strange is that the same code works in python 2.1 on the same machine. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-19 12:38 Message: Logged In: YES user_id=21627 If OpenSSL says the server violates the protocol, I'm pretty sure OpenSSL is right. So I fail to see the problem in Python. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494762&group_id=5470 From noreply@sourceforge.net Fri Dec 28 22:42:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 14:42:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-497160 ] test_commands assumes ls is in /bin Message-ID: Bugs item #497160, was opened at 2001-12-27 13:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497160&group_id=5470 Category: Build Group: Python 2.2 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Guido van Rossum (gvanrossum) Summary: test_commands assumes ls is in /bin Initial Comment: I got this test failure while building Python 2.2: test test_commands failed -- Traceback (most recent call last): File "./Lib/test/test_commands.py", line 43, in test_getstatus self.assert_(re.match(pat, getstatus("/bin/ls"), re.VERBOSE)) File "/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py", line 262, in failUnless if not expr: raise self.failureException, msg AssertionError My ls happens to be somewhere other than /bin. It would be nice if the test used a different file, such as "/", ".", or even "./Lib/test/test_commands.py". ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:42 Message: Logged In: YES user_id=6380 If the patch is so simple, why don't you provide it? ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2001-12-28 14:20 Message: Logged In: YES user_id=412110 The test suite already uses $PATH to *run* ls (as does other software, which is why I don't get into a lot of trouble). It merely uses /bin/ls as a filename to pass to ls so it can check the output. Any other filename will do just as well here, and the fix is extremely simple; what's the benefit of listing /bin/ls in particular that makes it worth risk breaking on systems like this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 13:56 Message: Logged In: YES user_id=6380 I think you are going to get in a lot of trouble when /bin/ls doesn't exist. It's not worth fixing the test suite for this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497160&group_id=5470 From noreply@sourceforge.net Fri Dec 28 22:43:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 14:43:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-497162 ] test_email assumes Unix uses NTP scale Message-ID: Bugs item #497162, was opened at 2001-12-27 13:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470 Category: Build Group: Python 2.2 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Guido van Rossum (gvanrossum) Summary: test_email assumes Unix uses NTP scale Initial Comment: I got this test failure while building Python 2.2: test test_email failed -- Traceback (most recent call last): File "./Lib/test/test_email.py", line 935, in test_formatdate self.assertEqual(gdate, matchdate) File "/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py", line 286, in failUnlessEqual raise self.failureException, \ AssertionError: 'Fri, 09 Nov 2001 17:33:30 -0000' != 'Fri, 09 Nov 2001 17:33:52 -0000' This happens because the test assumes that the system clock is a count of non-leap seconds since the epoch. This is a common configuration, but it renders some clock values ambiguous, and complicates interval calculations. So my clock counts *all* seconds since the epoch. It would be nice if the test could handle both cases, by checking the broken-down values around a leap second, or by checking that the calculated string matches either of the two possibilities. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:43 Message: Logged In: YES user_id=6380 If you want this fixed, please submit a patch. ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2001-12-28 14:12 Message: Logged In: YES user_id=412110 Most software will trust localtime() and gmtime() to interpret the clock. It's only a problem here because you're testing (and thus doubting) the Python bindings to those functions, and rather than check it against some other use of the C functions, you check it against a precomputed string, thus doubting the C functions. C's localtime and gmtime give correct results on my system, because I'm using a time zone designed for a clock that counts all seconds. Don't doubt the C functions; they aren't what you're trying to test. I already explained the point of keeping the clock this way (the TAI scale): it simplifies interval calculations (the difference t1-t0 actually tells you how many seconds passed between those times), and it makes no clock values ambiguous. The NTP scale (counting only non-leap seconds) is a horrible bit of backward compatibility. By depending on it, you punish those with well-configured systems to reward those with badly-configured systems. I mentioned an easy fix, which is to compare the computed string to each of the values seen above, and to pass the test if it matches either of them. This will still fail for people who use even more exotic setups, but I don't know of any such. Is there anything wrong with this? I think the benefit easily outweighs the cost. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 13:54 Message: Logged In: YES user_id=6380 I think a lot of other software will fail too if you set your clock this way. What's the point? I don't want to argume too much about this, but I believe that this idea has been tried before and rejected. So I'm closing this as a won't fix. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470 From noreply@sourceforge.net Sat Dec 29 01:18:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 17:18:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-494762 ] urllib2 on python2.2 ssl bug Message-ID: Bugs item #494762, was opened at 2001-12-18 13:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494762&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Marcus Felipe Pereira (makim) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 on python2.2 ssl bug Initial Comment: urllib2 on python 2.2 can´t get some SSL pages. It seams that it´s dependent of the server and the issuer of the key. The server showed below (https://wwws.task.com.br) uses IIS 5.0 and 128 bits key issued by Thawte. I´ve tested on python 2.1 and it's OK. ******** Code ************* import os,urllib2 os.environ["http_proxy"]='' f = urllib2.urlopen("https://wwws.task.com.br/i.htm") print f.read() ******** Output ************ Traceback (most recent call last): File "./httpstest", line 6, in ? f = urllib2.urlopen ("https://wwws.task.com.br/i.htm") File "/usr/lib/python2.2/urllib2.py", line 138, in urlopen return _opener.open(url, data) File "/usr/lib/python2.2/urllib2.py", line 322, in open '_open', req) File "/usr/lib/python2.2/urllib2.py", line 301, in _call_chain result = func(*args) File "/usr/lib/python2.2/urllib2.py", line 792, in https_open return self.do_open(httplib.HTTPS, req) File "/usr/lib/python2.2/urllib2.py", line 774, in do_open code, msg, hdrs = h.getreply() File "/usr/lib/python2.2/httplib.py", line 728, in getreply response = self._conn.getresponse() File "/usr/lib/python2.2/httplib.py", line 572, in getresponse response = self.response_class(self.sock) File "/usr/lib/python2.2/httplib.py", line 98, in __init__ self.fp = sock.makefile('rb', 0) File "/usr/lib/python2.2/httplib.py", line 607, in makefile buf = self.__ssl.read() socket.sslerror: (5, 'EOF occurred in violation of protocol') ***************************************** ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 17:18 Message: Logged In: YES user_id=21627 The problem does not lie in the urllib module, and likely also not in the SSL support in the socket module. Please refer to the attached https.py. On a server that does an orderly SSL shutdown (e.g. sf.net), this raises socket.sslerror: (6, 'TLS/SSL connection has been closed') or socket.SSL_ERROR_ZERO_RETURN. On wwws.task.com.br, it prints HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Sat, 29 Dec 2001 00:50:32 GMT Content-Type: text/html Accept-Ranges: by tes Last-Modified: Tue, 18 Dec 2001 21:17:02 GMT ETag: "05be155988c11:85f" Content-Length: 80 HTTPS Test HTTPS Test Traceback (most recent call last): File "https.py", line 16, in ? buf = ssl.read() socket.sslerror: (5, 'EOF occurred in violation of protocol') So I still think that the bug is on the server side (Microsoft IIS, in this case), which does not perform proper connection shutdown, but just closes the connection. This problem went unnoticed in 2.1, since httplib.FakeSocket.makefile would read until any kind of exception occurred, then consider the exception as the end of the conversation. This was bug #458835; Jeremy fixed it in httplib.py 1.41. I don't think we should restore the 2.1 behaviour. In the specific case of IIS, the best thing would be to honor the Content-length, i.e. not try to read more than content-length bytes; that would require implementing a true file-like object, instead of re-using StringIO. The best work-around (for this case, and the general case of a server violating the SSL protocol) is to special-case socket.SSL_ERROR_SYSCALL in addition to SSL_ERROR_ZERO_RETURN, perhaps checking for the message ""EOF occurred in violation of protocol" (since this message is generated inside Python). In summary, I agree with Jeremy that these changes were for the better... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:37 Message: Logged In: YES user_id=6380 BTW it's not specific to urllib2, regular old urllib has the same problem on 2.2 but not on 2.1.1. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:37 Message: Logged In: YES user_id=6380 Hm, I do get the same outcome: Python 2.1.1 gives a valid result, while Python 2.2 gives socket.sslerror: (5, 'EOF occurred in violation of protocol'). There have been a few changes in the SSL support in 2.2. I'm assigning this to Jeremy Hylton, who made some of those changes thinking they were for the better. :-) ---------------------------------------------------------------------- Comment By: Marcus Felipe Pereira (makim) Date: 2001-12-19 14:40 Message: Logged In: YES user_id=405476 Strange is that the same code works in python 2.1 on the same machine. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-19 12:38 Message: Logged In: YES user_id=21627 If OpenSSL says the server violates the protocol, I'm pretty sure OpenSSL is right. So I fail to see the problem in Python. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494762&group_id=5470 From noreply@sourceforge.net Sat Dec 29 03:10:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 19:10:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-494762 ] urllib2 on python2.2 ssl bug Message-ID: Bugs item #494762, was opened at 2001-12-18 13:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494762&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Marcus Felipe Pereira (makim) >Assigned to: Guido van Rossum (gvanrossum) Summary: urllib2 on python2.2 ssl bug Initial Comment: urllib2 on python 2.2 can´t get some SSL pages. It seams that it´s dependent of the server and the issuer of the key. The server showed below (https://wwws.task.com.br) uses IIS 5.0 and 128 bits key issued by Thawte. I´ve tested on python 2.1 and it's OK. ******** Code ************* import os,urllib2 os.environ["http_proxy"]='' f = urllib2.urlopen("https://wwws.task.com.br/i.htm") print f.read() ******** Output ************ Traceback (most recent call last): File "./httpstest", line 6, in ? f = urllib2.urlopen ("https://wwws.task.com.br/i.htm") File "/usr/lib/python2.2/urllib2.py", line 138, in urlopen return _opener.open(url, data) File "/usr/lib/python2.2/urllib2.py", line 322, in open '_open', req) File "/usr/lib/python2.2/urllib2.py", line 301, in _call_chain result = func(*args) File "/usr/lib/python2.2/urllib2.py", line 792, in https_open return self.do_open(httplib.HTTPS, req) File "/usr/lib/python2.2/urllib2.py", line 774, in do_open code, msg, hdrs = h.getreply() File "/usr/lib/python2.2/httplib.py", line 728, in getreply response = self._conn.getresponse() File "/usr/lib/python2.2/httplib.py", line 572, in getresponse response = self.response_class(self.sock) File "/usr/lib/python2.2/httplib.py", line 98, in __init__ self.fp = sock.makefile('rb', 0) File "/usr/lib/python2.2/httplib.py", line 607, in makefile buf = self.__ssl.read() socket.sslerror: (5, 'EOF occurred in violation of protocol') ***************************************** ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 19:10 Message: Logged In: YES user_id=6380 OK, the I'm closing this as invalid. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 17:18 Message: Logged In: YES user_id=21627 The problem does not lie in the urllib module, and likely also not in the SSL support in the socket module. Please refer to the attached https.py. On a server that does an orderly SSL shutdown (e.g. sf.net), this raises socket.sslerror: (6, 'TLS/SSL connection has been closed') or socket.SSL_ERROR_ZERO_RETURN. On wwws.task.com.br, it prints HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Sat, 29 Dec 2001 00:50:32 GMT Content-Type: text/html Accept-Ranges: by tes Last-Modified: Tue, 18 Dec 2001 21:17:02 GMT ETag: "05be155988c11:85f" Content-Length: 80 HTTPS Test HTTPS Test Traceback (most recent call last): File "https.py", line 16, in ? buf = ssl.read() socket.sslerror: (5, 'EOF occurred in violation of protocol') So I still think that the bug is on the server side (Microsoft IIS, in this case), which does not perform proper connection shutdown, but just closes the connection. This problem went unnoticed in 2.1, since httplib.FakeSocket.makefile would read until any kind of exception occurred, then consider the exception as the end of the conversation. This was bug #458835; Jeremy fixed it in httplib.py 1.41. I don't think we should restore the 2.1 behaviour. In the specific case of IIS, the best thing would be to honor the Content-length, i.e. not try to read more than content-length bytes; that would require implementing a true file-like object, instead of re-using StringIO. The best work-around (for this case, and the general case of a server violating the SSL protocol) is to special-case socket.SSL_ERROR_SYSCALL in addition to SSL_ERROR_ZERO_RETURN, perhaps checking for the message ""EOF occurred in violation of protocol" (since this message is generated inside Python). In summary, I agree with Jeremy that these changes were for the better... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:37 Message: Logged In: YES user_id=6380 BTW it's not specific to urllib2, regular old urllib has the same problem on 2.2 but not on 2.1.1. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:37 Message: Logged In: YES user_id=6380 Hm, I do get the same outcome: Python 2.1.1 gives a valid result, while Python 2.2 gives socket.sslerror: (5, 'EOF occurred in violation of protocol'). There have been a few changes in the SSL support in 2.2. I'm assigning this to Jeremy Hylton, who made some of those changes thinking they were for the better. :-) ---------------------------------------------------------------------- Comment By: Marcus Felipe Pereira (makim) Date: 2001-12-19 14:40 Message: Logged In: YES user_id=405476 Strange is that the same code works in python 2.1 on the same machine. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-19 12:38 Message: Logged In: YES user_id=21627 If OpenSSL says the server violates the protocol, I'm pretty sure OpenSSL is right. So I fail to see the problem in Python. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494762&group_id=5470 From noreply@sourceforge.net Sat Dec 29 04:40:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 28 Dec 2001 20:40:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-497426 ] can't deepcopy recursive new objects Message-ID: Bugs item #497426, was opened at 2001-12-28 13:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497426&group_id=5470 Category: Type/class unification Group: Python 2.2.1 candidate >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: can't deepcopy recursive new objects Initial Comment: (This was reported on c.l.py by Oliver Hartman, using a more elaborate example.) Take this simple recursive data structure: | class Node(object): | pass | a = Node(); b = Node() | a.b = b; b.a = a | import copy | c = copy.deepcopy(a) This raises RuntimeError: maximum recursion depth exceeded ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-28 20:40 Message: Logged In: YES user_id=31435 I'm sure Guido meant to close this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 13:35 Message: Logged In: YES user_id=6380 Cause: The code in deepcopy() and _reconstruct() was naive -- they didn't pass the memo to each other. I've checked in a fix as copy.py rev. 1.23. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497426&group_id=5470 From noreply@sourceforge.net Sat Dec 29 09:19:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 01:19:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-496084 ] unicode, tkfiledialog.py Message-ID: Bugs item #496084, was opened at 2001-12-22 03:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496084&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Klaus-G. Meyer (kgm) Assigned to: M.-A. Lemburg (lemburg) Summary: unicode, tkfiledialog.py Initial Comment: The file tkfiledialog.py from python/lib/lib-tk contains some test code: if __name__ == "__main__": print "open", askopenfilename(filetypes=[("all filez", "*")]) print "saveas", asksaveasfilename() I tried it, but it won't work, if i select filenames with umlaut: C:\Programme\Python\Lib\lib-tk>python tkfiledialog.py open Traceback (most recent call last): File "tkfiledialog.py", line 128, in ? print "open", askopenfilename(filetypes=[("all filez", "*")]) UnicodeError: ASCII encoding error: ordinal not in range(128) The reason is (i think), that askopenfilename surprisingly returns unicode string instead of string. If functions return sometimes unicode strings, how should this be done? Is this a bug or a design problem? It would be nice, if the test code contains a working example. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 01:19 Message: Logged In: YES user_id=21627 It is by design that the dialog returns Unicode strings if the file name contains non-ASCII characters. It is easy to fix the example, just append .encode("utf-8") at the end of each print statement. Fixing it in the "right" way is more involved; you'll have to find out what encoding the terminal uses on which the string is printed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496084&group_id=5470 From noreply@sourceforge.net Sat Dec 29 09:23:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 01:23:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-495401 ] Build troubles: --with-pymalloc Message-ID: Bugs item #495401, was opened at 2001-12-20 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 3 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Build troubles: --with-pymalloc Initial Comment: The build process segfaults with the current CVS version when using --with-pymalloc System is SuSE Linux 7.0 > uname -a Linux amazonas 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 GMT 2000 i686 unknown > gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse- linux/2.95.2/specs gcc version 2.95.2 19991024 (release) Attached is the complete build log. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 01:23 Message: Logged In: YES user_id=21627 Atleast I cannot reproduce it, on SuSE 7.3. Can you retry this, building from a clean source tree (no .o files, no build directory)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:30 Message: Logged In: YES user_id=6380 My prediction: this is irreproducible. Lowering the priority accordingly. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-23 04:24 Message: Logged In: YES user_id=89016 Unfortunately no core file was generated. Can I somehow force core file generation? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:42 Message: Logged In: YES user_id=21627 Did that produce a core file? If so, can you attach a gdb backtrace as well? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 From noreply@sourceforge.net Sat Dec 29 10:53:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 02:53:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-495401 ] Build troubles: --with-pymalloc Message-ID: Bugs item #495401, was opened at 2001-12-20 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 3 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Build troubles: --with-pymalloc Initial Comment: The build process segfaults with the current CVS version when using --with-pymalloc System is SuSE Linux 7.0 > uname -a Linux amazonas 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 GMT 2000 i686 unknown > gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse- linux/2.95.2/specs gcc version 2.95.2 19991024 (release) Attached is the complete build log. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2001-12-29 02:53 Message: Logged In: YES user_id=89016 OK, I did a "make distclean" which removed .o files and the build directory and redid a "./configure --enable- unicode=ucs4 --with-pymalloc && make && make altinstall". The build process still crashes in the same spot: Compiling /usr/local/lib/python2.2/test/test_urlparse.py ... make: *** [libinstall] Segmentation fault I also retried with a fresh untarred Python-2.2.tgz. This shows the same behaviour. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 01:23 Message: Logged In: YES user_id=21627 Atleast I cannot reproduce it, on SuSE 7.3. Can you retry this, building from a clean source tree (no .o files, no build directory)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:30 Message: Logged In: YES user_id=6380 My prediction: this is irreproducible. Lowering the priority accordingly. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-23 04:24 Message: Logged In: YES user_id=89016 Unfortunately no core file was generated. Can I somehow force core file generation? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:42 Message: Logged In: YES user_id=21627 Did that produce a core file? If so, can you attach a gdb backtrace as well? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 From noreply@sourceforge.net Sat Dec 29 11:55:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 03:55:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-497160 ] test_commands assumes ls is in /bin Message-ID: Bugs item #497160, was opened at 2001-12-27 13:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497160&group_id=5470 Category: Build Group: Python 2.2 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Guido van Rossum (gvanrossum) Summary: test_commands assumes ls is in /bin Initial Comment: I got this test failure while building Python 2.2: test test_commands failed -- Traceback (most recent call last): File "./Lib/test/test_commands.py", line 43, in test_getstatus self.assert_(re.match(pat, getstatus("/bin/ls"), re.VERBOSE)) File "/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py", line 262, in failUnless if not expr: raise self.failureException, msg AssertionError My ls happens to be somewhere other than /bin. It would be nice if the test used a different file, such as "/", ".", or even "./Lib/test/test_commands.py". ---------------------------------------------------------------------- >Comment By: Sjoerd Mullender (sjoerd) Date: 2001-12-29 03:55 Message: Logged In: YES user_id=43607 This bug report is related to [ #460613 ] test_commands fails on SGI, which nobody ever seems to have noticed and which is still open. The problem there is that /bin/ls *does* exist, but is a symlink. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:42 Message: Logged In: YES user_id=6380 If the patch is so simple, why don't you provide it? ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2001-12-28 14:20 Message: Logged In: YES user_id=412110 The test suite already uses $PATH to *run* ls (as does other software, which is why I don't get into a lot of trouble). It merely uses /bin/ls as a filename to pass to ls so it can check the output. Any other filename will do just as well here, and the fix is extremely simple; what's the benefit of listing /bin/ls in particular that makes it worth risk breaking on systems like this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 13:56 Message: Logged In: YES user_id=6380 I think you are going to get in a lot of trouble when /bin/ls doesn't exist. It's not worth fixing the test suite for this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497160&group_id=5470 From noreply@sourceforge.net Sat Dec 29 11:57:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 03:57:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-496084 ] unicode, tkfiledialog.py Message-ID: Bugs item #496084, was opened at 2001-12-22 03:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496084&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Klaus-G. Meyer (kgm) >Assigned to: Martin v. Löwis (loewis) Summary: unicode, tkfiledialog.py Initial Comment: The file tkfiledialog.py from python/lib/lib-tk contains some test code: if __name__ == "__main__": print "open", askopenfilename(filetypes=[("all filez", "*")]) print "saveas", asksaveasfilename() I tried it, but it won't work, if i select filenames with umlaut: C:\Programme\Python\Lib\lib-tk>python tkfiledialog.py open Traceback (most recent call last): File "tkfiledialog.py", line 128, in ? print "open", askopenfilename(filetypes=[("all filez", "*")]) UnicodeError: ASCII encoding error: ordinal not in range(128) The reason is (i think), that askopenfilename surprisingly returns unicode string instead of string. If functions return sometimes unicode strings, how should this be done? Is this a bug or a design problem? It would be nice, if the test code contains a working example. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-29 03:57 Message: Logged In: YES user_id=38388 I don't know anything a about Tkinter, sorry. Printing Unicode is a huge can of worms -- I'm not sure whether it's worth the trouble to try to magically find out which encoding the terminal, GUI or whatever backend you use for stdout is being used. ASCII should work in most cases and that's what Python already tries... Martin, please patch the file or simply close the bug with "Won't fix". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 01:19 Message: Logged In: YES user_id=21627 It is by design that the dialog returns Unicode strings if the file name contains non-ASCII characters. It is easy to fix the example, just append .encode("utf-8") at the end of each print statement. Fixing it in the "right" way is more involved; you'll have to find out what encoding the terminal uses on which the string is printed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496084&group_id=5470 From noreply@sourceforge.net Sat Dec 29 14:54:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 06:54:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-497160 ] test_commands assumes ls is in /bin Message-ID: Bugs item #497160, was opened at 2001-12-27 13:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497160&group_id=5470 Category: Build Group: Python 2.2 >Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Guido van Rossum (gvanrossum) Summary: test_commands assumes ls is in /bin Initial Comment: I got this test failure while building Python 2.2: test test_commands failed -- Traceback (most recent call last): File "./Lib/test/test_commands.py", line 43, in test_getstatus self.assert_(re.match(pat, getstatus("/bin/ls"), re.VERBOSE)) File "/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py", line 262, in failUnless if not expr: raise self.failureException, msg AssertionError My ls happens to be somewhere other than /bin. It would be nice if the test used a different file, such as "/", ".", or even "./Lib/test/test_commands.py". ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-29 06:54 Message: Logged In: YES user_id=6380 OK, reopening. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2001-12-29 03:55 Message: Logged In: YES user_id=43607 This bug report is related to [ #460613 ] test_commands fails on SGI, which nobody ever seems to have noticed and which is still open. The problem there is that /bin/ls *does* exist, but is a symlink. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:42 Message: Logged In: YES user_id=6380 If the patch is so simple, why don't you provide it? ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2001-12-28 14:20 Message: Logged In: YES user_id=412110 The test suite already uses $PATH to *run* ls (as does other software, which is why I don't get into a lot of trouble). It merely uses /bin/ls as a filename to pass to ls so it can check the output. Any other filename will do just as well here, and the fix is extremely simple; what's the benefit of listing /bin/ls in particular that makes it worth risk breaking on systems like this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 13:56 Message: Logged In: YES user_id=6380 I think you are going to get in a lot of trouble when /bin/ls doesn't exist. It's not worth fixing the test suite for this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497160&group_id=5470 From noreply@sourceforge.net Sat Dec 29 14:55:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 06:55:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-497160 ] test_commands assumes ls is in /bin Message-ID: Bugs item #497160, was opened at 2001-12-27 13:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497160&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Paul Jarc (prjsf) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: test_commands assumes ls is in /bin Initial Comment: I got this test failure while building Python 2.2: test test_commands failed -- Traceback (most recent call last): File "./Lib/test/test_commands.py", line 43, in test_getstatus self.assert_(re.match(pat, getstatus("/bin/ls"), re.VERBOSE)) File "/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py", line 262, in failUnless if not expr: raise self.failureException, msg AssertionError My ls happens to be somewhere other than /bin. It would be nice if the test used a different file, such as "/", ".", or even "./Lib/test/test_commands.py". ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-29 06:55 Message: Logged In: YES user_id=6380 Assigned to Fred Drake, who wrote the test suite. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-29 06:54 Message: Logged In: YES user_id=6380 OK, reopening. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2001-12-29 03:55 Message: Logged In: YES user_id=43607 This bug report is related to [ #460613 ] test_commands fails on SGI, which nobody ever seems to have noticed and which is still open. The problem there is that /bin/ls *does* exist, but is a symlink. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:42 Message: Logged In: YES user_id=6380 If the patch is so simple, why don't you provide it? ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2001-12-28 14:20 Message: Logged In: YES user_id=412110 The test suite already uses $PATH to *run* ls (as does other software, which is why I don't get into a lot of trouble). It merely uses /bin/ls as a filename to pass to ls so it can check the output. Any other filename will do just as well here, and the fix is extremely simple; what's the benefit of listing /bin/ls in particular that makes it worth risk breaking on systems like this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 13:56 Message: Logged In: YES user_id=6380 I think you are going to get in a lot of trouble when /bin/ls doesn't exist. It's not worth fixing the test suite for this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497160&group_id=5470 From noreply@sourceforge.net Sat Dec 29 14:57:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 06:57:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-460613 ] test_commands fails on SGI Message-ID: Bugs item #460613, was opened at 2001-09-11 01:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=460613&group_id=5470 >Category: Build >Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: test_commands fails on SGI Initial Comment: test_commands fails on SGI. The problem is that the test expects /bin/ls to be a file, whereas on IRIX it's a symbolic link. For completeness, here is the output of running the test: + ./python ../Lib/test/regrtest.py test_commands.py test_commands test test_commands failed -- Traceback (most recent call last): File "../Lib/test/test_commands.py", line 43, in test_getstatus self.assert_(re.match(pat, getstatus("/bin/ls"), re.VERBOSE)) File "/ufs/sjoerd/src/Python/dist/src/Lib/unittest.py", line 256, in failUnless if not expr: raise self.failureException, msg AssertionError 1 test failed: test_commands ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-29 06:57 Message: Logged In: YES user_id=6380 Related to [ #497160 ] test_commands assumes ls is in /bin. Assigned to Fred Drake, who wrote the test suite. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=460613&group_id=5470 From noreply@sourceforge.net Sat Dec 29 14:52:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 06:52:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-495401 ] Build troubles: --with-pymalloc Message-ID: Bugs item #495401, was opened at 2001-12-20 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 Category: Build >Group: Platform-specific Status: Open Resolution: None Priority: 3 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Build troubles: --with-pymalloc Initial Comment: The build process segfaults with the current CVS version when using --with-pymalloc System is SuSE Linux 7.0 > uname -a Linux amazonas 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 GMT 2000 i686 unknown > gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse- linux/2.95.2/specs gcc version 2.95.2 19991024 (release) Attached is the complete build log. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-29 06:52 Message: Logged In: YES user_id=6380 Aha! The --enable-unicode=ucs4 is more suspicious than the --with-pymalloc. I had missed that info when this was first reported. Not that I'm any closer to solving it... :-( ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-29 02:53 Message: Logged In: YES user_id=89016 OK, I did a "make distclean" which removed .o files and the build directory and redid a "./configure --enable- unicode=ucs4 --with-pymalloc && make && make altinstall". The build process still crashes in the same spot: Compiling /usr/local/lib/python2.2/test/test_urlparse.py ... make: *** [libinstall] Segmentation fault I also retried with a fresh untarred Python-2.2.tgz. This shows the same behaviour. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 01:23 Message: Logged In: YES user_id=21627 Atleast I cannot reproduce it, on SuSE 7.3. Can you retry this, building from a clean source tree (no .o files, no build directory)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:30 Message: Logged In: YES user_id=6380 My prediction: this is irreproducible. Lowering the priority accordingly. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-23 04:24 Message: Logged In: YES user_id=89016 Unfortunately no core file was generated. Can I somehow force core file generation? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:42 Message: Logged In: YES user_id=21627 Did that produce a core file? If so, can you attach a gdb backtrace as well? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 From noreply@sourceforge.net Sat Dec 29 16:00:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 08:00:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-495401 ] Build troubles: --with-pymalloc Message-ID: Bugs item #495401, was opened at 2001-12-20 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 3 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Build troubles: --with-pymalloc Initial Comment: The build process segfaults with the current CVS version when using --with-pymalloc System is SuSE Linux 7.0 > uname -a Linux amazonas 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 GMT 2000 i686 unknown > gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse- linux/2.95.2/specs gcc version 2.95.2 19991024 (release) Attached is the complete build log. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 08:00 Message: Logged In: YES user_id=21627 Ok, I can reproduce it now; I did not 'make install' before. Here is a gdb back trace #0 _PyCore_ObjectMalloc (nbytes=33) at Objects/obmalloc.c:417 #1 0x805885c in PyString_FromString (str=0x816c6e8 "checkJoin") at Objects/stringobject.c:136 #2 0x805d772 in PyString_InternFromString (cp=0x816c6e8 "checkJoin") at Objects/stringobject.c:3640 #3 0x807c9c6 in com_addop_varname (c=0xbfffe87c, kind=0, name=0x816c6e8 "checkJoin") at Python/compile.c:939 #4 0x807de24 in com_atom (c=0xbfffe87c, n=0x816c258) at Python/compile.c:1478 #5 0x807f01c in com_power (c=0xbfffe87c, n=0x816c8b8) at Python/compile.c:1846 #6 0x807f545 in com_factor (c=0xbfffe87c, n=0x816c898) at Python/compile.c:1975 #7 0x807f56c in com_term (c=0xbfffe87c, n=0x816c878) at Python/compile.c:1985 #8 0x807f6bc in com_arith_expr (c=0xbfffe87c, n=0x816c858) at Python/compile.c:2020 #9 0x807f7dc in com_shift_expr (c=0xbfffe87c, n=0x816c838) at Python/compile.c:2046 #10 0x807f8fc in com_and_expr (c=0xbfffe87c, n=0x816c818) at Python/compile.c:2072 #11 0x807fa0c in com_xor_expr (c=0xbfffe87c, n=0x816c7f8) at Python/compile.c:2094 ... The access that crashes is *(block **)bp, since bp is 0x2. Not sure how that happens; I'll investigate (but would appreciate a clue). It seems that the pool chain got corrupted. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-29 06:52 Message: Logged In: YES user_id=6380 Aha! The --enable-unicode=ucs4 is more suspicious than the --with-pymalloc. I had missed that info when this was first reported. Not that I'm any closer to solving it... :-( ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-29 02:53 Message: Logged In: YES user_id=89016 OK, I did a "make distclean" which removed .o files and the build directory and redid a "./configure --enable- unicode=ucs4 --with-pymalloc && make && make altinstall". The build process still crashes in the same spot: Compiling /usr/local/lib/python2.2/test/test_urlparse.py ... make: *** [libinstall] Segmentation fault I also retried with a fresh untarred Python-2.2.tgz. This shows the same behaviour. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 01:23 Message: Logged In: YES user_id=21627 Atleast I cannot reproduce it, on SuSE 7.3. Can you retry this, building from a clean source tree (no .o files, no build directory)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:30 Message: Logged In: YES user_id=6380 My prediction: this is irreproducible. Lowering the priority accordingly. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-23 04:24 Message: Logged In: YES user_id=89016 Unfortunately no core file was generated. Can I somehow force core file generation? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:42 Message: Logged In: YES user_id=21627 Did that produce a core file? If so, can you attach a gdb backtrace as well? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 From noreply@sourceforge.net Sat Dec 29 18:43:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 10:43:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-495401 ] Build troubles: --with-pymalloc Message-ID: Bugs item #495401, was opened at 2001-12-20 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None >Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Build troubles: --with-pymalloc Initial Comment: The build process segfaults with the current CVS version when using --with-pymalloc System is SuSE Linux 7.0 > uname -a Linux amazonas 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 GMT 2000 i686 unknown > gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse- linux/2.95.2/specs gcc version 2.95.2 19991024 (release) Attached is the complete build log. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-29 10:43 Message: Logged In: YES user_id=31435 Ouch. Boosted priority back to 5, since Martin can reproduce it. Alas, where pymalloc got called *from* is almost certainly irrelevant -- we're seeing the end result of earlier corruption. Note that pymalloc is unusually sensitive to off-by-1 stores, since the chunks it hands out are contiguous (there's no hidden bookkeeping padding between them). Plausible: an earlier bogus store went beyond the end of its allocated chunk, overwriting the "next free block" pointer at the start of a previously free()'ed chunk of the same size (rounded up to a multiple of 8; 40 bytes in this case). At the time this blows up, bp is supposed to point to a previously free()'ed chunk of size 40 bytes (if there were none free()'ed and available, the earlier "pool != pool- >nextpool" guard should have failed). The first 4 bytes (let's simplify by assuming this is a 32-bit box) of the free chunks link the free chunks together, most recently free()'ed at the start of the (singly linked) list. So the code at this point is intent on returning bp, and "pool- >freeblock = *(block **)bp" is setting the 40-byte-chunk list header's idea of the *next* available 40-byte chunk. But bp is bogus. The value of bp is gotten out of the free list headers, the static array usedpools. This mechanism is horridly obscure, an array of pointer pairs that, in effect, capture just the first two members of the pool_header struct, once for each chunk size. It's possible that someone is overwriting usedpools[4 + 4]- >freeblock directly with 2, but that seems unlikely. More likely is that a free() operation linked a 40-byte chunk into the list headed at usedpools[4+4]->freeblock correctly, and a later bad store overwrote the first 4 bytes of the free()'ed block with 2. Then the "pool- >freeblock = *(block **)bp)" near the start of an unexceptional pymalloc would copy the 2 into the list header's freeblock without complaint. The error wouldn't show up until a subsequent malloc tried to use it. So that's one idea to get closer to the cause: add code to dereference pool->freeblock, before the "return (void *) bp". If that blows up earlier, then the first four bytes of bp were corrupted, and that gives you a useful data breakpoint address for the next run. If it doesn't blow up earlier, the corruption will be harder to find, but let's count on being lucky at first . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 08:00 Message: Logged In: YES user_id=21627 Ok, I can reproduce it now; I did not 'make install' before. Here is a gdb back trace #0 _PyCore_ObjectMalloc (nbytes=33) at Objects/obmalloc.c:417 #1 0x805885c in PyString_FromString (str=0x816c6e8 "checkJoin") at Objects/stringobject.c:136 #2 0x805d772 in PyString_InternFromString (cp=0x816c6e8 "checkJoin") at Objects/stringobject.c:3640 #3 0x807c9c6 in com_addop_varname (c=0xbfffe87c, kind=0, name=0x816c6e8 "checkJoin") at Python/compile.c:939 #4 0x807de24 in com_atom (c=0xbfffe87c, n=0x816c258) at Python/compile.c:1478 #5 0x807f01c in com_power (c=0xbfffe87c, n=0x816c8b8) at Python/compile.c:1846 #6 0x807f545 in com_factor (c=0xbfffe87c, n=0x816c898) at Python/compile.c:1975 #7 0x807f56c in com_term (c=0xbfffe87c, n=0x816c878) at Python/compile.c:1985 #8 0x807f6bc in com_arith_expr (c=0xbfffe87c, n=0x816c858) at Python/compile.c:2020 #9 0x807f7dc in com_shift_expr (c=0xbfffe87c, n=0x816c838) at Python/compile.c:2046 #10 0x807f8fc in com_and_expr (c=0xbfffe87c, n=0x816c818) at Python/compile.c:2072 #11 0x807fa0c in com_xor_expr (c=0xbfffe87c, n=0x816c7f8) at Python/compile.c:2094 ... The access that crashes is *(block **)bp, since bp is 0x2. Not sure how that happens; I'll investigate (but would appreciate a clue). It seems that the pool chain got corrupted. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-29 06:52 Message: Logged In: YES user_id=6380 Aha! The --enable-unicode=ucs4 is more suspicious than the --with-pymalloc. I had missed that info when this was first reported. Not that I'm any closer to solving it... :-( ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-29 02:53 Message: Logged In: YES user_id=89016 OK, I did a "make distclean" which removed .o files and the build directory and redid a "./configure --enable- unicode=ucs4 --with-pymalloc && make && make altinstall". The build process still crashes in the same spot: Compiling /usr/local/lib/python2.2/test/test_urlparse.py ... make: *** [libinstall] Segmentation fault I also retried with a fresh untarred Python-2.2.tgz. This shows the same behaviour. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 01:23 Message: Logged In: YES user_id=21627 Atleast I cannot reproduce it, on SuSE 7.3. Can you retry this, building from a clean source tree (no .o files, no build directory)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:30 Message: Logged In: YES user_id=6380 My prediction: this is irreproducible. Lowering the priority accordingly. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-23 04:24 Message: Logged In: YES user_id=89016 Unfortunately no core file was generated. Can I somehow force core file generation? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:42 Message: Logged In: YES user_id=21627 Did that produce a core file? If so, can you attach a gdb backtrace as well? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 From noreply@sourceforge.net Sat Dec 29 21:29:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 13:29:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-495401 ] Build troubles: --with-pymalloc Message-ID: Bugs item #495401, was opened at 2001-12-20 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Build troubles: --with-pymalloc Initial Comment: The build process segfaults with the current CVS version when using --with-pymalloc System is SuSE Linux 7.0 > uname -a Linux amazonas 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 GMT 2000 i686 unknown > gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse- linux/2.95.2/specs gcc version 2.95.2 19991024 (release) Attached is the complete build log. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-29 13:29 Message: Logged In: YES user_id=6656 I don't know if these are helpful observations or not, but anyway: (1) it doesn't core without the --enable-unicode=ucs4 option (2) if you just run "make altinstall" the library files are installed *and compiled* before the dynamically linked modules are built. Then we don't crash. (3) if you run "make altinstall" again, we crash. If you initially ran "make && make install", we crash. (4) when we crash, it's not long after the unicode tests are compiled. Are these real clues or just red herrings? I'm afraid I can't tell :( ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-29 10:43 Message: Logged In: YES user_id=31435 Ouch. Boosted priority back to 5, since Martin can reproduce it. Alas, where pymalloc got called *from* is almost certainly irrelevant -- we're seeing the end result of earlier corruption. Note that pymalloc is unusually sensitive to off-by-1 stores, since the chunks it hands out are contiguous (there's no hidden bookkeeping padding between them). Plausible: an earlier bogus store went beyond the end of its allocated chunk, overwriting the "next free block" pointer at the start of a previously free()'ed chunk of the same size (rounded up to a multiple of 8; 40 bytes in this case). At the time this blows up, bp is supposed to point to a previously free()'ed chunk of size 40 bytes (if there were none free()'ed and available, the earlier "pool != pool- >nextpool" guard should have failed). The first 4 bytes (let's simplify by assuming this is a 32-bit box) of the free chunks link the free chunks together, most recently free()'ed at the start of the (singly linked) list. So the code at this point is intent on returning bp, and "pool- >freeblock = *(block **)bp" is setting the 40-byte-chunk list header's idea of the *next* available 40-byte chunk. But bp is bogus. The value of bp is gotten out of the free list headers, the static array usedpools. This mechanism is horridly obscure, an array of pointer pairs that, in effect, capture just the first two members of the pool_header struct, once for each chunk size. It's possible that someone is overwriting usedpools[4 + 4]- >freeblock directly with 2, but that seems unlikely. More likely is that a free() operation linked a 40-byte chunk into the list headed at usedpools[4+4]->freeblock correctly, and a later bad store overwrote the first 4 bytes of the free()'ed block with 2. Then the "pool- >freeblock = *(block **)bp)" near the start of an unexceptional pymalloc would copy the 2 into the list header's freeblock without complaint. The error wouldn't show up until a subsequent malloc tried to use it. So that's one idea to get closer to the cause: add code to dereference pool->freeblock, before the "return (void *) bp". If that blows up earlier, then the first four bytes of bp were corrupted, and that gives you a useful data breakpoint address for the next run. If it doesn't blow up earlier, the corruption will be harder to find, but let's count on being lucky at first . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 08:00 Message: Logged In: YES user_id=21627 Ok, I can reproduce it now; I did not 'make install' before. Here is a gdb back trace #0 _PyCore_ObjectMalloc (nbytes=33) at Objects/obmalloc.c:417 #1 0x805885c in PyString_FromString (str=0x816c6e8 "checkJoin") at Objects/stringobject.c:136 #2 0x805d772 in PyString_InternFromString (cp=0x816c6e8 "checkJoin") at Objects/stringobject.c:3640 #3 0x807c9c6 in com_addop_varname (c=0xbfffe87c, kind=0, name=0x816c6e8 "checkJoin") at Python/compile.c:939 #4 0x807de24 in com_atom (c=0xbfffe87c, n=0x816c258) at Python/compile.c:1478 #5 0x807f01c in com_power (c=0xbfffe87c, n=0x816c8b8) at Python/compile.c:1846 #6 0x807f545 in com_factor (c=0xbfffe87c, n=0x816c898) at Python/compile.c:1975 #7 0x807f56c in com_term (c=0xbfffe87c, n=0x816c878) at Python/compile.c:1985 #8 0x807f6bc in com_arith_expr (c=0xbfffe87c, n=0x816c858) at Python/compile.c:2020 #9 0x807f7dc in com_shift_expr (c=0xbfffe87c, n=0x816c838) at Python/compile.c:2046 #10 0x807f8fc in com_and_expr (c=0xbfffe87c, n=0x816c818) at Python/compile.c:2072 #11 0x807fa0c in com_xor_expr (c=0xbfffe87c, n=0x816c7f8) at Python/compile.c:2094 ... The access that crashes is *(block **)bp, since bp is 0x2. Not sure how that happens; I'll investigate (but would appreciate a clue). It seems that the pool chain got corrupted. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-29 06:52 Message: Logged In: YES user_id=6380 Aha! The --enable-unicode=ucs4 is more suspicious than the --with-pymalloc. I had missed that info when this was first reported. Not that I'm any closer to solving it... :-( ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-29 02:53 Message: Logged In: YES user_id=89016 OK, I did a "make distclean" which removed .o files and the build directory and redid a "./configure --enable- unicode=ucs4 --with-pymalloc && make && make altinstall". The build process still crashes in the same spot: Compiling /usr/local/lib/python2.2/test/test_urlparse.py ... make: *** [libinstall] Segmentation fault I also retried with a fresh untarred Python-2.2.tgz. This shows the same behaviour. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 01:23 Message: Logged In: YES user_id=21627 Atleast I cannot reproduce it, on SuSE 7.3. Can you retry this, building from a clean source tree (no .o files, no build directory)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:30 Message: Logged In: YES user_id=6380 My prediction: this is irreproducible. Lowering the priority accordingly. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-23 04:24 Message: Logged In: YES user_id=89016 Unfortunately no core file was generated. Can I somehow force core file generation? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:42 Message: Logged In: YES user_id=21627 Did that produce a core file? If so, can you attach a gdb backtrace as well? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 From noreply@sourceforge.net Sat Dec 29 21:39:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 13:39:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-497695 ] ext.doc uses deprecated(?) build proc. Message-ID: Bugs item #497695, was opened at 2001-12-29 13:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497695&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: ext.doc uses deprecated(?) build proc. Initial Comment: python2.2 and up: The ext docs (http://www.python.org/doc/current/ext/building-on- unix.html) describe the deprecated(?) build procedure. At least Makefile.pre.in isn't installed in /config. Should the documentation updated to a description how to build with distutils? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497695&group_id=5470 From noreply@sourceforge.net Sat Dec 29 21:43:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 13:43:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-497697 ] building shared modules Message-ID: Bugs item #497697, was opened at 2001-12-29 13:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497697&group_id=5470 Category: None Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: building shared modules Initial Comment: [ report from http://bugs.debian.org/121759, submitted by Jochen Voss ] I tried to follow the description in /usr/share/doc/python2.1/html/ext/dnt-type- methods.html and the following manual sections in order to build a C extension module for Python 2.1. The mechanism does not work as advertised in the manual. To reproduce the problem try the following mkdir bugdir cd bugdir touch testx1module.c touch testx2module.c Now create a file named "Setup" with the following three lines in it: == Setup starts at next line ======================= *shared* testx1 testx1module.c testx2 testx2module.c -DFISCH=Barsch == Setup ends at previous line ===================== The third line will cause the problem later. I think it is valid syntax, because .../ext/module-defn-example.html states Several compiler options are supported: [...] -Dname=value Define a macro Now we try whether it works: type cp /usr/lib/python2.1/config/Makefile.pre.in . make -f Makefile.pre.in boot make For me this gives the output gcc -fPIC -g -O2 -Wall -Wstrict-prototypes - I/usr/include/python2.1 -I/usr/include/python2.1 - DHAVE_CONFIG_H -c ././testx1module.c - o ./testx1module.o gcc -shared ./testx1module.o - o ./testx1module.so The bug is the following: file "testx2module.so" is not created. And in fact "grep testx Makefile" emits SHAREDMODS= ./testx1module$(SO) testx2 testx2module.c -DFISCH=Barsch ./testx1module.o: $(srcdir)/./testx1module.c; $(CC) $(CCSHARED) $(CFLAGS) -c $(srcdir)/./testx1module.c -o ./testx1module.o ./testx1module$(SO): ./testx1module.o; $(LDSHARED) ./testx1module.o -o ./testx1module$(SO) The second line looks suspicious. I can work around this by putting the defines in a variable, but I think this should be fixed nevertheless. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497697&group_id=5470 From noreply@sourceforge.net Sat Dec 29 22:01:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 14:01:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-495401 ] Build troubles: --with-pymalloc Message-ID: Bugs item #495401, was opened at 2001-12-20 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Build troubles: --with-pymalloc Initial Comment: The build process segfaults with the current CVS version when using --with-pymalloc System is SuSE Linux 7.0 > uname -a Linux amazonas 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 GMT 2000 i686 unknown > gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse- linux/2.95.2/specs gcc version 2.95.2 19991024 (release) Attached is the complete build log. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-12-29 14:01 Message: Logged In: YES user_id=6656 Hmm. I now think that the stuff about extension modules is almost certainly a read herring. What I said about "make && make altinstall" vs "make altinstall" still seems to be true, though. If you compile with --with-pydebug, you crash right at the end of the second (-O) run of compileall.py -- I suspect this is something else, but it might not be. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-29 13:29 Message: Logged In: YES user_id=6656 I don't know if these are helpful observations or not, but anyway: (1) it doesn't core without the --enable-unicode=ucs4 option (2) if you just run "make altinstall" the library files are installed *and compiled* before the dynamically linked modules are built. Then we don't crash. (3) if you run "make altinstall" again, we crash. If you initially ran "make && make install", we crash. (4) when we crash, it's not long after the unicode tests are compiled. Are these real clues or just red herrings? I'm afraid I can't tell :( ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-29 10:43 Message: Logged In: YES user_id=31435 Ouch. Boosted priority back to 5, since Martin can reproduce it. Alas, where pymalloc got called *from* is almost certainly irrelevant -- we're seeing the end result of earlier corruption. Note that pymalloc is unusually sensitive to off-by-1 stores, since the chunks it hands out are contiguous (there's no hidden bookkeeping padding between them). Plausible: an earlier bogus store went beyond the end of its allocated chunk, overwriting the "next free block" pointer at the start of a previously free()'ed chunk of the same size (rounded up to a multiple of 8; 40 bytes in this case). At the time this blows up, bp is supposed to point to a previously free()'ed chunk of size 40 bytes (if there were none free()'ed and available, the earlier "pool != pool- >nextpool" guard should have failed). The first 4 bytes (let's simplify by assuming this is a 32-bit box) of the free chunks link the free chunks together, most recently free()'ed at the start of the (singly linked) list. So the code at this point is intent on returning bp, and "pool- >freeblock = *(block **)bp" is setting the 40-byte-chunk list header's idea of the *next* available 40-byte chunk. But bp is bogus. The value of bp is gotten out of the free list headers, the static array usedpools. This mechanism is horridly obscure, an array of pointer pairs that, in effect, capture just the first two members of the pool_header struct, once for each chunk size. It's possible that someone is overwriting usedpools[4 + 4]- >freeblock directly with 2, but that seems unlikely. More likely is that a free() operation linked a 40-byte chunk into the list headed at usedpools[4+4]->freeblock correctly, and a later bad store overwrote the first 4 bytes of the free()'ed block with 2. Then the "pool- >freeblock = *(block **)bp)" near the start of an unexceptional pymalloc would copy the 2 into the list header's freeblock without complaint. The error wouldn't show up until a subsequent malloc tried to use it. So that's one idea to get closer to the cause: add code to dereference pool->freeblock, before the "return (void *) bp". If that blows up earlier, then the first four bytes of bp were corrupted, and that gives you a useful data breakpoint address for the next run. If it doesn't blow up earlier, the corruption will be harder to find, but let's count on being lucky at first . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 08:00 Message: Logged In: YES user_id=21627 Ok, I can reproduce it now; I did not 'make install' before. Here is a gdb back trace #0 _PyCore_ObjectMalloc (nbytes=33) at Objects/obmalloc.c:417 #1 0x805885c in PyString_FromString (str=0x816c6e8 "checkJoin") at Objects/stringobject.c:136 #2 0x805d772 in PyString_InternFromString (cp=0x816c6e8 "checkJoin") at Objects/stringobject.c:3640 #3 0x807c9c6 in com_addop_varname (c=0xbfffe87c, kind=0, name=0x816c6e8 "checkJoin") at Python/compile.c:939 #4 0x807de24 in com_atom (c=0xbfffe87c, n=0x816c258) at Python/compile.c:1478 #5 0x807f01c in com_power (c=0xbfffe87c, n=0x816c8b8) at Python/compile.c:1846 #6 0x807f545 in com_factor (c=0xbfffe87c, n=0x816c898) at Python/compile.c:1975 #7 0x807f56c in com_term (c=0xbfffe87c, n=0x816c878) at Python/compile.c:1985 #8 0x807f6bc in com_arith_expr (c=0xbfffe87c, n=0x816c858) at Python/compile.c:2020 #9 0x807f7dc in com_shift_expr (c=0xbfffe87c, n=0x816c838) at Python/compile.c:2046 #10 0x807f8fc in com_and_expr (c=0xbfffe87c, n=0x816c818) at Python/compile.c:2072 #11 0x807fa0c in com_xor_expr (c=0xbfffe87c, n=0x816c7f8) at Python/compile.c:2094 ... The access that crashes is *(block **)bp, since bp is 0x2. Not sure how that happens; I'll investigate (but would appreciate a clue). It seems that the pool chain got corrupted. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-29 06:52 Message: Logged In: YES user_id=6380 Aha! The --enable-unicode=ucs4 is more suspicious than the --with-pymalloc. I had missed that info when this was first reported. Not that I'm any closer to solving it... :-( ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-29 02:53 Message: Logged In: YES user_id=89016 OK, I did a "make distclean" which removed .o files and the build directory and redid a "./configure --enable- unicode=ucs4 --with-pymalloc && make && make altinstall". The build process still crashes in the same spot: Compiling /usr/local/lib/python2.2/test/test_urlparse.py ... make: *** [libinstall] Segmentation fault I also retried with a fresh untarred Python-2.2.tgz. This shows the same behaviour. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 01:23 Message: Logged In: YES user_id=21627 Atleast I cannot reproduce it, on SuSE 7.3. Can you retry this, building from a clean source tree (no .o files, no build directory)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:30 Message: Logged In: YES user_id=6380 My prediction: this is irreproducible. Lowering the priority accordingly. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-23 04:24 Message: Logged In: YES user_id=89016 Unfortunately no core file was generated. Can I somehow force core file generation? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:42 Message: Logged In: YES user_id=21627 Did that produce a core file? If so, can you attach a gdb backtrace as well? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 From noreply@sourceforge.net Sat Dec 29 22:23:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 14:23:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-497126 ] dl module and flags Message-ID: Bugs item #497126, was opened at 2001-12-27 11:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497126&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Nobody/Anonymous (nobody) Summary: dl module and flags Initial Comment: With the introduction of sys.setdlopenflags, the dl module got some special usefulness, carrying the flags used in this function. On the other hand, the dl module is not available on every platform where dlopen is. Alpha, for example, is not able to import the dl module because sizeof(int) is not equal to sizeof(long), as the assertion in initdl() ensures. I can think about two obvious solutions: a) Move RTLD_* flags to some standard module (sys?) b) Make some of the functionality in dlmodule.c optional, instead of the whole module. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-12-29 14:23 Message: Logged In: YES user_id=7887 It's ready!! I've attached it to this bug. Please, let me know if any change is needed. Thanks! ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-12-28 12:35 Message: Logged In: YES user_id=7887 Sure... I'll build a patch and let you know. Thanks! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 11:59 Message: Logged In: YES user_id=21627 If you need dlfcn.h constants without having the dl module, you need to run h2py for dlfcn.h. Moving the constants to sys is not acceptable. OTOH, allowing to use dlmodule on all systems seems reasonable. I believe the problem is that dl.call uses a function type that has all arguments "long", and still allows to pass char* and int. So moving the test into dl_call might be appropriate. Would you like to prepare a patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497126&group_id=5470 From noreply@sourceforge.net Sat Dec 29 23:13:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 15:13:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-495401 ] Build troubles: --with-pymalloc Message-ID: Bugs item #495401, was opened at 2001-12-20 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Build troubles: --with-pymalloc Initial Comment: The build process segfaults with the current CVS version when using --with-pymalloc System is SuSE Linux 7.0 > uname -a Linux amazonas 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 GMT 2000 i686 unknown > gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse- linux/2.95.2/specs gcc version 2.95.2 19991024 (release) Attached is the complete build log. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 15:13 Message: Logged In: YES user_id=21627 It's a Heisenbug. I found that even slightest modifications to the Python source make it come and go, or appear at different places. On my system, the crashes normally occur in the first run (.pyc). So I don't think the order of make invocations is the source of the problem. It's likely as Tim says: somebody overwrites memory somewhere. Unfortunately, even though I can reproduce crashes for the same pool, for some reason, my gdb memory watches don't trigger. Tim's approach of checking whether a the value came from following the free list did not help, either: the bug disappeared under the change. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-29 14:01 Message: Logged In: YES user_id=6656 Hmm. I now think that the stuff about extension modules is almost certainly a read herring. What I said about "make && make altinstall" vs "make altinstall" still seems to be true, though. If you compile with --with-pydebug, you crash right at the end of the second (-O) run of compileall.py -- I suspect this is something else, but it might not be. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-29 13:29 Message: Logged In: YES user_id=6656 I don't know if these are helpful observations or not, but anyway: (1) it doesn't core without the --enable-unicode=ucs4 option (2) if you just run "make altinstall" the library files are installed *and compiled* before the dynamically linked modules are built. Then we don't crash. (3) if you run "make altinstall" again, we crash. If you initially ran "make && make install", we crash. (4) when we crash, it's not long after the unicode tests are compiled. Are these real clues or just red herrings? I'm afraid I can't tell :( ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-29 10:43 Message: Logged In: YES user_id=31435 Ouch. Boosted priority back to 5, since Martin can reproduce it. Alas, where pymalloc got called *from* is almost certainly irrelevant -- we're seeing the end result of earlier corruption. Note that pymalloc is unusually sensitive to off-by-1 stores, since the chunks it hands out are contiguous (there's no hidden bookkeeping padding between them). Plausible: an earlier bogus store went beyond the end of its allocated chunk, overwriting the "next free block" pointer at the start of a previously free()'ed chunk of the same size (rounded up to a multiple of 8; 40 bytes in this case). At the time this blows up, bp is supposed to point to a previously free()'ed chunk of size 40 bytes (if there were none free()'ed and available, the earlier "pool != pool- >nextpool" guard should have failed). The first 4 bytes (let's simplify by assuming this is a 32-bit box) of the free chunks link the free chunks together, most recently free()'ed at the start of the (singly linked) list. So the code at this point is intent on returning bp, and "pool- >freeblock = *(block **)bp" is setting the 40-byte-chunk list header's idea of the *next* available 40-byte chunk. But bp is bogus. The value of bp is gotten out of the free list headers, the static array usedpools. This mechanism is horridly obscure, an array of pointer pairs that, in effect, capture just the first two members of the pool_header struct, once for each chunk size. It's possible that someone is overwriting usedpools[4 + 4]- >freeblock directly with 2, but that seems unlikely. More likely is that a free() operation linked a 40-byte chunk into the list headed at usedpools[4+4]->freeblock correctly, and a later bad store overwrote the first 4 bytes of the free()'ed block with 2. Then the "pool- >freeblock = *(block **)bp)" near the start of an unexceptional pymalloc would copy the 2 into the list header's freeblock without complaint. The error wouldn't show up until a subsequent malloc tried to use it. So that's one idea to get closer to the cause: add code to dereference pool->freeblock, before the "return (void *) bp". If that blows up earlier, then the first four bytes of bp were corrupted, and that gives you a useful data breakpoint address for the next run. If it doesn't blow up earlier, the corruption will be harder to find, but let's count on being lucky at first . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 08:00 Message: Logged In: YES user_id=21627 Ok, I can reproduce it now; I did not 'make install' before. Here is a gdb back trace #0 _PyCore_ObjectMalloc (nbytes=33) at Objects/obmalloc.c:417 #1 0x805885c in PyString_FromString (str=0x816c6e8 "checkJoin") at Objects/stringobject.c:136 #2 0x805d772 in PyString_InternFromString (cp=0x816c6e8 "checkJoin") at Objects/stringobject.c:3640 #3 0x807c9c6 in com_addop_varname (c=0xbfffe87c, kind=0, name=0x816c6e8 "checkJoin") at Python/compile.c:939 #4 0x807de24 in com_atom (c=0xbfffe87c, n=0x816c258) at Python/compile.c:1478 #5 0x807f01c in com_power (c=0xbfffe87c, n=0x816c8b8) at Python/compile.c:1846 #6 0x807f545 in com_factor (c=0xbfffe87c, n=0x816c898) at Python/compile.c:1975 #7 0x807f56c in com_term (c=0xbfffe87c, n=0x816c878) at Python/compile.c:1985 #8 0x807f6bc in com_arith_expr (c=0xbfffe87c, n=0x816c858) at Python/compile.c:2020 #9 0x807f7dc in com_shift_expr (c=0xbfffe87c, n=0x816c838) at Python/compile.c:2046 #10 0x807f8fc in com_and_expr (c=0xbfffe87c, n=0x816c818) at Python/compile.c:2072 #11 0x807fa0c in com_xor_expr (c=0xbfffe87c, n=0x816c7f8) at Python/compile.c:2094 ... The access that crashes is *(block **)bp, since bp is 0x2. Not sure how that happens; I'll investigate (but would appreciate a clue). It seems that the pool chain got corrupted. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-29 06:52 Message: Logged In: YES user_id=6380 Aha! The --enable-unicode=ucs4 is more suspicious than the --with-pymalloc. I had missed that info when this was first reported. Not that I'm any closer to solving it... :-( ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-29 02:53 Message: Logged In: YES user_id=89016 OK, I did a "make distclean" which removed .o files and the build directory and redid a "./configure --enable- unicode=ucs4 --with-pymalloc && make && make altinstall". The build process still crashes in the same spot: Compiling /usr/local/lib/python2.2/test/test_urlparse.py ... make: *** [libinstall] Segmentation fault I also retried with a fresh untarred Python-2.2.tgz. This shows the same behaviour. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 01:23 Message: Logged In: YES user_id=21627 Atleast I cannot reproduce it, on SuSE 7.3. Can you retry this, building from a clean source tree (no .o files, no build directory)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:30 Message: Logged In: YES user_id=6380 My prediction: this is irreproducible. Lowering the priority accordingly. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-23 04:24 Message: Logged In: YES user_id=89016 Unfortunately no core file was generated. Can I somehow force core file generation? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:42 Message: Logged In: YES user_id=21627 Did that produce a core file? If so, can you attach a gdb backtrace as well? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 From noreply@sourceforge.net Sat Dec 29 23:21:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 15:21:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-497697 ] building shared modules Message-ID: Bugs item #497697, was opened at 2001-12-29 13:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497697&group_id=5470 >Category: Documentation Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: building shared modules Initial Comment: [ report from http://bugs.debian.org/121759, submitted by Jochen Voss ] I tried to follow the description in /usr/share/doc/python2.1/html/ext/dnt-type- methods.html and the following manual sections in order to build a C extension module for Python 2.1. The mechanism does not work as advertised in the manual. To reproduce the problem try the following mkdir bugdir cd bugdir touch testx1module.c touch testx2module.c Now create a file named "Setup" with the following three lines in it: == Setup starts at next line ======================= *shared* testx1 testx1module.c testx2 testx2module.c -DFISCH=Barsch == Setup ends at previous line ===================== The third line will cause the problem later. I think it is valid syntax, because .../ext/module-defn-example.html states Several compiler options are supported: [...] -Dname=value Define a macro Now we try whether it works: type cp /usr/lib/python2.1/config/Makefile.pre.in . make -f Makefile.pre.in boot make For me this gives the output gcc -fPIC -g -O2 -Wall -Wstrict-prototypes - I/usr/include/python2.1 -I/usr/include/python2.1 - DHAVE_CONFIG_H -c ././testx1module.c - o ./testx1module.o gcc -shared ./testx1module.o - o ./testx1module.so The bug is the following: file "testx2module.so" is not created. And in fact "grep testx Makefile" emits SHAREDMODS= ./testx1module$(SO) testx2 testx2module.c -DFISCH=Barsch ./testx1module.o: $(srcdir)/./testx1module.c; $(CC) $(CCSHARED) $(CFLAGS) -c $(srcdir)/./testx1module.c -o ./testx1module.o ./testx1module$(SO): ./testx1module.o; $(LDSHARED) ./testx1module.o -o ./testx1module$(SO) The second line looks suspicious. I can work around this by putting the defines in a variable, but I think this should be fixed nevertheless. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 15:21 Message: Logged In: YES user_id=21627 It's a documentation bug. The Setup.in method of building extensions is not supported anymore; please use distutils. If you can provide patches to bring Makefile.pre.in into a state so that it works for extensions again, such a patch would be incorporated (unless it breaks other things); we will not actively look for a solution. I assume that the specific section of the documentation you've been looking at is the same as http://www.python.org/doc/current/ext/building-on-unix.html (i.e. section 3, not section 2). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497697&group_id=5470 From noreply@sourceforge.net Sat Dec 29 23:24:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 15:24:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-497695 ] ext.doc uses deprecated(?) build proc. Message-ID: Bugs item #497695, was opened at 2001-12-29 13:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497695&group_id=5470 >Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: ext.doc uses deprecated(?) build proc. Initial Comment: python2.2 and up: The ext docs (http://www.python.org/doc/current/ext/building-on- unix.html) describe the deprecated(?) build procedure. At least Makefile.pre.in isn't installed in /config. Should the documentation updated to a description how to build with distutils? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 15:24 Message: Logged In: YES user_id=21627 This is a bug, indeed, see my comments to 497697. Unless somebody volunteers to write a patch for Makefile.pre.in, I recommend to close 497697 as a duplicate of this report. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497695&group_id=5470 From noreply@sourceforge.net Sat Dec 29 23:28:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 15:28:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-497126 ] dl module and flags Message-ID: Bugs item #497126, was opened at 2001-12-27 11:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497126&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Nobody/Anonymous (nobody) Summary: dl module and flags Initial Comment: With the introduction of sys.setdlopenflags, the dl module got some special usefulness, carrying the flags used in this function. On the other hand, the dl module is not available on every platform where dlopen is. Alpha, for example, is not able to import the dl module because sizeof(int) is not equal to sizeof(long), as the assertion in initdl() ensures. I can think about two obvious solutions: a) Move RTLD_* flags to some standard module (sys?) b) Make some of the functionality in dlmodule.c optional, instead of the whole module. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 15:28 Message: Logged In: YES user_id=21627 Looks fine; I'll apply it shortly. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-12-29 14:23 Message: Logged In: YES user_id=7887 It's ready!! I've attached it to this bug. Please, let me know if any change is needed. Thanks! ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-12-28 12:35 Message: Logged In: YES user_id=7887 Sure... I'll build a patch and let you know. Thanks! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 11:59 Message: Logged In: YES user_id=21627 If you need dlfcn.h constants without having the dl module, you need to run h2py for dlfcn.h. Moving the constants to sys is not acceptable. OTOH, allowing to use dlmodule on all systems seems reasonable. I believe the problem is that dl.call uses a function type that has all arguments "long", and still allows to pass char* and int. So moving the test into dl_call might be appropriate. Would you like to prepare a patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497126&group_id=5470 From noreply@sourceforge.net Sat Dec 29 23:28:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 15:28:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-497126 ] dl module and flags Message-ID: Bugs item #497126, was opened at 2001-12-27 11:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497126&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) >Assigned to: Martin v. Löwis (loewis) Summary: dl module and flags Initial Comment: With the introduction of sys.setdlopenflags, the dl module got some special usefulness, carrying the flags used in this function. On the other hand, the dl module is not available on every platform where dlopen is. Alpha, for example, is not able to import the dl module because sizeof(int) is not equal to sizeof(long), as the assertion in initdl() ensures. I can think about two obvious solutions: a) Move RTLD_* flags to some standard module (sys?) b) Make some of the functionality in dlmodule.c optional, instead of the whole module. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 15:28 Message: Logged In: YES user_id=21627 Looks fine; I'll apply it shortly. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-12-29 14:23 Message: Logged In: YES user_id=7887 It's ready!! I've attached it to this bug. Please, let me know if any change is needed. Thanks! ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-12-28 12:35 Message: Logged In: YES user_id=7887 Sure... I'll build a patch and let you know. Thanks! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 11:59 Message: Logged In: YES user_id=21627 If you need dlfcn.h constants without having the dl module, you need to run h2py for dlfcn.h. Moving the constants to sys is not acceptable. OTOH, allowing to use dlmodule on all systems seems reasonable. I believe the problem is that dl.call uses a function type that has all arguments "long", and still allows to pass char* and int. So moving the test into dl_call might be appropriate. Would you like to prepare a patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497126&group_id=5470 From noreply@sourceforge.net Sun Dec 30 01:44:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 17:44:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-495401 ] Build troubles: --with-pymalloc Message-ID: Bugs item #495401, was opened at 2001-12-20 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Martin v. Löwis (loewis) Summary: Build troubles: --with-pymalloc Initial Comment: The build process segfaults with the current CVS version when using --with-pymalloc System is SuSE Linux 7.0 > uname -a Linux amazonas 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 GMT 2000 i686 unknown > gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse- linux/2.95.2/specs gcc version 2.95.2 19991024 (release) Attached is the complete build log. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 17:44 Message: Logged In: YES user_id=21627 I've found one source of troubles, see the attached unicode.diff. Guido's intuition was right; it was an UCS-4 problem: EncodeUTF8 would over-allocate 3*size bytes, but can actually write 4*size in the worst case, which occurs in test_unicode. I'll leave the patch for review and experiments; it fixes the problem for me. The existing adjustment for surrogates is pointless, IMO: for the surrogate pair, it will allocate 6 bytes UTF-8 in advance, which is more than actually needed. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 15:13 Message: Logged In: YES user_id=21627 It's a Heisenbug. I found that even slightest modifications to the Python source make it come and go, or appear at different places. On my system, the crashes normally occur in the first run (.pyc). So I don't think the order of make invocations is the source of the problem. It's likely as Tim says: somebody overwrites memory somewhere. Unfortunately, even though I can reproduce crashes for the same pool, for some reason, my gdb memory watches don't trigger. Tim's approach of checking whether a the value came from following the free list did not help, either: the bug disappeared under the change. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-29 14:01 Message: Logged In: YES user_id=6656 Hmm. I now think that the stuff about extension modules is almost certainly a read herring. What I said about "make && make altinstall" vs "make altinstall" still seems to be true, though. If you compile with --with-pydebug, you crash right at the end of the second (-O) run of compileall.py -- I suspect this is something else, but it might not be. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-29 13:29 Message: Logged In: YES user_id=6656 I don't know if these are helpful observations or not, but anyway: (1) it doesn't core without the --enable-unicode=ucs4 option (2) if you just run "make altinstall" the library files are installed *and compiled* before the dynamically linked modules are built. Then we don't crash. (3) if you run "make altinstall" again, we crash. If you initially ran "make && make install", we crash. (4) when we crash, it's not long after the unicode tests are compiled. Are these real clues or just red herrings? I'm afraid I can't tell :( ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-29 10:43 Message: Logged In: YES user_id=31435 Ouch. Boosted priority back to 5, since Martin can reproduce it. Alas, where pymalloc got called *from* is almost certainly irrelevant -- we're seeing the end result of earlier corruption. Note that pymalloc is unusually sensitive to off-by-1 stores, since the chunks it hands out are contiguous (there's no hidden bookkeeping padding between them). Plausible: an earlier bogus store went beyond the end of its allocated chunk, overwriting the "next free block" pointer at the start of a previously free()'ed chunk of the same size (rounded up to a multiple of 8; 40 bytes in this case). At the time this blows up, bp is supposed to point to a previously free()'ed chunk of size 40 bytes (if there were none free()'ed and available, the earlier "pool != pool- >nextpool" guard should have failed). The first 4 bytes (let's simplify by assuming this is a 32-bit box) of the free chunks link the free chunks together, most recently free()'ed at the start of the (singly linked) list. So the code at this point is intent on returning bp, and "pool- >freeblock = *(block **)bp" is setting the 40-byte-chunk list header's idea of the *next* available 40-byte chunk. But bp is bogus. The value of bp is gotten out of the free list headers, the static array usedpools. This mechanism is horridly obscure, an array of pointer pairs that, in effect, capture just the first two members of the pool_header struct, once for each chunk size. It's possible that someone is overwriting usedpools[4 + 4]- >freeblock directly with 2, but that seems unlikely. More likely is that a free() operation linked a 40-byte chunk into the list headed at usedpools[4+4]->freeblock correctly, and a later bad store overwrote the first 4 bytes of the free()'ed block with 2. Then the "pool- >freeblock = *(block **)bp)" near the start of an unexceptional pymalloc would copy the 2 into the list header's freeblock without complaint. The error wouldn't show up until a subsequent malloc tried to use it. So that's one idea to get closer to the cause: add code to dereference pool->freeblock, before the "return (void *) bp". If that blows up earlier, then the first four bytes of bp were corrupted, and that gives you a useful data breakpoint address for the next run. If it doesn't blow up earlier, the corruption will be harder to find, but let's count on being lucky at first . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 08:00 Message: Logged In: YES user_id=21627 Ok, I can reproduce it now; I did not 'make install' before. Here is a gdb back trace #0 _PyCore_ObjectMalloc (nbytes=33) at Objects/obmalloc.c:417 #1 0x805885c in PyString_FromString (str=0x816c6e8 "checkJoin") at Objects/stringobject.c:136 #2 0x805d772 in PyString_InternFromString (cp=0x816c6e8 "checkJoin") at Objects/stringobject.c:3640 #3 0x807c9c6 in com_addop_varname (c=0xbfffe87c, kind=0, name=0x816c6e8 "checkJoin") at Python/compile.c:939 #4 0x807de24 in com_atom (c=0xbfffe87c, n=0x816c258) at Python/compile.c:1478 #5 0x807f01c in com_power (c=0xbfffe87c, n=0x816c8b8) at Python/compile.c:1846 #6 0x807f545 in com_factor (c=0xbfffe87c, n=0x816c898) at Python/compile.c:1975 #7 0x807f56c in com_term (c=0xbfffe87c, n=0x816c878) at Python/compile.c:1985 #8 0x807f6bc in com_arith_expr (c=0xbfffe87c, n=0x816c858) at Python/compile.c:2020 #9 0x807f7dc in com_shift_expr (c=0xbfffe87c, n=0x816c838) at Python/compile.c:2046 #10 0x807f8fc in com_and_expr (c=0xbfffe87c, n=0x816c818) at Python/compile.c:2072 #11 0x807fa0c in com_xor_expr (c=0xbfffe87c, n=0x816c7f8) at Python/compile.c:2094 ... The access that crashes is *(block **)bp, since bp is 0x2. Not sure how that happens; I'll investigate (but would appreciate a clue). It seems that the pool chain got corrupted. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-29 06:52 Message: Logged In: YES user_id=6380 Aha! The --enable-unicode=ucs4 is more suspicious than the --with-pymalloc. I had missed that info when this was first reported. Not that I'm any closer to solving it... :-( ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-29 02:53 Message: Logged In: YES user_id=89016 OK, I did a "make distclean" which removed .o files and the build directory and redid a "./configure --enable- unicode=ucs4 --with-pymalloc && make && make altinstall". The build process still crashes in the same spot: Compiling /usr/local/lib/python2.2/test/test_urlparse.py ... make: *** [libinstall] Segmentation fault I also retried with a fresh untarred Python-2.2.tgz. This shows the same behaviour. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 01:23 Message: Logged In: YES user_id=21627 Atleast I cannot reproduce it, on SuSE 7.3. Can you retry this, building from a clean source tree (no .o files, no build directory)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:30 Message: Logged In: YES user_id=6380 My prediction: this is irreproducible. Lowering the priority accordingly. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-23 04:24 Message: Logged In: YES user_id=89016 Unfortunately no core file was generated. Can I somehow force core file generation? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:42 Message: Logged In: YES user_id=21627 Did that produce a core file? If so, can you attach a gdb backtrace as well? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 From noreply@sourceforge.net Sun Dec 30 03:54:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 29 Dec 2001 19:54:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-495401 ] Build troubles: --with-pymalloc Message-ID: Bugs item #495401, was opened at 2001-12-20 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Martin v. Löwis (loewis) Summary: Build troubles: --with-pymalloc Initial Comment: The build process segfaults with the current CVS version when using --with-pymalloc System is SuSE Linux 7.0 > uname -a Linux amazonas 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 GMT 2000 i686 unknown > gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse- linux/2.95.2/specs gcc version 2.95.2 19991024 (release) Attached is the complete build log. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-29 19:54 Message: Logged In: YES user_id=31435 Good eye, Martin! It's clearly possible for the unpatched code to write beyond the memory allocated. The one thing that doesn't jibe is that you said bp is 0x2, which means 3 of its 4 bytes are 0x00, but UTF-8 doesn't produce 0 bytes except for one per \u0000 input character. Right? So, if this routine is the cause, where are the 0 bytes coming from? (It could be test_unicode sets up a UTF-8 encoding case with several \u0000 characters, but if so I didn't stumble into it.) Plausible: when a new pymalloc "page" is allocated, the 40-byte chunks in it are *not* linked together at the start. Instead a NULL pointer is stored at just the start of "the first" 40-byte chunk, and pymalloc-- on subsequent mallocs --finds that NULL and incrementally carves out additional 40-byte chunks. So as a startup-- but not a steady-state --condition, the "next free block" pointers will very often be NULLs, and then if this is a little-endian machine, writing a single 2 byte at the start of a free block would lead to a bogus pointer value of 0x2. About a fix, I'm in favor of junking all the cleverness here, by allocating size*4 bytes from the start. It's overallocating in all normal cases already, so we're going to incur the expense of cutting the result string back anyway; how *much* we overallocate doesn't matter to speed, except that if we don't have to keep checking inside the loop, the code gets simpler and quicker and more robust. The loop should instead merely assert that cbWritten <= cbAllocated at the end of each trip. Had this been done from the start, a debug build would have assert-failed a few nanoseconds after the wild store. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 17:44 Message: Logged In: YES user_id=21627 I've found one source of troubles, see the attached unicode.diff. Guido's intuition was right; it was an UCS-4 problem: EncodeUTF8 would over-allocate 3*size bytes, but can actually write 4*size in the worst case, which occurs in test_unicode. I'll leave the patch for review and experiments; it fixes the problem for me. The existing adjustment for surrogates is pointless, IMO: for the surrogate pair, it will allocate 6 bytes UTF-8 in advance, which is more than actually needed. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 15:13 Message: Logged In: YES user_id=21627 It's a Heisenbug. I found that even slightest modifications to the Python source make it come and go, or appear at different places. On my system, the crashes normally occur in the first run (.pyc). So I don't think the order of make invocations is the source of the problem. It's likely as Tim says: somebody overwrites memory somewhere. Unfortunately, even though I can reproduce crashes for the same pool, for some reason, my gdb memory watches don't trigger. Tim's approach of checking whether a the value came from following the free list did not help, either: the bug disappeared under the change. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-29 14:01 Message: Logged In: YES user_id=6656 Hmm. I now think that the stuff about extension modules is almost certainly a read herring. What I said about "make && make altinstall" vs "make altinstall" still seems to be true, though. If you compile with --with-pydebug, you crash right at the end of the second (-O) run of compileall.py -- I suspect this is something else, but it might not be. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-29 13:29 Message: Logged In: YES user_id=6656 I don't know if these are helpful observations or not, but anyway: (1) it doesn't core without the --enable-unicode=ucs4 option (2) if you just run "make altinstall" the library files are installed *and compiled* before the dynamically linked modules are built. Then we don't crash. (3) if you run "make altinstall" again, we crash. If you initially ran "make && make install", we crash. (4) when we crash, it's not long after the unicode tests are compiled. Are these real clues or just red herrings? I'm afraid I can't tell :( ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-29 10:43 Message: Logged In: YES user_id=31435 Ouch. Boosted priority back to 5, since Martin can reproduce it. Alas, where pymalloc got called *from* is almost certainly irrelevant -- we're seeing the end result of earlier corruption. Note that pymalloc is unusually sensitive to off-by-1 stores, since the chunks it hands out are contiguous (there's no hidden bookkeeping padding between them). Plausible: an earlier bogus store went beyond the end of its allocated chunk, overwriting the "next free block" pointer at the start of a previously free()'ed chunk of the same size (rounded up to a multiple of 8; 40 bytes in this case). At the time this blows up, bp is supposed to point to a previously free()'ed chunk of size 40 bytes (if there were none free()'ed and available, the earlier "pool != pool- >nextpool" guard should have failed). The first 4 bytes (let's simplify by assuming this is a 32-bit box) of the free chunks link the free chunks together, most recently free()'ed at the start of the (singly linked) list. So the code at this point is intent on returning bp, and "pool- >freeblock = *(block **)bp" is setting the 40-byte-chunk list header's idea of the *next* available 40-byte chunk. But bp is bogus. The value of bp is gotten out of the free list headers, the static array usedpools. This mechanism is horridly obscure, an array of pointer pairs that, in effect, capture just the first two members of the pool_header struct, once for each chunk size. It's possible that someone is overwriting usedpools[4 + 4]- >freeblock directly with 2, but that seems unlikely. More likely is that a free() operation linked a 40-byte chunk into the list headed at usedpools[4+4]->freeblock correctly, and a later bad store overwrote the first 4 bytes of the free()'ed block with 2. Then the "pool- >freeblock = *(block **)bp)" near the start of an unexceptional pymalloc would copy the 2 into the list header's freeblock without complaint. The error wouldn't show up until a subsequent malloc tried to use it. So that's one idea to get closer to the cause: add code to dereference pool->freeblock, before the "return (void *) bp". If that blows up earlier, then the first four bytes of bp were corrupted, and that gives you a useful data breakpoint address for the next run. If it doesn't blow up earlier, the corruption will be harder to find, but let's count on being lucky at first . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 08:00 Message: Logged In: YES user_id=21627 Ok, I can reproduce it now; I did not 'make install' before. Here is a gdb back trace #0 _PyCore_ObjectMalloc (nbytes=33) at Objects/obmalloc.c:417 #1 0x805885c in PyString_FromString (str=0x816c6e8 "checkJoin") at Objects/stringobject.c:136 #2 0x805d772 in PyString_InternFromString (cp=0x816c6e8 "checkJoin") at Objects/stringobject.c:3640 #3 0x807c9c6 in com_addop_varname (c=0xbfffe87c, kind=0, name=0x816c6e8 "checkJoin") at Python/compile.c:939 #4 0x807de24 in com_atom (c=0xbfffe87c, n=0x816c258) at Python/compile.c:1478 #5 0x807f01c in com_power (c=0xbfffe87c, n=0x816c8b8) at Python/compile.c:1846 #6 0x807f545 in com_factor (c=0xbfffe87c, n=0x816c898) at Python/compile.c:1975 #7 0x807f56c in com_term (c=0xbfffe87c, n=0x816c878) at Python/compile.c:1985 #8 0x807f6bc in com_arith_expr (c=0xbfffe87c, n=0x816c858) at Python/compile.c:2020 #9 0x807f7dc in com_shift_expr (c=0xbfffe87c, n=0x816c838) at Python/compile.c:2046 #10 0x807f8fc in com_and_expr (c=0xbfffe87c, n=0x816c818) at Python/compile.c:2072 #11 0x807fa0c in com_xor_expr (c=0xbfffe87c, n=0x816c7f8) at Python/compile.c:2094 ... The access that crashes is *(block **)bp, since bp is 0x2. Not sure how that happens; I'll investigate (but would appreciate a clue). It seems that the pool chain got corrupted. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-29 06:52 Message: Logged In: YES user_id=6380 Aha! The --enable-unicode=ucs4 is more suspicious than the --with-pymalloc. I had missed that info when this was first reported. Not that I'm any closer to solving it... :-( ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-29 02:53 Message: Logged In: YES user_id=89016 OK, I did a "make distclean" which removed .o files and the build directory and redid a "./configure --enable- unicode=ucs4 --with-pymalloc && make && make altinstall". The build process still crashes in the same spot: Compiling /usr/local/lib/python2.2/test/test_urlparse.py ... make: *** [libinstall] Segmentation fault I also retried with a fresh untarred Python-2.2.tgz. This shows the same behaviour. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 01:23 Message: Logged In: YES user_id=21627 Atleast I cannot reproduce it, on SuSE 7.3. Can you retry this, building from a clean source tree (no .o files, no build directory)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:30 Message: Logged In: YES user_id=6380 My prediction: this is irreproducible. Lowering the priority accordingly. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-23 04:24 Message: Logged In: YES user_id=89016 Unfortunately no core file was generated. Can I somehow force core file generation? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:42 Message: Logged In: YES user_id=21627 Did that produce a core file? If so, can you attach a gdb backtrace as well? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 From noreply@sourceforge.net Sun Dec 30 10:26:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 30 Dec 2001 02:26:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-495401 ] Build troubles: --with-pymalloc Message-ID: Bugs item #495401, was opened at 2001-12-20 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Martin v. Löwis (loewis) Summary: Build troubles: --with-pymalloc Initial Comment: The build process segfaults with the current CVS version when using --with-pymalloc System is SuSE Linux 7.0 > uname -a Linux amazonas 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 GMT 2000 i686 unknown > gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse- linux/2.95.2/specs gcc version 2.95.2 19991024 (release) Attached is the complete build log. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-30 02:26 Message: Logged In: YES user_id=21627 I disabled threading, which fortunately gave me memory watchpoints back. Then I noticed that the final *p=0 corrupted a non-NULL freeblock pointer, slightly decreasing it. Then following the freeblock pointer, freeblock was changed to a bogus block, which had its next pointer as garbage. I had to trace this from the back, of course. As for overallocation, I wonder whether the UTF-8 encoding should overallocate at all. unicode2.diff is a modification where it runs over the string twice, counting the number of needed bytes the first time. This is likely slower (atleast if no reallocations occur), but doesn't waste that much memory (I notice that pymalloc will never copy objects when they shrink, to return the extra space). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-29 19:54 Message: Logged In: YES user_id=31435 Good eye, Martin! It's clearly possible for the unpatched code to write beyond the memory allocated. The one thing that doesn't jibe is that you said bp is 0x2, which means 3 of its 4 bytes are 0x00, but UTF-8 doesn't produce 0 bytes except for one per \u0000 input character. Right? So, if this routine is the cause, where are the 0 bytes coming from? (It could be test_unicode sets up a UTF-8 encoding case with several \u0000 characters, but if so I didn't stumble into it.) Plausible: when a new pymalloc "page" is allocated, the 40-byte chunks in it are *not* linked together at the start. Instead a NULL pointer is stored at just the start of "the first" 40-byte chunk, and pymalloc-- on subsequent mallocs --finds that NULL and incrementally carves out additional 40-byte chunks. So as a startup-- but not a steady-state --condition, the "next free block" pointers will very often be NULLs, and then if this is a little-endian machine, writing a single 2 byte at the start of a free block would lead to a bogus pointer value of 0x2. About a fix, I'm in favor of junking all the cleverness here, by allocating size*4 bytes from the start. It's overallocating in all normal cases already, so we're going to incur the expense of cutting the result string back anyway; how *much* we overallocate doesn't matter to speed, except that if we don't have to keep checking inside the loop, the code gets simpler and quicker and more robust. The loop should instead merely assert that cbWritten <= cbAllocated at the end of each trip. Had this been done from the start, a debug build would have assert-failed a few nanoseconds after the wild store. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 17:44 Message: Logged In: YES user_id=21627 I've found one source of troubles, see the attached unicode.diff. Guido's intuition was right; it was an UCS-4 problem: EncodeUTF8 would over-allocate 3*size bytes, but can actually write 4*size in the worst case, which occurs in test_unicode. I'll leave the patch for review and experiments; it fixes the problem for me. The existing adjustment for surrogates is pointless, IMO: for the surrogate pair, it will allocate 6 bytes UTF-8 in advance, which is more than actually needed. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 15:13 Message: Logged In: YES user_id=21627 It's a Heisenbug. I found that even slightest modifications to the Python source make it come and go, or appear at different places. On my system, the crashes normally occur in the first run (.pyc). So I don't think the order of make invocations is the source of the problem. It's likely as Tim says: somebody overwrites memory somewhere. Unfortunately, even though I can reproduce crashes for the same pool, for some reason, my gdb memory watches don't trigger. Tim's approach of checking whether a the value came from following the free list did not help, either: the bug disappeared under the change. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-29 14:01 Message: Logged In: YES user_id=6656 Hmm. I now think that the stuff about extension modules is almost certainly a read herring. What I said about "make && make altinstall" vs "make altinstall" still seems to be true, though. If you compile with --with-pydebug, you crash right at the end of the second (-O) run of compileall.py -- I suspect this is something else, but it might not be. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-29 13:29 Message: Logged In: YES user_id=6656 I don't know if these are helpful observations or not, but anyway: (1) it doesn't core without the --enable-unicode=ucs4 option (2) if you just run "make altinstall" the library files are installed *and compiled* before the dynamically linked modules are built. Then we don't crash. (3) if you run "make altinstall" again, we crash. If you initially ran "make && make install", we crash. (4) when we crash, it's not long after the unicode tests are compiled. Are these real clues or just red herrings? I'm afraid I can't tell :( ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-29 10:43 Message: Logged In: YES user_id=31435 Ouch. Boosted priority back to 5, since Martin can reproduce it. Alas, where pymalloc got called *from* is almost certainly irrelevant -- we're seeing the end result of earlier corruption. Note that pymalloc is unusually sensitive to off-by-1 stores, since the chunks it hands out are contiguous (there's no hidden bookkeeping padding between them). Plausible: an earlier bogus store went beyond the end of its allocated chunk, overwriting the "next free block" pointer at the start of a previously free()'ed chunk of the same size (rounded up to a multiple of 8; 40 bytes in this case). At the time this blows up, bp is supposed to point to a previously free()'ed chunk of size 40 bytes (if there were none free()'ed and available, the earlier "pool != pool- >nextpool" guard should have failed). The first 4 bytes (let's simplify by assuming this is a 32-bit box) of the free chunks link the free chunks together, most recently free()'ed at the start of the (singly linked) list. So the code at this point is intent on returning bp, and "pool- >freeblock = *(block **)bp" is setting the 40-byte-chunk list header's idea of the *next* available 40-byte chunk. But bp is bogus. The value of bp is gotten out of the free list headers, the static array usedpools. This mechanism is horridly obscure, an array of pointer pairs that, in effect, capture just the first two members of the pool_header struct, once for each chunk size. It's possible that someone is overwriting usedpools[4 + 4]- >freeblock directly with 2, but that seems unlikely. More likely is that a free() operation linked a 40-byte chunk into the list headed at usedpools[4+4]->freeblock correctly, and a later bad store overwrote the first 4 bytes of the free()'ed block with 2. Then the "pool- >freeblock = *(block **)bp)" near the start of an unexceptional pymalloc would copy the 2 into the list header's freeblock without complaint. The error wouldn't show up until a subsequent malloc tried to use it. So that's one idea to get closer to the cause: add code to dereference pool->freeblock, before the "return (void *) bp". If that blows up earlier, then the first four bytes of bp were corrupted, and that gives you a useful data breakpoint address for the next run. If it doesn't blow up earlier, the corruption will be harder to find, but let's count on being lucky at first . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 08:00 Message: Logged In: YES user_id=21627 Ok, I can reproduce it now; I did not 'make install' before. Here is a gdb back trace #0 _PyCore_ObjectMalloc (nbytes=33) at Objects/obmalloc.c:417 #1 0x805885c in PyString_FromString (str=0x816c6e8 "checkJoin") at Objects/stringobject.c:136 #2 0x805d772 in PyString_InternFromString (cp=0x816c6e8 "checkJoin") at Objects/stringobject.c:3640 #3 0x807c9c6 in com_addop_varname (c=0xbfffe87c, kind=0, name=0x816c6e8 "checkJoin") at Python/compile.c:939 #4 0x807de24 in com_atom (c=0xbfffe87c, n=0x816c258) at Python/compile.c:1478 #5 0x807f01c in com_power (c=0xbfffe87c, n=0x816c8b8) at Python/compile.c:1846 #6 0x807f545 in com_factor (c=0xbfffe87c, n=0x816c898) at Python/compile.c:1975 #7 0x807f56c in com_term (c=0xbfffe87c, n=0x816c878) at Python/compile.c:1985 #8 0x807f6bc in com_arith_expr (c=0xbfffe87c, n=0x816c858) at Python/compile.c:2020 #9 0x807f7dc in com_shift_expr (c=0xbfffe87c, n=0x816c838) at Python/compile.c:2046 #10 0x807f8fc in com_and_expr (c=0xbfffe87c, n=0x816c818) at Python/compile.c:2072 #11 0x807fa0c in com_xor_expr (c=0xbfffe87c, n=0x816c7f8) at Python/compile.c:2094 ... The access that crashes is *(block **)bp, since bp is 0x2. Not sure how that happens; I'll investigate (but would appreciate a clue). It seems that the pool chain got corrupted. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-29 06:52 Message: Logged In: YES user_id=6380 Aha! The --enable-unicode=ucs4 is more suspicious than the --with-pymalloc. I had missed that info when this was first reported. Not that I'm any closer to solving it... :-( ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-29 02:53 Message: Logged In: YES user_id=89016 OK, I did a "make distclean" which removed .o files and the build directory and redid a "./configure --enable- unicode=ucs4 --with-pymalloc && make && make altinstall". The build process still crashes in the same spot: Compiling /usr/local/lib/python2.2/test/test_urlparse.py ... make: *** [libinstall] Segmentation fault I also retried with a fresh untarred Python-2.2.tgz. This shows the same behaviour. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 01:23 Message: Logged In: YES user_id=21627 Atleast I cannot reproduce it, on SuSE 7.3. Can you retry this, building from a clean source tree (no .o files, no build directory)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:30 Message: Logged In: YES user_id=6380 My prediction: this is irreproducible. Lowering the priority accordingly. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-23 04:24 Message: Logged In: YES user_id=89016 Unfortunately no core file was generated. Can I somehow force core file generation? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:42 Message: Logged In: YES user_id=21627 Did that produce a core file? If so, can you attach a gdb backtrace as well? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 From noreply@sourceforge.net Sun Dec 30 12:04:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 30 Dec 2001 04:04:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-497839 ] reindent chokes on empty first lines Message-ID: Bugs item #497839, was opened at 2001-12-30 04:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497839&group_id=5470 Category: Demos and Tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Tim Peters (tim_one) Summary: reindent chokes on empty first lines Initial Comment: If a file has an empty first line, and a hanging comment, reindent crashes. For the attached file, I get Traceback (most recent call last): File "/usr/src/python/Tools/scripts/reindent.py", line 271, in ? main() File "/usr/src/python/Tools/scripts/reindent.py", line 65, in main check(arg) File "/usr/src/python/Tools/scripts/reindent.py", line 90, in check if r.run(): File "/usr/src/python/Tools/scripts/reindent.py", line 187, in run want = have + getlspace(after[jline-1]) - \ IndexError: list index out of range ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497839&group_id=5470 From noreply@sourceforge.net Sun Dec 30 14:31:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 30 Dec 2001 06:31:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-497854 ] Short-cuts missing for All Users Message-ID: Bugs item #497854, was opened at 2001-12-30 06:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497854&group_id=5470 Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Short-cuts missing for All Users Initial Comment: Using the Windows installer of Python 2.2 on Windows XP Professional, as a user "root" who is member of the Administrator's group, performing an admin installation, the Python 2.2 program group does not show up in the start menu of other users. The cause for this problem is that the installer puts the shortcuts into \Documents and Settings\root\Start Menu, not into \Documents and Settings\All Users\Start Menu. Notice that it is difficult to login as Administrator on XP, since the Administrator account is not displayed on the welcome screen (only if the old-style login screen is selected). Even if installing Python as Administrator, the shortcuts still end up in \Documents and Settings\Administrator\Start Menu. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497854&group_id=5470 From noreply@sourceforge.net Sun Dec 30 14:46:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 30 Dec 2001 06:46:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-496084 ] unicode, tkfiledialog.py Message-ID: Bugs item #496084, was opened at 2001-12-22 03:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496084&group_id=5470 Category: Unicode Group: None >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Klaus-G. Meyer (kgm) Assigned to: Martin v. Löwis (loewis) Summary: unicode, tkfiledialog.py Initial Comment: The file tkfiledialog.py from python/lib/lib-tk contains some test code: if __name__ == "__main__": print "open", askopenfilename(filetypes=[("all filez", "*")]) print "saveas", asksaveasfilename() I tried it, but it won't work, if i select filenames with umlaut: C:\Programme\Python\Lib\lib-tk>python tkfiledialog.py open Traceback (most recent call last): File "tkfiledialog.py", line 128, in ? print "open", askopenfilename(filetypes=[("all filez", "*")]) UnicodeError: ASCII encoding error: ordinal not in range(128) The reason is (i think), that askopenfilename surprisingly returns unicode string instead of string. If functions return sometimes unicode strings, how should this be done? Is this a bug or a design problem? It would be nice, if the test code contains a working example. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-30 06:46 Message: Logged In: YES user_id=21627 Fixed in tkFileDialog 1.5. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-29 03:57 Message: Logged In: YES user_id=38388 I don't know anything a about Tkinter, sorry. Printing Unicode is a huge can of worms -- I'm not sure whether it's worth the trouble to try to magically find out which encoding the terminal, GUI or whatever backend you use for stdout is being used. ASCII should work in most cases and that's what Python already tries... Martin, please patch the file or simply close the bug with "Won't fix". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 01:19 Message: Logged In: YES user_id=21627 It is by design that the dialog returns Unicode strings if the file name contains non-ASCII characters. It is easy to fix the example, just append .encode("utf-8") at the end of each print statement. Fixing it in the "right" way is more involved; you'll have to find out what encoding the terminal uses on which the string is printed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496084&group_id=5470 From noreply@sourceforge.net Mon Dec 31 07:12:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 30 Dec 2001 23:12:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-497160 ] test_commands assumes ls is in /bin Message-ID: Bugs item #497160, was opened at 2001-12-27 13:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497160&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: test_commands assumes ls is in /bin Initial Comment: I got this test failure while building Python 2.2: test test_commands failed -- Traceback (most recent call last): File "./Lib/test/test_commands.py", line 43, in test_getstatus self.assert_(re.match(pat, getstatus("/bin/ls"), re.VERBOSE)) File "/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py", line 262, in failUnless if not expr: raise self.failureException, msg AssertionError My ls happens to be somewhere other than /bin. It would be nice if the test used a different file, such as "/", ".", or even "./Lib/test/test_commands.py". ---------------------------------------------------------------------- >Comment By: Paul Jarc (prjsf) Date: 2001-12-30 23:12 Message: Logged In: YES user_id=412110 Sorry, I should have thought of providing a patch to begin with. This regexp test is weaker than the original one, but seems to be still stronger than necessary. If ls is broken here, we don't care, because it isn't part of Python. All wee need is to be able to spawn a shell. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-29 06:55 Message: Logged In: YES user_id=6380 Assigned to Fred Drake, who wrote the test suite. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-29 06:54 Message: Logged In: YES user_id=6380 OK, reopening. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2001-12-29 03:55 Message: Logged In: YES user_id=43607 This bug report is related to [ #460613 ] test_commands fails on SGI, which nobody ever seems to have noticed and which is still open. The problem there is that /bin/ls *does* exist, but is a symlink. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:42 Message: Logged In: YES user_id=6380 If the patch is so simple, why don't you provide it? ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2001-12-28 14:20 Message: Logged In: YES user_id=412110 The test suite already uses $PATH to *run* ls (as does other software, which is why I don't get into a lot of trouble). It merely uses /bin/ls as a filename to pass to ls so it can check the output. Any other filename will do just as well here, and the fix is extremely simple; what's the benefit of listing /bin/ls in particular that makes it worth risk breaking on systems like this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 13:56 Message: Logged In: YES user_id=6380 I think you are going to get in a lot of trouble when /bin/ls doesn't exist. It's not worth fixing the test suite for this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497160&group_id=5470 From noreply@sourceforge.net Mon Dec 31 07:18:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 30 Dec 2001 23:18:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-497162 ] test_email assumes Unix uses NTP scale Message-ID: Bugs item #497162, was opened at 2001-12-27 13:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470 Category: Build Group: Python 2.2 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Guido van Rossum (gvanrossum) Summary: test_email assumes Unix uses NTP scale Initial Comment: I got this test failure while building Python 2.2: test test_email failed -- Traceback (most recent call last): File "./Lib/test/test_email.py", line 935, in test_formatdate self.assertEqual(gdate, matchdate) File "/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py", line 286, in failUnlessEqual raise self.failureException, \ AssertionError: 'Fri, 09 Nov 2001 17:33:30 -0000' != 'Fri, 09 Nov 2001 17:33:52 -0000' This happens because the test assumes that the system clock is a count of non-leap seconds since the epoch. This is a common configuration, but it renders some clock values ambiguous, and complicates interval calculations. So my clock counts *all* seconds since the epoch. It would be nice if the test could handle both cases, by checking the broken-down values around a leap second, or by checking that the calculated string matches either of the two possibilities. ---------------------------------------------------------------------- >Comment By: Paul Jarc (prjsf) Date: 2001-12-30 23:18 Message: Logged In: YES user_id=412110 Sorry, I should have thought of providing a patch to begin with. On a separate note, some patches would not be so easy simply because of the filenames containing spaces. You might consider renaming those files. This bit me when I tried to patch the 2.1.1 sources up to 2.2 on a machine stuck behind a slow modem. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:43 Message: Logged In: YES user_id=6380 If you want this fixed, please submit a patch. ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2001-12-28 14:12 Message: Logged In: YES user_id=412110 Most software will trust localtime() and gmtime() to interpret the clock. It's only a problem here because you're testing (and thus doubting) the Python bindings to those functions, and rather than check it against some other use of the C functions, you check it against a precomputed string, thus doubting the C functions. C's localtime and gmtime give correct results on my system, because I'm using a time zone designed for a clock that counts all seconds. Don't doubt the C functions; they aren't what you're trying to test. I already explained the point of keeping the clock this way (the TAI scale): it simplifies interval calculations (the difference t1-t0 actually tells you how many seconds passed between those times), and it makes no clock values ambiguous. The NTP scale (counting only non-leap seconds) is a horrible bit of backward compatibility. By depending on it, you punish those with well-configured systems to reward those with badly-configured systems. I mentioned an easy fix, which is to compare the computed string to each of the values seen above, and to pass the test if it matches either of them. This will still fail for people who use even more exotic setups, but I don't know of any such. Is there anything wrong with this? I think the benefit easily outweighs the cost. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 13:54 Message: Logged In: YES user_id=6380 I think a lot of other software will fail too if you set your clock this way. What's the point? I don't want to argume too much about this, but I believe that this idea has been tried before and rejected. So I'm closing this as a won't fix. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470 From noreply@sourceforge.net Mon Dec 31 12:48:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 31 Dec 2001 04:48:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-495401 ] Build troubles: --with-pymalloc Message-ID: Bugs item #495401, was opened at 2001-12-20 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Martin v. Löwis (loewis) Summary: Build troubles: --with-pymalloc Initial Comment: The build process segfaults with the current CVS version when using --with-pymalloc System is SuSE Linux 7.0 > uname -a Linux amazonas 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 GMT 2000 i686 unknown > gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse- linux/2.95.2/specs gcc version 2.95.2 19991024 (release) Attached is the complete build log. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-31 04:48 Message: Logged In: YES user_id=38388 I like the unicode.diff, but not the unicode2.diff. Instead of fixing the UTF-8 codec here we should fix the pymalloc implementation, since overallocation is common thing to do and not only used in codecs. (Note that all Python extensions will start to use pymalloc too once we enable it per default.) I don't know whether it's relevant, but I found that core dumps can easily be triggered by mixing the various memory allocation APIs in Python and the C lib. The bug may not only be related to the UTF-8 codec but may also linger in some other extension modules. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-30 02:26 Message: Logged In: YES user_id=21627 I disabled threading, which fortunately gave me memory watchpoints back. Then I noticed that the final *p=0 corrupted a non-NULL freeblock pointer, slightly decreasing it. Then following the freeblock pointer, freeblock was changed to a bogus block, which had its next pointer as garbage. I had to trace this from the back, of course. As for overallocation, I wonder whether the UTF-8 encoding should overallocate at all. unicode2.diff is a modification where it runs over the string twice, counting the number of needed bytes the first time. This is likely slower (atleast if no reallocations occur), but doesn't waste that much memory (I notice that pymalloc will never copy objects when they shrink, to return the extra space). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-29 19:54 Message: Logged In: YES user_id=31435 Good eye, Martin! It's clearly possible for the unpatched code to write beyond the memory allocated. The one thing that doesn't jibe is that you said bp is 0x2, which means 3 of its 4 bytes are 0x00, but UTF-8 doesn't produce 0 bytes except for one per \u0000 input character. Right? So, if this routine is the cause, where are the 0 bytes coming from? (It could be test_unicode sets up a UTF-8 encoding case with several \u0000 characters, but if so I didn't stumble into it.) Plausible: when a new pymalloc "page" is allocated, the 40-byte chunks in it are *not* linked together at the start. Instead a NULL pointer is stored at just the start of "the first" 40-byte chunk, and pymalloc-- on subsequent mallocs --finds that NULL and incrementally carves out additional 40-byte chunks. So as a startup-- but not a steady-state --condition, the "next free block" pointers will very often be NULLs, and then if this is a little-endian machine, writing a single 2 byte at the start of a free block would lead to a bogus pointer value of 0x2. About a fix, I'm in favor of junking all the cleverness here, by allocating size*4 bytes from the start. It's overallocating in all normal cases already, so we're going to incur the expense of cutting the result string back anyway; how *much* we overallocate doesn't matter to speed, except that if we don't have to keep checking inside the loop, the code gets simpler and quicker and more robust. The loop should instead merely assert that cbWritten <= cbAllocated at the end of each trip. Had this been done from the start, a debug build would have assert-failed a few nanoseconds after the wild store. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 17:44 Message: Logged In: YES user_id=21627 I've found one source of troubles, see the attached unicode.diff. Guido's intuition was right; it was an UCS-4 problem: EncodeUTF8 would over-allocate 3*size bytes, but can actually write 4*size in the worst case, which occurs in test_unicode. I'll leave the patch for review and experiments; it fixes the problem for me. The existing adjustment for surrogates is pointless, IMO: for the surrogate pair, it will allocate 6 bytes UTF-8 in advance, which is more than actually needed. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 15:13 Message: Logged In: YES user_id=21627 It's a Heisenbug. I found that even slightest modifications to the Python source make it come and go, or appear at different places. On my system, the crashes normally occur in the first run (.pyc). So I don't think the order of make invocations is the source of the problem. It's likely as Tim says: somebody overwrites memory somewhere. Unfortunately, even though I can reproduce crashes for the same pool, for some reason, my gdb memory watches don't trigger. Tim's approach of checking whether a the value came from following the free list did not help, either: the bug disappeared under the change. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-29 14:01 Message: Logged In: YES user_id=6656 Hmm. I now think that the stuff about extension modules is almost certainly a read herring. What I said about "make && make altinstall" vs "make altinstall" still seems to be true, though. If you compile with --with-pydebug, you crash right at the end of the second (-O) run of compileall.py -- I suspect this is something else, but it might not be. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-29 13:29 Message: Logged In: YES user_id=6656 I don't know if these are helpful observations or not, but anyway: (1) it doesn't core without the --enable-unicode=ucs4 option (2) if you just run "make altinstall" the library files are installed *and compiled* before the dynamically linked modules are built. Then we don't crash. (3) if you run "make altinstall" again, we crash. If you initially ran "make && make install", we crash. (4) when we crash, it's not long after the unicode tests are compiled. Are these real clues or just red herrings? I'm afraid I can't tell :( ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-29 10:43 Message: Logged In: YES user_id=31435 Ouch. Boosted priority back to 5, since Martin can reproduce it. Alas, where pymalloc got called *from* is almost certainly irrelevant -- we're seeing the end result of earlier corruption. Note that pymalloc is unusually sensitive to off-by-1 stores, since the chunks it hands out are contiguous (there's no hidden bookkeeping padding between them). Plausible: an earlier bogus store went beyond the end of its allocated chunk, overwriting the "next free block" pointer at the start of a previously free()'ed chunk of the same size (rounded up to a multiple of 8; 40 bytes in this case). At the time this blows up, bp is supposed to point to a previously free()'ed chunk of size 40 bytes (if there were none free()'ed and available, the earlier "pool != pool- >nextpool" guard should have failed). The first 4 bytes (let's simplify by assuming this is a 32-bit box) of the free chunks link the free chunks together, most recently free()'ed at the start of the (singly linked) list. So the code at this point is intent on returning bp, and "pool- >freeblock = *(block **)bp" is setting the 40-byte-chunk list header's idea of the *next* available 40-byte chunk. But bp is bogus. The value of bp is gotten out of the free list headers, the static array usedpools. This mechanism is horridly obscure, an array of pointer pairs that, in effect, capture just the first two members of the pool_header struct, once for each chunk size. It's possible that someone is overwriting usedpools[4 + 4]- >freeblock directly with 2, but that seems unlikely. More likely is that a free() operation linked a 40-byte chunk into the list headed at usedpools[4+4]->freeblock correctly, and a later bad store overwrote the first 4 bytes of the free()'ed block with 2. Then the "pool- >freeblock = *(block **)bp)" near the start of an unexceptional pymalloc would copy the 2 into the list header's freeblock without complaint. The error wouldn't show up until a subsequent malloc tried to use it. So that's one idea to get closer to the cause: add code to dereference pool->freeblock, before the "return (void *) bp". If that blows up earlier, then the first four bytes of bp were corrupted, and that gives you a useful data breakpoint address for the next run. If it doesn't blow up earlier, the corruption will be harder to find, but let's count on being lucky at first . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 08:00 Message: Logged In: YES user_id=21627 Ok, I can reproduce it now; I did not 'make install' before. Here is a gdb back trace #0 _PyCore_ObjectMalloc (nbytes=33) at Objects/obmalloc.c:417 #1 0x805885c in PyString_FromString (str=0x816c6e8 "checkJoin") at Objects/stringobject.c:136 #2 0x805d772 in PyString_InternFromString (cp=0x816c6e8 "checkJoin") at Objects/stringobject.c:3640 #3 0x807c9c6 in com_addop_varname (c=0xbfffe87c, kind=0, name=0x816c6e8 "checkJoin") at Python/compile.c:939 #4 0x807de24 in com_atom (c=0xbfffe87c, n=0x816c258) at Python/compile.c:1478 #5 0x807f01c in com_power (c=0xbfffe87c, n=0x816c8b8) at Python/compile.c:1846 #6 0x807f545 in com_factor (c=0xbfffe87c, n=0x816c898) at Python/compile.c:1975 #7 0x807f56c in com_term (c=0xbfffe87c, n=0x816c878) at Python/compile.c:1985 #8 0x807f6bc in com_arith_expr (c=0xbfffe87c, n=0x816c858) at Python/compile.c:2020 #9 0x807f7dc in com_shift_expr (c=0xbfffe87c, n=0x816c838) at Python/compile.c:2046 #10 0x807f8fc in com_and_expr (c=0xbfffe87c, n=0x816c818) at Python/compile.c:2072 #11 0x807fa0c in com_xor_expr (c=0xbfffe87c, n=0x816c7f8) at Python/compile.c:2094 ... The access that crashes is *(block **)bp, since bp is 0x2. Not sure how that happens; I'll investigate (but would appreciate a clue). It seems that the pool chain got corrupted. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-29 06:52 Message: Logged In: YES user_id=6380 Aha! The --enable-unicode=ucs4 is more suspicious than the --with-pymalloc. I had missed that info when this was first reported. Not that I'm any closer to solving it... :-( ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-29 02:53 Message: Logged In: YES user_id=89016 OK, I did a "make distclean" which removed .o files and the build directory and redid a "./configure --enable- unicode=ucs4 --with-pymalloc && make && make altinstall". The build process still crashes in the same spot: Compiling /usr/local/lib/python2.2/test/test_urlparse.py ... make: *** [libinstall] Segmentation fault I also retried with a fresh untarred Python-2.2.tgz. This shows the same behaviour. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 01:23 Message: Logged In: YES user_id=21627 Atleast I cannot reproduce it, on SuSE 7.3. Can you retry this, building from a clean source tree (no .o files, no build directory)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:30 Message: Logged In: YES user_id=6380 My prediction: this is irreproducible. Lowering the priority accordingly. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-23 04:24 Message: Logged In: YES user_id=89016 Unfortunately no core file was generated. Can I somehow force core file generation? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:42 Message: Logged In: YES user_id=21627 Did that produce a core file? If so, can you attach a gdb backtrace as well? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 From noreply@sourceforge.net Mon Dec 31 13:46:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 31 Dec 2001 05:46:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-495401 ] Build troubles: --with-pymalloc Message-ID: Bugs item #495401, was opened at 2001-12-20 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Martin v. Löwis (loewis) Summary: Build troubles: --with-pymalloc Initial Comment: The build process segfaults with the current CVS version when using --with-pymalloc System is SuSE Linux 7.0 > uname -a Linux amazonas 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 GMT 2000 i686 unknown > gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse- linux/2.95.2/specs gcc version 2.95.2 19991024 (release) Attached is the complete build log. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-12-31 05:46 Message: Logged In: YES user_id=21627 MAL, I'm 100% positive that the crash on my system was caused by the UTF-8 encoding; I've seen it in the debugger overwrite memory that it doesn't own. As for unicode.diff: Tim has proposed that this should not be done, but that 4*size should be allocated in advance. What do you think? On unicode2.diff: If pymalloc was changed to shrink the memory, it would have to copy the original string, since it would likely be in a different size class. This is less efficient than the approach taken in unicode2.diff. What specifically is it that you dislike about first counting the memory requirements? It actually simplifies the code. Notice that the current code is still buggy with regard to surrogates. If there is a high surrogate, but not a low one, it will write bogus UTF-8 (with no lead byte). This is fixed in unicode2.diff as well. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-31 04:48 Message: Logged In: YES user_id=38388 I like the unicode.diff, but not the unicode2.diff. Instead of fixing the UTF-8 codec here we should fix the pymalloc implementation, since overallocation is common thing to do and not only used in codecs. (Note that all Python extensions will start to use pymalloc too once we enable it per default.) I don't know whether it's relevant, but I found that core dumps can easily be triggered by mixing the various memory allocation APIs in Python and the C lib. The bug may not only be related to the UTF-8 codec but may also linger in some other extension modules. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-30 02:26 Message: Logged In: YES user_id=21627 I disabled threading, which fortunately gave me memory watchpoints back. Then I noticed that the final *p=0 corrupted a non-NULL freeblock pointer, slightly decreasing it. Then following the freeblock pointer, freeblock was changed to a bogus block, which had its next pointer as garbage. I had to trace this from the back, of course. As for overallocation, I wonder whether the UTF-8 encoding should overallocate at all. unicode2.diff is a modification where it runs over the string twice, counting the number of needed bytes the first time. This is likely slower (atleast if no reallocations occur), but doesn't waste that much memory (I notice that pymalloc will never copy objects when they shrink, to return the extra space). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-29 19:54 Message: Logged In: YES user_id=31435 Good eye, Martin! It's clearly possible for the unpatched code to write beyond the memory allocated. The one thing that doesn't jibe is that you said bp is 0x2, which means 3 of its 4 bytes are 0x00, but UTF-8 doesn't produce 0 bytes except for one per \u0000 input character. Right? So, if this routine is the cause, where are the 0 bytes coming from? (It could be test_unicode sets up a UTF-8 encoding case with several \u0000 characters, but if so I didn't stumble into it.) Plausible: when a new pymalloc "page" is allocated, the 40-byte chunks in it are *not* linked together at the start. Instead a NULL pointer is stored at just the start of "the first" 40-byte chunk, and pymalloc-- on subsequent mallocs --finds that NULL and incrementally carves out additional 40-byte chunks. So as a startup-- but not a steady-state --condition, the "next free block" pointers will very often be NULLs, and then if this is a little-endian machine, writing a single 2 byte at the start of a free block would lead to a bogus pointer value of 0x2. About a fix, I'm in favor of junking all the cleverness here, by allocating size*4 bytes from the start. It's overallocating in all normal cases already, so we're going to incur the expense of cutting the result string back anyway; how *much* we overallocate doesn't matter to speed, except that if we don't have to keep checking inside the loop, the code gets simpler and quicker and more robust. The loop should instead merely assert that cbWritten <= cbAllocated at the end of each trip. Had this been done from the start, a debug build would have assert-failed a few nanoseconds after the wild store. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 17:44 Message: Logged In: YES user_id=21627 I've found one source of troubles, see the attached unicode.diff. Guido's intuition was right; it was an UCS-4 problem: EncodeUTF8 would over-allocate 3*size bytes, but can actually write 4*size in the worst case, which occurs in test_unicode. I'll leave the patch for review and experiments; it fixes the problem for me. The existing adjustment for surrogates is pointless, IMO: for the surrogate pair, it will allocate 6 bytes UTF-8 in advance, which is more than actually needed. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 15:13 Message: Logged In: YES user_id=21627 It's a Heisenbug. I found that even slightest modifications to the Python source make it come and go, or appear at different places. On my system, the crashes normally occur in the first run (.pyc). So I don't think the order of make invocations is the source of the problem. It's likely as Tim says: somebody overwrites memory somewhere. Unfortunately, even though I can reproduce crashes for the same pool, for some reason, my gdb memory watches don't trigger. Tim's approach of checking whether a the value came from following the free list did not help, either: the bug disappeared under the change. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-29 14:01 Message: Logged In: YES user_id=6656 Hmm. I now think that the stuff about extension modules is almost certainly a read herring. What I said about "make && make altinstall" vs "make altinstall" still seems to be true, though. If you compile with --with-pydebug, you crash right at the end of the second (-O) run of compileall.py -- I suspect this is something else, but it might not be. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-29 13:29 Message: Logged In: YES user_id=6656 I don't know if these are helpful observations or not, but anyway: (1) it doesn't core without the --enable-unicode=ucs4 option (2) if you just run "make altinstall" the library files are installed *and compiled* before the dynamically linked modules are built. Then we don't crash. (3) if you run "make altinstall" again, we crash. If you initially ran "make && make install", we crash. (4) when we crash, it's not long after the unicode tests are compiled. Are these real clues or just red herrings? I'm afraid I can't tell :( ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-29 10:43 Message: Logged In: YES user_id=31435 Ouch. Boosted priority back to 5, since Martin can reproduce it. Alas, where pymalloc got called *from* is almost certainly irrelevant -- we're seeing the end result of earlier corruption. Note that pymalloc is unusually sensitive to off-by-1 stores, since the chunks it hands out are contiguous (there's no hidden bookkeeping padding between them). Plausible: an earlier bogus store went beyond the end of its allocated chunk, overwriting the "next free block" pointer at the start of a previously free()'ed chunk of the same size (rounded up to a multiple of 8; 40 bytes in this case). At the time this blows up, bp is supposed to point to a previously free()'ed chunk of size 40 bytes (if there were none free()'ed and available, the earlier "pool != pool- >nextpool" guard should have failed). The first 4 bytes (let's simplify by assuming this is a 32-bit box) of the free chunks link the free chunks together, most recently free()'ed at the start of the (singly linked) list. So the code at this point is intent on returning bp, and "pool- >freeblock = *(block **)bp" is setting the 40-byte-chunk list header's idea of the *next* available 40-byte chunk. But bp is bogus. The value of bp is gotten out of the free list headers, the static array usedpools. This mechanism is horridly obscure, an array of pointer pairs that, in effect, capture just the first two members of the pool_header struct, once for each chunk size. It's possible that someone is overwriting usedpools[4 + 4]- >freeblock directly with 2, but that seems unlikely. More likely is that a free() operation linked a 40-byte chunk into the list headed at usedpools[4+4]->freeblock correctly, and a later bad store overwrote the first 4 bytes of the free()'ed block with 2. Then the "pool- >freeblock = *(block **)bp)" near the start of an unexceptional pymalloc would copy the 2 into the list header's freeblock without complaint. The error wouldn't show up until a subsequent malloc tried to use it. So that's one idea to get closer to the cause: add code to dereference pool->freeblock, before the "return (void *) bp". If that blows up earlier, then the first four bytes of bp were corrupted, and that gives you a useful data breakpoint address for the next run. If it doesn't blow up earlier, the corruption will be harder to find, but let's count on being lucky at first . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 08:00 Message: Logged In: YES user_id=21627 Ok, I can reproduce it now; I did not 'make install' before. Here is a gdb back trace #0 _PyCore_ObjectMalloc (nbytes=33) at Objects/obmalloc.c:417 #1 0x805885c in PyString_FromString (str=0x816c6e8 "checkJoin") at Objects/stringobject.c:136 #2 0x805d772 in PyString_InternFromString (cp=0x816c6e8 "checkJoin") at Objects/stringobject.c:3640 #3 0x807c9c6 in com_addop_varname (c=0xbfffe87c, kind=0, name=0x816c6e8 "checkJoin") at Python/compile.c:939 #4 0x807de24 in com_atom (c=0xbfffe87c, n=0x816c258) at Python/compile.c:1478 #5 0x807f01c in com_power (c=0xbfffe87c, n=0x816c8b8) at Python/compile.c:1846 #6 0x807f545 in com_factor (c=0xbfffe87c, n=0x816c898) at Python/compile.c:1975 #7 0x807f56c in com_term (c=0xbfffe87c, n=0x816c878) at Python/compile.c:1985 #8 0x807f6bc in com_arith_expr (c=0xbfffe87c, n=0x816c858) at Python/compile.c:2020 #9 0x807f7dc in com_shift_expr (c=0xbfffe87c, n=0x816c838) at Python/compile.c:2046 #10 0x807f8fc in com_and_expr (c=0xbfffe87c, n=0x816c818) at Python/compile.c:2072 #11 0x807fa0c in com_xor_expr (c=0xbfffe87c, n=0x816c7f8) at Python/compile.c:2094 ... The access that crashes is *(block **)bp, since bp is 0x2. Not sure how that happens; I'll investigate (but would appreciate a clue). It seems that the pool chain got corrupted. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-29 06:52 Message: Logged In: YES user_id=6380 Aha! The --enable-unicode=ucs4 is more suspicious than the --with-pymalloc. I had missed that info when this was first reported. Not that I'm any closer to solving it... :-( ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-29 02:53 Message: Logged In: YES user_id=89016 OK, I did a "make distclean" which removed .o files and the build directory and redid a "./configure --enable- unicode=ucs4 --with-pymalloc && make && make altinstall". The build process still crashes in the same spot: Compiling /usr/local/lib/python2.2/test/test_urlparse.py ... make: *** [libinstall] Segmentation fault I also retried with a fresh untarred Python-2.2.tgz. This shows the same behaviour. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 01:23 Message: Logged In: YES user_id=21627 Atleast I cannot reproduce it, on SuSE 7.3. Can you retry this, building from a clean source tree (no .o files, no build directory)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:30 Message: Logged In: YES user_id=6380 My prediction: this is irreproducible. Lowering the priority accordingly. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-23 04:24 Message: Logged In: YES user_id=89016 Unfortunately no core file was generated. Can I somehow force core file generation? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:42 Message: Logged In: YES user_id=21627 Did that produce a core file? If so, can you attach a gdb backtrace as well? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 From noreply@sourceforge.net Mon Dec 31 14:34:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 31 Dec 2001 06:34:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-497162 ] test_email assumes Unix uses NTP scale Message-ID: Bugs item #497162, was opened at 2001-12-27 13:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470 Category: Build Group: Python 2.2 >Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Paul Jarc (prjsf) >Assigned to: Barry Warsaw (bwarsaw) Summary: test_email assumes Unix uses NTP scale Initial Comment: I got this test failure while building Python 2.2: test test_email failed -- Traceback (most recent call last): File "./Lib/test/test_email.py", line 935, in test_formatdate self.assertEqual(gdate, matchdate) File "/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py", line 286, in failUnlessEqual raise self.failureException, \ AssertionError: 'Fri, 09 Nov 2001 17:33:30 -0000' != 'Fri, 09 Nov 2001 17:33:52 -0000' This happens because the test assumes that the system clock is a count of non-leap seconds since the epoch. This is a common configuration, but it renders some clock values ambiguous, and complicates interval calculations. So my clock counts *all* seconds since the epoch. It would be nice if the test could handle both cases, by checking the broken-down values around a leap second, or by checking that the calculated string matches either of the two possibilities. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-31 06:34 Message: Logged In: YES user_id=6380 Thanks for the patch. I'm assigning this to Barry, who wrote the test. Re spaces in filenames: I think the only filenames with spaces in them occur in the Mac subtree, and the Mac folks insist on having them... ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2001-12-30 23:18 Message: Logged In: YES user_id=412110 Sorry, I should have thought of providing a patch to begin with. On a separate note, some patches would not be so easy simply because of the filenames containing spaces. You might consider renaming those files. This bit me when I tried to patch the 2.1.1 sources up to 2.2 on a machine stuck behind a slow modem. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:43 Message: Logged In: YES user_id=6380 If you want this fixed, please submit a patch. ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2001-12-28 14:12 Message: Logged In: YES user_id=412110 Most software will trust localtime() and gmtime() to interpret the clock. It's only a problem here because you're testing (and thus doubting) the Python bindings to those functions, and rather than check it against some other use of the C functions, you check it against a precomputed string, thus doubting the C functions. C's localtime and gmtime give correct results on my system, because I'm using a time zone designed for a clock that counts all seconds. Don't doubt the C functions; they aren't what you're trying to test. I already explained the point of keeping the clock this way (the TAI scale): it simplifies interval calculations (the difference t1-t0 actually tells you how many seconds passed between those times), and it makes no clock values ambiguous. The NTP scale (counting only non-leap seconds) is a horrible bit of backward compatibility. By depending on it, you punish those with well-configured systems to reward those with badly-configured systems. I mentioned an easy fix, which is to compare the computed string to each of the values seen above, and to pass the test if it matches either of them. This will still fail for people who use even more exotic setups, but I don't know of any such. Is there anything wrong with this? I think the benefit easily outweighs the cost. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 13:54 Message: Logged In: YES user_id=6380 I think a lot of other software will fail too if you set your clock this way. What's the point? I don't want to argume too much about this, but I believe that this idea has been tried before and rejected. So I'm closing this as a won't fix. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470 From noreply@sourceforge.net Mon Dec 31 17:56:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 31 Dec 2001 09:56:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-498124 ] base64 mishandles binary on Win32 Message-ID: Bugs item #498124, was opened at 2001-12-31 09:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498124&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Tim Roberts (timroberts) Assigned to: Nobody/Anonymous (nobody) Summary: base64 mishandles binary on Win32 Initial Comment: I'm using ActiveState Python 2.1.1 on Windows 2000 Service Pack 2, but I believe the problem happens on any recent Win32 Python. I use base64.py as a stand-alone tool for decoding Base64 attachments. This produces incorrect results with binary attachments on Win32, because it writes to sys.stdout, which is open in text mode by default. Thus, CR/LF and Ctrl-Z characters get botched. It is safe to assume that a base64 attachment will result in a binary file. A similar problem happens when encoding. The following patch towards the end of the test() function in base64.py should fix this. if o == '-t': test1(); return + if func == decode and sys.platform == 'win32': + import os, msvcrt + msvcrt.setmode( sys.stdout.fileno(), os.O_BINARY ) if args and args[0] != '-': ! func(open(args[0], 'rb'), sys.stdout) (Note I've changed 'r' to 'rb' in that last line; that's safe on Win32 and ignored on Linux.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498124&group_id=5470 From noreply@sourceforge.net Mon Dec 31 19:36:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 31 Dec 2001 11:36:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-495401 ] Build troubles: --with-pymalloc Message-ID: Bugs item #495401, was opened at 2001-12-20 05:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Martin v. Löwis (loewis) Summary: Build troubles: --with-pymalloc Initial Comment: The build process segfaults with the current CVS version when using --with-pymalloc System is SuSE Linux 7.0 > uname -a Linux amazonas 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 GMT 2000 i686 unknown > gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse- linux/2.95.2/specs gcc version 2.95.2 19991024 (release) Attached is the complete build log. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-12-31 11:36 Message: Logged In: YES user_id=31435 Martin, I like your second patch fine, but would like it a lot better with assert(p - PyString_AS_STRING(v) == cbAllocated); at the end. Else a piddly change in either loop can cause more miserably hard-to-track-down problems. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-31 05:46 Message: Logged In: YES user_id=21627 MAL, I'm 100% positive that the crash on my system was caused by the UTF-8 encoding; I've seen it in the debugger overwrite memory that it doesn't own. As for unicode.diff: Tim has proposed that this should not be done, but that 4*size should be allocated in advance. What do you think? On unicode2.diff: If pymalloc was changed to shrink the memory, it would have to copy the original string, since it would likely be in a different size class. This is less efficient than the approach taken in unicode2.diff. What specifically is it that you dislike about first counting the memory requirements? It actually simplifies the code. Notice that the current code is still buggy with regard to surrogates. If there is a high surrogate, but not a low one, it will write bogus UTF-8 (with no lead byte). This is fixed in unicode2.diff as well. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-31 04:48 Message: Logged In: YES user_id=38388 I like the unicode.diff, but not the unicode2.diff. Instead of fixing the UTF-8 codec here we should fix the pymalloc implementation, since overallocation is common thing to do and not only used in codecs. (Note that all Python extensions will start to use pymalloc too once we enable it per default.) I don't know whether it's relevant, but I found that core dumps can easily be triggered by mixing the various memory allocation APIs in Python and the C lib. The bug may not only be related to the UTF-8 codec but may also linger in some other extension modules. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-30 02:26 Message: Logged In: YES user_id=21627 I disabled threading, which fortunately gave me memory watchpoints back. Then I noticed that the final *p=0 corrupted a non-NULL freeblock pointer, slightly decreasing it. Then following the freeblock pointer, freeblock was changed to a bogus block, which had its next pointer as garbage. I had to trace this from the back, of course. As for overallocation, I wonder whether the UTF-8 encoding should overallocate at all. unicode2.diff is a modification where it runs over the string twice, counting the number of needed bytes the first time. This is likely slower (atleast if no reallocations occur), but doesn't waste that much memory (I notice that pymalloc will never copy objects when they shrink, to return the extra space). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-29 19:54 Message: Logged In: YES user_id=31435 Good eye, Martin! It's clearly possible for the unpatched code to write beyond the memory allocated. The one thing that doesn't jibe is that you said bp is 0x2, which means 3 of its 4 bytes are 0x00, but UTF-8 doesn't produce 0 bytes except for one per \u0000 input character. Right? So, if this routine is the cause, where are the 0 bytes coming from? (It could be test_unicode sets up a UTF-8 encoding case with several \u0000 characters, but if so I didn't stumble into it.) Plausible: when a new pymalloc "page" is allocated, the 40-byte chunks in it are *not* linked together at the start. Instead a NULL pointer is stored at just the start of "the first" 40-byte chunk, and pymalloc-- on subsequent mallocs --finds that NULL and incrementally carves out additional 40-byte chunks. So as a startup-- but not a steady-state --condition, the "next free block" pointers will very often be NULLs, and then if this is a little-endian machine, writing a single 2 byte at the start of a free block would lead to a bogus pointer value of 0x2. About a fix, I'm in favor of junking all the cleverness here, by allocating size*4 bytes from the start. It's overallocating in all normal cases already, so we're going to incur the expense of cutting the result string back anyway; how *much* we overallocate doesn't matter to speed, except that if we don't have to keep checking inside the loop, the code gets simpler and quicker and more robust. The loop should instead merely assert that cbWritten <= cbAllocated at the end of each trip. Had this been done from the start, a debug build would have assert-failed a few nanoseconds after the wild store. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 17:44 Message: Logged In: YES user_id=21627 I've found one source of troubles, see the attached unicode.diff. Guido's intuition was right; it was an UCS-4 problem: EncodeUTF8 would over-allocate 3*size bytes, but can actually write 4*size in the worst case, which occurs in test_unicode. I'll leave the patch for review and experiments; it fixes the problem for me. The existing adjustment for surrogates is pointless, IMO: for the surrogate pair, it will allocate 6 bytes UTF-8 in advance, which is more than actually needed. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 15:13 Message: Logged In: YES user_id=21627 It's a Heisenbug. I found that even slightest modifications to the Python source make it come and go, or appear at different places. On my system, the crashes normally occur in the first run (.pyc). So I don't think the order of make invocations is the source of the problem. It's likely as Tim says: somebody overwrites memory somewhere. Unfortunately, even though I can reproduce crashes for the same pool, for some reason, my gdb memory watches don't trigger. Tim's approach of checking whether a the value came from following the free list did not help, either: the bug disappeared under the change. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-29 14:01 Message: Logged In: YES user_id=6656 Hmm. I now think that the stuff about extension modules is almost certainly a read herring. What I said about "make && make altinstall" vs "make altinstall" still seems to be true, though. If you compile with --with-pydebug, you crash right at the end of the second (-O) run of compileall.py -- I suspect this is something else, but it might not be. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-29 13:29 Message: Logged In: YES user_id=6656 I don't know if these are helpful observations or not, but anyway: (1) it doesn't core without the --enable-unicode=ucs4 option (2) if you just run "make altinstall" the library files are installed *and compiled* before the dynamically linked modules are built. Then we don't crash. (3) if you run "make altinstall" again, we crash. If you initially ran "make && make install", we crash. (4) when we crash, it's not long after the unicode tests are compiled. Are these real clues or just red herrings? I'm afraid I can't tell :( ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-29 10:43 Message: Logged In: YES user_id=31435 Ouch. Boosted priority back to 5, since Martin can reproduce it. Alas, where pymalloc got called *from* is almost certainly irrelevant -- we're seeing the end result of earlier corruption. Note that pymalloc is unusually sensitive to off-by-1 stores, since the chunks it hands out are contiguous (there's no hidden bookkeeping padding between them). Plausible: an earlier bogus store went beyond the end of its allocated chunk, overwriting the "next free block" pointer at the start of a previously free()'ed chunk of the same size (rounded up to a multiple of 8; 40 bytes in this case). At the time this blows up, bp is supposed to point to a previously free()'ed chunk of size 40 bytes (if there were none free()'ed and available, the earlier "pool != pool- >nextpool" guard should have failed). The first 4 bytes (let's simplify by assuming this is a 32-bit box) of the free chunks link the free chunks together, most recently free()'ed at the start of the (singly linked) list. So the code at this point is intent on returning bp, and "pool- >freeblock = *(block **)bp" is setting the 40-byte-chunk list header's idea of the *next* available 40-byte chunk. But bp is bogus. The value of bp is gotten out of the free list headers, the static array usedpools. This mechanism is horridly obscure, an array of pointer pairs that, in effect, capture just the first two members of the pool_header struct, once for each chunk size. It's possible that someone is overwriting usedpools[4 + 4]- >freeblock directly with 2, but that seems unlikely. More likely is that a free() operation linked a 40-byte chunk into the list headed at usedpools[4+4]->freeblock correctly, and a later bad store overwrote the first 4 bytes of the free()'ed block with 2. Then the "pool- >freeblock = *(block **)bp)" near the start of an unexceptional pymalloc would copy the 2 into the list header's freeblock without complaint. The error wouldn't show up until a subsequent malloc tried to use it. So that's one idea to get closer to the cause: add code to dereference pool->freeblock, before the "return (void *) bp". If that blows up earlier, then the first four bytes of bp were corrupted, and that gives you a useful data breakpoint address for the next run. If it doesn't blow up earlier, the corruption will be harder to find, but let's count on being lucky at first . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 08:00 Message: Logged In: YES user_id=21627 Ok, I can reproduce it now; I did not 'make install' before. Here is a gdb back trace #0 _PyCore_ObjectMalloc (nbytes=33) at Objects/obmalloc.c:417 #1 0x805885c in PyString_FromString (str=0x816c6e8 "checkJoin") at Objects/stringobject.c:136 #2 0x805d772 in PyString_InternFromString (cp=0x816c6e8 "checkJoin") at Objects/stringobject.c:3640 #3 0x807c9c6 in com_addop_varname (c=0xbfffe87c, kind=0, name=0x816c6e8 "checkJoin") at Python/compile.c:939 #4 0x807de24 in com_atom (c=0xbfffe87c, n=0x816c258) at Python/compile.c:1478 #5 0x807f01c in com_power (c=0xbfffe87c, n=0x816c8b8) at Python/compile.c:1846 #6 0x807f545 in com_factor (c=0xbfffe87c, n=0x816c898) at Python/compile.c:1975 #7 0x807f56c in com_term (c=0xbfffe87c, n=0x816c878) at Python/compile.c:1985 #8 0x807f6bc in com_arith_expr (c=0xbfffe87c, n=0x816c858) at Python/compile.c:2020 #9 0x807f7dc in com_shift_expr (c=0xbfffe87c, n=0x816c838) at Python/compile.c:2046 #10 0x807f8fc in com_and_expr (c=0xbfffe87c, n=0x816c818) at Python/compile.c:2072 #11 0x807fa0c in com_xor_expr (c=0xbfffe87c, n=0x816c7f8) at Python/compile.c:2094 ... The access that crashes is *(block **)bp, since bp is 0x2. Not sure how that happens; I'll investigate (but would appreciate a clue). It seems that the pool chain got corrupted. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-29 06:52 Message: Logged In: YES user_id=6380 Aha! The --enable-unicode=ucs4 is more suspicious than the --with-pymalloc. I had missed that info when this was first reported. Not that I'm any closer to solving it... :-( ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-29 02:53 Message: Logged In: YES user_id=89016 OK, I did a "make distclean" which removed .o files and the build directory and redid a "./configure --enable- unicode=ucs4 --with-pymalloc && make && make altinstall". The build process still crashes in the same spot: Compiling /usr/local/lib/python2.2/test/test_urlparse.py ... make: *** [libinstall] Segmentation fault I also retried with a fresh untarred Python-2.2.tgz. This shows the same behaviour. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 01:23 Message: Logged In: YES user_id=21627 Atleast I cannot reproduce it, on SuSE 7.3. Can you retry this, building from a clean source tree (no .o files, no build directory)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:30 Message: Logged In: YES user_id=6380 My prediction: this is irreproducible. Lowering the priority accordingly. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-12-23 04:24 Message: Logged In: YES user_id=89016 Unfortunately no core file was generated. Can I somehow force core file generation? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-22 06:42 Message: Logged In: YES user_id=21627 Did that produce a core file? If so, can you attach a gdb backtrace as well? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470 From Mike Castle Wed Dec 12 21:56:51 2001 From: Mike Castle (Mike Castle) Date: Wed, 12 Dec 2001 13:56:51 -0800 Subject: [Python-bugs-list] mpzmodule fails to build with gmp-4.0 Message-ID: <20011212215651.GA10995@thune.mrc-home.com> gmp-4.0 is out. The following in Modules/mpzmodule.c is no longer valid: #if __GNU_MP__ + 0 == 2 #define GMP2 #define BITS_PER_MP_LIMB mp_bits_per_limb #else #define MPZ_GET_STR_BUG #include "gmp-mparam.h" #endif __GNU_MP__ is defined to be 4 now (it looks like in the previous versions, it should have been 3, but was 2 by mistake, so 3 was skipped for gmp.h) The whole set of defines at the top of mpzmodule.c probably needs review by someone who knows Python and GMP, so I'm not going to suggest any trivial patches. This was confirmed with 2.1.1. Not tried to build 2.2b2 yet. mrc -- Mike Castle dalgoda@ix.netcom.com www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal ("You are in a maze of twisty compiler features, all different"); -- gcc