2006-02-10T14:04:15Z Python links against the ncurses library which does not support UTF-8 output. The version of ncurses that supports UFT-8 is called "ncursesw". I have submitted a patch that lets python link agains ncursesw. It can be found here: http://sourceforge.net/tracker/index.php?func=detail&aid=1428494&group_id=5470&atid=305470 The Ubuntu python package dependencies will also have to be changed to use libncurses5w instead of libncurses5. Ian Ward UNCONFIRMED UNDECIDED Ian Ward Registry Administrators Ian Ward 2006-02-10T14:04:15Z Python links against the ncurses library which does not support UTF-8 output. The version of ncurses that supports UFT-8 is called "ncursesw". I have submitted a patch that lets python link agains ncursesw. It can be found here: http://sourceforge.net/tracker/index.php?func=detail&aid=1428494&group_id=5470&atid=305470 The Ubuntu python package dependencies will also have to be changed to use libncurses5w instead of libncurses5. 2000-06-16T23:33:00Z sf207608 Freshly built python: [mwh21@atrus build]$ PYTHONSTARTUP= ./python -U 'import site' failed; use -v for traceback Python 1.6a2 (#1, Jun 17 2000, 00:21:58) [GCC 2.95.1 19990816/Linux (release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> eval("1") Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: eval() argument 1 must be string or code object (this is also why the import site fails). exec is also broken. Michael Hudson REJECTED LOW M.-A. Lemburg Michael Hudson Michael Hudson 2000-06-16T23:33:00Z Freshly built python: [mwh21@atrus build]$ PYTHONSTARTUP= ./python -U 'import site' failed; use -v for traceback Python 1.6a2 (#1, Jun 17 2000, 00:21:58) [GCC 2.95.1 19990816/Linux (release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> eval("1") Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: eval() argument 1 must be string or code object (this is also why the import site fails). exec is also broken. Guido van Rossum 2000-06-26T19:19:00Z eval and exec need to support Unicode objects. This may be hard, and since -U is mostly experimental, I've given it a low priority. Tim Peters 2000-06-29T06:38:00Z Copied to Jitterbug on python.org, where it's bug 375. Closed here. Bug Importer 2001-11-18T01:10:00Z stjfsdgjvvnmbvvvvvv 2000-06-27T11:20:00Z sf208381 On Win32, os.listdir raises "No such process" when the directory does not exist. The error returned from GetLastError really is ERROR_PATH_NOT_FOUND, not ESRCH. Martin von Löwis REJECTED MEDIUM Tim Peters Martin von Löwis Martin von Löwis 2000-06-27T11:20:00Z On Win32, os.listdir raises "No such process" when the directory does not exist. The error returned from GetLastError really is ERROR_PATH_NOT_FOUND, not ESRCH. Tim Peters 2000-06-29T06:27:00Z Moved this to Jitterbug on python.org, and changed status here to Closed. It's bug 274 on Jitterbug. 2000-07-27T21:39:00Z sf210386 Jitterbug #38 Original User: klm@digicool.com When debugging with pdb exceptions are truncated, and useful information is often lost (at the most frustrating moments). The problem is that repr.py is used, and it has pretty severe default values for truncation, and no way to override them. The patch included below rectifies this, by (1) changing the Repr class to take keyword arguments on its initializer (including a handy 'factor', by which all the default values are simply multiplied), and (2) changing pdb.py to use it's own Repr instance, with a factor of 5 (picked, after many seconds of deep lack of thought, out of the air) for breathing room. Ken Jeremy Hylton REJECTED MEDIUM trash python-library Jeremy Hylton Jeremy Hylton 2000-07-27T21:39:00Z Jitterbug #38 Original User: klm@digicool.com When debugging with pdb exceptions are truncated, and useful information is often lost (at the most frustrating moments). The problem is that repr.py is used, and it has pretty severe default values for truncation, and no way to override them. The patch included below rectifies this, by (1) changing the Repr class to take keyword arguments on its initializer (including a handy 'factor', by which all the default values are simply multiplied), and (2) changing pdb.py to use it's own Repr instance, with a factor of 5 (picked, after many seconds of deep lack of thought, out of the air) for breathing room. Ken Jeremy Hylton 2000-07-27T21:40:00Z This looks like a good change, except that there should be a pdb command to change the factor setting on the repr. The sensible default Ken recommends will be good most of the time, but not every time. Jeremy Hylton 2000-07-31T21:03:00Z test bug from jitterbug -> sf conversion 2000-07-31T20:00:00Z sf210587 Jitterbug-Id%3 a 102 Submitted-By: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=%2 2 <Vladimir.Benes@pvt.cz> Date: Mon, 11 Oct 1999 13:00:07 +0200% 0aVersion: None OS: None Good afternoon, I have found a bug on Python 1.5.2. This bug doesn't occur on Python 1.5.1. Python version s and OS: - Python 1.5.1. at Debian GNU/Linux 2.0.36 - Python 1.5.2. at De bian GNU/Linux 2.2.9 Bug: Incorrect signal processing (Python 1.5.2). Process can assign procedure for signal processing. When process is wai ting at system call and this signal occur, then the signal assigned procedure is otherwise correctly completed but then waiting at system call is broken and process continues. Here is a simple program for demonstrate this bug: #!/usr/bin/python import signal import sys def signal_handle (signum, frame) : signal.signal(signal.SIGALRM, signal_handle) signal.alarm(2) print "signal" signal_handle(0,0) a=sys.stdin.readline() print "Line examined..." b=sys.stdin.readline%2 8) print "Line examined..." print a,b,"end" # end of example Correct behaviour: Message "Line examined..." occurs only after pr essing ENTER by user. Bug: Message "Line examined..." occurs immed iately after signal occured and procedure signal_handle finished. Output then look thus (when no input entered): signal signal Line examined. .. signal Line examined... end This bug appears at any signal o ccur and whatever process waiting at system call. Some system call even produces exception (e.g. waiting for data or connection on socket). Bug is perhaps caused by wrong seting "siginterrupt" on module signal. I have n't found any way how call in Python program "siginterrupt" for correct behavior of signal processing. Good bye, V. Benes **** **************************%2 a**************************% 2a****************** Ing. Vladimir Benes, pvt.net PVT, a.s., OZ Chomutov e-mail: vladimir.benes@pvt.cz , vladimir.benes@sms.paegas.cz *************** *****************************************************% 2a******* Audit trail: Mon Oct 11 18:12:13 1999 guido moved from incoming to open Bug Importer REJECTED LOW trash Bug Importer Bug Importer 2000-07-31T20:00:00Z Jitterbug-Id%3 a 102 Submitted-By: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=%2 2 <Vladimir.Benes@pvt.cz> Date: Mon, 11 Oct 1999 13:00:07 +0200% 0aVersion: None OS: None Good afternoon, I have found a bug on Python 1.5.2. This bug doesn't occur on Python 1.5.1. Python version s and OS: - Python 1.5.1. at Debian GNU/Linux 2.0.36 - Python 1.5.2. at De bian GNU/Linux 2.2.9 Bug: Incorrect signal processing (Python 1.5.2). Process can assign procedure for signal processing. When process is wai ting at system call and this signal occur, then the signal assigned procedure is otherwise correctly completed but then waiting at system call is broken and process continues. Here is a simple program for demonstrate this bug: #!/usr/bin/python import signal import sys def signal_handle (signum, frame) : signal.signal(signal.SIGALRM, signal_handle) signal.alarm(2) print "signal" signal_handle(0,0) a=sys.stdin.readline() print "Line examined..." b=sys.stdin.readline%2 8) print "Line examined..." print a,b,"end" # end of example Correct behaviour: Message "Line examined..." occurs only after pr essing ENTER by user. Bug: Message "Line examined..." occurs immed iately after signal occured and procedure signal_handle finished. Output then look thus (when no input entered): signal signal Line examined. .. signal Line examined... end This bug appears at any signal o ccur and whatever process waiting at system call. Some system call even produces exception (e.g. waiting for data or connection on socket). Bug is perhaps caused by wrong seting "siginterrupt" on module signal. I have n't found any way how call in Python program "siginterrupt" for correct behavior of signal processing. Good bye, V. Benes **** **************************%2 a**************************% 2a****************** Ing. Vladimir Benes, pvt.net PVT, a.s., OZ Chomutov e-mail: vladimir.benes@pvt.cz , vladimir.benes@sms.paegas.cz *************** *****************************************************% 2a******* Audit trail: Mon Oct 11 18:12:13 1999 guido moved from incoming to open 2000-07-31T20:05:00Z sf210589 Jitterbug-Id: 240 Submitted-By: kragen@pobox.com (Kragen Sitaker) Date: Fri, 17 Mar 2000 16:09:19 -0500 (EST) Version: None OS: None I'm building Python on NeXTStep; I've encountered three minor problems. - importdl.c by default on NeXTStep allows linking with Objective-C modules, which is cool. Unfortunately, properly supporting this requires adding -ObjC to the cc command line in the Makefile. - posixmodule.c doesn't #include anything that declares fsync() and doesn't declare it itself, but tries to reference it. Adding a declaration of fsync() fixes the problem. - test_strftime and test_time fail. test test_strftime failed -- Writing: 'Conflict for %j (julian day (001-366)):', expected: '' I suspect this may be a platform bug. Here's some of the output, which is 696 lines in full: strftime test for Fri Mar 17 12:53:20 2000 Strftime test, platform: next3_3, Python version: 1.5.2 Conflict for %j (julian day (001-366)): Expected 077, but got 076 Conflict for nonstandard '%c' format (near-asctime() format): Expected Fri Mar 17 12:53:20 2000, but got Fri Mar 17 12:53:20 2000 Conflict for nonstandard '%x' format (%m/%d/%y %H:%M:%S): Expected 03/17/00, but got Fri Mar 17 2000 Does not appear to support '%Z' format (time zone name) Conflict for nonstandard '%D' format (mm/dd/yy): Expected 03/17/00, but got ? Conflict for nonstandard '%e' format (day of month as number, blank padded ( 0-31)): Expected 17, but got ? Conflict for nonstandard '%h' format (abbreviated month name): Expected Mar, but got ? Conflict for nonstandard '%k' format (hour, blank padded ( 0-23)): Expected 12, but got ? Conflict for nonstandard '%n' format (newline character): Expected , but got ? Conflict for nonstandard '%r' format (%I:%M:%S %p): Expected 12:53:20 PM, but got ? Conflict for nonstandard '%R' format (%H:%M): Expected 12:53, but got ? Conflict for nonstandard '%s' format (seconds since the Epoch in UCT): Expected 953326400, but got ? Conflict for nonstandard '%t' format (tab character): Expected , but got ? Conflict for nonstandard '%T' format (%H:%M:%S): Expected 12:53:20, but got ? Conflict for nonstandard '%3y' format (year without century rendered using fieldwidth): Expected 000, but got ?y Conflict for %j (julian day (001-366)): Expected 327, but got 326 Conflict for %W (week number of the year (Mon 1st)): Expected 46, but got 47 Conflict for %j (julian day (001-366)): Expected 328, but got 327 Conflict for %j (julian day (001-366)): Expected 329, but got 328 Conflict for %j (julian day (001-366)): Expected 330, but got 329 test test_time failed -- Writing: 'time.mktime(time.localtime(t)) <> t', expected: '' (and that was all of the output from test_time. Presumably this is related to the strftime bugs --- perhaps the mythical Y2K leap-year bug?) I'm afraid I'm not sure what version of NeXTStep I'm on. 'arch' reports 'hppa'; 'cc --version' reports '2.5.8'; 'uname -a' reports 'Command not found'. I'm not trying to build a very sophisticated environment --- just the defaults. -- <kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/> The Internet stock bubble didn't burst on 1999-11-08. Hurrah! <URL:http://www.pobox.com/~kragen/bubble.html> The power didn't go out on 2000-01-01 either. :) Audit trail: Mon Apr 03 18:40:11 2000 guido changed notes Mon Apr 03 18:40:11 2000 guido moved from incoming to open Bug Importer REJECTED MEDIUM trash Bug Importer Bug Importer 2000-07-31T20:05:00Z Jitterbug-Id: 240 Submitted-By: kragen@pobox.com (Kragen Sitaker) Date: Fri, 17 Mar 2000 16:09:19 -0500 (EST) Version: None OS: None I'm building Python on NeXTStep; I've encountered three minor problems. - importdl.c by default on NeXTStep allows linking with Objective-C modules, which is cool. Unfortunately, properly supporting this requires adding -ObjC to the cc command line in the Makefile. - posixmodule.c doesn't #include anything that declares fsync() and doesn't declare it itself, but tries to reference it. Adding a declaration of fsync() fixes the problem. - test_strftime and test_time fail. test test_strftime failed -- Writing: 'Conflict for %j (julian day (001-366)):', expected: '' I suspect this may be a platform bug. Here's some of the output, which is 696 lines in full: strftime test for Fri Mar 17 12:53:20 2000 Strftime test, platform: next3_3, Python version: 1.5.2 Conflict for %j (julian day (001-366)): Expected 077, but got 076 Conflict for nonstandard '%c' format (near-asctime() format): Expected Fri Mar 17 12:53:20 2000, but got Fri Mar 17 12:53:20 2000 Conflict for nonstandard '%x' format (%m/%d/%y %H:%M:%S): Expected 03/17/00, but got Fri Mar 17 2000 Does not appear to support '%Z' format (time zone name) Conflict for nonstandard '%D' format (mm/dd/yy): Expected 03/17/00, but got ? Conflict for nonstandard '%e' format (day of month as number, blank padded ( 0-31)): Expected 17, but got ? Conflict for nonstandard '%h' format (abbreviated month name): Expected Mar, but got ? Conflict for nonstandard '%k' format (hour, blank padded ( 0-23)): Expected 12, but got ? Conflict for nonstandard '%n' format (newline character): Expected , but got ? Conflict for nonstandard '%r' format (%I:%M:%S %p): Expected 12:53:20 PM, but got ? Conflict for nonstandard '%R' format (%H:%M): Expected 12:53, but got ? Conflict for nonstandard '%s' format (seconds since the Epoch in UCT): Expected 953326400, but got ? Conflict for nonstandard '%t' format (tab character): Expected , but got ? Conflict for nonstandard '%T' format (%H:%M:%S): Expected 12:53:20, but got ? Conflict for nonstandard '%3y' format (year without century rendered using fieldwidth): Expected 000, but got ?y Conflict for %j (julian day (001-366)): Expected 327, but got 326 Conflict for %W (week number of the year (Mon 1st)): Expected 46, but got 47 Conflict for %j (julian day (001-366)): Expected 328, but got 327 Conflict for %j (julian day (001-366)): Expected 329, but got 328 Conflict for %j (julian day (001-366)): Expected 330, but got 329 test test_time failed -- Writing: 'time.mktime(time.localtime(t)) <> t', expected: '' (and that was all of the output from test_time. Presumably this is related to the strftime bugs --- perhaps the mythical Y2K leap-year bug?) I'm afraid I'm not sure what version of NeXTStep I'm on. 'arch' reports 'hppa'; 'cc --version' reports '2.5.8'; 'uname -a' reports 'Command not found'. I'm not trying to build a very sophisticated environment --- just the defaults. -- <kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/> The Internet stock bubble didn't burst on 1999-11-08. Hurrah! <URL:http://www.pobox.com/~kragen/bubble.html> The power didn't go out on 2000-01-01 either. :) Audit trail: Mon Apr 03 18:40:11 2000 guido changed notes Mon Apr 03 18:40:11 2000 guido moved from incoming to open Jeremy Hylton 2000-07-31T21:02:00Z test bug from jitterbug ->sf conversion 2000-07-31T20:12:00Z sf210590 What does the response page look like? How hard will it be to add jitterbug followup comments? Jeremy Hylton REJECTED MEDIUM trash python-library Jeremy Hylton Jeremy Hylton 2000-07-31T20:12:00Z What does the response page look like? How hard will it be to add jitterbug followup comments? 2000-07-31T20:20:00Z sf210592 Jitterbug-Id: 406 Submitted-By: howard_b_golden@yahoo.com Date: Thu, 20 Jul 2000 20:18:12 -0400 (EDT) Version: 1.5.2 OS: Windows 9x/NT/2000 On Windows 9x/NT/2000, os.system() doesn't return the exit code because COMMAND.COM doesn't. To make os.system() on Windows work like os.system() on Unix (a Good Idea-TM), implement os.system on Windows using code similar to what was suggested by Cary Evans in http://www.python.org/pipermail/python-list/1999-May/009409.html . (Note: It seems to me that this change is consistent with the recent change to posixmodule.c to make os.popen() work the same on Windows as Unix.) ==================================================================== Audit trail: Tue Jul 25 07:27:58 2000 guido moved from incoming to open Bug Importer REJECTED MEDIUM trash Bug Importer Bug Importer 2000-07-31T20:20:00Z Jitterbug-Id: 406 Submitted-By: howard_b_golden@yahoo.com Date: Thu, 20 Jul 2000 20:18:12 -0400 (EDT) Version: 1.5.2 OS: Windows 9x/NT/2000 On Windows 9x/NT/2000, os.system() doesn't return the exit code because COMMAND.COM doesn't. To make os.system() on Windows work like os.system() on Unix (a Good Idea-TM), implement os.system on Windows using code similar to what was suggested by Cary Evans in http://www.python.org/pipermail/python-list/1999-May/009409.html . (Note: It seems to me that this change is consistent with the recent change to posixmodule.c to make os.popen() work the same on Windows as Unix.) ==================================================================== Audit trail: Tue Jul 25 07:27:58 2000 guido moved from incoming to open Bug Importer 2000-07-31T20:45:00Z This is a test comment. Bug Importer 2000-07-31T20:53:00Z This is a test comment. Jeremy Hylton 2000-07-31T21:02:00Z test bug for jitterbug->sf conversion 2000-07-31T20:52:00Z sf210595 Jitterbug-Id: 296 Submitted-By: oli@andrich.net Date: Thu, 13 Apr 2000 15:18:07 -0400 (EDT) Version: 1.6a2 OS: Linux Mandrake 2.2.14-mdksmp Hi, I am currently evaluating Python 1.6 on my machine in order to be uptodate with the Linux distribution as soon as 1.6 final is released. The testsuite runs fine, just one test fails completely. test_fork1 When I run the test, it sometimes runs really fine (very seldom). Most of the time it hangs and uses nearly 100% of CPU time. The loop in the child prozess is completed successfully. n is 0 as it ought to be. But the os.waitpid call hangs for an indefinete time. This is strange, cause I can't reproduce this in an equivalent c code snippet. And without creation of the threads it works really fine and doesn't hang at all. Any idea? I am running a 2.2.14 Linux on a SMP machine (non SMP machine show the same behaviour). glibc 2.1.3. Bye, Oliver ==================================================================== Audit trail: Thu Apr 13 15:55:33 2000 fdrake sent reply 1 Thu Apr 13 15:55:45 2000 fdrake moved from incoming to open Bug Importer REJECTED MEDIUM trash Bug Importer Bug Importer 2000-07-31T20:52:00Z Jitterbug-Id: 296 Submitted-By: oli@andrich.net Date: Thu, 13 Apr 2000 15:18:07 -0400 (EDT) Version: 1.6a2 OS: Linux Mandrake 2.2.14-mdksmp Hi, I am currently evaluating Python 1.6 on my machine in order to be uptodate with the Linux distribution as soon as 1.6 final is released. The testsuite runs fine, just one test fails completely. test_fork1 When I run the test, it sometimes runs really fine (very seldom). Most of the time it hangs and uses nearly 100% of CPU time. The loop in the child prozess is completed successfully. n is 0 as it ought to be. But the os.waitpid call hangs for an indefinete time. This is strange, cause I can't reproduce this in an equivalent c code snippet. And without creation of the threads it works really fine and doesn't hang at all. Any idea? I am running a 2.2.14 Linux on a SMP machine (non SMP machine show the same behaviour). glibc 2.1.3. Bye, Oliver ==================================================================== Audit trail: Thu Apr 13 15:55:33 2000 fdrake sent reply 1 Thu Apr 13 15:55:45 2000 fdrake moved from incoming to open Bug Importer 2000-07-31T20:52:00Z From: Oliver Andrich <oli@rz-online.net> Subject: Re: test_fork1 hangs with 1.6a2 on Linux (PR#296) Date: Thu, 13 Apr 2000 23:38:08 +0200 Hi, I just checked the following to things. I patched the threading to work with GNU pth and get the same results. When I run the test script with Python 1.5.2 on the same machine, that means same glibc and so on, it works fine. I compared the threading code of Python 1.5.2 and 1.6.a2 and it doesn't seem to differ at all. Same for the posixcode as far it is relevant for the test. I am a little bit irritated by this. Best regards, Oliver On Thu, Apr 13, 2000 at 03:55:34PM -0400, Fred@python.org wrote: > Oliver, > We're aware of it, but haven't figured out the exact problem yet. If you can > provide additional information on the observed behavior, that would be good. I > get three different behaviors on a Mandrake 7.1 SMP machine: works, segfaults, > and blocks. I'm suspecting a pthread implementation problem, but haven't had > enough time to really dig into it sufficiently to be sure. > > > -Fred Bug Importer 2000-07-31T20:52:00Z From: Oliver Andrich <oli@rz-online.net> Subject: Re: test_fork1 hangs with 1.6a2 on Linux (PR#296) Date: Thu, 13 Apr 2000 22:26:08 +0200 Hi, well what I have discovered so far is. - Normal optimizations for Mandrake packages results in a sure segfault. - Normal python optimizations (jst calling make) causes hangs sometimes works. A look at ps ax shows, that there exist 6 active python "processes" (the parent process and 5 threads) and one defunct python process (the child). So thet child terminates correctly as I already mentioned. But the os.waitpid doesn't discover that the child has already exited. Things I will to tonight: - write a complete cversion of the testcode - compile python against another thread library - compile python against the most recent glibc snapshot - compile python on a RedHat 6.1 system Hopefully I get some more insights. Sadly, I am not good at c debugging, as I am a Python code by choice and a C coder who has written his last C code five years ago (a really program not just a Python extension ;-). Best regards, Oliver On Thu, Apr 13, 2000 at 03:55:34PM -0400, Fred@python.org wrote: > Oliver, > We're aware of it, but haven't figured out the exact problem yet. If you can > provide additional information on the observed behavior, that would be good. I > get three different behaviors on a Mandrake 7.1 SMP machine: works, segfaults, > and blocks. I'm suspecting a pthread implementation problem, but haven't had > enough time to really dig into it sufficiently to be sure. > > > -Fred Bug Importer 2000-07-31T20:52:00Z From: Fred L. Drake, Jr. <bugs-py@python.org> Subject: Re: test_fork1 hangs with 1.6a2 on Linux (PR#296) Date: Thu Apr 13 15:55:33 2000 Oliver, We're aware of it, but haven't figured out the exact problem yet. If you can provide additional information on the observed behavior, that would be good. I get three different behaviors on a Mandrake 7.1 SMP machine: works, segfaults, and blocks. I'm suspecting a pthread implementation problem, but haven't had enough time to really dig into it sufficiently to be sure. -Fred 2000-07-31T20:56:00Z sf210597 Jitterbug-Id: 296 Submitted-By: oli@andrich.net Date: Thu, 13 Apr 2000 15:18:07 -0400 (EDT) Version: 1.6a2 OS: Linux Mandrake 2.2.14-mdksmp Hi, I am currently evaluating Python 1.6 on my machine in order to be uptodate with the Linux distribution as soon as 1.6 final is released. The testsuite runs fine, just one test fails completely. test_fork1 When I run the test, it sometimes runs really fine (very seldom). Most of the time it hangs and uses nearly 100% of CPU time. The loop in the child prozess is completed successfully. n is 0 as it ought to be. But the os.waitpid call hangs for an indefinete time. This is strange, cause I can't reproduce this in an equivalent c code snippet. And without creation of the threads it works really fine and doesn't hang at all. Any idea? I am running a 2.2.14 Linux on a SMP machine (non SMP machine show the same behaviour). glibc 2.1.3. Bye, Oliver ==================================================================== Audit trail: Thu Apr 13 15:55:33 2000 fdrake sent reply 1 Thu Apr 13 15:55:45 2000 fdrake moved from incoming to open Bug Importer REJECTED MEDIUM trash Bug Importer Bug Importer 2000-07-31T20:56:00Z Jitterbug-Id: 296 Submitted-By: oli@andrich.net Date: Thu, 13 Apr 2000 15:18:07 -0400 (EDT) Version: 1.6a2 OS: Linux Mandrake 2.2.14-mdksmp Hi, I am currently evaluating Python 1.6 on my machine in order to be uptodate with the Linux distribution as soon as 1.6 final is released. The testsuite runs fine, just one test fails completely. test_fork1 When I run the test, it sometimes runs really fine (very seldom). Most of the time it hangs and uses nearly 100% of CPU time. The loop in the child prozess is completed successfully. n is 0 as it ought to be. But the os.waitpid call hangs for an indefinete time. This is strange, cause I can't reproduce this in an equivalent c code snippet. And without creation of the threads it works really fine and doesn't hang at all. Any idea? I am running a 2.2.14 Linux on a SMP machine (non SMP machine show the same behaviour). glibc 2.1.3. Bye, Oliver ==================================================================== Audit trail: Thu Apr 13 15:55:33 2000 fdrake sent reply 1 Thu Apr 13 15:55:45 2000 fdrake moved from incoming to open Bug Importer 2000-07-31T20:56:00Z From: Oliver Andrich <oli@rz-online.net> Subject: Re: test_fork1 hangs with 1.6a2 on Linux (PR#296) Date: Thu, 13 Apr 2000 23:38:08 +0200 Hi, I just checked the following to things. I patched the threading to work with GNU pth and get the same results. When I run the test script with Python 1.5.2 on the same machine, that means same glibc and so on, it works fine. I compared the threading code of Python 1.5.2 and 1.6.a2 and it doesn't seem to differ at all. Same for the posixcode as far it is relevant for the test. I am a little bit irritated by this. Best regards, Oliver On Thu, Apr 13, 2000 at 03:55:34PM -0400, Fred@python.org wrote: > Oliver, > We're aware of it, but haven't figured out the exact problem yet. If you can > provide additional information on the observed behavior, that would be good. I > get three different behaviors on a Mandrake 7.1 SMP machine: works, segfaults, > and blocks. I'm suspecting a pthread implementation problem, but haven't had > enough time to really dig into it sufficiently to be sure. > > > -Fred Bug Importer 2000-07-31T20:56:00Z From: Fred L. Drake, Jr. <bugs-py@python.org> Subject: Re: test_fork1 hangs with 1.6a2 on Linux (PR#296) Date: Thu Apr 13 15:55:33 2000 Oliver, We're aware of it, but haven't figured out the exact problem yet. If you can provide additional information on the observed behavior, that would be good. I get three different behaviors on a Mandrake 7.1 SMP machine: works, segfaults, and blocks. I'm suspecting a pthread implementation problem, but haven't had enough time to really dig into it sufficiently to be sure. -Fred Bug Importer 2000-07-31T20:56:00Z From: Oliver Andrich <oli@rz-online.net> Subject: Re: test_fork1 hangs with 1.6a2 on Linux (PR#296) Date: Thu, 13 Apr 2000 22:26:08 +0200 Hi, well what I have discovered so far is. - Normal optimizations for Mandrake packages results in a sure segfault. - Normal python optimizations (jst calling make) causes hangs sometimes works. A look at ps ax shows, that there exist 6 active python "processes" (the parent process and 5 threads) and one defunct python process (the child). So thet child terminates correctly as I already mentioned. But the os.waitpid doesn't discover that the child has already exited. Things I will to tonight: - write a complete cversion of the testcode - compile python against another thread library - compile python against the most recent glibc snapshot - compile python on a RedHat 6.1 system Hopefully I get some more insights. Sadly, I am not good at c debugging, as I am a Python code by choice and a C coder who has written his last C code five years ago (a really program not just a Python extension ;-). Best regards, Oliver On Thu, Apr 13, 2000 at 03:55:34PM -0400, Fred@python.org wrote: > Oliver, > We're aware of it, but haven't figured out the exact problem yet. If you can > provide additional information on the observed behavior, that would be good. I > get three different behaviors on a Mandrake 7.1 SMP machine: works, segfaults, > and blocks. I'm suspecting a pthread implementation problem, but haven't had > enough time to really dig into it sufficiently to be sure. > > > -Fred Jeremy Hylton 2000-07-31T21:01:00Z leftover from jitterbug -> sf conversion 2000-07-31T21:05:00Z sf210598 Jitterbug-Id: 101 Submitted-By: flight@mathi.uni-heidelberg.de Date: Mon, 11 Oct 1999 15:10:37 +0200 Version: 1.5.2 OS: Debian GNU/Linux potato [This was recorded as Debian bug#46993, cf. http://www.debian.org/Bugs/db/46/46993.html] Package: python-base Version: 1.5.2-6 Severity: normal On Unix systems, py_compile.compile() (and therefore compileall.py) won't compile files with DOS/Windows lineendings (CR+LF). Commands like "import" or "exec" will work, though. The problem seems to be that py_compile.compile read()'s the whole file at once and passes it as a string to __builtin__.compile(), while "import" calls __builtin__.compile() for a file, so that __builtin__.compile seems to do some magic while reading the file. For a quick testcase: import __builtin__ f=open("test.py","w") f.write('print "Hello"\015\012') f.close() f=open("test.py") c=f.read() f.close() __builtin__.compile(c,"test.py","exec") results in: Traceback (innermost last): File "<stdin>", line 1, in ? File "<stdin>", line 9, in x File "<string>", line 1 print "Hello" ^ SyntaxError: invalid syntax while "import test" works fine and results in test.pyc. Certainly the file.read() in py_compile.compile() isn't good enough for this case. Gregor ==================================================================== Audit trail: Mon Oct 11 18:12:13 1999 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM Martin von Löwis parser-compiler Bug Importer Bug Importer 2000-07-31T21:05:00Z Jitterbug-Id: 101 Submitted-By: flight@mathi.uni-heidelberg.de Date: Mon, 11 Oct 1999 15:10:37 +0200 Version: 1.5.2 OS: Debian GNU/Linux potato [This was recorded as Debian bug#46993, cf. http://www.debian.org/Bugs/db/46/46993.html] Package: python-base Version: 1.5.2-6 Severity: normal On Unix systems, py_compile.compile() (and therefore compileall.py) won't compile files with DOS/Windows lineendings (CR+LF). Commands like "import" or "exec" will work, though. The problem seems to be that py_compile.compile read()'s the whole file at once and passes it as a string to __builtin__.compile(), while "import" calls __builtin__.compile() for a file, so that __builtin__.compile seems to do some magic while reading the file. For a quick testcase: import __builtin__ f=open("test.py","w") f.write('print "Hello"\015\012') f.close() f=open("test.py") c=f.read() f.close() __builtin__.compile(c,"test.py","exec") results in: Traceback (innermost last): File "<stdin>", line 1, in ? File "<stdin>", line 9, in x File "<string>", line 1 print "Hello" ^ SyntaxError: invalid syntax while "import test" works fine and results in test.pyc. Certainly the file.read() in py_compile.compile() isn't good enough for this case. Gregor ==================================================================== Audit trail: Mon Oct 11 18:12:13 1999 guido moved from incoming to open Mark Hammond 2000-08-31T06:28:00Z Sorry, but I dont feel able to resolve this in time for 2.0 beta or final, so giving back to Jeremy to punt back off. If post 2.0 is OK, give it on back! Martin von Löwis 2000-09-05T21:42:00Z Fixed in 101425, see http://sourceforge.net/patch/?func=detailpatch&patch_id=101425&group_id=5470 Tim Peters 2000-09-15T05:33:00Z Assigned back to Martin. I see that the patch in question has been Accepted, so please change this bug to Fixed and Closed after you commit the patch and Close it. 2000-07-31T21:05:00Z sf210599 Jitterbug-Id: 102 Submitted-By: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" <Vladimir.Benes@pvt.cz> Date: Mon, 11 Oct 1999 13:00:07 +0200 Version: None OS: None Good afternoon, I have found a bug on Python 1.5.2. This bug doesn't occur on Python 1.5.1. Python versions and OS: - Python 1.5.1. at Debian GNU/Linux 2.0.36 - Python 1.5.2. at Debian GNU/Linux 2.2.9 Bug: Incorrect signal processing (Python 1.5.2). Process can assign procedure for signal processing. When process is waiting at system call and this signal occur, then the signal assigned procedure is otherwise correctly completed but then waiting at system call is broken and process continues. Here is a simple program for demonstrate this bug: #!/usr/bin/python import signal import sys def signal_handle(signum, frame) : signal.signal(signal.SIGALRM, signal_handle) signal.alarm(2) print "signal" signal_handle(0,0) a=sys.stdin.readline() print "Line examined..." b=sys.stdin.readline() print "Line examined..." print a,b,"end" # end of example Correct behaviour: Message "Line examined..." occurs only after pressing ENTER by user. Bug: Message "Line examined..." occurs immediately after signal occured and procedure signal_handle finished. Output then look thus (when no input entered): signal signal Line examined... signal Line examined... end This bug appears at any signal occur and whatever process waiting at system call. Some system call even produces exception (e.g. waiting for data or connection on socket). Bug is perhaps caused by wrong seting "siginterrupt" on module signal. I haven't found any way how call in Python program "siginterrupt" for correct behavior of signal processing. Good bye, V. Benes **************************************************************************** Ing. Vladimir Benes, pvt.net PVT, a.s., OZ Chomutov e-mail: vladimir.benes@pvt.cz, vladimir.benes@sms.paegas.cz **************************************************************************** ==================================================================== Audit trail: Mon Oct 11 18:12:13 1999 guido moved from incoming to open Bug Importer REJECTED MEDIUM feature-request Guido van Rossum python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:05:00Z Jitterbug-Id: 102 Submitted-By: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" <Vladimir.Benes@pvt.cz> Date: Mon, 11 Oct 1999 13:00:07 +0200 Version: None OS: None Good afternoon, I have found a bug on Python 1.5.2. This bug doesn't occur on Python 1.5.1. Python versions and OS: - Python 1.5.1. at Debian GNU/Linux 2.0.36 - Python 1.5.2. at Debian GNU/Linux 2.2.9 Bug: Incorrect signal processing (Python 1.5.2). Process can assign procedure for signal processing. When process is waiting at system call and this signal occur, then the signal assigned procedure is otherwise correctly completed but then waiting at system call is broken and process continues. Here is a simple program for demonstrate this bug: #!/usr/bin/python import signal import sys def signal_handle(signum, frame) : signal.signal(signal.SIGALRM, signal_handle) signal.alarm(2) print "signal" signal_handle(0,0) a=sys.stdin.readline() print "Line examined..." b=sys.stdin.readline() print "Line examined..." print a,b,"end" # end of example Correct behaviour: Message "Line examined..." occurs only after pressing ENTER by user. Bug: Message "Line examined..." occurs immediately after signal occured and procedure signal_handle finished. Output then look thus (when no input entered): signal signal Line examined... signal Line examined... end This bug appears at any signal occur and whatever process waiting at system call. Some system call even produces exception (e.g. waiting for data or connection on socket). Bug is perhaps caused by wrong seting "siginterrupt" on module signal. I haven't found any way how call in Python program "siginterrupt" for correct behavior of signal processing. Good bye, V. Benes **************************************************************************** Ing. Vladimir Benes, pvt.net PVT, a.s., OZ Chomutov e-mail: vladimir.benes@pvt.cz, vladimir.benes@sms.paegas.cz **************************************************************************** ==================================================================== Audit trail: Mon Oct 11 18:12:13 1999 guido moved from incoming to open Bug Importer 2000-07-31T21:05:00Z From: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" <Vladimir.Benes@pvt.cz> Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Date: Wed, 13 Oct 1999 16:34:39 +0200 >... >Concluding, I think Vladimir is better off not to use signal handlers >in the way he is using them now. Python's emulation of signal >semantics is sufficiently different from C that you can't rely on the >same behavior. (And note that in C, signal handlers are usually >broken anyway; e.g. the code you write, which prints something inside >the signal handler, is broken on C too because you don't know the >state of stdout when the handler is invoked.) Well, meantioned programs were only very simple demos for demonstrate incorrect signal processing. But exists a large range of meaningful programs where is necessary both synchronous and asynchronous signal processing - and signal can be triggered whenever. Example of C symbolic structure this programs: .... int event_flag; void trigger_signal(int signum) { // asynchonous signal processing event_flag = MY_EVENT; // only flag set } void initialize_signal(int sig) { event_flag = NO_EVENT; // initialize signal(sig, trigger_signal); } int main() { initialize_signal(SIGTERM); while (1) { my_func(); // synchronous signal processing: if (event_flag==MY_EVENT) my_sync_trigger(); } } Signal can be raised whenever when function my_func runs => flag event_flag is then set but my_func "does't know" his and continues at own processing. Signal should not influence my_func becouse my_func "doesn't know" both this signal and flag event_flag. Function event_flag can wait for system call (read, write, connect, etc). Incoming signal should not finish this waiting after trigger_signal function processing. So my_func is independed on signal processing and "does'nt know" signals. Program tests the flag at any "safe" location(s). If this flag is set, program run specific synchronous signal processing. It can be for example safe program end or synchronous SIGALRM processing. Python programs can by compose similar this example. >I looked at what could be different between 1.5.1 and 1.5.2, and found >that the call to siginterrupt() to disable restarting system calls was >added after 1.5.1. Given the alternatives, I think I like the 1.5.2 >behavior better than the 1.5.1 behavior. But then old Python programs writen for Python 1.5.1 are not compatible with Python 1.5.2. in this feature. I thing that better way is to let this behavior equal as in Python 1.5.1. but allow programs to call either new function "siginterrupt" at signal module (more flexible solution) or any else new function at signal module to set behavior signal processing by Your idea. Good bye, V. Benes Bug Importer 2000-07-31T21:05:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Date: Wed, 13 Oct 1999 08:57:25 -0400 > JH> ...... I'm not sure that the > JH> behavior you're seeing is a bug; it is the behavior I would expect. > JH> Slow system calls are interrupted, returning EINTR, when a signal > JH> occurs. > [Vladimir] > I'am sure that this behavior is bug becouse: When I first thought about this, I agreed with Vladimir. If you look careful at his code, readline() is returning "" when the alarm goes off; this can't be right, because it's not an end of file. It should either raise an exception (EINTR) or return one line of valid data. On the other hand, whatever solution is chosen should be careful that other signals raise exceptions; in particular you want SIGINT (^C) to be translated to a KeyboardError exception. Since the C code in readline() can't tell which signal was trapped or whether the handler raised an exception, it has two choices, both of which are bad: - Raise an IOError exception, honoring the EINTR. Unfortunately, in the SIGINT/^C case, the handler will run after this exception is raised, and it will raise KeyboardError. The Python program will *probably* see the KeyboardError exception, but it is not guaranteed that the signal handler is run immediately. (The Python-level signal handler is run only after the Python virtual machine finishes the current instruction, i.e. after the readline() completes.) - Continue to read a line, ignoring the EINTR. Unfortunately, this would mean that the user has to type ^C followed by Return to interrupt the program! An alternative solution would be to arrange for the Python-level interrupt handler to execute inside the readline() method, and to restart the read only when it raises no exception; but this would require a massive code rewrite (you'd want this behavior in any place that does a blocking I/O operation). Concluding, I think Vladimir is better off not to use signal handlers in the way he is using them now. Python's emulation of signal semantics is sufficiently different from C that you can't rely on the same behavior. (And note that in C, signal handlers are usually broken anyway; e.g. the code you write, which prints something inside the signal handler, is broken on C too because you don't know the state of stdout when the handler is invoked.) I looked at what could be different between 1.5.1 and 1.5.2, and found that the call to siginterrupt() to disable restarting system calls was added after 1.5.1. Given the alternatives, I think I like the 1.5.2 behavior better than the 1.5.1 behavior. --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-07-31T21:05:00Z From: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" <Vladimir.Benes@pvt.cz> Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Date: Wed, 13 Oct 1999 09:19:44 +0200 From: Jeremy Hylton <jeremy@cnri.reston.va.us> To: Vladimir.Benes@pvt.cz <Vladimir.Benes@pvt.cz> Cc: python-bugs-list@python.org <python-bugs-list@python.org>; bugs-py@python.org <bugs-py@python.org> Date: 12. 10. 1999 18:04 Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) JH>I see the behavior you report for 1.5.2 on Solaris 2.6. You don't write whether this bug appeared there. JH> ...... I'm not sure that the JH> behavior you're seeing is a bug; it is the behavior I would expect. JH> Slow system calls are interrupted, returning EINTR, when a signal JH> occurs. I'am sure that this behavior is bug becouse: 1. I wrote the same program in C language (see below). 2. I ran this program at the same machine where the Python *) program works incorrectly. 3. Behavior of C program is correct (line scan is ended only when user press ENTER and this end is independed on signal). => The C program works correct and the same Python *) program fails at the same platform. Base run of program should by independed on signal processing except program terminating signals. It's independed at C program but incorrect processed by Python *) programs. *) only Python 1.5.2; Python 1.5.1 here works correctly Here is the mentioned program: #include<stdio.h> #include <unistd.h> #include <signal.h> void signal_handle(int signum) { signal(SIGALRM, signal_handle); alarm(2); printf("signal\n\r"); } void main(void) { char a[100], b[100]; signal_handle(0); scanf("%s",&a); printf("Line examined...\n\r"); scanf("%s",&b); printf("Line examined...\n\r"); printf("%s\t%s\tend\n\r", a, b); } VB> Bug is perhaps caused by wrong seting "siginterrupt" on VB> module signal. I haven't found any way how call in Python VB> program "siginterrupt" for correct behavior of signal VB> processing. JH> Perhaps the signal module for Python should be extended to support JH> siginterrupt, but it sounds like it will only reduce the number of JH> system calls that can be interrupted. ....... Sorry, I wrong formulated possible couse of bug. I will try to specify my idea: It looks that there is any wrong calling "siginterupt" on signal module. Python libraries doesn't allow me to try correct this bug by calling "siginiterrupt" in my program before signal setting. But the best way is to reapir bug on signal module. Good bye, V. Benes Bug Importer 2000-07-31T21:05:00Z From: Jeremy Hylton <jeremy@cnri.reston.va.us> Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Date: Tue, 12 Oct 1999 12:04:42 -0400 (EDT) >>>>> "VB" == Vladimir Benes <Vladimir.Benes@pvt.cz> writes: VB> Bug: Incorrect signal processing (Python 1.5.2). Process can VB> assign procedure for signal processing. When process is waiting VB> at system call and this signal occur, then the signal assigned VB> procedure is otherwise correctly completed but then waiting at VB> system call is broken and process continues. [example program] I see the behavior you report for 1.5.2 on Solaris 2.6. VB> This bug appears at any signal occur and whatever process VB> waiting at system call. Some system call even produces exception VB> (e.g. waiting for data or connection on socket). These issues always occur in twos don't they. There was a similar question posted on comp.lang.python yesterday. I'm not sure that the behavior you're seeing is a bug; it is the behavior I would expect. Slow system calls are interrupted, returning EINTR, when a signal occurs. VB> Bug is perhaps caused by wrong seting "siginterrupt" on VB> module signal. I haven't found any way how call in Python VB> program "siginterrupt" for correct behavior of signal VB> processing. Perhaps the signal module for Python should be extended to support siginterrupt, but it sounds like it will only reduce the number of system calls that can be interrupted. The Solaris man page says: NOTES Use of these interfaces should be restricted to only appli- cations written on BSD platforms. Use of these interfaces with any of the system libraries or in multi-threaded appli- cations is unsupported. It doesn't sound particularly safe. Jeremy Guido van Rossum 2000-08-10T18:45:00Z Sorry, I can't take this. It's an issue though! There are a bunch of signal related bugs in Linux... Guido van Rossum 2000-09-13T10:42:00Z Confirmed with python 2.0b1 on Linux. Note that this is *not* the same bug as #110611 -- here, threads and readline don't matter (confirmed). Guido van Rossum 2000-09-16T01:01:00Z Something should be done, but it's not easy. I've added this to PEP 42 as a feature request. 2000-07-31T21:05:00Z sf210600 Jitterbug-Id: 113 Submitted-By: Toby J Sargeant <tjs@longford.cs.monash.edu.au> Date: Tue, 19 Oct 1999 13:15:23 +1000 Version: None OS: None [this is a repost of something I sent last week, which didn't receive any responses. python 1.5.2 coredumps (due to an assertion failure) when running the re module tests, if it is compiled with -DPy_DEBUG] System configuration: Python 1.5.2 (#1, Oct 13 1999, 14:15:09) gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) Linux ephedra 2.2.7 #2 Thu May 6 14:10:35 EST 1999 i686 unknown glibc-2.1.1 (Redhat 6.0) Compile: ./configure --prefix=/usr/local/contrib/python-debug --with-threads make OPT='-DPy_DEBUG' [toby@ephedra Python-1.5.2]$ ./python Lib/test/test_re.py Adding parser accelerators ... Done. 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 Running re_tests test suite Fatal Python error: UNREF invalid object Aborted (core dumped) This happens with or without --with-threads Stack trace follows: #3 0x8072c43 in Py_FatalError (msg=0x80a027b "UNREF invalid object") at pythonrun.c:1036 #4 0x80524f1 in _Py_ForgetReference (op=0x8125a88) at object.c:658 #5 0x8052534 in _Py_Dealloc (op=0x8125a88) at object.c:680 #6 0x805d729 in eval_code2 (co=0x8139260, globals=0x8135728, locals=0x0, args=0x80f0398, argcount=1, kws=0x80f039c, kwcount=0, defs=0x80da4e4, defcount=1, owner=0x0) at ceval.c:1656 #7 0x805d505 in eval_code2 (co=0x8109150, globals=0x80f44e8, locals=0x80f44e8, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1612 #8 0x805965e in PyEval_EvalCode (co=0x8109150, globals=0x80f44e8, locals=0x80f44e8) at ceval.c:324 #9 0x8072836 in run_node (n=0x80e5f88, filename=0xbffffda9 "Lib/test/test_re.py", globals=0x80f44e8, locals=0x80f44e8) at pythonrun.c:887 #10 0x80727e5 in run_err_node (n=0x80e5f88, filename=0xbffffda9 "Lib/test/test_re.py", globals=0x80f44e8, locals=0x80f44e8) at pythonrun.c:872 #11 0x80727af in PyRun_File (fp=0x80c4b08, filename=0xbffffda9 "Lib/test/test_re.py", start=257, globals=0x80f44e8, locals=0x80f44e8) at pythonrun.c:860 #12 0x8071cfa in PyRun_SimpleFile (fp=0x80c4b08, filename=0xbffffda9 "Lib/test/test_re.py") at pythonrun.c:570 #13 0x807189f in PyRun_AnyFile (fp=0x80c4b08, filename=0xbffffda9 "Lib/test/test_re.py") at pythonrun.c:451 #14 0x804fb9c in Py_Main (argc=2, argv=0xbffffca4) at main.c:287 #15 0x804f5f0 in main (argc=2, argv=0xbffffca4) at python.c:12 ==================================================================== Audit trail: Tue Oct 19 09:23:13 1999 guido changed notes Tue Oct 19 09:23:13 1999 guido changed notification Tue Oct 19 09:23:13 1999 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:05:00Z Jitterbug-Id: 113 Submitted-By: Toby J Sargeant <tjs@longford.cs.monash.edu.au> Date: Tue, 19 Oct 1999 13:15:23 +1000 Version: None OS: None [this is a repost of something I sent last week, which didn't receive any responses. python 1.5.2 coredumps (due to an assertion failure) when running the re module tests, if it is compiled with -DPy_DEBUG] System configuration: Python 1.5.2 (#1, Oct 13 1999, 14:15:09) gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) Linux ephedra 2.2.7 #2 Thu May 6 14:10:35 EST 1999 i686 unknown glibc-2.1.1 (Redhat 6.0) Compile: ./configure --prefix=/usr/local/contrib/python-debug --with-threads make OPT='-DPy_DEBUG' [toby@ephedra Python-1.5.2]$ ./python Lib/test/test_re.py Adding parser accelerators ... Done. 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 Running re_tests test suite Fatal Python error: UNREF invalid object Aborted (core dumped) This happens with or without --with-threads Stack trace follows: #3 0x8072c43 in Py_FatalError (msg=0x80a027b "UNREF invalid object") at pythonrun.c:1036 #4 0x80524f1 in _Py_ForgetReference (op=0x8125a88) at object.c:658 #5 0x8052534 in _Py_Dealloc (op=0x8125a88) at object.c:680 #6 0x805d729 in eval_code2 (co=0x8139260, globals=0x8135728, locals=0x0, args=0x80f0398, argcount=1, kws=0x80f039c, kwcount=0, defs=0x80da4e4, defcount=1, owner=0x0) at ceval.c:1656 #7 0x805d505 in eval_code2 (co=0x8109150, globals=0x80f44e8, locals=0x80f44e8, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1612 #8 0x805965e in PyEval_EvalCode (co=0x8109150, globals=0x80f44e8, locals=0x80f44e8) at ceval.c:324 #9 0x8072836 in run_node (n=0x80e5f88, filename=0xbffffda9 "Lib/test/test_re.py", globals=0x80f44e8, locals=0x80f44e8) at pythonrun.c:887 #10 0x80727e5 in run_err_node (n=0x80e5f88, filename=0xbffffda9 "Lib/test/test_re.py", globals=0x80f44e8, locals=0x80f44e8) at pythonrun.c:872 #11 0x80727af in PyRun_File (fp=0x80c4b08, filename=0xbffffda9 "Lib/test/test_re.py", start=257, globals=0x80f44e8, locals=0x80f44e8) at pythonrun.c:860 #12 0x8071cfa in PyRun_SimpleFile (fp=0x80c4b08, filename=0xbffffda9 "Lib/test/test_re.py") at pythonrun.c:570 #13 0x807189f in PyRun_AnyFile (fp=0x80c4b08, filename=0xbffffda9 "Lib/test/test_re.py") at pythonrun.c:451 #14 0x804fb9c in Py_Main (argc=2, argv=0xbffffca4) at main.c:287 #15 0x804f5f0 in main (argc=2, argv=0xbffffca4) at python.c:12 ==================================================================== Audit trail: Tue Oct 19 09:23:13 1999 guido changed notes Tue Oct 19 09:23:13 1999 guido changed notification Tue Oct 19 09:23:13 1999 guido moved from incoming to open Jeremy Hylton 2000-08-02T00:51:00Z Current version of Python build correctly with Py_DEBUG defined, so I assume this is closed. 2000-07-31T21:05:00Z sf210601 Jitterbug-Id: 125 Submitted-By: Nikolas Kauer <kauer@pheno.physics.wisc.edu> Date: Tue, 9 Nov 1999 18:43:09 -0600 (CST) Version: None OS: None Dear Guido, (please read first paragraph) I discovered a Python problem that so far nobody could really explain, since a precise explanation requires in-depth knowledge about the internals of the Python interpreter. I HAVE DONE MY HOMEWORK and have posted this message to various mailing lists including comp.lang.python, python-help@python.org and pyapache-devel@msg.com.mx and communicated with several people individually, getting some guesses (appended after the problem description), but no competent answer, yet. I'm sure you know somebody who could provide that answer, and would appreciate it if you could FORWARD THIS MESSAGE to such a person. Best regards, Nikolas PS I'm sure you heard this a thousand times, nevertheless I like Python and enjoy programming in Python. I think it's a beautifully designed programming language. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I run the following test script on Apache-1.3.6/PyApache-4.19 on Linux 2.2.5 (RedHat 6.0) with only one httpd child and the module mxDateTime compiled into Python/PyApache, so there is no dynamic loading of a shared library. ------------------------------------------------------------ print "Content-type: text/plain" print print import sys, traceback # just checking ... if not sys.modules.has_key('mxDateTime'): print 'No module mxDateTime in sys.modules' print import mxDateTime print "sys.modules['mxDateTime'] = ", sys.modules['mxDateTime'] print "mxDateTime.__dict__['now'] = ", mxDateTime.__dict__['now'] print print "calling mxDateTime.now() gives:", try: print mxDateTime.now() except: print traceback.print_exc(file=sys.stdout) -------------------------------------------------------------- First time http://localhost/mytest.py gives ******************************* No module mxDateTime in sys.modules sys.modules['mxDateTime'] = <module 'mxDateTime' (built-in)> mxDateTime.__dict__['now'] = <built-in function now> calling mxDateTime.now() gives: 1999-10-28 18:28:49.75 ******************************* And again http://localhost/mytest.py now gives ******************************* No module mxDateTime in sys.modules sys.modules['mxDateTime'] = <module 'mxDateTime' (built-in)> mxDateTime.__dict__['now'] = <built-in function now> calling mxDateTime.now() gives: Traceback (innermost last): File "/local/web/alpha/docroot/mytest.py", line 16, in ? print mxDateTime.now() TypeError: call of non-function (type None) ******************************* After that experience, I eliminated all dependencies on module DateTime/mxDateTime in my Python code, but now I get the same error whenever something in module MySQLdb is accessed for the second time ... The mxDateTime author Marc Lemburg <mal@lemburg.com> writes: "[...] indicates that PyApache (or perhaps the Python finalizer) has cleared the module's namespace... which is bad, since extension modules can typically only initialize themselves *once*." Marc writes further: "[T]his is really odd: the 'now' symbol still refers to the existing function while the module seems to return None as attribute." The PyApache coordinator Lele Gaifax <lele@seldati.it> writes: "I can confirm that the problem lives in the cleanup mechanism. Python clears up its dictionaries, and doesn't allow a reinit, as Marc pointed out. This is not a PyApache fault: you can get the very same result running the pysrv demo [...]. In fact, every use of such modules mixed to multiple interpreters should cause the problem." Apparently, the fact that a module works with regular Python does not guarantee that it also works with PyApache (or pysrv). Lele Gaifax writes: "[...]I cannot see a way out, if not digging in Python's internals. [D]oes someone know if the problem has been raised before in the Python community?" Please, could someone with Python internals expertise explain this issue? How can I tell in advance if an extension module will work with PyApache? Is it possible to trick Python into cleanly re-initializing a module? Is there any hope that I can run my existing Web site with the Python interpreter embedded into Apache's httpd? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ More insights from this past week: Lele Gaifax writes: "Well, I seems to have tracked it down to the cache you use on Python's time module. I changed the function mxDateTime_now, where's the only reference to that module, to use `PyImport_AddModule ("time")' instead and extracting the dictionary from its result instead from Python_time_module, that I left alone. That function returns a borrowed reference to the module object, *provided* it is already loaded. Since this is done at mxDateTime's initialization, this is probably safe, but it needs to be checked... Anyway, so patched the module does not break PyApache, [...]" Marc Lemburg replies: "That's interesting: the time module's namespace is probably cleared during the Fini code stage. This would change the interpretation of the error. What you see is the error produced by the internals of the now() function and not related to the mxDateTime module namespace itself. Since time.time is the only function I really use from the Python time module perhaps caching only the function would do the trick. BTW, when finalization occurrs, is mxDateTime_Cleanup() being called ? It should reset the global reference to the time module (at least that's what my current code does): [code] Something else I could do is move time module lookup from the initmxDateTime() function into now() itself in case that helps. [...] I would guess that the setup mxODBC + mxDateTime has the same problems related to mxODBC holding a reference to mxDateTime." Any help in form of diagnostics, explanations and suggestions would be greatly appreciated. Nikolas ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Some ideas from python-help@python.org: Mark Hammond <mhammond@skippinet.com.au> writes: "If I understand the problem correct, it is simply that Python can not handle multiple Py_Init()/Py_Finalize() calls. Doing a Py_Finalize() cleans things up, but another Py_Init() can not restore everything back to a working state. I agree this is a problem, and it has ben brought up before. I suffer the same problem with the COM extensions. Ideally this needs to be fixed properly, but it is not trivial to do so - the entire module init process would need to be re-thought. The only solution I can think of is to get Apache to never finalize Python. Of course, I may be completely off-track here..." Martin von Loewis <loewis@informatik.hu-berlin.de> writes: "I think the problem is different. PyApache does *not* invoke Py_Finalize(*), but Py_EndInterpreter. This does PyImport_Cleanup, then PyInterpreterState_Delete. This is where I got stuck: The PyImport_Cleanup iterates over the interpreter-state's module list, which is then cleared, and completely discarded. I did not actually find the place where state is preserved across interpreters, so the problem can't possibly happen :-> (*) Of course, Apache eventually does Py_Finalize, when the whole server is shut down. Each individual CGI only goes through Py_NewInterpreter/Py_EndInterpreter." ==================================================================== Audit trail: Fri Dec 03 10:21:06 1999 guido changed notes Fri Dec 03 10:21:07 1999 guido moved from incoming to open Fri Dec 03 10:21:47 1999 guido changed notes Bug Importer FIXRELEASED MEDIUM M.-A. Lemburg python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:05:00Z Jitterbug-Id: 125 Submitted-By: Nikolas Kauer <kauer@pheno.physics.wisc.edu> Date: Tue, 9 Nov 1999 18:43:09 -0600 (CST) Version: None OS: None Dear Guido, (please read first paragraph) I discovered a Python problem that so far nobody could really explain, since a precise explanation requires in-depth knowledge about the internals of the Python interpreter. I HAVE DONE MY HOMEWORK and have posted this message to various mailing lists including comp.lang.python, python-help@python.org and pyapache-devel@msg.com.mx and communicated with several people individually, getting some guesses (appended after the problem description), but no competent answer, yet. I'm sure you know somebody who could provide that answer, and would appreciate it if you could FORWARD THIS MESSAGE to such a person. Best regards, Nikolas PS I'm sure you heard this a thousand times, nevertheless I like Python and enjoy programming in Python. I think it's a beautifully designed programming language. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I run the following test script on Apache-1.3.6/PyApache-4.19 on Linux 2.2.5 (RedHat 6.0) with only one httpd child and the module mxDateTime compiled into Python/PyApache, so there is no dynamic loading of a shared library. ------------------------------------------------------------ print "Content-type: text/plain" print print import sys, traceback # just checking ... if not sys.modules.has_key('mxDateTime'): print 'No module mxDateTime in sys.modules' print import mxDateTime print "sys.modules['mxDateTime'] = ", sys.modules['mxDateTime'] print "mxDateTime.__dict__['now'] = ", mxDateTime.__dict__['now'] print print "calling mxDateTime.now() gives:", try: print mxDateTime.now() except: print traceback.print_exc(file=sys.stdout) -------------------------------------------------------------- First time http://localhost/mytest.py gives ******************************* No module mxDateTime in sys.modules sys.modules['mxDateTime'] = <module 'mxDateTime' (built-in)> mxDateTime.__dict__['now'] = <built-in function now> calling mxDateTime.now() gives: 1999-10-28 18:28:49.75 ******************************* And again http://localhost/mytest.py now gives ******************************* No module mxDateTime in sys.modules sys.modules['mxDateTime'] = <module 'mxDateTime' (built-in)> mxDateTime.__dict__['now'] = <built-in function now> calling mxDateTime.now() gives: Traceback (innermost last): File "/local/web/alpha/docroot/mytest.py", line 16, in ? print mxDateTime.now() TypeError: call of non-function (type None) ******************************* After that experience, I eliminated all dependencies on module DateTime/mxDateTime in my Python code, but now I get the same error whenever something in module MySQLdb is accessed for the second time ... The mxDateTime author Marc Lemburg <mal@lemburg.com> writes: "[...] indicates that PyApache (or perhaps the Python finalizer) has cleared the module's namespace... which is bad, since extension modules can typically only initialize themselves *once*." Marc writes further: "[T]his is really odd: the 'now' symbol still refers to the existing function while the module seems to return None as attribute." The PyApache coordinator Lele Gaifax <lele@seldati.it> writes: "I can confirm that the problem lives in the cleanup mechanism. Python clears up its dictionaries, and doesn't allow a reinit, as Marc pointed out. This is not a PyApache fault: you can get the very same result running the pysrv demo [...]. In fact, every use of such modules mixed to multiple interpreters should cause the problem." Apparently, the fact that a module works with regular Python does not guarantee that it also works with PyApache (or pysrv). Lele Gaifax writes: "[...]I cannot see a way out, if not digging in Python's internals. [D]oes someone know if the problem has been raised before in the Python community?" Please, could someone with Python internals expertise explain this issue? How can I tell in advance if an extension module will work with PyApache? Is it possible to trick Python into cleanly re-initializing a module? Is there any hope that I can run my existing Web site with the Python interpreter embedded into Apache's httpd? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ More insights from this past week: Lele Gaifax writes: "Well, I seems to have tracked it down to the cache you use on Python's time module. I changed the function mxDateTime_now, where's the only reference to that module, to use `PyImport_AddModule ("time")' instead and extracting the dictionary from its result instead from Python_time_module, that I left alone. That function returns a borrowed reference to the module object, *provided* it is already loaded. Since this is done at mxDateTime's initialization, this is probably safe, but it needs to be checked... Anyway, so patched the module does not break PyApache, [...]" Marc Lemburg replies: "That's interesting: the time module's namespace is probably cleared during the Fini code stage. This would change the interpretation of the error. What you see is the error produced by the internals of the now() function and not related to the mxDateTime module namespace itself. Since time.time is the only function I really use from the Python time module perhaps caching only the function would do the trick. BTW, when finalization occurrs, is mxDateTime_Cleanup() being called ? It should reset the global reference to the time module (at least that's what my current code does): [code] Something else I could do is move time module lookup from the initmxDateTime() function into now() itself in case that helps. [...] I would guess that the setup mxODBC + mxDateTime has the same problems related to mxODBC holding a reference to mxDateTime." Any help in form of diagnostics, explanations and suggestions would be greatly appreciated. Nikolas ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Some ideas from python-help@python.org: Mark Hammond <mhammond@skippinet.com.au> writes: "If I understand the problem correct, it is simply that Python can not handle multiple Py_Init()/Py_Finalize() calls. Doing a Py_Finalize() cleans things up, but another Py_Init() can not restore everything back to a working state. I agree this is a problem, and it has ben brought up before. I suffer the same problem with the COM extensions. Ideally this needs to be fixed properly, but it is not trivial to do so - the entire module init process would need to be re-thought. The only solution I can think of is to get Apache to never finalize Python. Of course, I may be completely off-track here..." Martin von Loewis <loewis@informatik.hu-berlin.de> writes: "I think the problem is different. PyApache does *not* invoke Py_Finalize(*), but Py_EndInterpreter. This does PyImport_Cleanup, then PyInterpreterState_Delete. This is where I got stuck: The PyImport_Cleanup iterates over the interpreter-state's module list, which is then cleared, and completely discarded. I did not actually find the place where state is preserved across interpreters, so the problem can't possibly happen :-> (*) Of course, Apache eventually does Py_Finalize, when the whole server is shut down. Each individual CGI only goes through Py_NewInterpreter/Py_EndInterpreter." ==================================================================== Audit trail: Fri Dec 03 10:21:06 1999 guido changed notes Fri Dec 03 10:21:07 1999 guido moved from incoming to open Fri Dec 03 10:21:47 1999 guido changed notes Mark Hammond 2000-08-14T06:31:00Z Assigning to MAL - it involves mxODBC and Apache on a Linux box, so surely he is more qualified :-) I'm inclined to mark this is irreproducible, but maybe Marc has had further insights. M.-A. Lemburg 2000-08-14T10:31:00Z The problem you describe is an artifact of the way mxDateTime tries to reuse the time.time() API available through the standard Python time module. I think I have fixed the problem in my latest version. If you're interested I can email you a pre-release copy to test it against PyApache. M.-A. Lemburg 2000-08-29T21:12:00Z This was a bug in mxDateTime < 1.3.0 and will be hopefully be fixed with the new upcoming relase 1.4.0. A pre-release is available at: http://starship.python.net/~lemburg/mxDateTime-1.4.0-prerelease.zip in case someone wants to test it. The bug doesn't have anything to do with Python internals, so I'm closing it. 2000-07-31T21:05:00Z sf210602 Jitterbug-Id: 146 Submitted-By: dgudeman@azstarnet.com Date: Fri, 3 Dec 1999 18:11:12 -0500 (EST) Version: 1.52 OS: all (only verified on Windows 95) Please send email to confirm that you received this... I have found 2.5 bugs in xmllib.py and am contributing a patch for 1.5 of them. Bug #1 (fixed in patch): handle_entityref() is never called. Bug #1.5 (addressed in patch): handle_entityref() doesn't handle the built-in named character refs correctly. It passes them on to handle_data() as an unresolved charref. This is half a bug because it isn't a bug until you apply the patch to fix #1. Also, whoever maintains xmllib may not like my fix for this one because I just skip the call to handle_charref(). I don't think it should be called in this case, but reasonable people may differ. Bug #2: The documentation states that handle_doctype() takes two arguments but it really takes 4. I think the correct solution to this is to fix the doc, not the function. Sorry, my windows diff will not produce context diffs, but this is pretty trivial: 333,340c333 < if self.entitydefs.has_key(name): < self.rawdata = rawdata = rawdata[:res.start(0)] + self.entitydefs[name] + rawdata[i:] < n = len(rawdata) < i = res.start(0) < else: < self.syntax_error("reference to unknown entity `&%s;'" % name) < self.unknown_entityref(name) < self.lineno = self.lineno + string.count(res.group(0), '\n') --- > self.handle_entityref(name) 706,710c707,711 < entitydefs = {'lt': '&#60;', # must use charref < 'gt': '&#62;', < 'amp': '&#38;', # must use charref < 'quot': '&#34;', < 'apos': '&#39;', --- > entitydefs = {'lt': '<', # must use charref > 'gt': '>', > 'amp': '&', # must use charref > 'quot': '"', > 'apos': "'", I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. ==================================================================== Audit trail: Fri Dec 03 19:26:38 1999 guido changed notes Fri Dec 03 19:26:38 1999 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM Sjoerd Mullender python-library Bug Importer Bug Importer 2000-07-31T21:05:00Z Jitterbug-Id: 146 Submitted-By: dgudeman@azstarnet.com Date: Fri, 3 Dec 1999 18:11:12 -0500 (EST) Version: 1.52 OS: all (only verified on Windows 95) Please send email to confirm that you received this... I have found 2.5 bugs in xmllib.py and am contributing a patch for 1.5 of them. Bug #1 (fixed in patch): handle_entityref() is never called. Bug #1.5 (addressed in patch): handle_entityref() doesn't handle the built-in named character refs correctly. It passes them on to handle_data() as an unresolved charref. This is half a bug because it isn't a bug until you apply the patch to fix #1. Also, whoever maintains xmllib may not like my fix for this one because I just skip the call to handle_charref(). I don't think it should be called in this case, but reasonable people may differ. Bug #2: The documentation states that handle_doctype() takes two arguments but it really takes 4. I think the correct solution to this is to fix the doc, not the function. Sorry, my windows diff will not produce context diffs, but this is pretty trivial: 333,340c333 < if self.entitydefs.has_key(name): < self.rawdata = rawdata = rawdata[:res.start(0)] + self.entitydefs[name] + rawdata[i:] < n = len(rawdata) < i = res.start(0) < else: < self.syntax_error("reference to unknown entity `&%s;'" % name) < self.unknown_entityref(name) < self.lineno = self.lineno + string.count(res.group(0), '\n') --- > self.handle_entityref(name) 706,710c707,711 < entitydefs = {'lt': '&#60;', # must use charref < 'gt': '&#62;', < 'amp': '&#38;', # must use charref < 'quot': '&#34;', < 'apos': '&#39;', --- > entitydefs = {'lt': '<', # must use charref > 'gt': '>', > 'amp': '&', # must use charref > 'quot': '"', > 'apos': "'", I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. ==================================================================== Audit trail: Fri Dec 03 19:26:38 1999 guido changed notes Fri Dec 03 19:26:38 1999 guido moved from incoming to open Fred Drake 2000-07-31T23:22:00Z The documentation has already been adjusted accordingly. Sjoerd, could you check on the rest of the issues here? Sjoerd Mullender 2000-08-01T08:37:00Z The bugs have already been fixed in the current version of xmllib.py. I also don't agree with the change of the entitydefs. The comment "must use charref" were there for a reason. The XML spec requires that substituted text gets rescanned for more character and entity references. The handle_entityref method had been removed earlier since it wasn't used. So, I reject these fixes. Sjoerd Mullender 2000-08-01T11:01:00Z See my previous comment for this bug (which I wrote when I wasn't allowed to change the status of this bug report). 2000-07-31T21:05:00Z sf210603 Jitterbug-Id: 156 Submitted-By: piers@cs.su.oz.au Date: Thu, 9 Dec 1999 17:09:50 -0500 (EST) Version: 1.5.2 OS: Solaris/Linux/win95 The Tkinter winfo_visualsavailable method fails if there is only one visual available, as the code assumes a list is returned, when in fact Tcl/Tk returns a string in the form '{truecolor 24}' ==================================================================== Audit trail: Tue Dec 14 17:15:16 1999 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM Fredrik Lundh tkinter Bug Importer Bug Importer 2000-07-31T21:05:00Z Jitterbug-Id: 156 Submitted-By: piers@cs.su.oz.au Date: Thu, 9 Dec 1999 17:09:50 -0500 (EST) Version: 1.5.2 OS: Solaris/Linux/win95 The Tkinter winfo_visualsavailable method fails if there is only one visual available, as the code assumes a list is returned, when in fact Tcl/Tk returns a string in the form '{truecolor 24}' ==================================================================== Audit trail: Tue Dec 14 17:15:16 1999 guido moved from incoming to open 2000-07-31T21:05:00Z sf210604 Jitterbug-Id: 160 Submitted-By: gpk@bell-labs.com Date: Tue, 14 Dec 1999 10:02:54 -0500 (EST) Version: 1.5.2 OS: Solaris 2.6 make install in the python distribution on Solaris 2.6 will terminate if ranlib is not in the search path. Ranlib is obsolete in solaris 2.x, and is not needed, the functionality being pulled into ar(1). I saw this problem when installing as a different user than the one I compiled as, so it's probably not important if your search path doesn't change. Man mage follows: man ranlib User Commands ranlib(1) NAME ranlib - convert archives to random libraries SYNOPSIS /usr/ccs/bin/ranlib archive DESCRIPTION ranlib was used in SunOS 4.x to add a table of contents to archive libraries, which converted each archive to a form that could be linked more rapidly. This is no longer needed as the ar(1) command automatically provides all the func- tionality ranlib used to provide. This script is provided as a convenience for software developers who need to maintain Makefiles that are portable across a variety of operating systems. EXIT STATUS ranlib has exit status 0. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: __________________________________ | ATTRIBUTE TYPE| ATTRIBUTE VALUE| |__________________________________ | Availability | SUNWbtool | |_______________|_________________| SEE ALSO ar(1), ar(4), attributes(5) SunOS 5.6 Last change: 13 Apr 1995 1 ==================================================================== Audit trail: Tue Dec 14 17:12:31 1999 guido moved from incoming to open Bug Importer REJECTED LOW platform-specific Thomas Wouters build Bug Importer Bug Importer 2000-07-31T21:05:00Z Jitterbug-Id: 160 Submitted-By: gpk@bell-labs.com Date: Tue, 14 Dec 1999 10:02:54 -0500 (EST) Version: 1.5.2 OS: Solaris 2.6 make install in the python distribution on Solaris 2.6 will terminate if ranlib is not in the search path. Ranlib is obsolete in solaris 2.x, and is not needed, the functionality being pulled into ar(1). I saw this problem when installing as a different user than the one I compiled as, so it's probably not important if your search path doesn't change. Man mage follows: man ranlib User Commands ranlib(1) NAME ranlib - convert archives to random libraries SYNOPSIS /usr/ccs/bin/ranlib archive DESCRIPTION ranlib was used in SunOS 4.x to add a table of contents to archive libraries, which converted each archive to a form that could be linked more rapidly. This is no longer needed as the ar(1) command automatically provides all the func- tionality ranlib used to provide. This script is provided as a convenience for software developers who need to maintain Makefiles that are portable across a variety of operating systems. EXIT STATUS ranlib has exit status 0. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: __________________________________ | ATTRIBUTE TYPE| ATTRIBUTE VALUE| |__________________________________ | Availability | SUNWbtool | |_______________|_________________| SEE ALSO ar(1), ar(4), attributes(5) SunOS 5.6 Last change: 13 Apr 1995 1 ==================================================================== Audit trail: Tue Dec 14 17:12:31 1999 guido moved from incoming to open Thomas Wouters 2000-08-02T10:10:00Z This *looks* solved in the current CVS tree, probably because of an updated 'autoconf'. From the configure log, running on our single Solaris box, SunOS 5.6: checking for ranlib... : checking for ar... ar If it doesn't work for you, try setting the 'RANLIB' environment variable to ':' or 'true' before running configure. Does that fix things ? 2000-07-31T21:05:00Z sf210605 Jitterbug-Id: 161 Submitted-By: Guido van Rossum <guido@CNRI.Reston.VA.US> Date: Thu, 16 Dec 1999 15:49:26 -0500 Version: None OS: None ------- Forwarded Message Date: Thu, 16 Dec 1999 13:48:20 +1100 From: Jonathan Giddy <jon@dgs.monash.edu.au> To: guido@python.org Subject: Tkinter inconsistency (missing methods) In Tkinter.py, most scrollable widgets support [xy]view_moveto and [xy]view_scroll, in addition to a basic [xy]view method. However, the Text widget is missing these additional methods. Thanks, Jon. ------- End of Forwarded Message ==================================================================== Audit trail: Wed Jan 12 18:30:41 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM feature-request Fredrik Lundh tkinter Bug Importer Bug Importer 2000-07-31T21:05:00Z Jitterbug-Id: 161 Submitted-By: Guido van Rossum <guido@CNRI.Reston.VA.US> Date: Thu, 16 Dec 1999 15:49:26 -0500 Version: None OS: None ------- Forwarded Message Date: Thu, 16 Dec 1999 13:48:20 +1100 From: Jonathan Giddy <jon@dgs.monash.edu.au> To: guido@python.org Subject: Tkinter inconsistency (missing methods) In Tkinter.py, most scrollable widgets support [xy]view_moveto and [xy]view_scroll, in addition to a basic [xy]view method. However, the Text widget is missing these additional methods. Thanks, Jon. ------- End of Forwarded Message ==================================================================== Audit trail: Wed Jan 12 18:30:41 2000 guido moved from incoming to open 2000-07-31T21:05:00Z sf210606 Jitterbug-Id: 162 Submitted-By: dwr2@ix.netcom.com Date: Sun, 19 Dec 1999 08:38:21 -0500 (EST) Version: 1.5 OS: Windows 95 When accessing os.environ under Windows 95/NT/etc., lower-case environment variable names are automatically converted to upper-case before use. However, ntpath.expandvars does not accept lower-case variable names. This is inconsistent. This also happens in dospath.expandvars and may happen in os2path.expandvars. Here is a Python session demonstrating the problem: >>> import os >>> os.name 'nt' >>> os.environ['abc']='xyz' >>> os.environ['abc'] 'xyz' >>> os.path.expandvars('$abc') '' >>> os.path.expandvars('$ABC') 'xyz' >>> Note that you can access os.environ using a lower-case name, but you must use upper-case for os.path.expandvars (-->ntpath.expandvars). This can easily be fixed by changing "os.environ.has_key(var)" to "os.environ.has_key(string.upper(key))" in two places in each of ntpath.expandvars, dospath.expandvars, and possibly os2path.expandvars. Another solution would be to add the following function to os._Environ, in the "if name in ('os2', 'nt', 'dos')" block: def has_key(self, key): return UserDict.UserDict.has_key(self, string.upper(key)) The latter solution seems better to me, but I don't know the possible negative ramifications of making such a change to a class used in so many places. (On the other had, it is consistent with the definitions of _Environ.__getitem__ and _Environ.__setitem__.) Further argument that lower-case should be accepted in ntpath.expandvars: A DOS window opened in Windows 95 expands a lower-case variable name, despite the actual variable name being stored in upper-case: C:\WINDOWS>set abc=xyz C:\WINDOWS>set [...(most of variable list elided)...] ABC=xyz C:\WINDOWS>echo %abc% xyz ==================================================================== Audit trail: Mon Jan 17 09:05:54 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM Fred Drake windows Bug Importer Bug Importer 2000-07-31T21:05:00Z Jitterbug-Id: 162 Submitted-By: dwr2@ix.netcom.com Date: Sun, 19 Dec 1999 08:38:21 -0500 (EST) Version: 1.5 OS: Windows 95 When accessing os.environ under Windows 95/NT/etc., lower-case environment variable names are automatically converted to upper-case before use. However, ntpath.expandvars does not accept lower-case variable names. This is inconsistent. This also happens in dospath.expandvars and may happen in os2path.expandvars. Here is a Python session demonstrating the problem: >>> import os >>> os.name 'nt' >>> os.environ['abc']='xyz' >>> os.environ['abc'] 'xyz' >>> os.path.expandvars('$abc') '' >>> os.path.expandvars('$ABC') 'xyz' >>> Note that you can access os.environ using a lower-case name, but you must use upper-case for os.path.expandvars (-->ntpath.expandvars). This can easily be fixed by changing "os.environ.has_key(var)" to "os.environ.has_key(string.upper(key))" in two places in each of ntpath.expandvars, dospath.expandvars, and possibly os2path.expandvars. Another solution would be to add the following function to os._Environ, in the "if name in ('os2', 'nt', 'dos')" block: def has_key(self, key): return UserDict.UserDict.has_key(self, string.upper(key)) The latter solution seems better to me, but I don't know the possible negative ramifications of making such a change to a class used in so many places. (On the other had, it is consistent with the definitions of _Environ.__getitem__ and _Environ.__setitem__.) Further argument that lower-case should be accepted in ntpath.expandvars: A DOS window opened in Windows 95 expands a lower-case variable name, despite the actual variable name being stored in upper-case: C:\WINDOWS>set abc=xyz C:\WINDOWS>set [...(most of variable list elided)...] ABC=xyz C:\WINDOWS>echo %abc% xyz ==================================================================== Audit trail: Mon Jan 17 09:05:54 2000 guido moved from incoming to open Fred Drake 2000-09-07T17:30:00Z Fixed at some point in the past. Tests OK using 2.0b1 on Win2K. 2000-07-31T21:05:00Z sf210607 Jitterbug-Id: 181 Submitted-By: cha@tandberg.no Date: Wed, 12 Jan 2000 09:49:29 -0500 (EST) Version: 1.5.2 OS: Windows NT4.0 The telnet.close() object does not close the telnet session. Session will only be closed after a timeout on the remote side. ==================================================================== Audit trail: Wed Jan 12 18:29:38 2000 guido changed notes Wed Jan 12 18:29:38 2000 guido changed notification Wed Jan 12 18:29:38 2000 guido moved from incoming to open Bug Importer REJECTED MEDIUM irreproducible Guido van Rossum python-library Bug Importer Bug Importer 2000-07-31T21:05:00Z Jitterbug-Id: 181 Submitted-By: cha@tandberg.no Date: Wed, 12 Jan 2000 09:49:29 -0500 (EST) Version: 1.5.2 OS: Windows NT4.0 The telnet.close() object does not close the telnet session. Session will only be closed after a timeout on the remote side. ==================================================================== Audit trail: Wed Jan 12 18:29:38 2000 guido changed notes Wed Jan 12 18:29:38 2000 guido changed notification Wed Jan 12 18:29:38 2000 guido moved from incoming to open Skip Montanaro 2000-08-24T01:50:00Z Replied to the submitter asking for a short script that fails. I don't run Windows so I may not be able to track this down. Skip Montanaro 2000-09-04T14:54:00Z Never did get any response from the submitter. This was apparently originally submitted back in January. I'm simply going to bounce this back to Tim since he at least runs Windows... Tim Peters 2000-09-15T05:23:00Z Assigned to Guido, cause it looks like telnetlib.py may be his code, he also has Windows, and-- unlike me --may actually know of a machine he can telnet *to* (I've never used this stuff, & the BeOpen machines don't telnet for me). The .close() method certainly appears to be closing the underlying socket. Guido van Rossum 2000-09-15T15:10:00Z Best I can tell, the connection is correctly closed by the close() method. I telnetted into a Unix machine from a Win98 SE machine (I have no NT here) and checked with netstat that the connection existed. Then I called the close() method. Then netstat showed the connection as closed for about 1 second and then no longer had it. 2000-07-31T21:05:00Z sf210608 Jitterbug-Id: 182 Submitted-By: akuchlin@mems-exchange.org Date: Wed, 12 Jan 2000 17:12:22 -0500 (EST) Version: CVS version OS: Solaris 2.6 I wanted to use the TCP_NODELAY socket option, but it wasn't found in the socket module, even though socketmodule.c contains: #ifdef TCP_NODELAY insint(d, "TCP_NODELAY", TCP_NODELAY); #endif "man tcp" on Solaris says that TCP_NODELAY is defined in netinet/tcp.h, and the Open Groups Unix98 spec agrees (http://www.opengroup.org/onlinepubs/009619199/ninettcp.htm). socketmodule.c doesn't include that header file. Fix: #include <netinet/tcp.h> in socketmodule.c. But are there Unix platforms which don't have that header, and will break? (Perhaps the configure script could check for it.) ==================================================================== Audit trail: Wed Jan 12 18:30:41 2000 guido moved from incoming to open Bug Importer REJECTED LOW platform-specific Thomas Wouters build Bug Importer Bug Importer 2000-07-31T21:05:00Z Jitterbug-Id: 182 Submitted-By: akuchlin@mems-exchange.org Date: Wed, 12 Jan 2000 17:12:22 -0500 (EST) Version: CVS version OS: Solaris 2.6 I wanted to use the TCP_NODELAY socket option, but it wasn't found in the socket module, even though socketmodule.c contains: #ifdef TCP_NODELAY insint(d, "TCP_NODELAY", TCP_NODELAY); #endif "man tcp" on Solaris says that TCP_NODELAY is defined in netinet/tcp.h, and the Open Groups Unix98 spec agrees (http://www.opengroup.org/onlinepubs/009619199/ninettcp.htm). socketmodule.c doesn't include that header file. Fix: #include <netinet/tcp.h> in socketmodule.c. But are there Unix platforms which don't have that header, and will break? (Perhaps the configure script could check for it.) ==================================================================== Audit trail: Wed Jan 12 18:30:41 2000 guido moved from incoming to open Thomas Wouters 2000-08-02T10:28:00Z Seems to work, on my Solaris 2.6 test-box (though I had to tweak around some other problems! These are likely caused by the screwed setup, so I'm not 100% sure it is fixed. But it Works For Me.) 2000-07-31T21:05:00Z sf210609 Jitterbug-Id: 187 Submitted-By: aa8vb@yahoo.com Date: Mon, 24 Jan 2000 11:19:11 -0500 (EST) Version: 1.5.2 OS: IRIX 6.5 This came up a few weeks ago, and bit again in the dumbdbm module last week. In the dumbdbm module in 1.5.2: '\0'*(npos-pos) (npos-pos) on some OSs will be a long int. However, the '*' operator won't handle a long int. I can't think of a reason why 'a'*10L should be invalid, for example. At issue a few weeks ago was long ints and the '%' operator. For example: >>> str( 0x80000000L ) '2147483648L' >>> "%ld" % 0x80000000L OverflowError: long int too long to convert >>> hex( 0x80000000L ) '0x80000000L' >>> "%lX" % 0x80000000L OverflowError: long int too long to convert Couldn't % use hex() and str() under the hood, for instance? ==================================================================== Audit trail: Mon Jan 24 14:28:42 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM Ka-Ping Yee python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:05:00Z Jitterbug-Id: 187 Submitted-By: aa8vb@yahoo.com Date: Mon, 24 Jan 2000 11:19:11 -0500 (EST) Version: 1.5.2 OS: IRIX 6.5 This came up a few weeks ago, and bit again in the dumbdbm module last week. In the dumbdbm module in 1.5.2: '\0'*(npos-pos) (npos-pos) on some OSs will be a long int. However, the '*' operator won't handle a long int. I can't think of a reason why 'a'*10L should be invalid, for example. At issue a few weeks ago was long ints and the '%' operator. For example: >>> str( 0x80000000L ) '2147483648L' >>> "%ld" % 0x80000000L OverflowError: long int too long to convert >>> hex( 0x80000000L ) '0x80000000L' >>> "%lX" % 0x80000000L OverflowError: long int too long to convert Couldn't % use hex() and str() under the hood, for instance? ==================================================================== Audit trail: Mon Jan 24 14:28:42 2000 guido moved from incoming to open Martin von Löwis 2000-09-16T13:57:00Z I believe the first issue is resolved in 2.0b1; '\0' * 10L does work. Martin von Löwis 2000-09-16T23:41:00Z A patch for the formatting problem in in http://sourceforge.net/patch/?func=detailpatch&patch_id=101544&group_id=5470 Martin von Löwis 2000-09-21T13:47:00Z The PyNumber_Format part is fixed with revision 2.89 of stringobject.c. 2000-07-31T21:05:00Z sf210610 Jitterbug-Id: 189 Submitted-By: gudo@python.org Date: Mon, 24 Jan 2000 14:27:24 -0500 (EST) Version: 1.5.2 OS: any Patrick Miller reminded me that there's still a race condition in the reading and writing of .pyc files. If two processes decide to write the .pyc, and a third reads the header after the first complete but before the second starts, but reads the rest of the file after the second starts but before it is done, the third can read corrupt data (and won't fall back to reading the .py source). Solution: when writing the .pyc file, (1) unlink the file before writing, (2) use open() with the Unix flags that fail creation if the file exists (and then just treat it like any open failure when writing the .pyc file). ==================================================================== Audit trail: Mon Jan 24 14:28:42 2000 guido moved from incoming to open Bug Importer FIXRELEASED LOW Guido van Rossum parser-compiler Bug Importer Bug Importer 2000-07-31T21:05:00Z Jitterbug-Id: 189 Submitted-By: gudo@python.org Date: Mon, 24 Jan 2000 14:27:24 -0500 (EST) Version: 1.5.2 OS: any Patrick Miller reminded me that there's still a race condition in the reading and writing of .pyc files. If two processes decide to write the .pyc, and a third reads the header after the first complete but before the second starts, but reads the rest of the file after the second starts but before it is done, the third can read corrupt data (and won't fall back to reading the .py source). Solution: when writing the .pyc file, (1) unlink the file before writing, (2) use open() with the Unix flags that fail creation if the file exists (and then just treat it like any open failure when writing the .pyc file). ==================================================================== Audit trail: Mon Jan 24 14:28:42 2000 guido moved from incoming to open Guido van Rossum 2000-08-10T18:52:00Z No time to fix this now... Jeremy Hylton 2000-09-07T22:02:00Z Please do triage on this bug. Guido van Rossum 2000-09-20T20:33:00Z Fixed as suggested in my last comment; using O_EXCL when opening the file (on Unix). 2000-07-31T21:05:00Z sf210611 Jitterbug-Id: 196 Submitted-By: Gregor Hoffleit <flight@mathi.uni-heidelberg.de> Date: Tue, 1 Feb 2000 14:43:09 +0100 Version: None OS: None --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, this must be the strangest bug report ever sent to bugs-py ;-). I don't expect a resolution for this bug from you, I just wanted to make sure this thing is recorded and the BTS. Perhaps somebody could give me a hint where I could look for the misbehavior. Candidates seem to be glibc, LinuxThreads, GNU readline, the Python readline module and the Python thread support ;-) In 1.5.2, there's a strange problem with signals on Linux systems. This has been discussed before on the mailing list, probably it even has a relation to Bug#102 ("incorrect signal processing"), but IMHO this reports adds a few other aspects. Definitely it is a (platform-specific) problem in 1.5.2. I have problems describing the bug, since the behavior seems to depend on so many parameters. The most obvious incarnation of the problem is probably this: In the Python 1.5.2 interpreter included with Debian 2.2 ("potato"), if you press Control-C on the command line (or send a SIGINT), the interpreter exits to the shell: freefly;104> python Python 1.5.2 (#0, Sep 13 1999, 09:12:57) [GCC 2.95.1 19990816 (release)]= on linux2=20 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> [Ctrl-C] freefly;105>=20 Normally, you'd expect a KeyboardInterrupt exception here. Now I tried and compiled different configurations of Python (each from a pristine source tree) on this Debian system: (151+t+rl) Python 1.5.1 (threads, readline) (152) Python 1.5.2 (no threads, no readline) =20 (152+rl) Python 1.5.2 (no threads, readline) (152+t) Python 1.5.2 (threads, no readline) (152+t+rl) Python 1.5.2 (threads, readline) (152+pth+rl) Python 1.5.2 (GNU Pth threads, readline) Thread support was realized with glibc 2.1.2's LinuxThreads, i.e. pthreads. readline was GNU readline 2.1 (for the record, I also tried 4.1beta3, but this made no difference). When I refer to Debian 2.1 ("slink"), this is a system with glibc 2.0.7 and the same GNU readline version 2.1. The following tables show the output of some experiments with those configurations. The [] brackets show the keys pressed. Note that a line like "[Ctrl-C][Enter]" implies that the interpreter showed no visible reaction to the first Ctrl-C! "----" lines mean that I started up a new clean session. (1) This is what happens when you start up a new interpreter and press Ctrl-C once, twice and so on, while on the command line: 152,152+t 152+rl,152+pth+rl 152+t+rl 151+t+rl =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D ------------------ ---------------- ------------- ---------------- >>> [Ctrl-C][Ctrl-C] >>> [Ctrl-C] >>> [Ctrl-C] >>> [Ctrl-C][Ct...] KeyboardInterrupt KeyboardInterrupt freefly:5> ---------------- >>> [Ctrl-C] >>> [Ctrl-C] ------------- KeyboardInterrupt KeyboardInterrupt >>> [Ctrl-C] >>> [Ctrl-C] KeyboardInterrupt KeyboardInterrupt >>> [Ctrl-C] >>> [Ctrl-C] KeyboardInterrupt KeyboardInterrupt ------------------ ---------------- 152+t+rl (on a Debian 2.1 system) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --------------------- >>> [Ctrl-C] KeyboardInterrupt >>> [Ctrl-C][Ctr...] --------------------- -> 1.5.2 with readline but without LinuxThreads is right. -> For some reason, 1.5.2 without readline ignores the first SIGINT. -> 1.5.2 with both readline and LinuxThreads kill the interpreter. -> 1.5.1 seems to ignore all SIGINTs's. =20 -> For 1.5.2 running glibc 2.0.7 (instead of 2.1.2) and readline, the interpreter doesn't get killed, but still after the first SIGINT all following SIGINTs are ignored. =20 -> It's worth a note that with only one of readline or thread support, the package seems to behave more reasonable; have both enabled is bad. =20 -> With threading support by means of GNU Pth (instead of the native libc6 LinuxThreads), the package behaves more correctly, too! =20 (2) Now on those systems who seemed to ignore the first SIGINT, I pressed Enter after it: 152,152+t 151+t+rl =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D= =3D --------------------- -------------------- >>> [Ctrl-C][Enter] >>> [Ctrl-C][Enter] Traceback (innermost last): Traceback (innermost last): File "<stdin>", line 0, in ? File "<stdin>", line 0, in ? KeyboardInterrupt KeyboardInterrupt >>> [Ctrl-C] >>> [Ctrl-C][Enter] KeyboardInterrupt Traceback (innermost last): --------------------- File "<stdin>", line 0, in ? KeyboardInterrupt >>> -------------------- =20 -> Obviously, the interpreter *DID* record the SIGINT in the first place, it just didn't provoke any immediate action=20 -> On 1.5.2 without readline, the second and all following SIGINTs are handled as one would expect. -> 1.5.1 with thread and readline shows this strange behavior not only for the first, but also for the second and any following SIGINT. =20 (3) On the glibc 2.0.7 system, I verified that indeed all subsequent SIGINTs are ignored. You're not able even to interrupt a loop, after the interpreter has received a SIGINT while he was on the command line: =20 152+t+rl (on a Debian 2.1 system) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D --------------------- >>> [Ctrl-C] KeyboardInterrupt >>> [Ctrl-C][Enter] >>> [Ctrl-C][Enter] {kein weiteres SIGINT wird akzeptiert, auch im Laufen:} >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C] 400 401 =2E.. 999 >>> --------------------- --------------------- >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C] 400 401 Traceback (innermost last): File "<stdin>", line 1, in ? KeyboardInterrupt >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C] 400 401 Traceback (innermost last): File "<stdin>", line 1, in ? KeyboardInterrupt >>> [Ctrl-C] KeyboardInterrupt >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C] 400 401 =2E.. 999 >>> --------------------- -> Note that it didn't hurt to break multiple times into a loop; only SIGINTs on the command line do mess up the interpreter! =20 =20 (4) In the Debian 2.2 Python package, you have to be careful not to kill the interpreter; that's especially a problem when you try to break into a loop--if you hold down Ctrl-C for too long, the interpreter quits! =20 152+t+rl (Debian 2.2 package) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D --------------------- >>> [Ctrl-C] freefly:5> --------------------- --------------------- >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C] 400 401 KeyboardInterrupt >>> --------------------- --------------------- >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C pressed down for a longer time] 400 401 freefly;19>=20 --------------------- (5) The Debian 2.2 package behaves more reasonable when the readline module has been moved out of the way: 152+t (Debian 2.2 package, readline module moved out of the way) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --------------------- >>> [Ctrl-C][Ctrl-C] KeyboardInterrupt >>> ... (vgl. 152, 152+t) --------------------- >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C] 400 401 40[Enter] Traceback (innermost last): File "<stdin>", line 0, in ? KeyboardInterrupt >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C] 400 401 KeyboardInterrupt >>> --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4luLt3eVfDf25G40RAQw9AKDhLyI7RDYt3G85Rxet2ZlK1b1nKwCg3zl/ tasWxAOGLUK3K3ucMBbhBag= =PTOI -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- ==================================================================== Audit trail: Mon Feb 07 12:38:12 2000 guido changed notes Mon Feb 07 12:38:12 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM platform-specific Guido van Rossum python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:05:00Z Jitterbug-Id: 196 Submitted-By: Gregor Hoffleit <flight@mathi.uni-heidelberg.de> Date: Tue, 1 Feb 2000 14:43:09 +0100 Version: None OS: None --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, this must be the strangest bug report ever sent to bugs-py ;-). I don't expect a resolution for this bug from you, I just wanted to make sure this thing is recorded and the BTS. Perhaps somebody could give me a hint where I could look for the misbehavior. Candidates seem to be glibc, LinuxThreads, GNU readline, the Python readline module and the Python thread support ;-) In 1.5.2, there's a strange problem with signals on Linux systems. This has been discussed before on the mailing list, probably it even has a relation to Bug#102 ("incorrect signal processing"), but IMHO this reports adds a few other aspects. Definitely it is a (platform-specific) problem in 1.5.2. I have problems describing the bug, since the behavior seems to depend on so many parameters. The most obvious incarnation of the problem is probably this: In the Python 1.5.2 interpreter included with Debian 2.2 ("potato"), if you press Control-C on the command line (or send a SIGINT), the interpreter exits to the shell: freefly;104> python Python 1.5.2 (#0, Sep 13 1999, 09:12:57) [GCC 2.95.1 19990816 (release)]= on linux2=20 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> [Ctrl-C] freefly;105>=20 Normally, you'd expect a KeyboardInterrupt exception here. Now I tried and compiled different configurations of Python (each from a pristine source tree) on this Debian system: (151+t+rl) Python 1.5.1 (threads, readline) (152) Python 1.5.2 (no threads, no readline) =20 (152+rl) Python 1.5.2 (no threads, readline) (152+t) Python 1.5.2 (threads, no readline) (152+t+rl) Python 1.5.2 (threads, readline) (152+pth+rl) Python 1.5.2 (GNU Pth threads, readline) Thread support was realized with glibc 2.1.2's LinuxThreads, i.e. pthreads. readline was GNU readline 2.1 (for the record, I also tried 4.1beta3, but this made no difference). When I refer to Debian 2.1 ("slink"), this is a system with glibc 2.0.7 and the same GNU readline version 2.1. The following tables show the output of some experiments with those configurations. The [] brackets show the keys pressed. Note that a line like "[Ctrl-C][Enter]" implies that the interpreter showed no visible reaction to the first Ctrl-C! "----" lines mean that I started up a new clean session. (1) This is what happens when you start up a new interpreter and press Ctrl-C once, twice and so on, while on the command line: 152,152+t 152+rl,152+pth+rl 152+t+rl 151+t+rl =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D ------------------ ---------------- ------------- ---------------- >>> [Ctrl-C][Ctrl-C] >>> [Ctrl-C] >>> [Ctrl-C] >>> [Ctrl-C][Ct...] KeyboardInterrupt KeyboardInterrupt freefly:5> ---------------- >>> [Ctrl-C] >>> [Ctrl-C] ------------- KeyboardInterrupt KeyboardInterrupt >>> [Ctrl-C] >>> [Ctrl-C] KeyboardInterrupt KeyboardInterrupt >>> [Ctrl-C] >>> [Ctrl-C] KeyboardInterrupt KeyboardInterrupt ------------------ ---------------- 152+t+rl (on a Debian 2.1 system) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --------------------- >>> [Ctrl-C] KeyboardInterrupt >>> [Ctrl-C][Ctr...] --------------------- -> 1.5.2 with readline but without LinuxThreads is right. -> For some reason, 1.5.2 without readline ignores the first SIGINT. -> 1.5.2 with both readline and LinuxThreads kill the interpreter. -> 1.5.1 seems to ignore all SIGINTs's. =20 -> For 1.5.2 running glibc 2.0.7 (instead of 2.1.2) and readline, the interpreter doesn't get killed, but still after the first SIGINT all following SIGINTs are ignored. =20 -> It's worth a note that with only one of readline or thread support, the package seems to behave more reasonable; have both enabled is bad. =20 -> With threading support by means of GNU Pth (instead of the native libc6 LinuxThreads), the package behaves more correctly, too! =20 (2) Now on those systems who seemed to ignore the first SIGINT, I pressed Enter after it: 152,152+t 151+t+rl =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D= =3D --------------------- -------------------- >>> [Ctrl-C][Enter] >>> [Ctrl-C][Enter] Traceback (innermost last): Traceback (innermost last): File "<stdin>", line 0, in ? File "<stdin>", line 0, in ? KeyboardInterrupt KeyboardInterrupt >>> [Ctrl-C] >>> [Ctrl-C][Enter] KeyboardInterrupt Traceback (innermost last): --------------------- File "<stdin>", line 0, in ? KeyboardInterrupt >>> -------------------- =20 -> Obviously, the interpreter *DID* record the SIGINT in the first place, it just didn't provoke any immediate action=20 -> On 1.5.2 without readline, the second and all following SIGINTs are handled as one would expect. -> 1.5.1 with thread and readline shows this strange behavior not only for the first, but also for the second and any following SIGINT. =20 (3) On the glibc 2.0.7 system, I verified that indeed all subsequent SIGINTs are ignored. You're not able even to interrupt a loop, after the interpreter has received a SIGINT while he was on the command line: =20 152+t+rl (on a Debian 2.1 system) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D --------------------- >>> [Ctrl-C] KeyboardInterrupt >>> [Ctrl-C][Enter] >>> [Ctrl-C][Enter] {kein weiteres SIGINT wird akzeptiert, auch im Laufen:} >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C] 400 401 =2E.. 999 >>> --------------------- --------------------- >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C] 400 401 Traceback (innermost last): File "<stdin>", line 1, in ? KeyboardInterrupt >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C] 400 401 Traceback (innermost last): File "<stdin>", line 1, in ? KeyboardInterrupt >>> [Ctrl-C] KeyboardInterrupt >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C] 400 401 =2E.. 999 >>> --------------------- -> Note that it didn't hurt to break multiple times into a loop; only SIGINTs on the command line do mess up the interpreter! =20 =20 (4) In the Debian 2.2 Python package, you have to be careful not to kill the interpreter; that's especially a problem when you try to break into a loop--if you hold down Ctrl-C for too long, the interpreter quits! =20 152+t+rl (Debian 2.2 package) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D --------------------- >>> [Ctrl-C] freefly:5> --------------------- --------------------- >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C] 400 401 KeyboardInterrupt >>> --------------------- --------------------- >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C pressed down for a longer time] 400 401 freefly;19>=20 --------------------- (5) The Debian 2.2 package behaves more reasonable when the readline module has been moved out of the way: 152+t (Debian 2.2 package, readline module moved out of the way) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --------------------- >>> [Ctrl-C][Ctrl-C] KeyboardInterrupt >>> ... (vgl. 152, 152+t) --------------------- >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C] 400 401 40[Enter] Traceback (innermost last): File "<stdin>", line 0, in ? KeyboardInterrupt >>> for i in xrange(1000): print i =2E.. 1 2 =2E.. [Ctrl-C] 400 401 KeyboardInterrupt >>> --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4luLt3eVfDf25G40RAQw9AKDhLyI7RDYt3G85Rxet2ZlK1b1nKwCg3zl/ tasWxAOGLUK3K3ucMBbhBag= =PTOI -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- ==================================================================== Audit trail: Mon Feb 07 12:38:12 2000 guido changed notes Mon Feb 07 12:38:12 2000 guido moved from incoming to open Bug Importer 2000-07-31T21:05:00Z From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de> Subject: Re: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196) Date: Fri, 11 Feb 2000 14:52:42 +0100 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Ok, one more data point: On Fri, Feb 11, 2000 at 08:29:43AM -0500, Randall Hopper wrote: > You know, I think you may have it. On IRIX, I don't have Python built > with threads. However, on FreeBSD at home I'd guess that it is (I built = it > from ports). My IRIX python has no problem with Ctrl-C while my FreeBSD > version at home locks up with Ctrl-C. I rebuilt my IRIX Python > --with-thread, and now it hangs when Ctrl-C is hit. And now, we're three: When using threads and readline, Ctrl-C hangs IRIX and FreeBSD and kills Linux Python. This doesn't sound like a kernel problem, more like a problem with readline not being thread-safe I guess. Gregor =20 --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4pBQq3eVfDf25G40RAUbSAJ41b+DgwHEmRUm0uQcJLjvZ3ROiSwCdH8Xq jFH5J1TsLQBbQTPU5Xvv0Bo= =0j16 -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- Bug Importer 2000-07-31T21:05:00Z From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de> Subject: Returned mail: User unknown Date: Thu, 3 Feb 2000 11:46:44 +0100 (MET) This is a MIME-encapsulated message --LAA26536.949574804/relay.uni-heidelberg.de The original message was received at Thu, 3 Feb 2000 11:46:41 +0100 (MET) from mailserver.mathi.uni-heidelberg.de [129.206.26.32] ----- The following addresses had permanent fatal errors ----- <bugs-by@python.org> ----- Transcript of session follows ----- .. while talking to parrot.python.org.: >>> RCPT To:<bugs-by@python.org> <<< 550 <bugs-by@python.org>... User unknown 550 <bugs-by@python.org>... User unknown --LAA26536.949574804/relay.uni-heidelberg.de Content-Type: message/delivery-status Reporting-MTA: dns; relay.uni-heidelberg.de Received-From-MTA: DNS; mailserver.mathi.uni-heidelberg.de Arrival-Date: Thu, 3 Feb 2000 11:46:41 +0100 (MET) Final-Recipient: RFC822; bugs-by@python.org Action: failed Status: 5.1.1 Remote-MTA: DNS; parrot.python.org Diagnostic-Code: SMTP; 550 <bugs-by@python.org>... User unknown Last-Attempt-Date: Thu, 3 Feb 2000 11:46:44 +0100 (MET) --LAA26536.949574804/relay.uni-heidelberg.de Content-Type: message/rfc822 Return-Path: <flight@mathi.uni-heidelberg.de> Received: from mailserver.mathi.uni-heidelberg.de (mailserver.mathi.uni-heidelberg.de [129.206.26.32]) by relay.uni-heidelberg.de (8.9.3+Sun/8.9.3) with ESMTP id LAA26531 for <bugs-by@python.org>; Thu, 3 Feb 2000 11:46:41 +0100 (MET) Received: from testserv.mathi.uni-heidelberg.de (testserv.mathi.uni-heidelberg.de [129.206.26.30]) by mailserver.mathi.uni-heidelberg.de (Postfix) with SMTP id CFF5512917 for <bugs-by@python.org>; Thu, 3 Feb 2000 11:48:11 +0100 (CET) Received: by testserv.mathi.uni-heidelberg.de (sSMTP sendmail emulation); Thu, 3 Feb 2000 11:48:12 +0100 Date: Thu, 3 Feb 2000 11:48:12 +0100 From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de> To: bugs-by@python.org Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196) Message-ID: <20000203114812.B18567@mathi.uni-heidelberg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0pre3i Fredric Lundh pointed me to Alex Zbyslaw's posting regarding this topic (http://x44.deja.com/getdoc.xp?AN=545159177). Indeed Alex' patch1 (http://www.xfb52.dial.pipex.com/patches/python.shtml) for FreeBSD (disabling the interrupt handler chanege in the readline module) works for Debian, too, i.e. if I stick with the default inthandler in the readline module, SIGINT doesn't kill the interpreter anymore. Still, the drawback of this change is that I have to press RETURN before a SIGINT is spotted by Python (btw, this is the same behavior as with 1.5.1 on the system with the same configuration). Still, IMHO this behavior is preferable. Gregor --LAA26536.949574804/relay.uni-heidelberg.de-- Bug Importer 2000-07-31T21:05:00Z From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de> Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196) Date: Wed, 2 Feb 2000 14:25:07 +0100 Hi, > If you haven't already done so, may I suggest building Python from the > current CVS development source tree instead? sorry, I forgot to mention that I tried that. Didnt't change the behavior at all (I also saw that there were no big changes to the readline nor to the threading code since 1.5.2). Gregor Bug Importer 2000-07-31T21:05:00Z From: "Tim Peters" <tim_one@email.msn.com> Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196) Date: Wed, 2 Feb 2000 03:04:04 -0500 [flight@mathi.uni-heidelberg.de] > this must be the strangest bug report ever sent to bugs-py ;-). No, but I don't recall one that evidenced more hard & tedious work! Wow. Thank you. Switch to Windows -- it's so much more reliable <wink>. If you haven't already done so, may I suggest building Python from the current CVS development source tree instead? http://www.python.org/download/cvs.html This may be a waste of effort, but I'd hate to see you pour more time tracking down obscure bugs that may already have been fixed. Contrarily, if the current CVS version still displays the problems, more work devoted to tracking them down is certain not to be a waste. Guido van Rossum 2000-09-16T02:47:00Z Some progress notes: There are several bugs here. 1. The combination readline + threads causes ^C to just exit or die. I've found that this can be fixed with readline 4.x by setting the global variable rl_catch_signals to 0 in setup_readline(). But my Red Hat 6. 2 system still comes with readline 2.2. How can I detect the readline version? And what to do for readline 2.2? 2. Without the readline module, the first ^C requires [Enter] before it is seen. I haven't researched this yet, but will. 3. Debian 2.1 ignores the second and all subsequent ^Cs. I won't look into this; apparently it's fixed in Debian 2.2. 4. Similar problems on IRIX. I'll presume this is the same as (1). Guido van Rossum 2000-09-16T16:43:00Z Whew! It looks like BOTH bugs (1) and (2) from my previous comment were caused by mixing of signal() and sigaction(). It appears that if signal() is used to set a handler, sigaction() doesn't report it as the old handler, and vice versa. Possibly this bug is more severe when threads are used. Bugs (1) and (2) are both fixed now -- I've introduced new APIs PyOS_setsig() and PyOS_getsig() that use sigaction() if it exists and signal() otherwise, and changed the readline and signal modules to use this. I won't look into the other problems -- if there are still problems with signals, please submit a new bug report. Viznut 2000-10-05T20:10:00Z Just a note: the Ctrl-C hangs at the interactive Python prompt with readline is still a problem on IRIX with Python 2.0b2. I rebuilt --without-threads again and now the Python prompt behaves as it should: > python2 Python 2.0b2 (#1, Oct 5 2000, 16:05:21) [C] on irix646-n32 Type "copyright", "credits" or "license" for more information. >>> KeyboardInterrupt >>> KeyboardInterrupt >>> KeyboardInterrupt >>> 2000-07-31T21:05:00Z sf210612 Jitterbug-Id: 200 Submitted-By: aa8vb@yahoo.com Date: Wed, 9 Feb 2000 13:05:57 -0500 (EST) Version: 1.5.2 OS: IRIX 6.5 Basically, anydbm won't open dumbdbm files that anydbm created. >>> import anydbm >>> db = anydbm.open( "database", "c" ) >>> db[ "1" ] = "one" >>> db.close() >>> db = anydbm.open( "database", "r" ) Traceback (innermost last): File "<stdin>", line 1, in ? File "/home/rhh/software/python-1.5.2/lib/python1.5/anydbm.py", line 80, in open raise error, "need 'c' or 'n' flag to open new db" anydbm.error: need 'c' or 'n' flag to open new db More details can be found in the c.l.python thread "anydbm - a simple question". I searched for a matching bug and didn't find one in the database. Also, I verified my whichdb.py matches what's currently in CVS, so I don't think this has been fixed yet. Thanks, Randall ==================================================================== Audit trail: Wed Feb 23 21:40:05 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM Jeremy Hylton python-library Bug Importer Bug Importer 2000-07-31T21:05:00Z Jitterbug-Id: 200 Submitted-By: aa8vb@yahoo.com Date: Wed, 9 Feb 2000 13:05:57 -0500 (EST) Version: 1.5.2 OS: IRIX 6.5 Basically, anydbm won't open dumbdbm files that anydbm created. >>> import anydbm >>> db = anydbm.open( "database", "c" ) >>> db[ "1" ] = "one" >>> db.close() >>> db = anydbm.open( "database", "r" ) Traceback (innermost last): File "<stdin>", line 1, in ? File "/home/rhh/software/python-1.5.2/lib/python1.5/anydbm.py", line 80, in open raise error, "need 'c' or 'n' flag to open new db" anydbm.error: need 'c' or 'n' flag to open new db More details can be found in the c.l.python thread "anydbm - a simple question". I searched for a matching bug and didn't find one in the database. Also, I verified my whichdb.py matches what's currently in CVS, so I don't think this has been fixed yet. Thanks, Randall ==================================================================== Audit trail: Wed Feb 23 21:40:05 2000 guido moved from incoming to open Moshez-users 2000-08-01T09:24:00Z It was a simple glitch in whichdb -- it didn't recognize the dumbdbm format. Fixed it. Bug Importer 2000-09-15T23:22:00Z I think this bug has appeared again. I get the exact same error with Python 1.6, but it works with 1.5.2. Guido van Rossum 2000-09-16T00:15:00Z Reopened and assigned to Jeremy since a comment claims it's reappeared in 1.6. Can you check 2.0? Martin von Löwis 2000-09-17T11:24:00Z The following script works for me, in 2.0b1 >>> import dumbdbm >>> dumbdbm.open("/tmp/hhh","c") <dumbdbm._Database instance at 0x829eaac> >>> s=_ >>> s['a']='b' >>> s.close() >>> import whichdb >>> whichdb.whichdb("/tmp/hhh") 'dumbdbm' >>> import anydbm >>> s=anydbm.open("/tmp/hhh") >>> s So it works for me, on i586-pc-linux-gnu. Guido van Rossum 2000-09-22T03:29:00Z Fixed in 2.0. Indeed broken in 1.6, but that's water under the bridge. Am closing this for Jeremy. 2000-07-31T21:05:00Z sf210613 Jitterbug-Id: 202 Submitted-By: aa8vb@yahoo.com Date: Fri, 11 Feb 2000 07:12:28 -0500 (EST) Version: 1.5.2 OS: IRIX 6.5 Recently tried to rebuild Python, adding in gdbm. This Setup line is new for this build: gdbm gdbmmodule.c -I/usr/local/include -L/usr/local/lib32 -rpath /usr/local/lib32 -lgdbm The problem is, 1.5.2's makesetup doesn't take RPATH directives, reporting -rpath as a "bad word". Note that RPATH directives take different forms on different OSs: -rpath on SGI IRIX is -R on Solaris, --rpath on FreeBSD, etc. A provision should be made for RPATH options as they are used to avoid the need for LD_LIBRARY_PATH hacks. --- Makefiles --- bad word -rpath in gdbm gdbmmodule.c -I/usr/local/include -L/usr/local/lib32 -rpath /usr/local/lib32 -lgdbm *** Error code 1 Thanks, Randall ==================================================================== Audit trail: Wed Feb 23 21:30:21 2000 guido changed notes Wed Feb 23 21:30:21 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM Fred Drake build Bug Importer Bug Importer 2000-07-31T21:05:00Z Jitterbug-Id: 202 Submitted-By: aa8vb@yahoo.com Date: Fri, 11 Feb 2000 07:12:28 -0500 (EST) Version: 1.5.2 OS: IRIX 6.5 Recently tried to rebuild Python, adding in gdbm. This Setup line is new for this build: gdbm gdbmmodule.c -I/usr/local/include -L/usr/local/lib32 -rpath /usr/local/lib32 -lgdbm The problem is, 1.5.2's makesetup doesn't take RPATH directives, reporting -rpath as a "bad word". Note that RPATH directives take different forms on different OSs: -rpath on SGI IRIX is -R on Solaris, --rpath on FreeBSD, etc. A provision should be made for RPATH options as they are used to avoid the need for LD_LIBRARY_PATH hacks. --- Makefiles --- bad word -rpath in gdbm gdbmmodule.c -I/usr/local/include -L/usr/local/lib32 -rpath /usr/local/lib32 -lgdbm *** Error code 1 Thanks, Randall ==================================================================== Audit trail: Wed Feb 23 21:30:21 2000 guido changed notes Wed Feb 23 21:30:21 2000 guido moved from incoming to open Fred Drake 2000-08-03T06:10:00Z The current CVS version of makesetup appears to handle -rpath and -R, but not --rpath. Is neither of the alternatives sufficient for FreeBSD? Fred Drake 2000-08-11T13:59:00Z -R and -rpath are supported; --rpath support is added in Modules/makesetup revision 1.27. 2000-07-31T21:06:00Z sf210614 Jitterbug-Id: 204 Submitted-By: guido@python.org Date: Tue, 15 Feb 2000 14:24:27 -0500 (EST) Version: 1.5.2 OS: Solaris 2.7 When PyArg_ParseTuple() needs an int (for an 'i' format char) but finds something else, it says TypeError: illegal argument type for built-in operation instead of the nice friendly error it usually gives. ==================================================================== Audit trail: Wed Feb 23 21:31:39 2000 guido moved from incoming to open Bug Importer FIXRELEASED LOW feature-request Jeremy Hylton python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:06:00Z Jitterbug-Id: 204 Submitted-By: guido@python.org Date: Tue, 15 Feb 2000 14:24:27 -0500 (EST) Version: 1.5.2 OS: Solaris 2.7 When PyArg_ParseTuple() needs an int (for an 'i' format char) but finds something else, it says TypeError: illegal argument type for built-in operation instead of the nice friendly error it usually gives. ==================================================================== Audit trail: Wed Feb 23 21:31:39 2000 guido moved from incoming to open Bug Importer 2000-07-31T21:06:00Z From: "Fred L. Drake, Jr." <fdrake@acm.org> Subject: Re: [Python-bugs-list] illegal argument type for built-in operation (PR#204) Date: Tue, 15 Feb 2000 14:33:49 -0500 (EST) guido@python.org writes: > When PyArg_ParseTuple() needs an int (for an 'i' format char) but finds > something else, it says > > TypeError: illegal argument type for built-in operation This is also the case for the 'l' format, which is what range() uses. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives Jeremy Hylton 2000-09-07T22:01:00Z Please do triage on this bug. Jeremy Hylton 2000-09-07T22:02:00Z Please do triage on this bug. Jeremy Hylton 2000-09-12T15:48:00Z The error messages are much better in 2.0: >>> sys.setrecursionlimit("a") Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: an integer is required >>> marshal.loads(12) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: loads, argument 1: expected read-only buffer, int found 2000-07-31T21:06:00Z sf210615 Jitterbug-Id: 207 Submitted-By: vincent@ldsol.com Date: Wed, 16 Feb 2000 10:31:02 -0500 (EST) Version: 1.5.2 OS: Linux 2.2.x Get the 2 files http://www.ldsol.com/~vincent/misc/P.KICORE (30 kb text data file) and http://www.ldsol.com/~vincent/misc/p2sql.py.KICORE (1kb script file) If I run python p2sql.py.KICORE I get a segfault from the python interpreter. I spotted the line that seems to cause the segfault (noted in the script). Not sure if that line is correct, but at the very least I don't expect the interpreted to abort. the stack trace obtained from the core file seems to indicate that the interpreter has gone in an infinite loop... Feel free to ask for any other info. Cordialement, ==================================================================== Audit trail: Wed Feb 23 21:28:40 2000 guido changed notes Wed Feb 23 21:28:40 2000 guido moved from incoming to open Bug Importer FIXRELEASED CRITICAL Jeremy Hylton python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:06:00Z Jitterbug-Id: 207 Submitted-By: vincent@ldsol.com Date: Wed, 16 Feb 2000 10:31:02 -0500 (EST) Version: 1.5.2 OS: Linux 2.2.x Get the 2 files http://www.ldsol.com/~vincent/misc/P.KICORE (30 kb text data file) and http://www.ldsol.com/~vincent/misc/p2sql.py.KICORE (1kb script file) If I run python p2sql.py.KICORE I get a segfault from the python interpreter. I spotted the line that seems to cause the segfault (noted in the script). Not sure if that line is correct, but at the very least I don't expect the interpreted to abort. the stack trace obtained from the core file seems to indicate that the interpreter has gone in an infinite loop... Feel free to ask for any other info. Cordialement, ==================================================================== Audit trail: Wed Feb 23 21:28:40 2000 guido changed notes Wed Feb 23 21:28:40 2000 guido moved from incoming to open Bug Importer 2000-07-31T21:06:00Z From: "Tim Peters" <tim_one@email.msn.com> Subject: RE: [Python-bugs-list] python dumps core on my script (PR#207) Date: Wed, 16 Feb 2000 20:36:03 -0500 [vincent@ldsol.com] > If I run python p2sql.py.KICORE I get a segfault from the python > interpreter. > ... > the stack trace obtained from the core file seems to indicate that the > interpreter has gone in an infinite loop... It's really that you've forced the interpreter into infinite recursion. Thinking about this one should make it clear: >>> class C: def __repr__(self): print "got into __repr__" return "OK" >>> c = C() >>> print c got into __repr__ OK >>> That is, by putting "print self" into your __repr__ method, you force never-ending recursion, because "print" implicitly invokes __repr__ again to come up with a string representation for self, which again tries to do "print self", which again invokes self.__repr__, etc etc. The solution is to not do this <wink>. It would be nice if the interpreter caught this and raised an error, but the code doesn't make sense so you're going to get a failure of one kind or another no matter what. Bug Importer 2000-07-31T21:06:00Z From: Vincent Renardias <vincent@ldsol.com> Subject: Re: [Python-bugs-list] python dumps core on my script (PR#207) Date: Wed, 16 Feb 2000 16:39:51 +0000 (GMT) On Wed, 16 Feb 2000, Guido van Rossum wrote: > The problem is that the call to "print self" inside the __repr__() > method causes a recursive call to __repr__(). This causes an > unchecked stack overflow in C. I guessed that about 3 minutes after sending the bug report... ;) > You can avoid this by not calling "print self" inside __repr__(). > > We'll mark this as an open problem because Python should have given > you a MemoryError as it tries to do with other stack overflows -- but > catching stack overflows is hard. I only found this one inadvertantly, but there are many more potential problems, ie: print self in __str__, creating an object in __init__, or even a loop involving (for example) __repr__ calling __hash__, itself calling __repr__ But I imagine these cases are not only very hard to detect but may also be hard to fix in an efficient way... NB: the script above that shown this bug was my first 'serious' python program, but I'm not discouraged... ;) Cordialement, -- "Si ca sent bon : mange-le, sinon pisse dessus..." [Proverbe chien] Bug Importer 2000-07-31T21:06:00Z From: Guido van Rossum <guido@python.org> Subject: Re: [Python-bugs-list] python dumps core on my script (PR#207) Date: Wed, 16 Feb 2000 10:57:29 -0500 > Full_Name: vincent renardias > Version: 1.5.2 > OS: Linux 2.2.x > Submission from: (NULL) (62.161.210.241) > > Get the 2 files > http://www.ldsol.com/~vincent/misc/P.KICORE (30 kb text data file) > and > http://www.ldsol.com/~vincent/misc/p2sql.py.KICORE (1kb script file) > > If I run python p2sql.py.KICORE I get a segfault from the python interpreter. > I spotted the line that seems to cause the segfault (noted in the script). > Not sure if that line is correct, but at the very least I don't expect the > interpreted to abort. > the stack trace obtained from the core file seems to indicate that the > interpreter > has gone in an infinite loop... Thanks for reporting this. The problem is that the call to "print self" inside the __repr__() method causes a recursive call to __repr__(). This causes an unchecked stack overflow in C. You can avoid this by not calling "print self" inside __repr__(). We'll mark this as an open problem because Python should have given you a MemoryError as it tries to do with other stack overflows -- but catching stack overflows is hard. --Guido van Rossum (home page: http://www.python.org/~guido/) Jeremy Hylton 2000-08-31T19:29:00Z Fixed as best we can in time for 2.0b1 release: Set the recursion limit much lower, and allow the user to bump it back up if she needs to. 2000-07-31T21:06:00Z sf210616 Jitterbug-Id: 209 Submitted-By: Guido van Rossum <guido@python.org> Date: Tue, 22 Feb 2000 10:42:17 -0500 Version: None OS: None The post below is evidence that there is a real need to close the source file sooner than when the program execution is over. Unfortunately, as Martin points out, this requires changing function signatures (in the sense that the behaviors change). The close-on-exec solution is not good enough; apart from the portability issue it also doesn't solve other problems caused by keeping the file open too long. --Guido van Rossum (home page: http://www.python.org/~guido/) ------- Forwarded Message Date: Mon, 21 Feb 2000 19:00:32 +0100 From: Martin von Loewis <loewis@informatik.hu-berlin.de> To: aliberi@acutronic.com cc: help@python.org, guido@CNRI.Reston.VA.US Subject: Re: [Python-Help] execve > I tried to submit the below report via the web interface, but kept getting > the folowing message: > > The system encountered a fatal error > > After command: > Received: > > The last error code was: Connection refused > > So, the bug report is below. Thanks. Thanks for your report. It looks like Python is not closing the file descriptor of the script being executed. Please have a look at Py_Main, where fp is the file descriptor of the script being executed (potentially stdin). That is passed to PyRun_AnyFile, which eventually calls the parser to read the file. When PyRun_AnyFile returns, the file is closed if it is not stdin (or, rather, does not have a name). Unfortunately, if the script performs exec, that file descriptor is still open. I see two solutions: a) close the file after it has been parsed, before execution starts. That appears to be the Right Way (TM), but requires changes to the signatures of a number of functions. b) set the close-on-exec flag for the script. That will automagically close it when necessary, but doing so is not very portable. It will probably work on both Linux and LynxOS, so you may consider fixing it that way yourself. Good luck, Martin P.S. CC'ed to Guido for inspection. ------- End of Forwarded Message ==================================================================== Audit trail: Wed Feb 23 21:30:38 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM Guido van Rossum parser-compiler Bug Importer Bug Importer 2000-07-31T21:06:00Z Jitterbug-Id: 209 Submitted-By: Guido van Rossum <guido@python.org> Date: Tue, 22 Feb 2000 10:42:17 -0500 Version: None OS: None The post below is evidence that there is a real need to close the source file sooner than when the program execution is over. Unfortunately, as Martin points out, this requires changing function signatures (in the sense that the behaviors change). The close-on-exec solution is not good enough; apart from the portability issue it also doesn't solve other problems caused by keeping the file open too long. --Guido van Rossum (home page: http://www.python.org/~guido/) ------- Forwarded Message Date: Mon, 21 Feb 2000 19:00:32 +0100 From: Martin von Loewis <loewis@informatik.hu-berlin.de> To: aliberi@acutronic.com cc: help@python.org, guido@CNRI.Reston.VA.US Subject: Re: [Python-Help] execve > I tried to submit the below report via the web interface, but kept getting > the folowing message: > > The system encountered a fatal error > > After command: > Received: > > The last error code was: Connection refused > > So, the bug report is below. Thanks. Thanks for your report. It looks like Python is not closing the file descriptor of the script being executed. Please have a look at Py_Main, where fp is the file descriptor of the script being executed (potentially stdin). That is passed to PyRun_AnyFile, which eventually calls the parser to read the file. When PyRun_AnyFile returns, the file is closed if it is not stdin (or, rather, does not have a name). Unfortunately, if the script performs exec, that file descriptor is still open. I see two solutions: a) close the file after it has been parsed, before execution starts. That appears to be the Right Way (TM), but requires changes to the signatures of a number of functions. b) set the close-on-exec flag for the script. That will automagically close it when necessary, but doing so is not very portable. It will probably work on both Linux and LynxOS, so you may consider fixing it that way yourself. Good luck, Martin P.S. CC'ed to Guido for inspection. ------- End of Forwarded Message ==================================================================== Audit trail: Wed Feb 23 21:30:38 2000 guido moved from incoming to open Guido van Rossum 2000-08-27T19:20:00Z Fixed as follows: Add three new APIs: PyRun_AnyFileEx(), PyRun_SimpleFileEx(), PyRun_FileEx(). These are the same as their non-Ex counterparts but have an extra argument, a flag telling them to close the file when done. Then this is used by Py_Main() and execfile() to close the file after it is parsed but before it is executed. 2000-07-31T21:06:00Z sf210617 Jitterbug-Id: 213 Submitted-By: aa8vb@yahoo.com Date: Fri, 25 Feb 2000 07:36:01 -0500 (EST) Version: 1.5.2 (w/ IDLE 0.5) OS: IRIX Since no other X app I know of works this way, I think this is a bug. If you set the title of the IDLE window: idle.py -t IDLE the title is set correctly, but the icon name is not. It is set to "*IDLE" rather than "IDLE". ==================================================================== Audit trail: Tue Mar 07 14:41:55 2000 guido changed notes Tue Mar 07 14:41:55 2000 guido moved from incoming to open Bug Importer FIXRELEASED LOW Guido van Rossum idle Bug Importer Bug Importer 2000-07-31T21:06:00Z Jitterbug-Id: 213 Submitted-By: aa8vb@yahoo.com Date: Fri, 25 Feb 2000 07:36:01 -0500 (EST) Version: 1.5.2 (w/ IDLE 0.5) OS: IRIX Since no other X app I know of works this way, I think this is a bug. If you set the title of the IDLE window: idle.py -t IDLE the title is set correctly, but the icon name is not. It is set to "*IDLE" rather than "IDLE". ==================================================================== Audit trail: Tue Mar 07 14:41:55 2000 guido changed notes Tue Mar 07 14:41:55 2000 guido moved from incoming to open Bug Importer 2000-07-31T21:06:00Z From: Guido van Rossum <guido@python.org> Subject: Re: [Python-bugs-list] IDLE and -t (PR#213) Date: Mon, 06 Mar 2000 09:11:30 -0500 > Sorry about that last message. This issue is very closely related to the > resource loading issue on idle-dev, but not the same. Once the small > change below is in-place (to solve this problem), the platform-independent > Tkinter methods for resource loading can be used to solve the idle-dev > problem, if desired. See my response in idle-dev :-) Of course the Tk options can still be used for changing things that the config file or prefs dialog doesn't support. > Research indicates that the Tk-ism for setting Toplevel classes is: > > "toplevel .mytop -class classname" > > So the Tkinter syntax is: > > top1 = Toplevel( root, class_=classname ) > > The attached test app demonstrates this. I verified that I am able to set > X resources for these windows using the class name "Idle". OK, I'll try to support this! --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-07-31T21:06:00Z From: Randall Hopper <aa8vb@yahoo.com> Subject: Re: [Python-bugs-list] IDLE and -t (PR#213) Date: Mon, 6 Mar 2000 08:50:29 -0500 --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Guido van Rossum: |Thanks for your enlightenment. I looked at your example, and it |works; but I need more, because IDLE creates windows using Toplevel(), |not using Tk(). (Using Tk() would create a new Tcl interpreter for |each window, which wastes time and memory resources, and re-reads the |~/.<whatever>.py file each time.) | |I've experimented with xprop a bit, and I'm not getting results I |like. If I write root = Tk(className="foo"), WM_CLASS is "foo", |"Foo". Them if I write top = Toplevel(root), WM_CLASS for that window |is "1234567", "Toplevel". If I try top = Toplevel(root, name="bar"), |I get "bar", "Toplevel". Shouldn't I be able to set the second |component of WM_CLASS somehow? | |Got any ideas? Sorry about that last message. This issue is very closely related to the resource loading issue on idle-dev, but not the same. Once the small change below is in-place (to solve this problem), the platform-independent Tkinter methods for resource loading can be used to solve the idle-dev problem, if desired. Research indicates that the Tk-ism for setting Toplevel classes is: "toplevel .mytop -class classname" So the Tkinter syntax is: top1 = Toplevel( root, class_=classname ) The attached test app demonstrates this. I verified that I am able to set X resources for these windows using the class name "Idle". -- Randall Hopper aa8vb@yahoo.com --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tk_class.py" from Tkinter import * CLASSNAME = "Idle" root = Tk( className=CLASSNAME ) root.wm_withdraw() # A toplevel with a WM_CLASS top1 = Toplevel( root, class_=CLASSNAME ) label1 = Label( top1, text="Toplevel 1" ) label1.pack() # Another one top2 = Toplevel( root, class_=CLASSNAME ) label2 = Label( top2, text="Toplevel 2" ) label2.pack() root.mainloop() --MGYHOYXEY6WxJCY8-- Bug Importer 2000-07-31T21:06:00Z From: Guido van Rossum <guido@python.org> Subject: Re: [Python-bugs-list] IDLE and -t (PR#213) Date: Wed, 01 Mar 2000 09:21:41 -0500 Randall, Thanks for your enlightenment. I looked at your example, and it works; but I need more, because IDLE creates windows using Toplevel(), not using Tk(). (Using Tk() would create a new Tcl interpreter for each window, which wastes time and memory resources, and re-reads the ~/.<whatever>.py file each time.) I've experimented with xprop a bit, and I'm not getting results I like. If I write root = Tk(className="foo"), WM_CLASS is "foo", "Foo". Them if I write top = Toplevel(root), WM_CLASS for that window is "1234567", "Toplevel". If I try top = Toplevel(root, name="bar"), I get "bar", "Toplevel". Shouldn't I be able to set the second component of WM_CLASS somehow? Got any ideas? If you can send me a patch, that would be greatly appreciated! --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-07-31T21:06:00Z From: Randall Hopper <aa8vb@yahoo.com> Subject: Re: [Python-bugs-list] IDLE and -t (PR#213) Date: Tue, 29 Feb 2000 14:26:37 -0500 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Guido van Rossum: |Hm, I have to admit that I have given up years ago on configuring X |apps through their app name. Is that still a common practice? I could Definitely. Most all (all?) use WM_CLASS, and many use WM_NAME and WM_ICONNAME as fallbacks. This is useful if WM_CLASS isn't set to a useful value (as in this case). IDLE doesn't set a class name property on it's window, so the window name and icon name are all the window manager has to go on when matching it up with configuration settings. However, I believe IDLE could set a class name easily by passing it to Tkinter -- e.g. root = Tk( className="IDLE" ). See attached. More info: the properties used by many window managers as a key into a configuration database are: CLASS, NAME, and ICON_NAME. For example, running 'xprop' on my xterm window here: > xprop ... WM_CLASS(STRING) = "xterm-color", "XTerm" ... WM_ICON_NAME(STRING) = "Local" WM_NAME(STRING) = "Local" So I can set window manager resources for this window using "XTerm", "xterm-color", or "Local" -- with overrides in that order I believe. So I can have a default icon for xterms, and then an override icon for xterm windows with a certain title. IDLE doesn't set CLASS so it's basically useless for this configuration purpose. On stock IDLE: WM_CLASS(STRING) = "270515832", "Toplevel" |certainly change things around so that the title and icon are always "idle: |*file*" or "idle: file" depending on saved status. If IDLE could set WM_CLASS to a static (or cmd-line-specified) value on it's shell windows, that'd be enough for me. For now I'm using -t IDLE, but that doesn't cover opening new windows inside of IDLE (opening files, File->New Window, etc.) A unique prefix on the WM_NAME (title string) would work too. |> I do think the icon should have a '*' both before "and after", as you |> described though. I'm guessing this was just a typo. | |I think it was intentional, trying to save some space in the icon |label. Not worth it, probably. Thanks, Randall -- Randall Hopper aa8vb@yahoo.com --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tk.py" from Tkinter import * root = Tk( className="Test" ) btn = Button( root ) btn.pack() root.mainloop() --oyUTqETQ0mS9luUI-- Bug Importer 2000-07-31T21:06:00Z From: Guido van Rossum <guido@python.org> Subject: Re: [Python-bugs-list] IDLE and -t (PR#213) Date: Mon, 28 Feb 2000 08:16:48 -0500 > |Not a bug -- IDLE adds * before (and after!) the window title and > |icon name to indicate that the window is modified and unsaved. > > The icon name doesn't follow this convention: > > if not self.get_saved(): > title = "*%s*" % title > icon = "*%s" % icon > > The reason I took note of this inconsistency is that I was assigning a > window manager icon to IDLE based on the startup icon string. > > |Does this bother you in some way? > > Well, no other X app I know of communicates unsaved status by putting '*'s > in the title and icon, but I don't have a big problem with it. Hm, I have to admit that I have given up years ago on configuring X apps through their app name. Is that still a common practice? I could certainly change things around so that the title and icon are always "idle: *file*" or "idle: file" depending on saved status. > I do think the icon should have a '*' both before "and after", as you > described though. I'm guessing this was just a typo. I think it was intentional, trying to save some space in the icon label. Not worth it, probably. --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-07-31T21:06:00Z From: Randall Hopper <aa8vb@yahoo.com> Subject: Re: [Python-bugs-list] IDLE and -t (PR#213) Date: Mon, 28 Feb 2000 07:25:31 -0500 Guido van Rossum: |> Since no other X app I know of works this way, I think this is a bug. |> |> If you set the title of the IDLE window: |> |> idle.py -t IDLE |> |> the title is set correctly, but the icon name is not. |> It is set to "*IDLE" rather than "IDLE". | |Not a bug -- IDLE adds * before (and after!) the window title and |icon name to indicate that the window is modified and unsaved. The icon name doesn't follow this convention: if not self.get_saved(): title = "*%s*" % title icon = "*%s" % icon The reason I took note of this inconsistency is that I was assigning a window manager icon to IDLE based on the startup icon string. |Does this bother you in some way? Well, no other X app I know of communicates unsaved status by putting '*'s in the title and icon, but I don't have a big problem with it. I do think the icon should have a '*' both before "and after", as you described though. I'm guessing this was just a typo. Thanks, Randall -- Randall Hopper aa8vb@yahoo.com Bug Importer 2000-07-31T21:06:00Z From: Guido van Rossum <guido@python.org> Subject: Re: [Python-bugs-list] IDLE and -t (PR#213) Date: Fri, 25 Feb 2000 08:26:32 -0500 > Since no other X app I know of works this way, I think this is a bug. > > If you set the title of the IDLE window: > > idle.py -t IDLE > > the title is set correctly, but the icon name is not. > It is set to "*IDLE" rather than "IDLE". Not a bug -- IDLE adds * before (and after!) the window title and icon name to indicate that the window is modified and unsaved. Does this bother you in some way? --Guido van Rossum (home page: http://www.python.org/~guido/) Jeremy Hylton 2000-09-07T22:06:00Z Please do triage on this bug. Tim Peters 2000-09-15T05:29:00Z Assigned to Guido for obvious reasons. Guido van Rossum 2000-09-15T15:34:00Z The original complaint (about the icon being set to *IDLE) was taken care of by explanation. The remaining issue of the proper className is taken care of by using Tk(className="Idle") in PyShell.py -- Fred just checked this in. 2000-07-31T21:06:00Z sf210618 Jitterbug-Id: 219 Submitted-By: aa8vb@yahoo.com Date: Mon, 28 Feb 2000 07:49:55 -0500 (EST) Version: 1.5.2 OS: IRIX 6.5.6f (Two problems leading up to allowing IDLE to read color settings from ~/.idle.py. They're separate problems so I'll put each in separate bug reports.) As Bernhard Herzog recently pointed out, Tkinter apps try to load .<classname>.tcl, .<classname>.py, .<appname>.tcl and .<appname>.py out of a user's home directory, if present. <classname> defaults to "Tk" and <appname> defaults to the base of argv[0] (e.g. "idle"). With these reasonable defaults, one would expect they could create a ~/.idle.py which IDLE would read for configuration info. However, Tkinter "won't" try to read ~/.idle.py unless -e is specified. This is because IDLE is hacking up sys.argv for some reason when -e isn't specified, which results in sys.argv[0] being empty, which prevents baseName from being set, which in turn causes Tkinter to look for these files: ~/.Tk.tcl ~/.Tk.py ~/..tcl ~/..py instead of: ~/.Tk.tcl ~/.Tk.py ~/.idle.tcl ~/.idle.py Seeing this, I verified that IDLE does indeed read ~/.idle.py when invoked as "idle.py -e". This appears to be a bug. If so, please update IDLE so that argv[0] is left unadulterated at least until Tkinter is initialized, so that it can read ~/.<basename>.py for configuration. Also, it might be worthwhile to set the className (argument to Tk()) to "Idle" or "IDLE" so an IDLE configuration file can be created which will be executed independent of what the idle script itself is named. ==================================================================== Audit trail: Tue Mar 07 14:38:27 2000 guido changed notes Tue Mar 07 14:38:27 2000 guido changed notification Tue Mar 07 14:38:27 2000 guido moved from incoming to open Bug Importer FIXRELEASED LOW Fred Drake idle Bug Importer Bug Importer 2000-07-31T21:06:00Z Jitterbug-Id: 219 Submitted-By: aa8vb@yahoo.com Date: Mon, 28 Feb 2000 07:49:55 -0500 (EST) Version: 1.5.2 OS: IRIX 6.5.6f (Two problems leading up to allowing IDLE to read color settings from ~/.idle.py. They're separate problems so I'll put each in separate bug reports.) As Bernhard Herzog recently pointed out, Tkinter apps try to load .<classname>.tcl, .<classname>.py, .<appname>.tcl and .<appname>.py out of a user's home directory, if present. <classname> defaults to "Tk" and <appname> defaults to the base of argv[0] (e.g. "idle"). With these reasonable defaults, one would expect they could create a ~/.idle.py which IDLE would read for configuration info. However, Tkinter "won't" try to read ~/.idle.py unless -e is specified. This is because IDLE is hacking up sys.argv for some reason when -e isn't specified, which results in sys.argv[0] being empty, which prevents baseName from being set, which in turn causes Tkinter to look for these files: ~/.Tk.tcl ~/.Tk.py ~/..tcl ~/..py instead of: ~/.Tk.tcl ~/.Tk.py ~/.idle.tcl ~/.idle.py Seeing this, I verified that IDLE does indeed read ~/.idle.py when invoked as "idle.py -e". This appears to be a bug. If so, please update IDLE so that argv[0] is left unadulterated at least until Tkinter is initialized, so that it can read ~/.<basename>.py for configuration. Also, it might be worthwhile to set the className (argument to Tk()) to "Idle" or "IDLE" so an IDLE configuration file can be created which will be executed independent of what the idle script itself is named. ==================================================================== Audit trail: Tue Mar 07 14:38:27 2000 guido changed notes Tue Mar 07 14:38:27 2000 guido changed notification Tue Mar 07 14:38:27 2000 guido moved from incoming to open Jeremy Hylton 2000-09-07T22:05:00Z Please do triage on this bug. Fred Drake 2000-09-15T04:33:00Z This is fixed in Tools/idle/PyShell.py revision 1.30. 2000-07-31T21:06:00Z sf210619 Jitterbug-Id: 221 Submitted-By: tarka@zip.com.au Date: Tue, 29 Feb 2000 19:15:45 -0500 (EST) Version: 1.5.2 OS: Irix urllib.py fails to handle proxies with user and password information included in the proxy URL, e.g. http://ssmith:testpass@10.11.12.13:1234 The following example ... import os, urllib os.environ['http_proxy'] = "http://ssmith:testpass01@10.11.12.13:1234" f = urllib.urlopen('http://www.python.org') data = f.read() print data fails with the following errors : Traceback (innermost last): File "url.py", line 3, in ? f = urllib.urlopen('http://www.python.org') File "/var/share//lib/python1.5/urllib.py", line 59, in urlopen return _urlopener.open(url) File "/var/share//lib/python1.5/urllib.py", line 157, in open return getattr(self, name)(url) File "/var/share//lib/python1.5/urllib.py", line 253, in open_http h = httplib.HTTP(host) File "/var/share//lib/python1.5/httplib.py", line 51, in __init__ if host: self.connect(host, port) File "/var/share//lib/python1.5/httplib.py", line 75, in connect raise socket.error, "nonnumeric port" IOError: [Errno socket error] nonnumeric port ==================================================================== Audit trail: Mon May 22 17:35:04 2000 guido moved from incoming to open Bug Importer REJECTED LOW feature-request Fred Drake python-library Bug Importer Bug Importer 2000-07-31T21:06:00Z Jitterbug-Id: 221 Submitted-By: tarka@zip.com.au Date: Tue, 29 Feb 2000 19:15:45 -0500 (EST) Version: 1.5.2 OS: Irix urllib.py fails to handle proxies with user and password information included in the proxy URL, e.g. http://ssmith:testpass@10.11.12.13:1234 The following example ... import os, urllib os.environ['http_proxy'] = "http://ssmith:testpass01@10.11.12.13:1234" f = urllib.urlopen('http://www.python.org') data = f.read() print data fails with the following errors : Traceback (innermost last): File "url.py", line 3, in ? f = urllib.urlopen('http://www.python.org') File "/var/share//lib/python1.5/urllib.py", line 59, in urlopen return _urlopener.open(url) File "/var/share//lib/python1.5/urllib.py", line 157, in open return getattr(self, name)(url) File "/var/share//lib/python1.5/urllib.py", line 253, in open_http h = httplib.HTTP(host) File "/var/share//lib/python1.5/httplib.py", line 51, in __init__ if host: self.connect(host, port) File "/var/share//lib/python1.5/httplib.py", line 75, in connect raise socket.error, "nonnumeric port" IOError: [Errno socket error] nonnumeric port ==================================================================== Audit trail: Mon May 22 17:35:04 2000 guido moved from incoming to open Fred Drake 2000-08-31T17:15:00Z Will be documented as a limitation in the implementation, as suggested in bug #111725. I'm converting this to a feature request that can be dealt with in a subsequent version of Python. Jeremy Hylton 2000-09-07T22:04:00Z Please do triage on this bug. Guido van Rossum 2000-09-13T10:17:00Z Fred, please document this limitation, add this to the feature-requests PEP (to be created), and then close the bug. Fred Drake 2000-09-15T04:16:00Z This limitation was already documented, but I've added a note that should be easier to find for people looking for limitations. Also fixed typo from existing note. This is checked in as Doc/lib/liburllib.tex revision 1.29. Fred Drake 2000-09-15T17:26:00Z Moved request to Feature Requests PEP & submitted to the PEP Editor. 2000-07-31T21:06:00Z sf210620 Jitterbug-Id: 224 Submitted-By: Gregor Hoffleit <flight@mathi.uni-heidelberg.de> Date: Sat, 4 Mar 2000 20:45:20 +0100 Version: None OS: None --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I think Python 1.5.2's configure script is to fast with including -lieee in= LIBS. I would suggest the following change to configure.in: @@ -850,7 +856,10 @@ # (none yet) =20 # Linux requires this for correct f.p. operations -AC_CHECK_LIB(ieee, __fpu_control) +AC_CHECK_FUNC(__fpu_control, + [], + [AC_CHECK_LIB(ieee, __fpu_control) +]) =20 # Check for --with-fpectl AC_MSG_CHECKING(for --with-fpectl) This mean, libieee will only by tried if __fpu_control isn't found elsewhere (i.e. in libc).=20 =20 With glibc 2.x, Linux doesn't need libieee anymore (it's still there for compilation of legacy applications, but it's an empty static library), since __fpu_control() is already defined in the libc library. Furthermore, __fpu_control() is only used in fpectlmodule which currently doesn't build with glibc 2.1 anyway due to the absence of __setfpucw (see manpage below). Does anybody know how to fix fpectlmodule for glibc 2.1 ? How does __setfpucw(0x1372) translate into the _FPU_SETCW language ? Gregor =20 NAME __setfpucw - set fpu control word on i386 architecture (obsolete) SYNOPSIS #include <i386/fpu_control.h> void __setfpucw((unsigned short) control_word); DESCRIPTION __setfpucw transfer control_word to the registers of the fpu (floating point unit) on i386 architecture. This was used to control floating point precision, rounding and floating point exceptions. AVAILABILITY As of glibc 2.1 (libc6 2.1) this function does not exist anymore. There are new functions from ISO C 9x to control fpu rounding modes. These functions don't have manpages, but are documented in the info docs. If direct acces to the FPU control word is still needed, the _FPU_GETCW and _FPU_SETCW macros from /usr/include/fpu_control.h can be used. =20 --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4wWfQ3eVfDf25G40RAel1AKC+sA67Wy2fzav4T0fAYd84PXT4rQCdGXdr j9s6W3nqetjTtWGLg1g7C0Y= =Y40q -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx-- ==================================================================== Audit trail: Mon May 22 17:36:47 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM build Bug Importer Bug Importer 2000-07-31T21:06:00Z Jitterbug-Id: 224 Submitted-By: Gregor Hoffleit <flight@mathi.uni-heidelberg.de> Date: Sat, 4 Mar 2000 20:45:20 +0100 Version: None OS: None --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I think Python 1.5.2's configure script is to fast with including -lieee in= LIBS. I would suggest the following change to configure.in: @@ -850,7 +856,10 @@ # (none yet) =20 # Linux requires this for correct f.p. operations -AC_CHECK_LIB(ieee, __fpu_control) +AC_CHECK_FUNC(__fpu_control, + [], + [AC_CHECK_LIB(ieee, __fpu_control) +]) =20 # Check for --with-fpectl AC_MSG_CHECKING(for --with-fpectl) This mean, libieee will only by tried if __fpu_control isn't found elsewhere (i.e. in libc).=20 =20 With glibc 2.x, Linux doesn't need libieee anymore (it's still there for compilation of legacy applications, but it's an empty static library), since __fpu_control() is already defined in the libc library. Furthermore, __fpu_control() is only used in fpectlmodule which currently doesn't build with glibc 2.1 anyway due to the absence of __setfpucw (see manpage below). Does anybody know how to fix fpectlmodule for glibc 2.1 ? How does __setfpucw(0x1372) translate into the _FPU_SETCW language ? Gregor =20 NAME __setfpucw - set fpu control word on i386 architecture (obsolete) SYNOPSIS #include <i386/fpu_control.h> void __setfpucw((unsigned short) control_word); DESCRIPTION __setfpucw transfer control_word to the registers of the fpu (floating point unit) on i386 architecture. This was used to control floating point precision, rounding and floating point exceptions. AVAILABILITY As of glibc 2.1 (libc6 2.1) this function does not exist anymore. There are new functions from ISO C 9x to control fpu rounding modes. These functions don't have manpages, but are documented in the info docs. If direct acces to the FPU control word is still needed, the _FPU_GETCW and _FPU_SETCW macros from /usr/include/fpu_control.h can be used. =20 --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4wWfQ3eVfDf25G40RAel1AKC+sA67Wy2fzav4T0fAYd84PXT4rQCdGXdr j9s6W3nqetjTtWGLg1g7C0Y= =Y40q -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx-- ==================================================================== Audit trail: Mon May 22 17:36:47 2000 guido moved from incoming to open 2000-07-31T21:06:00Z sf210621 Jitterbug-Id: 235 Submitted-By: piers@cs.su.oz.au Date: Tue, 14 Mar 2000 18:55:39 -0500 (EST) Version: 1.5.2 OS: sunos RFC822 specifies an address form known as a "domain literal", eg: [132.151.1.21], but rfc822.parseaddr() incorrectly strips the square brackets denoting special treatment of the contents. (This routine is used by smtplib module, and thus causes it to deliver messages using this form of address incorrectly.) Here is an example: : s ; python Python 1.5.2 (#10, May 11 1999, 15:32:03) [GCC 2.8.1] on sunos5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import rfc822 >>> rfc822.parseaddr('guido@[132.151.1.21]') ('', 'guido@132.151.1.21') >>> ==================================================================== Audit trail: Mon May 22 17:36:36 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM barry python-library Bug Importer Bug Importer 2000-07-31T21:06:00Z Jitterbug-Id: 235 Submitted-By: piers@cs.su.oz.au Date: Tue, 14 Mar 2000 18:55:39 -0500 (EST) Version: 1.5.2 OS: sunos RFC822 specifies an address form known as a "domain literal", eg: [132.151.1.21], but rfc822.parseaddr() incorrectly strips the square brackets denoting special treatment of the contents. (This routine is used by smtplib module, and thus causes it to deliver messages using this form of address incorrectly.) Here is an example: : s ; python Python 1.5.2 (#10, May 11 1999, 15:32:03) [GCC 2.8.1] on sunos5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import rfc822 >>> rfc822.parseaddr('guido@[132.151.1.21]') ('', 'guido@132.151.1.21') >>> ==================================================================== Audit trail: Mon May 22 17:36:36 2000 guido moved from incoming to open barry 2000-09-25T15:06:00Z The patch is simple. Change line 706 (in the 2.0beta1 CVS tree) to read return '[%s]' % self.getdelimited('[', ']\r', 0) to rewrap the value in angle brackets. Will try to get this into 2.0beta2. 2000-07-31T21:06:00Z sf210622 Jitterbug-Id: 236 Submitted-By: jsolbrig@webcom.com Date: Tue, 14 Mar 2000 19:55:22 -0500 (EST) Version: 1.5.2 OS: Win32/win95 pdb (python debugger) tends to drop (ignore) breaks in multi-file debugging. I wish I had time to isolate the offending code but I don't. ==================================================================== Audit trail: Mon May 22 17:37:26 2000 guido moved from incoming to open Bug Importer REJECTED MEDIUM irreproducible Mark Hammond python-library Bug Importer Bug Importer 2000-07-31T21:06:00Z Jitterbug-Id: 236 Submitted-By: jsolbrig@webcom.com Date: Tue, 14 Mar 2000 19:55:22 -0500 (EST) Version: 1.5.2 OS: Win32/win95 pdb (python debugger) tends to drop (ignore) breaks in multi-file debugging. I wish I had time to isolate the offending code but I don't. ==================================================================== Audit trail: Mon May 22 17:37:26 2000 guido moved from incoming to open Mark Hammond 2000-08-14T06:37:00Z I've done extensive work with bdb and pdb, and never seen this. I believe we can close this as irreproducible, and I will in a few days unless someone screams or describes a reproduction scenario. Mark Hammond 2000-08-31T06:08:00Z Oops - marked as "irreproducible" and "works for me", but left open! 2000-07-31T21:07:00Z sf210623 Jitterbug-Id: 240 Submitted-By: kragen@pobox.com (Kragen Sitaker) Date: Fri, 17 Mar 2000 16:09:19 -0500 (EST) Version: None OS: None I'm building Python on NeXTStep; I've encountered three minor problems. - importdl.c by default on NeXTStep allows linking with Objective-C modules, which is cool. Unfortunately, properly supporting this requires adding -ObjC to the cc command line in the Makefile. - posixmodule.c doesn't #include anything that declares fsync() and doesn't declare it itself, but tries to reference it. Adding a declaration of fsync() fixes the problem. - test_strftime and test_time fail. test test_strftime failed -- Writing: 'Conflict for %j (julian day (001-366)):', expected: '' I suspect this may be a platform bug. Here's some of the output, which is 696 lines in full: strftime test for Fri Mar 17 12:53:20 2000 Strftime test, platform: next3_3, Python version: 1.5.2 Conflict for %j (julian day (001-366)): Expected 077, but got 076 Conflict for nonstandard '%c' format (near-asctime() format): Expected Fri Mar 17 12:53:20 2000, but got Fri Mar 17 12:53:20 2000 Conflict for nonstandard '%x' format (%m/%d/%y %H:%M:%S): Expected 03/17/00, but got Fri Mar 17 2000 Does not appear to support '%Z' format (time zone name) Conflict for nonstandard '%D' format (mm/dd/yy): Expected 03/17/00, but got ? Conflict for nonstandard '%e' format (day of month as number, blank padded ( 0-31)): Expected 17, but got ? Conflict for nonstandard '%h' format (abbreviated month name): Expected Mar, but got ? Conflict for nonstandard '%k' format (hour, blank padded ( 0-23)): Expected 12, but got ? Conflict for nonstandard '%n' format (newline character): Expected , but got ? Conflict for nonstandard '%r' format (%I:%M:%S %p): Expected 12:53:20 PM, but got ? Conflict for nonstandard '%R' format (%H:%M): Expected 12:53, but got ? Conflict for nonstandard '%s' format (seconds since the Epoch in UCT): Expected 953326400, but got ? Conflict for nonstandard '%t' format (tab character): Expected , but got ? Conflict for nonstandard '%T' format (%H:%M:%S): Expected 12:53:20, but got ? Conflict for nonstandard '%3y' format (year without century rendered using fieldwidth): Expected 000, but got ?y Conflict for %j (julian day (001-366)): Expected 327, but got 326 Conflict for %W (week number of the year (Mon 1st)): Expected 46, but got 47 Conflict for %j (julian day (001-366)): Expected 328, but got 327 Conflict for %j (julian day (001-366)): Expected 329, but got 328 Conflict for %j (julian day (001-366)): Expected 330, but got 329 test test_time failed -- Writing: 'time.mktime(time.localtime(t)) <> t', expected: '' (and that was all of the output from test_time. Presumably this is related to the strftime bugs --- perhaps the mythical Y2K leap-year bug?) I'm afraid I'm not sure what version of NeXTStep I'm on. 'arch' reports 'hppa'; 'cc --version' reports '2.5.8'; 'uname -a' reports 'Command not found'. I'm not trying to build a very sophisticated environment --- just the defaults. -- <kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/> The Internet stock bubble didn't burst on 1999-11-08. Hurrah! <URL:http://www.pobox.com/~kragen/bubble.html> The power didn't go out on 2000-01-01 either. :) ==================================================================== Audit trail: Mon Apr 03 18:40:11 2000 guido changed notes Mon Apr 03 18:40:11 2000 guido moved from incoming to open Bug Importer REJECTED MEDIUM platform-specific build Bug Importer Bug Importer 2000-07-31T21:07:00Z Jitterbug-Id: 240 Submitted-By: kragen@pobox.com (Kragen Sitaker) Date: Fri, 17 Mar 2000 16:09:19 -0500 (EST) Version: None OS: None I'm building Python on NeXTStep; I've encountered three minor problems. - importdl.c by default on NeXTStep allows linking with Objective-C modules, which is cool. Unfortunately, properly supporting this requires adding -ObjC to the cc command line in the Makefile. - posixmodule.c doesn't #include anything that declares fsync() and doesn't declare it itself, but tries to reference it. Adding a declaration of fsync() fixes the problem. - test_strftime and test_time fail. test test_strftime failed -- Writing: 'Conflict for %j (julian day (001-366)):', expected: '' I suspect this may be a platform bug. Here's some of the output, which is 696 lines in full: strftime test for Fri Mar 17 12:53:20 2000 Strftime test, platform: next3_3, Python version: 1.5.2 Conflict for %j (julian day (001-366)): Expected 077, but got 076 Conflict for nonstandard '%c' format (near-asctime() format): Expected Fri Mar 17 12:53:20 2000, but got Fri Mar 17 12:53:20 2000 Conflict for nonstandard '%x' format (%m/%d/%y %H:%M:%S): Expected 03/17/00, but got Fri Mar 17 2000 Does not appear to support '%Z' format (time zone name) Conflict for nonstandard '%D' format (mm/dd/yy): Expected 03/17/00, but got ? Conflict for nonstandard '%e' format (day of month as number, blank padded ( 0-31)): Expected 17, but got ? Conflict for nonstandard '%h' format (abbreviated month name): Expected Mar, but got ? Conflict for nonstandard '%k' format (hour, blank padded ( 0-23)): Expected 12, but got ? Conflict for nonstandard '%n' format (newline character): Expected , but got ? Conflict for nonstandard '%r' format (%I:%M:%S %p): Expected 12:53:20 PM, but got ? Conflict for nonstandard '%R' format (%H:%M): Expected 12:53, but got ? Conflict for nonstandard '%s' format (seconds since the Epoch in UCT): Expected 953326400, but got ? Conflict for nonstandard '%t' format (tab character): Expected , but got ? Conflict for nonstandard '%T' format (%H:%M:%S): Expected 12:53:20, but got ? Conflict for nonstandard '%3y' format (year without century rendered using fieldwidth): Expected 000, but got ?y Conflict for %j (julian day (001-366)): Expected 327, but got 326 Conflict for %W (week number of the year (Mon 1st)): Expected 46, but got 47 Conflict for %j (julian day (001-366)): Expected 328, but got 327 Conflict for %j (julian day (001-366)): Expected 329, but got 328 Conflict for %j (julian day (001-366)): Expected 330, but got 329 test test_time failed -- Writing: 'time.mktime(time.localtime(t)) <> t', expected: '' (and that was all of the output from test_time. Presumably this is related to the strftime bugs --- perhaps the mythical Y2K leap-year bug?) I'm afraid I'm not sure what version of NeXTStep I'm on. 'arch' reports 'hppa'; 'cc --version' reports '2.5.8'; 'uname -a' reports 'Command not found'. I'm not trying to build a very sophisticated environment --- just the defaults. -- <kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/> The Internet stock bubble didn't burst on 1999-11-08. Hurrah! <URL:http://www.pobox.com/~kragen/bubble.html> The power didn't go out on 2000-01-01 either. :) ==================================================================== Audit trail: Mon Apr 03 18:40:11 2000 guido changed notes Mon Apr 03 18:40:11 2000 guido moved from incoming to open Bug Importer 2000-07-31T21:07:00Z From: Guido van Rossum <guido@python.org> Subject: Re: [Python-bugs-list] build on NeXTStep (PR#240) Date: Tue, 28 Mar 2000 14:41:28 -0500 > It's NeXTStep 3.3. > > > Can you send us some patches? We don't have a NextStep system around > > to test any of this, and your description of the problem doesn't help > > me to create fixes that will certainly work for you. > > I can send a patch for importdl.c; the right thing to do for this would > be to modify the Makefile to change the flags passed to the compiler to > include -ObjC, but I don't know how to do that. My solution was to > change a #define in the source to turn off the ability to import > Objective-C modules, which is obviously far from optimal --- thus my > failure to include a patch for this in the first email. > > In posixmodule.c, which needs fsync() declared, I'm not sure where to > declare it. I can certainly supply a patch that works for NeXTStep > 3.3, but I don't understand the rat's-nest of #ifdefs there well enough > to be sure it won't break compilation on some other platform, or even > another version of NeXTStep --- thus my failure to include a patch for > this in the first email. > > So I can send patches for both of these, but I am not sure if I should. Maybe we should just drop it? I don't think NextStep 3.3 has much future or even much current use, does it? it's only supported for historic reasons. If you get it to work, fine -- but I don't think the general public would benefit much from adding NS 3.3 support... Or am I wrong? --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-07-31T21:07:00Z From: kragen@pobox.com (Kragen Sitaker) Subject: Re: [Python-bugs-list] build on NeXTStep (PR#240) Date: Tue, 28 Mar 2000 12:46:18 -0500 (EST) Guido writes: > [Kragen wrote:] > > I'm afraid I'm not sure what version of NeXTStep I'm on. 'arch' > > reports 'hppa'; 'cc --version' reports '2.5.8'; 'uname -a' reports > > 'Command not found'. It's NeXTStep 3.3. > Can you send us some patches? We don't have a NextStep system around > to test any of this, and your description of the problem doesn't help > me to create fixes that will certainly work for you. I can send a patch for importdl.c; the right thing to do for this would be to modify the Makefile to change the flags passed to the compiler to include -ObjC, but I don't know how to do that. My solution was to change a #define in the source to turn off the ability to import Objective-C modules, which is obviously far from optimal --- thus my failure to include a patch for this in the first email. In posixmodule.c, which needs fsync() declared, I'm not sure where to declare it. I can certainly supply a patch that works for NeXTStep 3.3, but I don't understand the rat's-nest of #ifdefs there well enough to be sure it won't break compilation on some other platform, or even another version of NeXTStep --- thus my failure to include a patch for this in the first email. So I can send patches for both of these, but I am not sure if I should. > Please read python.org/patches for info on how to submit patches. Thanks. -- <kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/> The Internet stock bubble didn't burst on 1999-11-08. Hurrah! <URL:http://www.pobox.com/~kragen/bubble.html> The power didn't go out on 2000-01-01 either. :) Bug Importer 2000-07-31T21:07:00Z From: Guido van Rossum <guido@python.org> Subject: Re: [Python-bugs-list] build on NeXTStep (PR#240) Date: Fri, 24 Mar 2000 10:05:14 -0500 > I'm building Python on NeXTStep; I've encountered three minor problems. > > - importdl.c by default on NeXTStep allows linking with Objective-C > modules, which is cool. Unfortunately, properly supporting this > requires adding -ObjC to the cc command line in the Makefile. > - posixmodule.c doesn't #include anything that declares fsync() and > doesn't declare it itself, but tries to reference it. Adding a > declaration of fsync() fixes the problem. > - test_strftime and test_time fail. > test test_strftime failed -- Writing: 'Conflict for %j (julian day (001-366)):', expected: '' > I suspect this may be a platform bug. Here's some of the output, > which is 696 lines in full: [...] > (and that was all of the output from test_time. Presumably this is > related to the strftime bugs --- perhaps the mythical Y2K leap-year bug?) > > I'm afraid I'm not sure what version of NeXTStep I'm on. 'arch' > reports 'hppa'; 'cc --version' reports '2.5.8'; 'uname -a' reports > 'Command not found'. > > I'm not trying to build a very sophisticated environment --- just the > defaults. Kragen, Can you send us some patches? We don't have a NextStep system around to test any of this, and your description of the problem doesn't help me to create fixes that will certainly work for you. There's probably not much you can do about the strftime problem -- just don't use time.strftime()! :-) Please read python.org/patches for info on how to submit patches. Thanks for contributing! --Guido van Rossum (home page: http://www.python.org/~guido/) Jeremy Hylton 2000-08-28T14:41:00Z Kragen says thius bug report is probably only useful as proof that it is possible to get Python to build on Nextstep 3.2 on Hp-HPs. A closed bug report should satisfy that need as well as an open one. Not opposed to patches to allow builds under nextstep, but no one has the expertise to provide them. 2000-07-31T21:08:00Z sf210624 Jitterbug-Id: 245 Submitted-By: sde@recombinant.demon.co.uk Date: Wed, 22 Mar 2000 16:13:26 -0500 (EST) Version: 1.5.2 OS: win32 #! /usr/bin/python # Inconsistent behaviour. # Python 1.5.2 win32 fails the second print (why not both?) # other versions print both expressions # Ok Python 1.5.2 on SuSE Linux 6.3 # Ok JPython 1.1 on java1.1.7B # Partial failure Python 1.5.2 win32 print eval("float(1.0e-309)") print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 ==================================================================== Audit trail: Fri Mar 24 16:42:36 2000 guido changed notes Fri Mar 24 16:42:36 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM Tim Peters python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:08:00Z Jitterbug-Id: 245 Submitted-By: sde@recombinant.demon.co.uk Date: Wed, 22 Mar 2000 16:13:26 -0500 (EST) Version: 1.5.2 OS: win32 #! /usr/bin/python # Inconsistent behaviour. # Python 1.5.2 win32 fails the second print (why not both?) # other versions print both expressions # Ok Python 1.5.2 on SuSE Linux 6.3 # Ok JPython 1.1 on java1.1.7B # Partial failure Python 1.5.2 win32 print eval("float(1.0e-309)") print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 ==================================================================== Audit trail: Fri Mar 24 16:42:36 2000 guido changed notes Fri Mar 24 16:42:36 2000 guido moved from incoming to open Bug Importer 2000-07-31T21:08:00Z From: "Tim Peters" <tim_one@email.msn.com> Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Tue, 4 Apr 2000 00:29:01 -0400 [Guido] > OK, so let's stick with the defaults that 754 presecribes until we can > give the user control. That's the purpose of defaults, right? In every world other 754 (see below), but we really have no choice now (because C doesn't give us any control now). > I think even 754 tells us that 1e-500 is smaller than what we normally > need to deal with. Well, there is no 1e-500 under 754, which is why there's some reason to at least warn about it (if the user wanted 0, why didn't they type 0?). > Again: 754 gives a default. I want to conform to the default -- it's > better to provide control, but even when we provide control, there will > still be default behavior, and (if I understand 754 correctly) the > default is not to interrupt for underflow. The 754 default is never to raise an exception no matter what, whether overflow, underflow, invalid operation (like sqrt(-4)), or divide by 0. So Python's current behavior wrt these two is non-conforming: math.sqrt(-4) 1. / 0. However, 754 is primarily a HW std, and the defaults were prescribed by a committee of HW geeks and math library authors. They were caught totally off guard by how long it took for languages to provide the control features the std also mandates -- for "regular users" it's plainly insane to avoid griping about the two above, and it was never 754's intent to let them pass silently for regular users. Note that Java has been skewered mercilessly by Kahan (Mr. 754 Himself) for accepting the defaults but not providing the also-mandated control functions. The std is subtler than it appears, and all the fiddly bits are really needed. >> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >> >>> 1e500 >> 1.#INF >> >>> 1e200**2 >> 1.#INF >> >>> > Oops, you're right. Must be another 754 default behavior! Right. > I would personally also prefer an exception for overflow. You don't > say what you want for underflow though. I still like silent underflow > to zero by default. 754 defines (almost) everything: underflow when the underflow exception is masked out must deliver a zero with the same sign as the infinite-precision result. > I'm not fighting it. You will <wink>; e.g., returning 1 for "x == x" is incorrect when x is a NaN. > Say the ideal Python has full user control over fp exceptions. What > should the defaults be? IMO, exception on overflow, divide-by-0 and invalid operation. Let underflow and inexact pass silently. That's what I implemented at KSR, and customers were *very* much happier with that than with the 754 defaults. Of course I also implemented all the 754 control and status inquiry functions, so the one 754-savvy programmer per site was happy too (they need the control to write robust numerical libraries for everyone else to use -- the *true* purpose of the 754 HW defaults). > Python 1.6 should have the same defaults, even if it doesn't have the > controls. This is a big project, as there's no portable way even to detect fp overflow now. The math libraries should play along too. > I'll change float() to use atof(). OK by me! Bug Importer 2000-07-31T21:08:00Z From: Guido van Rossum <guido@python.org> Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Sat, 25 Mar 2000 14:15:54 -0500 > "In the face of ambiguity, refuse the temptation to guess". > > That's one of the Pythonic Theses you're tempted to ignore too often <wink>. > > Part of taking 754 seriously is that 754 gives the user complete control > over what happens in case of exceptions (including underflow): ignore them, > raise a fatal error, or simply set a flag saying it occurred. > Unfortunately, we have to wait for C9x until there's a portable way to get > at that stuff. Before then, it requires wildly varying platform-specific > hair. OK, so let's stick with the defaults that 754 presecribes until we can give the user control. That's the purpose of defaults, right? > > Hm, I'm not so sure. Suppose I'm writing a program that reads a data > > files generated by some Fortran program. The Fortran program is > > giving me points to plot for example. If Fortran manages to output > > 1e-500, wouldn't it make more sense if I rounded that to zero instead > > of rejecting it? > > This *may* make good sense if Python had certain knowledge that the program > is merely going to plot the points, but probably not even then. That is, > "insignificantly small" is relative to the application, and e.g. for all we > know the Fortran program generated a million doubles *all* in the range > [1e-500, 10e-500]: the intended plot of the data could very well be a > pointillistic version of the Mona Lisa rather than a straight line. OK, forget the example. > > After all, after converting to plot precision it's > > going to be zero anyway. > > As above, this conclusion relies on the dubious assumption that 1e-500 is > very much smaller than the other values. I think even 754 tells us that 1e-500 is smaller than what we normally need to deal with. > > This way I could almost defend using strtod() for literals in > > Python source code (where it makes more sense to warn about underflow) > > but atof() for input. Except that of course input could conceivably > > be using eval()... > > > > Another argument for turning underflow into zero is that that also > > happens in regular arithmetic: > > > > >>> 0.1**2**8 > > 1.0000000000000275e-256 > > >>> 0.1**2**9 > > 0.0 > > Which is often desired but sometimes a disaster -- the language simply can't > guess. On whatever machine you ran this on, it almost certainly set the > "underflow happened" flag but continued on because the underflow exception > was masked out by default. Again: 754 gives a default. I want to conform to the default -- it's better to provide control, but even when we provide control, there will still be default behavior, and (if I understand 754 correctly) the default is not to interrupt for underflow. > > I like this uniform behavior: overflow -> exception, underflow -> > > zero. My calculator does this too. > > Not mine <wink>. Really, whether underflow gripes is controlled by a > user-settable flag on high end HP calculators. Note too that neither does > float *overflow* raise an exception under most Pythons today: > > D:\Python>python > Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> 1e500 > 1.#INF > >>> 1e200**2 > 1.#INF > >>> Oops, you're right. Must be another 754 default behavior! > I personally favor raising exceptions (by default) on 754's overflow, divide > by 0, and invalid operation conditions, while (again by default) letting > the HW's 754 control registers to make that happen. P3K, not now. I would personally also prefer an exception for overflow. You don't say what you want for underflow though. I still like silent underflow to zero by default. > > Am I hopelessly naive about this? > > Not *entirely* hopeless, but close <wink>. If we ever talk about it for an > hour, I'll convince you of the futility of fighting 754. They beat all > resistance out of me in a mere decade <0.5 wink>. I'm not fighting it. Say the ideal Python has full user control over fp exceptions. What should the defaults be? Python 1.6 should have the same defaults, even if it doesn't have the controls. > > What else can we do? > > Not much! Switching uniformly to either atof() or strtod() would be OK by > me for now, although I don't think patching over the current inconsistency > buys enough bang for the buck to be worth the effort. > > > What control does C give? > > None, until C9X. > > > What does sscanf() do? > > I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI > C's numerics fight the *right* thing to do now just about every step of the > way. C9x is supposed to fix all that. > > In the meantime, I think what JPython does is much more interesting (but > don't know what that is): whatever we do here should be consistent with The > Other Python too, and Java has a much better 754 story than ANSI C. 754 is > here to stay, but the last iteration of ANSI C isn't. Best guess is that > Java acts more like atof than strtod in this case. Bingo. Indeed it does. 1e500 prints as Infinity; 1e-500 is 0.0, either as literal or when converted from a string. I'll change float() to use atof(). --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-07-31T21:08:00Z From: "Tim Peters" <tim_one@email.msn.com> Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 23:53:10 -0500 "In the face of ambiguity, refuse the temptation to guess". That's one of the Pythonic Theses you're tempted to ignore too often <wink>. Part of taking 754 seriously is that 754 gives the user complete control over what happens in case of exceptions (including underflow): ignore them, raise a fatal error, or simply set a flag saying it occurred. Unfortunately, we have to wait for C9x until there's a portable way to get at that stuff. Before then, it requires wildly varying platform-specific hair. > Hm, I'm not so sure. Suppose I'm writing a program that reads a data > files generated by some Fortran program. The Fortran program is > giving me points to plot for example. If Fortran manages to output > 1e-500, wouldn't it make more sense if I rounded that to zero instead > of rejecting it? This *may* make good sense if Python had certain knowledge that the program is merely going to plot the points, but probably not even then. That is, "insignificantly small" is relative to the application, and e.g. for all we know the Fortran program generated a million doubles *all* in the range [1e-500, 10e-500]: the intended plot of the data could very well be a pointillistic version of the Mona Lisa rather than a straight line. > After all, after converting to plot precision it's > going to be zero anyway. As above, this conclusion relies on the dubious assumption that 1e-500 is very much smaller than the other values. > This way I could almost defend using strtod() for literals in > Python source code (where it makes more sense to warn about underflow) > but atof() for input. Except that of course input could conceivably > be using eval()... > > Another argument for turning underflow into zero is that that also > happens in regular arithmetic: > > >>> 0.1**2**8 > 1.0000000000000275e-256 > >>> 0.1**2**9 > 0.0 Which is often desired but sometimes a disaster -- the language simply can't guess. On whatever machine you ran this on, it almost certainly set the "underflow happened" flag but continued on because the underflow exception was masked out by default. > I like this uniform behavior: overflow -> exception, underflow -> > zero. My calculator does this too. Not mine <wink>. Really, whether underflow gripes is controlled by a user-settable flag on high end HP calculators. Note too that neither does float *overflow* raise an exception under most Pythons today: D:\Python>python Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> 1e500 1.#INF >>> 1e200**2 1.#INF >>> I personally favor raising exceptions (by default) on 754's overflow, divide by 0, and invalid operation conditions, while (again by default) letting underflow and inexact pass without comment. But it again requires fiddling the HW's 754 control registers to make that happen. P3K, not now. > Am I hopelessly naive about this? Not *entirely* hopeless, but close <wink>. If we ever talk about it for an hour, I'll convince you of the futility of fighting 754. They beat all resistance out of me in a mere decade <0.5 wink>. > What else can we do? Not much! Switching uniformly to either atof() or strtod() would be OK by me for now, although I don't think patching over the current inconsistency buys enough bang for the buck to be worth the effort. > What control does C give? None, until C9X. > What does sscanf() do? I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI C's numerics fight the *right* thing to do now just about every step of the way. C9x is supposed to fix all that. In the meantime, I think what JPython does is much more interesting (but don't know what that is): whatever we do here should be consistent with The Other Python too, and Java has a much better 754 story than ANSI C. 754 is here to stay, but the last iteration of ANSI C isn't. Best guess is that Java acts more like atof than strtod in this case. Bug Importer 2000-07-31T21:08:00Z From: Guido van Rossum <guido@python.org> Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 23:14:29 -0500 > [atof and strtod act differently given denormals on both Windows & > Solaris] > > [Guido] > > ... > > Apparently strtod() and atof() differ in implementation, even though > > the Solaris man page says "The atof(str) function call is equivalent > > to strtod(str, (char **)NULL)." [Tim] > Ya, their man page is lying. atof() existed in the mists of prehistory and > typically did no error checking at all. IIRC, ANSI C introduced strtod(), > which generally got implemented as a layer of error-checking around atof. > > I have to take it back that this is a bug in MS's strtod: DBL_MIN is MS's > limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero > inputs with absolute value smaller than that. > > > We could fix this by changing float() to do its own syntax checking > > and then use atof()... Is it worth it? > > Depends on your goal <wink>: do you want more extreme cases, like 1e-500, > to blow up (strtod) or underflow to 0 (atof)? The example in the original > test case is subtler because atof made it *appear* to be "a regular old > number"; in fact, it's not, it's small enough that it falls into 754's > "denormalized" range. This means the conversion loses some extraordinary > amount of-- but not all --information (whereas 1e-500 is below even the > denorm range: conversion loses all information). > > Without a coherent strategy for dealing with 754 issues, it's hard to decide > which is better. Since strtod() is more restrictive, if this is worth > bothering about at all now (for P3K I think 754 needs to be taken > seriously), I actually recommend changing current atof() calls to use > native strtod() instead. Hm, I'm not so sure. Suppose I'm writing a program that reads a data files generated by some Fortran program. The Fortran program is giving me points to plot for example. If Fortran manages to output 1e-500, wouldn't it make more sense if I rounded that to zero instead of rejecting it? After all, after converting to plot precision it's going to be zero anyway. This way I could almost defend using strtod() for literals in Python source code (where it makes more sense to warn about underflow) but atof() for input. Except that of course input could conceivably be using eval()... Another argument for turning underflow into zero is that that also happens in regular arithmetic: >>> 0.1**2**8 1.0000000000000275e-256 >>> 0.1**2**9 0.0 I like this uniform behavior: overflow -> exception, underflow -> zero. My calculator does this too. Am I hopelessly naive about this? What else can we do? What control does C give? What does sscanf() do? --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-07-31T21:08:00Z From: "Tim Peters" <tim_one@email.msn.com> Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 22:48:50 -0500 [atof and strtod act differently given denormals on both Windows & Solaris] [Guido] > ... > Apparently strtod() and atof() differ in implementation, even though > the Solaris man page says "The atof(str) function call is equivalent > to strtod(str, (char **)NULL)." Ya, their man page is lying. atof() existed in the mists of prehistory and typically did no error checking at all. IIRC, ANSI C introduced strtod(), which generally got implemented as a layer of error-checking around atof. I have to take it back that this is a bug in MS's strtod: DBL_MIN is MS's limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero inputs with absolute value smaller than that. > We could fix this by changing float() to do its own syntax checking > and then use atof()... Is it worth it? Depends on your goal <wink>: do you want more extreme cases, like 1e-500, to blow up (strtod) or underflow to 0 (atof)? The example in the original test case is subtler because atof made it *appear* to be "a regular old number"; in fact, it's not, it's small enough that it falls into 754's "denormalized" range. This means the conversion loses some extraordinary amount of-- but not all --information (whereas 1e-500 is below even the denorm range: conversion loses all information). Without a coherent strategy for dealing with 754 issues, it's hard to decide which is better. Since strtod() is more restrictive, if this is worth bothering about at all now (for P3K I think 754 needs to be taken seriously), I actually recommend changing current atof() calls to use native strtod() instead. Bug Importer 2000-07-31T21:08:00Z From: Guido van Rossum <guido@python.org> Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 04:51:57 -0500 > > Full_Name: Stephen D Evans > > Version: 1.5.2 > > OS: win32 > > Submission from: recombinant.demon.co.uk (212.229.73.7) > > > > > > #! /usr/bin/python > > > > # Inconsistent behaviour. > > > > # Python 1.5.2 win32 fails the second print (why not both?) > > # other versions print both expressions > > > > # Ok Python 1.5.2 on SuSE Linux 6.3 > > # Ok JPython 1.1 on java1.1.7B > > # Partial failure Python 1.5.2 win32 > > > > print eval("float(1.0e-309)") > > print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 > > First note that these don't do the same thing: the first passes a float to > "float", the second passes a string to "float". Change the first to > > print eval("float('1.0e-309')") > > and it gives the same bogus error as the second one. > > Then it turns out the error is Microsoft's fault. This tiny C program shows > the bug: > > #include <errno.h> > #include <stdlib.h> > #include <stdio.h> > > void > main() > { > double x; > char* dontcare; > errno = 0; > x = strtod("1.0e-309", &dontcare); > printf("errno after = %d\n", errno); > printf("x after = %g\n", x); > } > > This prints > > errno after = 34 > x after = 0 > > when compiled & linked with MS's VC5; don't know about VC6. Same thing for > "1.0e-308". Works fine for "1.0e-307". Doubt this will get fixed before MS > fixes their library. The bizarre thing is that this is broken the same way on Solaris: >>> 1.0e-309 1.0000000000000019e-309 >>> float("1.0e-309") Traceback (innermost last): File "<stdin>", line 1, in ? ValueError: float() literal too large: 1.0e-309 >>> I looked and it turns out that Python uses atof() in the first case (string literal encountered in a Python expression) and strtod() in the second case (string passed to float()). Apparently strtod() and atof() differ in implementation, even though the Solaris man page says "The atof(str) function call is equivalent to strtod(str, (char **)NULL)." We could fix this by changing float() to do its own syntax checking and then use atof()... Is it worth it? --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-07-31T21:08:00Z From: "Tim Peters" <tim_one@email.msn.com> Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Thu, 23 Mar 2000 01:43:30 -0500 > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > sde@recombinant.demon.co.uk > Sent: Wednesday, March 22, 2000 4:13 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32 > (PR#245) > > > Full_Name: Stephen D Evans > Version: 1.5.2 > OS: win32 > Submission from: recombinant.demon.co.uk (212.229.73.7) > > > #! /usr/bin/python > > # Inconsistent behaviour. > > # Python 1.5.2 win32 fails the second print (why not both?) > # other versions print both expressions > > # Ok Python 1.5.2 on SuSE Linux 6.3 > # Ok JPython 1.1 on java1.1.7B > # Partial failure Python 1.5.2 win32 > > print eval("float(1.0e-309)") > print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 First note that these don't do the same thing: the first passes a float to "float", the second passes a string to "float". Change the first to print eval("float('1.0e-309')") and it gives the same bogus error as the second one. Then it turns out the error is Microsoft's fault. This tiny C program shows the bug: #include <errno.h> #include <stdlib.h> #include <stdio.h> void main() { double x; char* dontcare; errno = 0; x = strtod("1.0e-309", &dontcare); printf("errno after = %d\n", errno); printf("x after = %g\n", x); } This prints errno after = 34 x after = 0 when compiled & linked with MS's VC5; don't know about VC6. Same thing for "1.0e-308". Works fine for "1.0e-307". Doubt this will get fixed before MS fixes their library. Thomas Wouters 2000-08-03T12:43:00Z I *think* this one is fixed and closed. It looks like Guido promises to fix this, in any case, and it looks done. Guido van Rossum 2000-08-10T18:48:00Z No, it's not fixed, but it is platform dependent how it behaves. The conclusion was that we should use atof() everywhere, and write a separate syntax checker (since atof() stops at the first invalid character). I made a start at a syntax checker but then got distracted. Here's my code: static char * floatsyntax(char *s) { /* Check for valid floating point syntax: space* [sign] (digit+ [period digit*] | period digit+) [(e|E) [sign] digit+] space* */ int digits, period; while (isspace(*s)) s++; if (*s == '+' || *s == '-') s++; digits = period = 0; for (;;) { if (isdigit(*s)) digits++; else if (*s == '.') { if (period) return NULL; period++; } else break; } if (!digits) return NULL; if (*s == 'e' || *s == 'E') { s++; if (*s == '+' || *s == '-') s++; digits = 0; while (isdigit(*s)) digits++; if (!digits) return NULL; } return s; } Guido van Rossum 2000-08-10T18:51:00Z Shit. SF removes leading whitespace. Oh well, mail me for a properly formatted version of that code. Tim Peters 2000-08-11T04:57:00Z It's curious that in the change mail SF generated, leading indentation was *not* lost. This must be a browser display thing. Anyway, by eyeball the syntax checker has two bugs: 1. Infinite loop when looking at an exponent. x while (isdigit(*s)) digits++; should be x while (isdigit(*s)) {digits++; s++;) 2. Like atof, stops at an invalid character. Before the x return s; it should have, e.g., x while (ispace(*s)) ++s; x if (*s) return NULL; although I'm not sure what the assumptions are about the input to this function. Guido van Rossum 2000-08-27T18:38:00Z I'm mailing Tim a fixed version of floatsyntax(). Tim Peters 2000-08-30T07:39:00Z I'm afraid the code here is a freakin' mess. No wonder Guido assigned it to me <0.3 wink>. Turnabout is fair play, so I'm assigning it back to him (for Pronouncements, or at least to alert him what's going on here). I *think* you intended to change the guts of PyFloat_FromString. Which appears to be a so-far undocumented public API function, with a strtod-like prototype, and where nobody calls it with anything but NULL for the 2nd argument. Does the signature of this have to remain the same, or can I toss the 2nd argument? Or even define it to do something useful <wink>? Note that in the Unicode case, pend is set to point into stack trash! Python has its own strtod.c and atof.c files too. Are these really needed, or can I toss those as well? (They're not used on Windows, but I don't understand the layers of Unix config.) They're both ANSI std, so I don't think we should be supplying our own anymore (besides which, they suck numerically). Bad news: our strategy for fixing this bug relies on atof() behavior that's explicitly not defined by the std (if strtod sets errno on a given input, the result of atof on that same input is undefined). Let's assume from here on that we're just lucky. Note that complex_from_string (bltinmodule.c) does its own by-hand parsing, again calling strtod directly, so the bug here will just pop up there too. Ditto for load_float in cpickle.c (we can *write out* flost strings that strtod won't read back in -- in effect, that *is* this bug, in another guise). Ditto for strop_atof in stropmodule.c. If we *don't* assume we're lucky, there are about 6 calls to atof that are vulnerable too. Unfortunately, C did a bad job of defining float<->string facilities, and C's problems have propagated throughout Python (i.e., wherever atof or strtod are called). Note that atof/strtod both get much hairier in C99 (they sprout new ways to spell NaN and Inf, and support a new binary floating-point notation too). The Python code calling these guys now doesn't know anything about that, so it will again be a distributed mess to fix all the call sites. I suggest there should be exactly one routine in the entire source tree that converts strings to doubles, exactly one in the other direction too; and outside of the former, calls to atof and strtod should be strictly banned. C is a mess here, C99 is less of a mess but much more complex, and we can't afford to have the mess or the complexity spread throughout the codebase. Guido van Rossum 2000-09-07T00:18:00Z Back to Tim. - You can ignore strtod.c and atof.c; these aren't used *except* on platforms that don't have them in libc. (Are there any left? It used to be necessary for some, but that was almost 10 years ago.) - Let's not change existing APIs, even if they aren't documented. - Let's assume we're "lucky". - I agree with your proposed solution: one function each way. Go ahead! This is fine for 2.0b1. Tim Peters 2000-09-23T01:08:00Z Changed Resolution back to None since I'm working on it now. Tim Peters 2000-09-23T03:37:00Z I fixed the specific complaint (1e-309 is returned in both contexts now). Changed the summary line to remove the "Win32" bit, since it also occurred on some flavors of Unix. The grander schemes are, I think, hopeless before P3K and C99. For example: + The low-level details of floating-point syntax are locale-dependent, and up until now we've deferred to the platform on all such issues (including ways they may have to spell infinity and NaN). So we can't plug in any parser of our own that won't break *somebody's* code without a whale of a lot of work and community help. C99 is better-defined. + Safe ways to generate infs and NaNs are wildly platform-dependent now. C99 and P3K. Note that I didn't change the interface to PyFloat_FromString, but did declare that its 2nd (pend) argument is now officially useless (see the checkin comment for why). 2000-07-31T21:08:00Z sf210625 Jitterbug-Id: 260 Submitted-By: lipman@helix.nih.gov Date: Fri, 31 Mar 2000 18:03:56 -0500 (EST) Version: 1.5.2 OS: Solaris 7 106541-08 When I built Python on my machine: SunOS 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-5_10 Python's internal symbols (for instance PySequence_Length) were not included in the dynamic symbol table of the python executable. This prevented the Numerical-15.2 extensions from importing properly. My machine has both the Sun linker (in /usr/ccs/bin) and the GNU linker installed. I use the GNU linker, which is first in the $PATH under which Python was built. A workaround for this problem is to change the following line in Modules/Makefile.pre from LDFLAGS= to LDFLAGS= -export-dynamic This will only work for the GNU linker. ==================================================================== Audit trail: Mon May 22 17:39:59 2000 guido changed notes Mon May 22 17:39:59 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM platform-specific Jeremy Hylton build Bug Importer Bug Importer 2000-07-31T21:08:00Z Jitterbug-Id: 260 Submitted-By: lipman@helix.nih.gov Date: Fri, 31 Mar 2000 18:03:56 -0500 (EST) Version: 1.5.2 OS: Solaris 7 106541-08 When I built Python on my machine: SunOS 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-5_10 Python's internal symbols (for instance PySequence_Length) were not included in the dynamic symbol table of the python executable. This prevented the Numerical-15.2 extensions from importing properly. My machine has both the Sun linker (in /usr/ccs/bin) and the GNU linker installed. I use the GNU linker, which is first in the $PATH under which Python was built. A workaround for this problem is to change the following line in Modules/Makefile.pre from LDFLAGS= to LDFLAGS= -export-dynamic This will only work for the GNU linker. ==================================================================== Audit trail: Mon May 22 17:39:59 2000 guido changed notes Mon May 22 17:39:59 2000 guido moved from incoming to open Thomas Wouters 2000-08-06T21:25:00Z This might be fixed by newer autoconf ? A.M. Kuchling 2000-08-30T12:39:00Z Reassigning to Jeremy, since I lack the time. Martin von Löwis 2000-09-05T20:41:00Z I believe this is fixed in Python 2. I had the same problem in 1.5.2, as GNU ld suddenly started printing its -V output to stderr instead of stdout. Then, $CC -Xlinker -V 2>/dev/null | grep BFD >/dev/null of 1.5.2 would not consider the linker as GNU ld. In 2.0, the line is $CC -Xlinker -V 2>&1 | grep BFD >/dev/null so stderr is grepped as well and the bug is fixed. Jeremy Hylton 2000-09-15T19:14:00Z I will believe Martin about this bug being fixed. 2000-07-31T21:08:00Z sf210626 Jitterbug-Id: 268 Submitted-By: Gregor Hoffleit <flight@hoffleit.de> Date: Mon, 3 Apr 2000 13:08:33 +0200 Version: None OS: None --lMM8JwqTlfDpEaS6 Content-Type: multipart/mixed; boundary="NMuMz9nt05w80d4+" --NMuMz9nt05w80d4+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable configure.in (as in Python 1.5.2 and 1.6a1) has a flaw: There's a library libnet (http://www.packetfactory.net/libnet) for portable packet creation that provides a function socket. configure.in mistakes this library for BeOS's libnet library, and erroneously adds a "-lnet" to LIBS when this libnet library is present at compilation time. AFAICS from the comments in the file, the check for socket in libnet is only reasonable on BeOS systems. The attached patch therefore only runs this check on BeOS* systems. Gregor =20 --NMuMz9nt05w80d4+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="configure.in.diff" Content-Transfer-Encoding: quoted-printable --- configure.in Mon Apr 3 13:07:18 2000 +++ configure.in.x Mon Apr 3 13:06:34 2000 @@ -541,20 +541,24 @@ AC_CHECK_LIB(dl, dlopen) # Dynamic linking for SunOS/Solaris and SYSV AC_CHECK_LIB(dld, shl_load) # Dynamic linking for HP-UX # Most SVR4 platforms (e.g. Solaris) need -lsocket and -lnsl. # However on SGI IRIX, these exist but are broken. # BeOS' sockets are stashed in libnet. case "$ac_sys_system" in IRIX*) ;; *) AC_CHECK_LIB(nsl, t_open, [LIBS=3D"-lnsl $LIBS"]) # SVR4 AC_CHECK_LIB(socket, socket, [LIBS=3D"-lsocket $LIBS"], [], $LIBS) # SVR4 = sockets +;; +esac +case "$ac_sys_system" in +BeOS*) AC_CHECK_LIB(net, socket, [LIBS=3D"-lnet $LIBS"], [], $LIBS) # BeOS ;; esac =20 AC_MSG_CHECKING(for --with-libs) AC_ARG_WITH(libs, [--with-libs=3D'lib1 ...' link against additional lib= s], [ AC_MSG_RESULT($withval) LIBS=3D"$withval $LIBS" ], AC_MSG_RESULT(no)) =20 --NMuMz9nt05w80d4+-- --lMM8JwqTlfDpEaS6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE46Hux3eVfDf25G40RAYsAAKCgaXXvDYljeovae+JcS1c8Kn8waQCg2UvV 7cp6j9fWcJOxziFNjRCXWw8= =J41q -----END PGP SIGNATURE----- --lMM8JwqTlfDpEaS6-- ==================================================================== Audit trail: Mon May 22 17:43:39 2000 guido changed notes Tue Jul 11 08:29:14 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM platform-specific Thomas Wouters build Bug Importer Bug Importer 2000-07-31T21:08:00Z Jitterbug-Id: 268 Submitted-By: Gregor Hoffleit <flight@hoffleit.de> Date: Mon, 3 Apr 2000 13:08:33 +0200 Version: None OS: None --lMM8JwqTlfDpEaS6 Content-Type: multipart/mixed; boundary="NMuMz9nt05w80d4+" --NMuMz9nt05w80d4+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable configure.in (as in Python 1.5.2 and 1.6a1) has a flaw: There's a library libnet (http://www.packetfactory.net/libnet) for portable packet creation that provides a function socket. configure.in mistakes this library for BeOS's libnet library, and erroneously adds a "-lnet" to LIBS when this libnet library is present at compilation time. AFAICS from the comments in the file, the check for socket in libnet is only reasonable on BeOS systems. The attached patch therefore only runs this check on BeOS* systems. Gregor =20 --NMuMz9nt05w80d4+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="configure.in.diff" Content-Transfer-Encoding: quoted-printable --- configure.in Mon Apr 3 13:07:18 2000 +++ configure.in.x Mon Apr 3 13:06:34 2000 @@ -541,20 +541,24 @@ AC_CHECK_LIB(dl, dlopen) # Dynamic linking for SunOS/Solaris and SYSV AC_CHECK_LIB(dld, shl_load) # Dynamic linking for HP-UX # Most SVR4 platforms (e.g. Solaris) need -lsocket and -lnsl. # However on SGI IRIX, these exist but are broken. # BeOS' sockets are stashed in libnet. case "$ac_sys_system" in IRIX*) ;; *) AC_CHECK_LIB(nsl, t_open, [LIBS=3D"-lnsl $LIBS"]) # SVR4 AC_CHECK_LIB(socket, socket, [LIBS=3D"-lsocket $LIBS"], [], $LIBS) # SVR4 = sockets +;; +esac +case "$ac_sys_system" in +BeOS*) AC_CHECK_LIB(net, socket, [LIBS=3D"-lnet $LIBS"], [], $LIBS) # BeOS ;; esac =20 AC_MSG_CHECKING(for --with-libs) AC_ARG_WITH(libs, [--with-libs=3D'lib1 ...' link against additional lib= s], [ AC_MSG_RESULT($withval) LIBS=3D"$withval $LIBS" ], AC_MSG_RESULT(no)) =20 --NMuMz9nt05w80d4+-- --lMM8JwqTlfDpEaS6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE46Hux3eVfDf25G40RAYsAAKCgaXXvDYljeovae+JcS1c8Kn8waQCg2UvV 7cp6j9fWcJOxziFNjRCXWw8= =J41q -----END PGP SIGNATURE----- --lMM8JwqTlfDpEaS6-- ==================================================================== Audit trail: Mon May 22 17:43:39 2000 guido changed notes Tue Jul 11 08:29:14 2000 guido moved from incoming to open Thomas Wouters 2000-08-02T10:49:00Z This was fixed by patch #100720, which was submitted by Gregor himself. 2000-07-31T21:08:00Z sf210627 Jitterbug-Id: 277 Submitted-By: gellsmore@yahoo.com Date: Wed, 5 Apr 2000 17:00:09 -0400 (EDT) Version: Python CE 1.0b1 OS: Windows CE H/PC 3.01 pro Floating point answer objects not returned correctly >>>3.1 g All floats return g but will work in scenario below where floats form part of the expression but not the answer object >>>int(3.1/2) 1 this works. ==================================================================== Audit trail: Mon May 22 17:49:40 2000 guido changed notes Mon May 22 17:49:40 2000 guido moved from incoming to open Bug Importer REJECTED LOW x-3rd-party Mark Hammond windows Bug Importer Bug Importer 2000-07-31T21:08:00Z Jitterbug-Id: 277 Submitted-By: gellsmore@yahoo.com Date: Wed, 5 Apr 2000 17:00:09 -0400 (EDT) Version: Python CE 1.0b1 OS: Windows CE H/PC 3.01 pro Floating point answer objects not returned correctly >>>3.1 g All floats return g but will work in scenario below where floats form part of the expression but not the answer object >>>int(3.1/2) 1 this works. ==================================================================== Audit trail: Mon May 22 17:49:40 2000 guido changed notes Mon May 22 17:49:40 2000 guido moved from incoming to open Thomas Wouters 2000-08-03T12:50:00Z Hm, Python CE 1.0b1 ? I'm not sure if that's an old version of Python ported to the CE, or a recent version of Python ported to the CE with a new version number. In any case, I dont believe the CE port is being maintained by the core Python group, so I don't think we can do much about it. Jeremy Hylton 2000-09-07T22:02:00Z Please do triage on this bug. barry 2000-09-16T21:50:00Z This works fine for me on Linux w/ Python 2.0b1. I don't have Windows CE available to test if it's a platform bug. Tim Peters 2000-09-16T22:16:00Z Reassigned to Mark Hammond, as I believe he did the CE port. There's no problem here in the Python core, so nothing we can do about it. Mark Hammond 2000-09-16T22:34:00Z The CE port is not maintained by the core Python group - indeed, as far as I know, it is not being maintained by anyone. Marking as "Wont Fix", but I will forward the bug report to the python-ce mailing list. 2000-07-31T21:08:00Z sf210628 Jitterbug-Id: 278 Submitted-By: =?ISO-8859-1?Q?Fran=E7ois_Pinard?= <pinard@iro.umontreal.ca> Date: 06 Apr 2000 11:10:00 -0400 Version: None OS: None Hello. This might be seen as a limitation, rather than a bug. This is not specific to 1.6a1, as 1.5.2 shows the same. Executing a Python script yields: Traceback (most recent call last): File "./to-html", line 26, in ? import data, htmlpage, localweb, registry SyntaxError: non-keyword arg after keyword arg (line 26) There is such an error in file `../lib/htmlpage.py' here, so the diagnostic is proper. However, a mere `(line 26)' does not hint about which of the four imported sources has the error. As a way around the poor diagnostic, you might suggest that I avoid bundling many imports on one line. This would help of course, but I still think Python could do better, here. -- François Pinard http://www.iro.umontreal.ca/~pinard ==================================================================== Audit trail: Mon May 22 17:50:15 2000 guido changed notes Mon May 22 17:50:15 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM feature-request Fred Drake python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:08:00Z Jitterbug-Id: 278 Submitted-By: =?ISO-8859-1?Q?Fran=E7ois_Pinard?= <pinard@iro.umontreal.ca> Date: 06 Apr 2000 11:10:00 -0400 Version: None OS: None Hello. This might be seen as a limitation, rather than a bug. This is not specific to 1.6a1, as 1.5.2 shows the same. Executing a Python script yields: Traceback (most recent call last): File "./to-html", line 26, in ? import data, htmlpage, localweb, registry SyntaxError: non-keyword arg after keyword arg (line 26) There is such an error in file `../lib/htmlpage.py' here, so the diagnostic is proper. However, a mere `(line 26)' does not hint about which of the four imported sources has the error. As a way around the poor diagnostic, you might suggest that I avoid bundling many imports on one line. This would help of course, but I still think Python could do better, here. -- François Pinard http://www.iro.umontreal.ca/~pinard ==================================================================== Audit trail: Mon May 22 17:50:15 2000 guido changed notes Mon May 22 17:50:15 2000 guido moved from incoming to open Fred Drake 2000-08-15T15:53:00Z Changed SyntaxError generation and formatting to provide more information in the displayed message. The changes add the "filename" and "lineno" attributes to SyntaxError exceptions when those values are known. 2000-07-31T21:08:00Z sf210629 Jitterbug-Id: 28 Submitted-By: guido@python.org Date: Wed, 14 Jul 1999 14:00:14 -0400 (EDT) Version: 1.5.2b OS: Mark Lutz wrote me: (BTW, this will probably never surface again (I'm stressing the image object a bit), but I think there's a problem with using the id() of an image as its name. I ran into a situation where an image was drawn in the wrong place, because a newly allocated image object had the same id() as one very recently reclaimed. It's very obscure, will only happen if you have > 1 canvas in a process and happen to be creating and deleting images very quickly, and is too complex for me to describe further at the moment ;-). I worked around it by first generating image names from a simple counter, and then prebuilding all images up front.) ==================================================================== Audit trail: Wed Jul 14 14:00:28 1999 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM Martin von Löwis tkinter Bug Importer Bug Importer 2000-07-31T21:08:00Z Jitterbug-Id: 28 Submitted-By: guido@python.org Date: Wed, 14 Jul 1999 14:00:14 -0400 (EDT) Version: 1.5.2b OS: Mark Lutz wrote me: (BTW, this will probably never surface again (I'm stressing the image object a bit), but I think there's a problem with using the id() of an image as its name. I ran into a situation where an image was drawn in the wrong place, because a newly allocated image object had the same id() as one very recently reclaimed. It's very obscure, will only happen if you have > 1 canvas in a process and happen to be creating and deleting images very quickly, and is too complex for me to describe further at the moment ;-). I worked around it by first generating image names from a simple counter, and then prebuilding all images up front.) ==================================================================== Audit trail: Wed Jul 14 14:00:28 1999 guido moved from incoming to open Martin von Löwis 2000-09-05T21:00:00Z Fixed in patch 101424, http://sourceforge.net/patch/?func=detailpatch&patch_id=101424&group_id=5470 Fred Drake 2000-09-07T04:08:00Z Should be fixed by Martin's patch (#101424). I've accepted the patch and assigned it and this bug to Martin for checkin and closure. 2000-07-31T21:09:00Z sf210630 Jitterbug-Id: 281 Submitted-By: larsga@garshol.priv.no Date: Fri, 7 Apr 2000 03:38:55 -0400 (EDT) Version: 1.6a1 OS: Linux It seems that when doing 'a % b' where a is a normal string and b is a Unicode string, the result will be a normal string where b appears UTF-8-encoded. IMHO this is the Wrong Thing, since Unicode strings should always appear as Unicode unless the code explicitly requests something else. Also, this differs from the behaviour of the corresponding approach using +. The interpreter dialog below should explain. [larsga@lambda Python-1.6a1]$ ./python Python 1.6a1 (#1, Apr 7 2000, 09:29:32) [GCC 2.8.1] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> s1 = unichr(4312) >>> s1 u'\u10D8' >>> s2 = "This is a " >>> s3 = " text" >>> s2 + s1 + s3 u'This is a \u10D8 text' >>> "This is a %s text" % s1 'This is a \341\203\230 text' >>> u"This is a %s text" % s1 u'This is a \u10D8 text' >>> ==================================================================== Audit trail: Tue Jul 11 08:29:14 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM Thomas Wouters python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:09:00Z Jitterbug-Id: 281 Submitted-By: larsga@garshol.priv.no Date: Fri, 7 Apr 2000 03:38:55 -0400 (EDT) Version: 1.6a1 OS: Linux It seems that when doing 'a % b' where a is a normal string and b is a Unicode string, the result will be a normal string where b appears UTF-8-encoded. IMHO this is the Wrong Thing, since Unicode strings should always appear as Unicode unless the code explicitly requests something else. Also, this differs from the behaviour of the corresponding approach using +. The interpreter dialog below should explain. [larsga@lambda Python-1.6a1]$ ./python Python 1.6a1 (#1, Apr 7 2000, 09:29:32) [GCC 2.8.1] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> s1 = unichr(4312) >>> s1 u'\u10D8' >>> s2 = "This is a " >>> s3 = " text" >>> s2 + s1 + s3 u'This is a \u10D8 text' >>> "This is a %s text" % s1 'This is a \341\203\230 text' >>> u"This is a %s text" % s1 u'This is a \u10D8 text' >>> ==================================================================== Audit trail: Tue Jul 11 08:29:14 2000 guido moved from incoming to open Bug Importer 2000-07-31T21:09:00Z From: "M.-A. Lemburg" <mal@lemburg.com> Subject: Re: [Python-bugs-list] Unicode and % operator (PR#281) Date: Fri, 07 Apr 2000 12:05:50 +0200 larsga@garshol.priv.no wrote: > > Full_Name: Lars Marius Garshol > Version: 1.6a1 > OS: Linux > Submission from: epsilon.opera.no (195.0.254.101) > > It seems that when doing 'a % b' where a is a normal string and b is a > Unicode string, the result will be a normal string where b appears > UTF-8-encoded. IMHO this is the Wrong Thing, since Unicode strings should > always appear as Unicode unless the code explicitly requests something > else. > > Also, this differs from the behaviour of the corresponding approach using > +. > > The interpreter dialog below should explain. > > [larsga@lambda Python-1.6a1]$ ./python > Python 1.6a1 (#1, Apr 7 2000, 09:29:32) [GCC 2.8.1] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> s1 = unichr(4312) > >>> s1 > u'\u10D8' > >>> s2 = "This is a " > >>> s3 = " text" > >>> s2 + s1 + s3 > u'This is a \u10D8 text' > >>> "This is a %s text" % s1 > 'This is a \341\203\230 text' > >>> u"This is a %s text" % s1 > u'This is a \u10D8 text' > >>> Thanks for noticing this one... it will be fixed in the next alpha round. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ Thomas Wouters 2000-08-02T10:54:00Z This seems to be fixed, like MAL promised. (I'm not sure if I'm happy with % on an 8-bit string returning a unicode string, but I don't do anything with unicode, period ;) 2000-07-31T21:09:00Z sf210631 Jitterbug-Id: 283 Submitted-By: musingattheruins@yahoo.com Date: Mon, 10 Apr 2000 12:30:44 -0400 (EDT) Version: 1.5.2 OS: Win32 The python debugger (both Idle and PythonWin) does not undertand packages. Can run scripts from the command line that cannot be run in the debugger... Create package 'Test' in the directory "My Modules", add an __init__.py (empty) to the directory "My modules\Test", create file testfile.py with the contents... class TheTest: def __init__(self): self.i = 1 def go(self): return self.i Add the path to the Python path with the following file (test.reg)... REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\1.5\PythonPath\TheTest] @="C:\\My modules" then try the following at the python prompt: import Test.testfile j = Test.testfile.TheTest() k = j.go runs fine right? Yes it does, now step through it in the debugger and you get... import Test.testfile j = Test.testfile.TheTest() #exception: attribute 'TheTest' k = j.go Does not appear to be realted to the class (you can change it to a 'function in a module' instead of a 'method in a class in a module' and you get the a similar result.) Debugger does not understand packages. ==================================================================== Audit trail: Tue Jul 11 08:29:15 2000 guido moved from incoming to open Bug Importer FIXRELEASED LOW feature-request python-library Bug Importer Bug Importer 2000-07-31T21:09:00Z Jitterbug-Id: 283 Submitted-By: musingattheruins@yahoo.com Date: Mon, 10 Apr 2000 12:30:44 -0400 (EDT) Version: 1.5.2 OS: Win32 The python debugger (both Idle and PythonWin) does not undertand packages. Can run scripts from the command line that cannot be run in the debugger... Create package 'Test' in the directory "My Modules", add an __init__.py (empty) to the directory "My modules\Test", create file testfile.py with the contents... class TheTest: def __init__(self): self.i = 1 def go(self): return self.i Add the path to the Python path with the following file (test.reg)... REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\1.5\PythonPath\TheTest] @="C:\\My modules" then try the following at the python prompt: import Test.testfile j = Test.testfile.TheTest() k = j.go runs fine right? Yes it does, now step through it in the debugger and you get... import Test.testfile j = Test.testfile.TheTest() #exception: attribute 'TheTest' k = j.go Does not appear to be realted to the class (you can change it to a 'function in a module' instead of a 'method in a class in a module' and you get the a similar result.) Debugger does not understand packages. ==================================================================== Audit trail: Tue Jul 11 08:29:15 2000 guido moved from incoming to open Guido van Rossum 2000-12-12T20:49:00Z I've added this feature request to PEP 42. 2000-07-31T21:09:00Z sf210632 Jitterbug-Id: 284 Submitted-By: kessler@ccdc.cam.ac.uk Date: Mon, 10 Apr 2000 13:32:30 -0400 (EDT) Version: 1.6a (10.04.2000) OS: Irix 6.3 In the current CVS tree, the files _sre.c, sre.h, and sre_constants.h contain CR/LF windows-style line endings, which the MipsPro 7.2.1 compiler does not accept. ==================================================================== Audit trail: Tue Jul 11 08:29:15 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM Bug Importer Bug Importer 2000-07-31T21:09:00Z Jitterbug-Id: 284 Submitted-By: kessler@ccdc.cam.ac.uk Date: Mon, 10 Apr 2000 13:32:30 -0400 (EDT) Version: 1.6a (10.04.2000) OS: Irix 6.3 In the current CVS tree, the files _sre.c, sre.h, and sre_constants.h contain CR/LF windows-style line endings, which the MipsPro 7.2.1 compiler does not accept. ==================================================================== Audit trail: Tue Jul 11 08:29:15 2000 guido moved from incoming to open Bug Importer 2000-07-31T21:09:00Z From: Guido van Rossum <guido@python.org> Subject: Re: [Python-bugs-list] CR/LF line endings in _sre.c sre.h sre_constants.h (PR#284) Date: Mon, 10 Apr 2000 13:36:37 -0400 > In the current CVS tree, the files _sre.c, sre.h, and > sre_constants.h contain CR/LF windows-style line endings, which the > MipsPro 7.2.1 compiler does not accept. Try again. I just checked in new versions which fix this, about 5 minutes ago! --Guido van Rossum (home page: http://www.python.org/~guido/) Thomas Wouters 2000-08-02T10:58:00Z Already fixed. 2000-07-31T21:09:00Z sf210633 Jitterbug-Id: 286 Submitted-By: alex@shop.com Date: Mon, 10 Apr 2000 16:40:57 -0400 (EDT) Version: >=1.5 OS: win32 linux urlparse requires that the url contain a "/" so that urlparse("http://foo.com?q=a#blah") results in ("http","foo.com?q=a#blah",....) urlparse should not require slashes in urls that have fragments or query strings. ==================================================================== Audit trail: Tue Jul 11 08:29:15 2000 guido moved from incoming to open Bug Importer REJECTED MEDIUM not-a-bug Fred Drake python-library Bug Importer Bug Importer 2000-07-31T21:09:00Z Jitterbug-Id: 286 Submitted-By: alex@shop.com Date: Mon, 10 Apr 2000 16:40:57 -0400 (EDT) Version: >=1.5 OS: win32 linux urlparse requires that the url contain a "/" so that urlparse("http://foo.com?q=a#blah") results in ("http","foo.com?q=a#blah",....) urlparse should not require slashes in urls that have fragments or query strings. ==================================================================== Audit trail: Tue Jul 11 08:29:15 2000 guido moved from incoming to open Fred Drake 2000-08-17T01:54:00Z Assigned to me so I can deal with urlparse all at once. Fred Drake 2000-08-24T15:07:00Z RFC 1738, section 3.3, discusses the syntax for HTTP URLs. It implies that the "/" between the is required if either the path of searchpart of the URL is provided, but is not completely clear. I don't see anything relevant in RFC 1945 (HTTP 1.0), but RFC 2616 (HTTP 1.1), section 3.2.2 clearly indicates that the search part should only exist as a part of the path component, which is required to include the leading "/". There is some confusion as to how this should relate to parsing of relative URLs (RFC 1808). This bug can be re-opened if there's evidence urlparse is actually wrong or inconsistent with other URL parsers. Aaronsw 2001-11-27T00:44:00Z RFC2396, not RFC1738 is the latest RFC for URI/URL defintions. Walter Dörwald 2002-02-14T18:23:00Z RFC2396 Section 3.2 states that: """The authority component is preceded by a double slash "//" and is terminated by the next slash "/", question-mark "?", or by the end of the URI.""" So IMHO this would mean that "http://foo.com?q=a#blah" should be parsed by urlsplit as ('http', 'foo.com', '', 'q=a', 'blah') (or maybe ('http', 'foo.com', '/', 'q=a', 'blah')) 2000-07-31T21:09:00Z sf210634 Jitterbug-Id: 287 Submitted-By: kessler@ccdc.cam.ac.uk Date: Tue, 11 Apr 2000 06:32:40 -0400 (EDT) Version: 1.6a (10.04.2000) OS: Irix 6.3 In the current CVS tree, the files _sre.c, sre.h, and sre_constants.h contain CR/LF windows-style line endings, which the MipsPro 7.2.1 compiler does not accept. ==================================================================== Audit trail: Tue Jul 11 08:29:16 2000 guido moved from incoming to open Bug Importer REJECTED MEDIUM Bug Importer Bug Importer 2000-07-31T21:09:00Z Jitterbug-Id: 287 Submitted-By: kessler@ccdc.cam.ac.uk Date: Tue, 11 Apr 2000 06:32:40 -0400 (EDT) Version: 1.6a (10.04.2000) OS: Irix 6.3 In the current CVS tree, the files _sre.c, sre.h, and sre_constants.h contain CR/LF windows-style line endings, which the MipsPro 7.2.1 compiler does not accept. ==================================================================== Audit trail: Tue Jul 11 08:29:16 2000 guido moved from incoming to open Thomas Wouters 2000-08-02T10:59:00Z <empty comment> 2000-07-31T21:09:00Z sf210635 Jitterbug-Id: 288 Submitted-By: kessler@ccdc.cam.ac.uk Date: Tue, 11 Apr 2000 06:58:39 -0400 (EDT) Version: 1.6a2 OS: Irix6.3 Under Irix6.3 (python compiled in -n32 mode with MipsPro 7.2.1), test_signal works fine (?) if you run it on its own: >>> import test.test_signal starting pause() loop... call pause()... + kill -5 7487 + sleep 2 handlerA (5, <frame object at 100cf928>) pause() returned call pause()... + kill -2 7487 + sleep 2 handlerB (2, <frame object at 100cf928>) HandlerBCalled exception caught call pause()... + kill -3 7487 KeyboardInterrupt (assume the alarm() went off) however, as part of the test suite, this test hangs: >>> import test.testall [...] test_signal test_signal + sleep 2 starting pause() loop... call pause()... + kill -5 7454 + sleep 2 + kill -2 7454 + sleep 2 + kill -3 7454 ==================================================================== Audit trail: Tue Jul 11 08:29:16 2000 guido moved from incoming to open Bug Importer FIXRELEASED LOW platform-specific Guido van Rossum python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:09:00Z Jitterbug-Id: 288 Submitted-By: kessler@ccdc.cam.ac.uk Date: Tue, 11 Apr 2000 06:58:39 -0400 (EDT) Version: 1.6a2 OS: Irix6.3 Under Irix6.3 (python compiled in -n32 mode with MipsPro 7.2.1), test_signal works fine (?) if you run it on its own: >>> import test.test_signal starting pause() loop... call pause()... + kill -5 7487 + sleep 2 handlerA (5, <frame object at 100cf928>) pause() returned call pause()... + kill -2 7487 + sleep 2 handlerB (2, <frame object at 100cf928>) HandlerBCalled exception caught call pause()... + kill -3 7487 KeyboardInterrupt (assume the alarm() went off) however, as part of the test suite, this test hangs: >>> import test.testall [...] test_signal test_signal + sleep 2 starting pause() loop... call pause()... + kill -5 7454 + sleep 2 + kill -2 7454 + sleep 2 + kill -3 7454 ==================================================================== Audit trail: Tue Jul 11 08:29:16 2000 guido moved from incoming to open Bug Importer 2000-07-31T21:09:00Z From: Guido van Rossum <guido@python.org> Subject: Re: [Python-bugs-list] test_signal hangs when running as part of testall (PR#288) Date: Tue, 11 Apr 2000 11:27:20 -0400 > Under Irix6.3 (python compiled in -n32 mode with MipsPro 7.2.1), test_signal > works fine (?) if you run it on its own: > > >>> import test.test_signal > starting pause() loop... > call pause()... > + kill -5 7487 > + sleep 2 > handlerA (5, <frame object at 100cf928>) > pause() returned > call pause()... > + kill -2 7487 > + sleep 2 > handlerB (2, <frame object at 100cf928>) > HandlerBCalled exception caught > call pause()... > + kill -3 7487 > KeyboardInterrupt (assume the alarm() went off) > > however, as part of the test suite, this test hangs: > > >>> import test.testall > [...] > test_signal > test_signal > + sleep 2 > starting pause() loop... > call pause()... > + kill -5 7454 > + sleep 2 > + kill -2 7454 > + sleep 2 > + kill -3 7454 Yes, I've seen this too. Unfortunately, I don't have a clue, and I don't have the time to delve into it... I bet there's a compile time #define that might do it. It may have something to do with threads... --Guido van Rossum (home page: http://www.python.org/~guido/) Thomas Wouters 2000-08-02T11:05:00Z Unsure if this is still an actual problem, but I've seen similar behaviour of test_signal on BSDI 4.0 and 4.0.1 systems, when Python was compiled with threads. The problem appeared to be the BSDI thread library, which had (among other things) problems with pause() in threaded code. I haven't tried to enable threading on 4.0.x for a while, since new systems are 4.1, and 4.1 works properly with threads. Does disabling threads fix the problem ? (Or perhaps *en*abling them, if they weren't ?) Jeremy Hylton 2000-09-07T22:01:00Z Please do triage on this bug. Jeremy Hylton 2000-09-07T22:02:00Z Please do triage on this bug. Jeremy Hylton 2000-09-19T01:35:00Z I've got no hope of fixing an IRIX bug. At least you've used IRIX <0.2 wink> Guido van Rossum 2000-09-19T01:51:00Z I've got no hope either. I'll write the submittor. I've lowered the priority to 1 -- meaning I won't lose sleep over this. Guido van Rossum 2000-09-19T12:45:00Z Original submittor lost access to SGI hardware. Closing since there's not much we can do about this. 2000-07-31T21:09:00Z sf210636 Jitterbug-Id: 293 Submitted-By: kajiyama@grad.sccs.chukyo-u.ac.jp Date: Wed, 12 Apr 2000 15:14:10 -0400 (EDT) Version: 1.6a2 OS: Plamo Linux 1.3 (Repost: excuse me for annoyance) The installation procedure ("make install") fails if the prefix directory specified with configure's --prefix option does not exist. Manually making the prefix directory is sufficient, but automatic creation may be more preferable. ==================================================================== Audit trail: Tue Jul 11 08:29:17 2000 guido moved from incoming to open Bug Importer REJECTED LOW Guido van Rossum build Bug Importer Bug Importer 2000-07-31T21:09:00Z Jitterbug-Id: 293 Submitted-By: kajiyama@grad.sccs.chukyo-u.ac.jp Date: Wed, 12 Apr 2000 15:14:10 -0400 (EDT) Version: 1.6a2 OS: Plamo Linux 1.3 (Repost: excuse me for annoyance) The installation procedure ("make install") fails if the prefix directory specified with configure's --prefix option does not exist. Manually making the prefix directory is sufficient, but automatic creation may be more preferable. ==================================================================== Audit trail: Tue Jul 11 08:29:17 2000 guido moved from incoming to open Thomas Wouters 2000-08-03T15:38:00Z Yup, this is a problem. This could be fixed by using mkdir's '-p' flag, in the Makefile. However, I'm not entirely sure how portable the -p flag is. The other solution, manually checking each parent directory and creating them when necessary, is a lot more work. Guido van Rossum 2000-08-03T19:04:00Z This intentional. The reason is that "make install" is often done as root. If you make a typo and accidentally specify an erroneous prefix, it would silently create that for you! In nurmal use, prefix is /usr or /usr/local so it should always exist. 2000-07-31T21:09:00Z sf210637 Jitterbug-Id: 294 Submitted-By: mak@mikroplan.com.pl Date: Thu, 13 Apr 2000 04:09:35 -0400 (EDT) Version: cvs OS: windows Hi, Python module ihooks is not so compatible with builtin imp while importing modules whose name is stored in registry eg. pythoncom/pywintypes. import ihooks ihooks.install() import pythoncom This code will fail inside pythonwin ide too ! ==================================================================== Audit trail: Tue Jul 11 08:29:17 2000 guido moved from incoming to open Bug Importer REJECTED MEDIUM platform-specific Mark Hammond windows Bug Importer Bug Importer 2000-07-31T21:09:00Z Jitterbug-Id: 294 Submitted-By: mak@mikroplan.com.pl Date: Thu, 13 Apr 2000 04:09:35 -0400 (EDT) Version: cvs OS: windows Hi, Python module ihooks is not so compatible with builtin imp while importing modules whose name is stored in registry eg. pythoncom/pywintypes. import ihooks ihooks.install() import pythoncom This code will fail inside pythonwin ide too ! ==================================================================== Audit trail: Tue Jul 11 08:29:17 2000 guido moved from incoming to open Mark Hammond 2000-08-14T06:42:00Z This needs a resolution. The "registered module" code in the code also needs to support HKEY_CURRENT_USER along with the HKEY_LOCAL_MACHINE it does now. Mark Hammond 2000-08-31T06:23:00Z Leaving open, but moving down the priority and resolution lists. A patch would help bump it back up :-) Mpmak 2001-03-02T12:27:00Z BasicModuleLoader.find_module_in_dir is searching for main modules only in frozen and builtin. The imp searches the registry, too. ModuleLoader.find_module_in_dir should call the functions from the inherited object. so this patch should help: --- V:\py21\Lib\ihooks.py Mon Feb 12 08:55:46 2001 +++ ihooks.py Sun Feb 18 04:39:39 2001 @@ -122,8 +122,13 @@ def find_module_in_dir(self, name, dir): if dir is None: - return self.find_builtin_module(name) - else: + result = self.find_builtin_module(name) + if result is not None: + return result + try: + return imp.find_module(name, None) + except: + return None try: return imp.find_module(name, [dir]) except ImportError: @@ -237,7 +242,7 @@ def find_module_in_dir(self, name, dir, allow_packages=1): if dir is None: - return self.find_builtin_module(name) + return BasicModuleLoader.find_module_in_dir (self,name,dir) if allow_packages: fullname = self.hooks.path_join(dir, name) if self.hooks.path_isdir(fullname): Bug Importer 2001-09-19T17:23:00Z ruoy retupmoc si daed Bug Importer 2001-11-15T23:19:00Z ¾È³çÇϼ¼¿ä ÀÌÁ¦ºÎÅÍ Á¦ ¼Ò°³¸¦ ÇÏ°Ú½À´Ï´Ù ÀúÀÇ À̸§Àº ¹ÚÇýÁØ ÀÌ°í¿ä ³ªÀÌ´Â 13»ìÀÌ¿¡¿ä ±×¸®°í °¡Á·Àº ¸ðµÎ 4¸í ¾ö¸¶ ¾Æºü ´©³ª ³ª Á¦°¡ »ç´Â °÷Àº ºÐ´ç±¸ ¾ßžµ¿ ¸ÅÈ­¸¶À» 105-1006 Á¦ ÀüÈ­¹øÈ£´Â¿© 031-704-9838 Àú´Â Çѱ¹ÀÎ ÀÔ´Ï´Ù. Bug Importer 2002-02-12T15:13:00Z i try it first,ok Jeremy Hylton 2002-03-01T22:29:00Z Mark, Any interest in looking at this bug? It holds the record for the oldest Python bug at SF. Bug Importer 2002-06-13T11:51:00Z yes i found that your new modele is the shit Mark Hammond 2002-07-11T07:04:00Z Really dont know how to fix this and it is not clear the patch is acceptable just for pythoncom. Not clear that anyone even really cares about ihooks as no one else has complained about this but i am willing to look at it again if anyone even notices :) 2000-07-31T21:09:00Z sf210638 Jitterbug-Id: 295 Submitted-By: niels@endea.demon.nl Date: Thu, 13 Apr 2000 14:16:25 -0400 (EDT) Version: 1.5.2 and 1.6.a2 OS: Win95 and Linux Hi, I ran into a bug while running a regrtest on 1.6a2 with debugging on. This produced a reference checking problem, which I now see is the same as reported in #113. I have tracked this down to the use of PyMem_DEL on an object created by PyObject_NEW in PyPcre_compile. When the compile fails, the new object is deallocated, but not removed from the reference chain. This also happens in 1.5.2. With a little grepping, I tracked down a few instances of this problem: pcremodule.c:PyPcre_compile unicodeobject.c:_PyUnicode_New socketmodule.c:newSSLObject threadmodule.c:newlockobject In each case a partially constructed, but already registered object is simply deleted without calling _Py_ForgetReference. ==================================================================== Audit trail: Tue Jul 11 08:29:17 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM A.M. Kuchling python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:09:00Z Jitterbug-Id: 295 Submitted-By: niels@endea.demon.nl Date: Thu, 13 Apr 2000 14:16:25 -0400 (EDT) Version: 1.5.2 and 1.6.a2 OS: Win95 and Linux Hi, I ran into a bug while running a regrtest on 1.6a2 with debugging on. This produced a reference checking problem, which I now see is the same as reported in #113. I have tracked this down to the use of PyMem_DEL on an object created by PyObject_NEW in PyPcre_compile. When the compile fails, the new object is deallocated, but not removed from the reference chain. This also happens in 1.5.2. With a little grepping, I tracked down a few instances of this problem: pcremodule.c:PyPcre_compile unicodeobject.c:_PyUnicode_New socketmodule.c:newSSLObject threadmodule.c:newlockobject In each case a partially constructed, but already registered object is simply deleted without calling _Py_ForgetReference. ==================================================================== Audit trail: Tue Jul 11 08:29:17 2000 guido moved from incoming to open A.M. Kuchling 2000-08-17T00:25:00Z Fixed in revision 2.16 of Modules/pypcre.c . The other reported bugs also seem to be fixed in the CVS tree at this time. Thanks for your bug report! 2000-07-31T21:09:00Z sf210639 Jitterbug-Id: 296 Submitted-By: oli@andrich.net Date: Thu, 13 Apr 2000 15:18:07 -0400 (EDT) Version: 1.6a2 OS: Linux Mandrake 2.2.14-mdksmp Hi, I am currently evaluating Python 1.6 on my machine in order to be uptodate with the Linux distribution as soon as 1.6 final is released. The testsuite runs fine, just one test fails completely. test_fork1 When I run the test, it sometimes runs really fine (very seldom). Most of the time it hangs and uses nearly 100% of CPU time. The loop in the child prozess is completed successfully. n is 0 as it ought to be. But the os.waitpid call hangs for an indefinete time. This is strange, cause I can't reproduce this in an equivalent c code snippet. And without creation of the threads it works really fine and doesn't hang at all. Any idea? I am running a 2.2.14 Linux on a SMP machine (non SMP machine show the same behaviour). glibc 2.1.3. Bye, Oliver ==================================================================== Audit trail: Thu Apr 13 15:55:33 2000 fdrake sent reply 1 Thu Apr 13 15:55:45 2000 fdrake moved from incoming to open Bug Importer REJECTED HIGH x-3rd-party Fred Drake python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:09:00Z Jitterbug-Id: 296 Submitted-By: oli@andrich.net Date: Thu, 13 Apr 2000 15:18:07 -0400 (EDT) Version: 1.6a2 OS: Linux Mandrake 2.2.14-mdksmp Hi, I am currently evaluating Python 1.6 on my machine in order to be uptodate with the Linux distribution as soon as 1.6 final is released. The testsuite runs fine, just one test fails completely. test_fork1 When I run the test, it sometimes runs really fine (very seldom). Most of the time it hangs and uses nearly 100% of CPU time. The loop in the child prozess is completed successfully. n is 0 as it ought to be. But the os.waitpid call hangs for an indefinete time. This is strange, cause I can't reproduce this in an equivalent c code snippet. And without creation of the threads it works really fine and doesn't hang at all. Any idea? I am running a 2.2.14 Linux on a SMP machine (non SMP machine show the same behaviour). glibc 2.1.3. Bye, Oliver ==================================================================== Audit trail: Thu Apr 13 15:55:33 2000 fdrake sent reply 1 Thu Apr 13 15:55:45 2000 fdrake moved from incoming to open Bug Importer 2000-07-31T21:09:00Z From: Oliver Andrich <oli@rz-online.net> Subject: Re: test_fork1 hangs with 1.6a2 on Linux (PR#296) Date: Thu, 13 Apr 2000 23:38:08 +0200 Hi, I just checked the following to things. I patched the threading to work with GNU pth and get the same results. When I run the test script with Python 1.5.2 on the same machine, that means same glibc and so on, it works fine. I compared the threading code of Python 1.5.2 and 1.6.a2 and it doesn't seem to differ at all. Same for the posixcode as far it is relevant for the test. I am a little bit irritated by this. Best regards, Oliver On Thu, Apr 13, 2000 at 03:55:34PM -0400, Fred@python.org wrote: > Oliver, > We're aware of it, but haven't figured out the exact problem yet. If you can > provide additional information on the observed behavior, that would be good. I > get three different behaviors on a Mandrake 7.1 SMP machine: works, segfaults, > and blocks. I'm suspecting a pthread implementation problem, but haven't had > enough time to really dig into it sufficiently to be sure. > > > -Fred Bug Importer 2000-07-31T21:09:00Z From: Oliver Andrich <oli@rz-online.net> Subject: Re: test_fork1 hangs with 1.6a2 on Linux (PR#296) Date: Thu, 13 Apr 2000 22:26:08 +0200 Hi, well what I have discovered so far is. - Normal optimizations for Mandrake packages results in a sure segfault. - Normal python optimizations (jst calling make) causes hangs sometimes works. A look at ps ax shows, that there exist 6 active python "processes" (the parent process and 5 threads) and one defunct python process (the child). So thet child terminates correctly as I already mentioned. But the os.waitpid doesn't discover that the child has already exited. Things I will to tonight: - write a complete cversion of the testcode - compile python against another thread library - compile python against the most recent glibc snapshot - compile python on a RedHat 6.1 system Hopefully I get some more insights. Sadly, I am not good at c debugging, as I am a Python code by choice and a C coder who has written his last C code five years ago (a really program not just a Python extension ;-). Best regards, Oliver On Thu, Apr 13, 2000 at 03:55:34PM -0400, Fred@python.org wrote: > Oliver, > We're aware of it, but haven't figured out the exact problem yet. If you can > provide additional information on the observed behavior, that would be good. I > get three different behaviors on a Mandrake 7.1 SMP machine: works, segfaults, > and blocks. I'm suspecting a pthread implementation problem, but haven't had > enough time to really dig into it sufficiently to be sure. > > > -Fred Bug Importer 2000-07-31T21:09:00Z From: Fred L. Drake, Jr. <bugs-py@python.org> Subject: Re: test_fork1 hangs with 1.6a2 on Linux (PR#296) Date: Thu Apr 13 15:55:33 2000 Oliver, We're aware of it, but haven't figured out the exact problem yet. If you can provide additional information on the observed behavior, that would be good. I get three different behaviors on a Mandrake 7.1 SMP machine: works, segfaults, and blocks. I'm suspecting a pthread implementation problem, but haven't had enough time to really dig into it sufficiently to be sure. -Fred Fred Drake 2000-08-11T13:49:00Z I do not currently have ready access to an SMP machine, so I can't tell if this is fixed or not. I cannot reproduce this using a uniprocessor running Mandrake 7.1 (kernel 2.2.15-4mdk). This bug may also be related to the use of the GNU Pth pthreads implementation; we should find out which threading library was being used. Fred Drake 2000-08-14T13:50:00Z This does not appear to be a problem in the currrent code base, and may be an artefact of using the GNU Pth thread library; I cannot reproduce this on either a single or dual processor machine. If you can still get this behavior from the CVS version of Python, please ask us to reopen this bug. 2000-07-31T21:09:00Z sf210640 Jitterbug-Id: 306 Submitted-By: mark.favas@per.dem.csiro.au Date: Mon, 24 Apr 2000 19:26:25 -0400 (EDT) Version: 1.6a2 CVS of 25 April OS: DEC Alpha, Tru64 Unix 4.0F There seems to be issues (and perhaps lurking cans of worms) on 64-bit platforms where sizeof(long) != sizeof(int). For example, the CVS version of 1.6a2 of 25 April fails the UserString regression test. The tests fail as follows (verbose set to 1): abcabcabc.count(('abc',)) no 'abcabcabc' <method UserString.count of UserString instance at 140217e40> 3 <> 2 abcabcabc.count(('abc', 1)) no 'abcabcabc' <method UserString.count of UserString instance at 140216580> 2 <> 1 abcdefghiabc.find(('abc', 1)) no 'abcdefghiabc' <method UserString.find of UserString instance at 140216730> 9 <> -1 abcdefghiabc.rfind(('abc',)) no 'abcdefghiabc' <method UserString.rfind of UserString instance at 140216580> 9 <> 0 abcabcabc.rindex(('abc',)) no 'abcabcabc' <method UserString.rindex of UserString instance at 140216dc0> 6 <> 3 abcabcabc.rindex(('abc', 1)) no 'abcabcabc' <method UserString.rindex of UserString instance at 140216730> 6 <> 3 These tests are failing because the calls from the UserString methods to the underlying string methods are setting the default value of the end-of-string parameter to sys.maxint, which is defined as LONG_MAX (9223372036854775807), whereas the string methods in stringobject.c are using ints and expecting them to be no larger than INT_MAX (2147483647). Thus the end-of-string parameter becomes -1 in the default case. The size of an int on my platform is 4, and the size of a long is 8, so the "natural size of a Python integer" should be 8, by my understanding. The obvious fix is to change stringobject.c to use longs, rather than ints, but the problem might be more widespread than that. INT_MAX is used in unicodeobject.c, pypcre.c, _sre.c, stropmodule.c, and ceval.c as well as stringobject.c. Some of these look as though LONG_MAX should have been used (variables compared to INT_MAX are longs, but I am not confident enough to submit patches for them... Mark ==================================================================== Audit trail: Mon May 22 17:22:20 2000 guido changed notes Mon May 22 17:22:20 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM platform-specific Trent Mick python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:09:00Z Jitterbug-Id: 306 Submitted-By: mark.favas@per.dem.csiro.au Date: Mon, 24 Apr 2000 19:26:25 -0400 (EDT) Version: 1.6a2 CVS of 25 April OS: DEC Alpha, Tru64 Unix 4.0F There seems to be issues (and perhaps lurking cans of worms) on 64-bit platforms where sizeof(long) != sizeof(int). For example, the CVS version of 1.6a2 of 25 April fails the UserString regression test. The tests fail as follows (verbose set to 1): abcabcabc.count(('abc',)) no 'abcabcabc' <method UserString.count of UserString instance at 140217e40> 3 <> 2 abcabcabc.count(('abc', 1)) no 'abcabcabc' <method UserString.count of UserString instance at 140216580> 2 <> 1 abcdefghiabc.find(('abc', 1)) no 'abcdefghiabc' <method UserString.find of UserString instance at 140216730> 9 <> -1 abcdefghiabc.rfind(('abc',)) no 'abcdefghiabc' <method UserString.rfind of UserString instance at 140216580> 9 <> 0 abcabcabc.rindex(('abc',)) no 'abcabcabc' <method UserString.rindex of UserString instance at 140216dc0> 6 <> 3 abcabcabc.rindex(('abc', 1)) no 'abcabcabc' <method UserString.rindex of UserString instance at 140216730> 6 <> 3 These tests are failing because the calls from the UserString methods to the underlying string methods are setting the default value of the end-of-string parameter to sys.maxint, which is defined as LONG_MAX (9223372036854775807), whereas the string methods in stringobject.c are using ints and expecting them to be no larger than INT_MAX (2147483647). Thus the end-of-string parameter becomes -1 in the default case. The size of an int on my platform is 4, and the size of a long is 8, so the "natural size of a Python integer" should be 8, by my understanding. The obvious fix is to change stringobject.c to use longs, rather than ints, but the problem might be more widespread than that. INT_MAX is used in unicodeobject.c, pypcre.c, _sre.c, stropmodule.c, and ceval.c as well as stringobject.c. Some of these look as though LONG_MAX should have been used (variables compared to INT_MAX are longs, but I am not confident enough to submit patches for them... Mark ==================================================================== Audit trail: Mon May 22 17:22:20 2000 guido changed notes Mon May 22 17:22:20 2000 guido moved from incoming to open Thomas Wouters 2000-08-02T11:07:00Z Most likely fixed by the 64-bit-platform fixes from Trent Mick and others. Mark, is this still a problem ? Trent Mick 2000-08-03T21:50:00Z This was fixed a while back.Relevant email threads: Guido raises Mark's bug report and MAL,Guido,Tim, and I discuss it: http://www.python.org/pipermail/python-dev/2000-April/010456.html http://www.python.org/pipermail/python-dev/2000-May/010514.html MAL's silent truncation proposed patch (Guido turned it down): http://www.python.org/pipermail/patches/2000-May/000588.html My proposed patch to correct the string slice-semantic functions to actually correctly accept and handle all integral values. http://www.python.org/pipermail/patches/2000-May/000608.html And my patches getting checked in for string- and unicode- object.c: http://www.python.org/pipermail/python-checkins/2000-May/005562.html http://www.python.org/pipermail/python-checkins/2000-May/005573.html Mark Favas (via private email), the bug submitter, verified through provate email that the bug seems to be fixed for him as well. 2000-07-31T21:09:00Z sf210641 Jitterbug-Id: 309 Submitted-By: skip@mojam.com Date: Fri, 28 Apr 2000 17:00:40 -0400 (EDT) Version: 1.5.2, 1.6a2 OS: Linux If you hit Ctrl-C while the Python interpreter is sitting at the ps2 prompt the interpreter exits instead of returning you to the top-level prompt. % python Python 1.5.2+ (#12, Feb 17 2000, 14:52:05) [GCC pgcc-2.91.66 19990314 (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> if 1: ... % PYTHONSTARTUP= ./python Python 1.6a2 (#7, Apr 24 2000, 23:02:54) [GCC pgcc-2.91.66 19990314 (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> if 1: ... When run under gdb's control, you can see what's happening: % gdb ./python 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-mandrake-linux"... (gdb) set env PYTHONSTARTUP "" (gdb) run Starting program: /home/beluga/skip/src/python/dist/src/./python Python 1.6a2 (#7, Apr 24 2000, 23:02:54) [GCC pgcc-2.91.66 19990314 (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> if 1: ... Program received signal SIGINT, Interrupt. 0x4013bf14 in __libc_read () from /lib/libc.so.6 (gdb) bt #0 0x4013bf14 in __libc_read () from /lib/libc.so.6 (gdb) c Continuing. File "<stdin>", line 2 ^ SyntaxError: invalid syntax >>> It appears that SIGINT isn't handled properly when awaiting console input in certain circumstances. If you can entice the program to continue, things work okay. I don't know interrupt handling from a hole in the ground or I'd investigate further. It is quite annoying, especially considering that Python's input history isn't continuous across sessions... Skip ==================================================================== Audit trail: Mon May 22 17:23:42 2000 guido changed notes Mon May 22 17:23:42 2000 guido moved from incoming to open Bug Importer REJECTED MEDIUM platform-specific Thomas Wouters extension-modules Bug Importer Bug Importer 2000-07-31T21:09:00Z Jitterbug-Id: 309 Submitted-By: skip@mojam.com Date: Fri, 28 Apr 2000 17:00:40 -0400 (EDT) Version: 1.5.2, 1.6a2 OS: Linux If you hit Ctrl-C while the Python interpreter is sitting at the ps2 prompt the interpreter exits instead of returning you to the top-level prompt. % python Python 1.5.2+ (#12, Feb 17 2000, 14:52:05) [GCC pgcc-2.91.66 19990314 (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> if 1: ... % PYTHONSTARTUP= ./python Python 1.6a2 (#7, Apr 24 2000, 23:02:54) [GCC pgcc-2.91.66 19990314 (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> if 1: ... When run under gdb's control, you can see what's happening: % gdb ./python 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-mandrake-linux"... (gdb) set env PYTHONSTARTUP "" (gdb) run Starting program: /home/beluga/skip/src/python/dist/src/./python Python 1.6a2 (#7, Apr 24 2000, 23:02:54) [GCC pgcc-2.91.66 19990314 (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> if 1: ... Program received signal SIGINT, Interrupt. 0x4013bf14 in __libc_read () from /lib/libc.so.6 (gdb) bt #0 0x4013bf14 in __libc_read () from /lib/libc.so.6 (gdb) c Continuing. File "<stdin>", line 2 ^ SyntaxError: invalid syntax >>> It appears that SIGINT isn't handled properly when awaiting console input in certain circumstances. If you can entice the program to continue, things work okay. I don't know interrupt handling from a hole in the ground or I'd investigate further. It is quite annoying, especially considering that Python's input history isn't continuous across sessions... Skip ==================================================================== Audit trail: Mon May 22 17:23:42 2000 guido changed notes Mon May 22 17:23:42 2000 guido moved from incoming to open Thomas Wouters 2000-07-31T21:40:00Z This seems to be platform specific: On Linux, up-to-date CVS compile, this is reproducible. On BSDI 4.1, however, with an almost-up-to-date CVS compile, ^C doesn't exit the interpreter. Thomas Wouters 2000-08-06T11:57:00Z Oh, and it's also definately readline-related. (without readline compiled in, the bug doesn't get triggered, in any case.) Thomas Wouters 2000-08-09T15:59:00Z I've been toying with this, and the problem *is* readline. Readline overrides a number of signal handlers, in order to do cleanup when exiting, and apparently does not restore them on exit :-S The signals readline 'overrides' the handlers of are: SIGINT SIGALRM SIGTSTP SIGTTOU SIGTTIN SIGTERM SIGWINCH Which means that the signal handlers for these signals *vanish* when using readline. Interactive mode uses readline, but scripts can themselves, too. I'm not sure why this isn't showing on BSDI, but it might have something to do with the BSD vs the SysV signal handling routines. I'm also not sure if it's possible to fix this problem; it might be a bug in readline, or it might be documented behaviour. But I wasn't able to find a reference to signal handling in the 2.2.1 readline info files. Guido van Rossum 2000-09-22T03:33:00Z I'm quite confident that this was fixed by my checkin (last Sunday) to deal with the mixing of signal() and sigaction(), which makes it a duplicate of bug #110611. I'm closing this for Thomas. 2000-07-31T21:09:00Z sf210642 Jitterbug-Id: 315 Submitted-By: tdickenson@geminidataloggers.com Date: Fri, 5 May 2000 05:50:37 -0400 (EDT) Version: 1.5.2 OS: Windows There is a problem with combining two different options to freeze. Those options are: 1. "-s service" indicating that the frozen program is a windows service. one effect of this is that the myscript.py file on the freeze command line should be available for import, not as __main__ 2. "-m" indicating that extra modules are to be included in the freeze. The relevant block of code is at line 335... # Add the main script as either __main__, or the actual module name. if python_entry_is_main: mf.run_script(scriptfile) else: if modargs: mf.import_hook(scriptfile) else: mf.load_file(scriptfile) For a service, the outer 'else' block is entered. If -m is not specified then the inner 'else' block is entered. mf.load_file assumes its parameter is a filename (to be imported from), an everything is happy. If -m is specified then the inner 'if' block is entered. mf.import_hook assumes its parameter is a module to imported. This fails because "myscript.py" is not a module name, and can not be imported. I think this block of code was naively copy/pasted from the block above it (where it correctly implements the -m option), and never tested with the -m option. This block (starting line 335) should be replaced with # Add the main script as either __main__, or the actual module name. if python_entry_is_main: mf.run_script(scriptfile) else: mf.load_file(scriptfile) I have tested this patch on windows, freezing service and non-service scripts, both with and without -m ==================================================================== Audit trail: Mon May 22 17:28:43 2000 guido changed notes Mon May 22 17:28:43 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM feature-request Mark Hammond demos-and-tools Bug Importer Bug Importer 2000-07-31T21:09:00Z Jitterbug-Id: 315 Submitted-By: tdickenson@geminidataloggers.com Date: Fri, 5 May 2000 05:50:37 -0400 (EDT) Version: 1.5.2 OS: Windows There is a problem with combining two different options to freeze. Those options are: 1. "-s service" indicating that the frozen program is a windows service. one effect of this is that the myscript.py file on the freeze command line should be available for import, not as __main__ 2. "-m" indicating that extra modules are to be included in the freeze. The relevant block of code is at line 335... # Add the main script as either __main__, or the actual module name. if python_entry_is_main: mf.run_script(scriptfile) else: if modargs: mf.import_hook(scriptfile) else: mf.load_file(scriptfile) For a service, the outer 'else' block is entered. If -m is not specified then the inner 'else' block is entered. mf.load_file assumes its parameter is a filename (to be imported from), an everything is happy. If -m is specified then the inner 'if' block is entered. mf.import_hook assumes its parameter is a module to imported. This fails because "myscript.py" is not a module name, and can not be imported. I think this block of code was naively copy/pasted from the block above it (where it correctly implements the -m option), and never tested with the -m option. This block (starting line 335) should be replaced with # Add the main script as either __main__, or the actual module name. if python_entry_is_main: mf.run_script(scriptfile) else: mf.load_file(scriptfile) I have tested this patch on windows, freezing service and non-service scripts, both with and without -m ==================================================================== Audit trail: Mon May 22 17:28:43 2000 guido changed notes Mon May 22 17:28:43 2000 guido moved from incoming to open Bug Importer 2000-07-31T21:10:00Z From: "Mark Hammond" <mhammond@skippinet.com.au> Subject: RE: [Python-bugs-list] freeze with "-s service" and "-m" (PR#315) Date: Fri, 5 May 2000 23:19:14 +1000 > I think this block of code was naively copy/pasted from the > block above it Quite likely! > This block (starting line 335) should be replaced with ... If you submit a patch to this effect (to the patches address), I would be happy to bless it (and given that the service code is mine, I guess that would be all that is needed...) Thanks, Mark. Mark Hammond 2000-08-15T01:40:00Z Fixed in Rev. 1.35 of freeze.py 2000-07-31T21:10:00Z sf210643 Jitterbug-Id: 32 Submitted-By: brainval@ehome.encis.es;brainstorm@vlc.servicom.es; Date: Mon, 19 Jul 1999 06:24:45 -0400 (EDT) Version: 1.5.2 OS: IRIX 6.5 - Make a file consisting of a simple commented paragraph like: """ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ..... aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa """ so that it occupies 20Mb more or less. Running python with this file crashes with the message: SystemError: com_addbyte: byte out of range We are having this kind of error when compiling big files. With other kind of strings the file can be of 1Mb more or less to make it crash. Your help will be very much appreciated. Thank you. ==================================================================== Audit trail: Tue Jul 20 12:38:43 1999 guido changed notes Tue Jul 20 12:38:43 1999 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM parser-compiler Bug Importer Bug Importer 2000-07-31T21:10:00Z Jitterbug-Id: 32 Submitted-By: brainval@ehome.encis.es;brainstorm@vlc.servicom.es; Date: Mon, 19 Jul 1999 06:24:45 -0400 (EDT) Version: 1.5.2 OS: IRIX 6.5 - Make a file consisting of a simple commented paragraph like: """ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ..... aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa """ so that it occupies 20Mb more or less. Running python with this file crashes with the message: SystemError: com_addbyte: byte out of range We are having this kind of error when compiling big files. With other kind of strings the file can be of 1Mb more or less to make it crash. Your help will be very much appreciated. Thank you. ==================================================================== Audit trail: Tue Jul 20 12:38:43 1999 guido changed notes Tue Jul 20 12:38:43 1999 guido moved from incoming to open Jeremy Hylton 2000-08-01T23:01:00Z Now raises SyntaxError 2000-07-31T21:10:00Z sf210644 Jitterbug-Id: 324 Submitted-By: Thomas.Malik@t-online.de Date: Wed, 10 May 2000 15:37:28 -0400 (EDT) Version: 1.5.2 OS: all there's a bug in PyLong_FromLongLong, resulting in truncation of negative 64 bit integers. PyLong_FromLongLong starts with: if( ival <= (LONG_LONG)LONG_MAX ) { return PyLong_FromLong( (long)ival ); } else if( ival <= (unsigned LONG_LONG)ULONG_MAX ) { return PyLong_FromUnsignedLong( (unsigned long)ival ); } else { .... Now, if ival is smaller than -LONG_MAX, it falls outside the long integer range (being a 64 bit negative integer), but gets handled by the first if-then-case in above code ('cause it is, of course, smaller than LONG_MAX). This results in truncation of the 64 bit negative integer to a more or less arbitrary 32 bit number. The way to fix it is to compare the absolute value of imax against LONG_MAX in the first condition. The second condition (ULONG_MAX) must, at least, check wether ival is positive. ==================================================================== Audit trail: Mon May 22 17:13:25 2000 guido changed notes Mon May 22 17:13:25 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM platform-specific Trent Mick python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:10:00Z Jitterbug-Id: 324 Submitted-By: Thomas.Malik@t-online.de Date: Wed, 10 May 2000 15:37:28 -0400 (EDT) Version: 1.5.2 OS: all there's a bug in PyLong_FromLongLong, resulting in truncation of negative 64 bit integers. PyLong_FromLongLong starts with: if( ival <= (LONG_LONG)LONG_MAX ) { return PyLong_FromLong( (long)ival ); } else if( ival <= (unsigned LONG_LONG)ULONG_MAX ) { return PyLong_FromUnsignedLong( (unsigned long)ival ); } else { .... Now, if ival is smaller than -LONG_MAX, it falls outside the long integer range (being a 64 bit negative integer), but gets handled by the first if-then-case in above code ('cause it is, of course, smaller than LONG_MAX). This results in truncation of the 64 bit negative integer to a more or less arbitrary 32 bit number. The way to fix it is to compare the absolute value of imax against LONG_MAX in the first condition. The second condition (ULONG_MAX) must, at least, check wether ival is positive. ==================================================================== Audit trail: Mon May 22 17:13:25 2000 guido changed notes Mon May 22 17:13:25 2000 guido moved from incoming to open Tim Peters 2000-08-23T18:20:00Z Reassigned from Trent to me -- Python had the same bug in its "regular int" code for years, and I fixed it there, so I should fix it here too. 'Tis tricky to get right. Trent Mick 2000-08-23T22:08:00Z Tim, Sorry to have left this siting here. I did not know that it was assigned to me. The code is now: if ((LONG_LONG)LONG_MIN <= ival && ival <= (LONG_LONG)LONG_MAX) { return PyLong_FromLong( (long)ival ); } else if (0 <= ival && ival <= (unsigned LONG_LONG)ULONG_MAX) { return PyLong_FromUnsignedLong( (unsigned long)ival ); } else { which means that the bug is fixed n'est ce pas? I remember discussing this way back (though "way back" for me is like last week for you). Tim Peters 2000-08-24T00:27:00Z What do you mean you didn't know it was assigned to you? It was assigned to you for an entire 7 minutes before I reassigned it to me <wink>! So I assigned it back to you. You're indeed right about the fix -- I had hallucinated this into something deeper than it was. Better for you to fix it since you can actually test it! Thanks, Trent. Trent Mick 2000-08-31T15:49:00Z I am confident that this is fixed I just can't test it because my Win64 box is currently down. I'll leave it open and close it when I get a change to verify (a week or two from now). Tim Peters 2000-09-23T04:37:00Z Marked this Fixed since Trent checked in the change weeks ago. Leaving it for Trent to Close, though. Jeremy Hylton 2000-10-05T14:23:00Z I am marking this closed, because Tim said it was fixed weeks ago and Trent seems to have forgotten to close it. 2000-07-31T21:10:00Z sf210645 Jitterbug-Id: 328 Submitted-By: peter@verecomm.com Date: Mon, 15 May 2000 15:21:33 -0400 (EDT) Version: 1.52 OS: Linux There's a problem with the xmllib module when used with JPython. Specifically, the JPython re module has trouble with the () characters in strings passed into re.compile. Until the JPython folks fix the re module, I'd like to ask that the xmllib module be modified to escape the () characters. Here's the output from diff: $ diff xmllib.py /usr/lib/python1.5/ 29c29 < '(?P<value>'+_QStr+'|[-a-zA-Z0-9.:+*%?!\(\)_#=~]+))?') --- > '(?P<value>'+_QStr+'|[-a-zA-Z0-9.:+*%?!()_#=~]+))?') 45,46c45,46 < _PublicLiteral = '(?P<%s>"[-\'\(\)+,./:=?;!*#@$_%% \n\ra-zA-Z0-9]*"|' \ < "'[-\(\)+,./:=?;!*#@$_%% \n\ra-zA-Z0-9]*')" --- > _PublicLiteral = '(?P<%s>"[-\'()+,./:=?;!*#@$_%% \n\ra-zA-Z0-9]*"|' \ > "'[-()+,./:=?;!*#@$_%% \n\ra-zA-Z0-9]*')" Thanks! ==================================================================== Audit trail: Mon May 22 17:29:00 2000 guido changed notes Tue Jul 11 08:29:18 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM platform-specific Sjoerd Mullender extension-modules Bug Importer Bug Importer 2000-07-31T21:10:00Z Jitterbug-Id: 328 Submitted-By: peter@verecomm.com Date: Mon, 15 May 2000 15:21:33 -0400 (EDT) Version: 1.52 OS: Linux There's a problem with the xmllib module when used with JPython. Specifically, the JPython re module has trouble with the () characters in strings passed into re.compile. Until the JPython folks fix the re module, I'd like to ask that the xmllib module be modified to escape the () characters. Here's the output from diff: $ diff xmllib.py /usr/lib/python1.5/ 29c29 < '(?P<value>'+_QStr+'|[-a-zA-Z0-9.:+*%?!\(\)_#=~]+))?') --- > '(?P<value>'+_QStr+'|[-a-zA-Z0-9.:+*%?!()_#=~]+))?') 45,46c45,46 < _PublicLiteral = '(?P<%s>"[-\'\(\)+,./:=?;!*#@$_%% \n\ra-zA-Z0-9]*"|' \ < "'[-\(\)+,./:=?;!*#@$_%% \n\ra-zA-Z0-9]*')" --- > _PublicLiteral = '(?P<%s>"[-\'()+,./:=?;!*#@$_%% \n\ra-zA-Z0-9]*"|' \ > "'[-()+,./:=?;!*#@$_%% \n\ra-zA-Z0-9]*')" Thanks! ==================================================================== Audit trail: Mon May 22 17:29:00 2000 guido changed notes Tue Jul 11 08:29:18 2000 guido moved from incoming to open Sjoerd Mullender 2000-08-08T11:22:00Z This bug was fixed in revision 1.18. 2000-07-31T21:10:00Z sf210646 Jitterbug-Id: 333 Submitted-By: savichev@physik.uni-freiburg.de Date: Sat, 20 May 2000 17:36:46 -0400 (EDT) Version: 1.6a2 OS: IRIX64 './configure --with-threads' won't pass test_signal during 'make test'. './regrtest.py -v test_signal' # adds on in Makefile fixes the problem. test_threads goes through and test_signal on the compiled python completes also. './regrtest.py -v' mode shows that script = """ ( set %(x)s sleep 2 kill -5 %(pid)d sleep 2 kill -2 %(pid)d sleep 2 kill -3 %(pid)d ) can't be fully completed. ==================================================================== Audit trail: Mon May 22 17:29:29 2000 guido changed notes Tue Jul 11 08:29:18 2000 guido moved from incoming to open Bug Importer REJECTED MEDIUM platform-specific Sjoerd Mullender extension-modules Bug Importer Bug Importer 2000-07-31T21:10:00Z Jitterbug-Id: 333 Submitted-By: savichev@physik.uni-freiburg.de Date: Sat, 20 May 2000 17:36:46 -0400 (EDT) Version: 1.6a2 OS: IRIX64 './configure --with-threads' won't pass test_signal during 'make test'. './regrtest.py -v test_signal' # adds on in Makefile fixes the problem. test_threads goes through and test_signal on the compiled python completes also. './regrtest.py -v' mode shows that script = """ ( set %(x)s sleep 2 kill -5 %(pid)d sleep 2 kill -2 %(pid)d sleep 2 kill -3 %(pid)d ) can't be fully completed. ==================================================================== Audit trail: Mon May 22 17:29:29 2000 guido changed notes Tue Jul 11 08:29:18 2000 guido moved from incoming to open Sjoerd Mullender 2000-08-25T16:19:00Z I have tested this on IRIX 6.5.2, both on IRIX and IRIX64 systems. I have tested both the latest version in the cnri-16-start branch and the main branch, and test_signal and test_thread both pass. 2000-07-31T21:10:00Z sf210647 Jitterbug-Id: 334 Submitted-By: haase@media.mit.edu Date: Sat, 20 May 2000 20:08:00 -0400 (EDT) Version: Both Python 1.5.2 and 1.6a2 OS: SUSE Linux Loading a .py file which attempts to define a very long list causes a segmentation violation. An example file can be found at ftp:/pub/haase/todo.py, but I expect that most any long file defining a long list (20K elements) would do. Thanks, Ken Haase ==================================================================== Audit trail: Mon May 22 17:08:11 2000 guido changed notes Mon May 22 17:08:11 2000 guido moved from incoming to open Bug Importer FIXRELEASED LOW Tim Peters parser-compiler Bug Importer Bug Importer 2000-07-31T21:10:00Z Jitterbug-Id: 334 Submitted-By: haase@media.mit.edu Date: Sat, 20 May 2000 20:08:00 -0400 (EDT) Version: Both Python 1.5.2 and 1.6a2 OS: SUSE Linux Loading a .py file which attempts to define a very long list causes a segmentation violation. An example file can be found at ftp:/pub/haase/todo.py, but I expect that most any long file defining a long list (20K elements) would do. Thanks, Ken Haase ==================================================================== Audit trail: Mon May 22 17:08:11 2000 guido changed notes Mon May 22 17:08:11 2000 guido moved from incoming to open Bug Importer 2000-07-31T21:10:00Z From: Guido van Rossum <guido@python.org> Subject: Re: [Python-bugs-list] Segmentation violation on very long lists (PR#334) Date: Sun, 21 May 2000 12:12:22 -0700 > Loading a .py file which attempts to define a very long list causes > a segmentation violation. An example file can be found at > ftp:/pub/haase/todo.py, but I expect that most any long file defining a long > list (20K elements) would do. Thanks -- this is a known problem, it probably has to do with bytecode field overflow (offsets are signed shorts). --Guido van Rossum (home page: http://www.python.org/~guido/) Jeremy Hylton 2000-08-01T22:54:00Z Currently raises SyntaxError. A better fix is in progress. Jeremy Hylton 2000-09-07T22:06:00Z Please do triage on this bug. Tim Peters 2000-09-15T05:44:00Z Marked as closed and fixed, but without running your test case (the FTP address you gave doesn't make sense -- at least not on *my* machine <wink>). I generated a 50,000-element list with this program instead: f = open("k.py", "w") print >> f, "biglist = [" for i in range(50000): print >> f, i, "," print >> f, "]" print >> f, "print len(biglist)" f.close() and Python 2.0b1 compiles and executes the resulting k.py without incident. 2000-07-31T21:10:00Z sf210648 Jitterbug-Id: 340 Submitted-By: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= <ragnark@vestdata.no> Date: Fri, 26 May 2000 16:51:51 +0200 Version: None OS: None --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Problem on python 1.5.1 on linux 2.2.14aa6. Decoding quoted-printable files using mimetools.decode is really slow. The really strange thing is, that it appers to work a lot faster on smaller files! I put together a little test-program that reads blocks from a file, and decodes them individually. (The output will not be 100% correct. The point was just to test the performance). Results show the time it took to decode a 300k file with the diferent block-sizes: 1k: 6.28 s 3k: 6.59 s 10k: 8.57 s 30k: 30.45 s 100k: 127.82 s 300k: 221.67 s I looked in quopri.decode for clues about the problem, but could not find any. Is there something _very_ wrong with my reasoning, or is something wrong here? -- Ragnar Kjørstad --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="test.py" #!/usr/bin/python from mimetools import decode from StringIO import StringIO from sys import stdout, argv from string import atoi bsize=atoi(argv[1]) output=StringIO() f=open("mail-test") s=f.read(bsize) while s: input=StringIO(s) decode(input, output, 'quoted-printable') s=f.read(bsize) stdout.write('.') stdout.flush() stdout.write('done\n') --7JfCtLOvnd9MIVvH-- ==================================================================== Audit trail: Tue Jul 11 08:25:57 2000 guido moved from incoming to open Bug Importer REJECTED MEDIUM barry python-library Bug Importer Bug Importer 2000-07-31T21:10:00Z Jitterbug-Id: 340 Submitted-By: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= <ragnark@vestdata.no> Date: Fri, 26 May 2000 16:51:51 +0200 Version: None OS: None --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Problem on python 1.5.1 on linux 2.2.14aa6. Decoding quoted-printable files using mimetools.decode is really slow. The really strange thing is, that it appers to work a lot faster on smaller files! I put together a little test-program that reads blocks from a file, and decodes them individually. (The output will not be 100% correct. The point was just to test the performance). Results show the time it took to decode a 300k file with the diferent block-sizes: 1k: 6.28 s 3k: 6.59 s 10k: 8.57 s 30k: 30.45 s 100k: 127.82 s 300k: 221.67 s I looked in quopri.decode for clues about the problem, but could not find any. Is there something _very_ wrong with my reasoning, or is something wrong here? -- Ragnar Kjørstad --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="test.py" #!/usr/bin/python from mimetools import decode from StringIO import StringIO from sys import stdout, argv from string import atoi bsize=atoi(argv[1]) output=StringIO() f=open("mail-test") s=f.read(bsize) while s: input=StringIO(s) decode(input, output, 'quoted-printable') s=f.read(bsize) stdout.write('.') stdout.flush() stdout.write('done\n') --7JfCtLOvnd9MIVvH-- ==================================================================== Audit trail: Tue Jul 11 08:25:57 2000 guido moved from incoming to open Martin von Löwis 2000-09-19T16:52:00Z I can't reproduce the problem. On sparc-sun-solaris2.6, Python 1.5.2 needs the same time for a 330k file, regardless of the block size. Guido van Rossum 2000-09-19T18:11:00Z Can't reproduce it either. Note he's using Python 1.5.1. Maybe it was a buffering problem in StringIO there - quopri.py is using readline(). Barry, if you don't have another idea, just close it as Invalid. Tim Peters 2000-09-22T01:35:00Z I marked this Invalid and Closed. There *may* have been a buffering problem in 1.5.2 that got fixed, or it may simply be that the original report used an unrealistic input file (which is what I suspect -- gory details below), or both. But note that the true complaint ("decode is really slow") probably remains valid. There's *something* still going on here in 2.0b1, at least under Win98SE. Here's the output from a more self-contained version of the program: C:\Python20>python mtest.py 1024 4.6 2048 6.1 10240 7.9 30720 8.8 102400 8.9 307200 9.4 1024 4.5 2048 5.8 10240 8.3 30720 8.9 102400 9.0 307200 9.4 C:\Python20> That's with everything in cache, and there's a very clear & reproducible factor-of-2 advantage to using the small blocksize. Here's the program: BIGFILE = "DLLs/tk83.dll" def timer(fname, blockseq): from mimetools import decode from StringIO import StringIO from time import clock for mult in blockseq: start = clock() bsize = mult * 1024 output = StringIO() f = open(fname, "rb") s = f.read(bsize) while s: input = StringIO(s) decode(input, output, 'quoted-printable') s = f.read(bsize) f.close() del output, f, s, input finish = clock() print "%10d %10.1f" % (bsize, finish - start) if __name__ == "__main__": timer(BIGFILE, (1, 2, 10, 30, 100, 300) * 2) Of course, I'm reading in a binary file there, so the test makes no real sense! And I *suspect* the original bug report also used a nonsense file. Why that's important will become clear soon. If I interrupt the program at random, it's usually on line 72 of quopri.py: File "C:\PYTHON20\lib\quopri.py", line 72, in decode new = new + c; i = i+1 That hints at a problem with the quadratic-time nature of repeated appends. Conventional wisdom is that's just theoretical, but it isn't, and the crossover point is highly platform-dependent. If I replace the call to decode with: while 1: line = input.readline() if not line: break new = "" for ch in line: pass output.write(line) then there's no apparent dependence on block size. So this is not a problem with buffering, it's specific to decode. But if I replace the "pass" with new = new + ch then I get back a very strong dependence on block size. And that loop is what decode does, except for the useful parts <wink>. So that explains *my* glitch: the smaller the blocksize, the more "lines" get artificially created, the smaller the longest lines become, and the less the ch-at-a-time append can hurt. But this is all an artifact of me using a binary file for input! That is, it's an artifact of using a test file with nearly arbitrarily long "lines". If I create a giant 4Mb text file via catenating all the *.html files in the Windows Python doc/lib directory, there is no dependence on blocksize in the test program, other than that it gets a little *faster* the larger the block size. And that's what I'd expect (repeated catenation is linear-time on all platforms I've heard of, so long as the lines are reasonably short). Bug Importer 2001-07-23T17:10:00Z Ive reproduced this problem. The file that gives the library fits is a PDF file that reports as quoted-printable. The file is an actual PDF sent with Microsoft Outlook. Every line in the quoted-printable ends in an =. It looks like the decode function will keep appending to a single line if it finds an = at the end of the line. This is the flag that tells the quopri.decode that the line is a partial line. Bug Importer 2002-05-21T20:34:00Z I've been able to reproduce this using ActivePython 2.1 (build 210) on Windows 2000. The (apparent) solution is to replace the recursive "new = new + c" with a simple "output.write(c)". Seems kind of silly to write a single character at a time, but it took my mail program from infinite loop (running through mod_python) to decoding a 5MB attachment in seconds. Thoughts? 2000-07-31T21:10:00Z sf210649 Jitterbug-Id: 341 Submitted-By: scut@nb.in-berlin.de Date: Sat, 27 May 2000 09:41:23 -0400 (EDT) Version: 1.5.2 OS: Linux To reproduce just start python and enter something like: "%.1200d" % 1 It is constructed in a local buffer on the stack which is about 1000 characters or so long, so you overwrite the framepointer and the retaddr, may be exploitable to attackers under some conditions. Though this bug appears in GNU libc also, this one is within the Python code. Thanks for developing such a great programming language as Python is :-) ciao, scut / teso http://teso.scene.at/ ==================================================================== Audit trail: Tue Jul 11 08:25:57 2000 guido moved from incoming to open Bug Importer FIXRELEASED HIGH python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:10:00Z Jitterbug-Id: 341 Submitted-By: scut@nb.in-berlin.de Date: Sat, 27 May 2000 09:41:23 -0400 (EDT) Version: 1.5.2 OS: Linux To reproduce just start python and enter something like: "%.1200d" % 1 It is constructed in a local buffer on the stack which is about 1000 characters or so long, so you overwrite the framepointer and the retaddr, may be exploitable to attackers under some conditions. Though this bug appears in GNU libc also, this one is within the Python code. Thanks for developing such a great programming language as Python is :-) ciao, scut / teso http://teso.scene.at/ ==================================================================== Audit trail: Tue Jul 11 08:25:57 2000 guido moved from incoming to open Bug Importer 2000-08-01T21:01:00Z From: "M.-A. Lemburg" <mal@lemburg.com> Subject: Re: [Python-bugs-list] %.1200d will make Python segfault (PR#341) Date: Sat, 27 May 2000 17:47:47 +0200 scut@nb.in-berlin.de wrote: > > Full_Name: - > Version: 1.5.2 > OS: Linux > Submission from: elch.in-berlin.de (192.109.42.5) > > To reproduce just start python and enter something like: > > "%.1200d" % 1 > > It is constructed in a local buffer on the stack which is about 1000 characters > or so long, so you overwrite the framepointer and the retaddr, may be > exploitable > to attackers under some conditions. It's a bug in the format code in stringobject.c and unicodeobject.c. Note that the buffer in only 120 chars in size, so "%.130d" % 1 already does the trick. Strange that noone has noticed this one before... Python should really provide the n-variants of printf() et al. on those platforms which do not have them to make it more buffer overflow safe. FYI, I've posted a fix to the patches list. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ 2000-07-31T21:10:00Z sf210650 Jitterbug-Id: 342 Submitted-By: michael.exner@mrz.uni-magdeburg.de Date: Wed, 31 May 2000 09:43:38 -0400 (EDT) Version: 1.5.2 OS: hpux-11.00 When I compile python with threads python core-dumps: $ ./python pthread_mutex_init: Invalid argument Memory fault(coredump) without thread-support everything works fine I tried this with hpux-ansi-c and with gcc (2.95.2) but got the same result ==================================================================== Audit trail: Tue Jul 11 08:25:57 2000 guido moved from incoming to open Bug Importer FIXRELEASED LOW platform-specific Guido van Rossum python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:10:00Z Jitterbug-Id: 342 Submitted-By: michael.exner@mrz.uni-magdeburg.de Date: Wed, 31 May 2000 09:43:38 -0400 (EDT) Version: 1.5.2 OS: hpux-11.00 When I compile python with threads python core-dumps: $ ./python pthread_mutex_init: Invalid argument Memory fault(coredump) without thread-support everything works fine I tried this with hpux-ansi-c and with gcc (2.95.2) but got the same result ==================================================================== Audit trail: Tue Jul 11 08:25:57 2000 guido moved from incoming to open Tim Peters 2000-08-29T03:43:00Z Note that the only call to pthread_mutex_init Python makes is in function PyThread_allocate_lock in file phread_pthread.h. If Python compiled at all, it's extremely unlikely that the first argument is in error. It's very likely that the second argument is in error, though: there were many imcompatible revisions of the pthreads std, and pthread_mutexattr_default is a macro conditionally defined near the top of the file. If this OS actually support pthreads, you have to figure out which *version* of pthreads it defines and arrange for config to define the *correct* one of the PY_PTHREAD_D4 PY_PTHREAD_D7 PY_PTHREAD_STD PY_PTHREAD_D6 symbols for your platform. Else disable threads entirely. Memaul 2000-08-29T14:34:00Z Goto link below for instructions and patches for building python 152 with threads on hpux 10.20 http://memaul.tripod.com/index.html Jeremy Hylton 2000-09-07T22:05:00Z Please do triage on this bug. Harripasanen 2000-09-15T09:34:00Z I can verify that the bug exists not only in 1.5.2 but also in 1.6. gcc 2.95.2 HPUX 11.00 I'll see if tim_one's suggestions help. Regards, Harri Pasanen Harripasanen 2000-09-15T11:55:00Z The problems seems to be that configure gets the libraries wrong on HP-UX 11.0. It links with -lcma, when it should link with -lpthread. So a quick and dirty solution is to relink the python by hand, replacing -lcma with -lpthread. Fred Drake 2000-09-15T17:04:00Z Noted that this is HP-UX specific in summary. Guido van Rossum 2000-09-22T10:02:00Z Assigned to myself because this is another one about thread configuration on HP-UX, which I plan to tackle. Note that Harri (hi, Harri!) contradicts what another HP-UX bug report (#110665) says -- Harri says you shouldn't link with -lcma, the other says you should. (Or does it? It's ambiguous!) Guido van Rossum 2000-09-25T13:10:00Z I'm hoping that this was fixed by recent changes. Sent an email to the original submittor to verify. Guido van Rossum 2000-10-06T17:41:00Z Haven't heard back from the original submittor after sending a reminder last week. Closing this -- there's still another HP-UX threads bug report open from a submitter who *did* write back and still has his particular problem. 2000-07-31T21:10:00Z sf210651 Jitterbug-Id: 343 Submitted-By: atkins@gweep.net Date: Wed, 31 May 2000 17:37:15 -0400 (EDT) Version: 1.5.2 OS: Linux - RH6.1 The following causes a SIGSEGV: import re re.compile ( '[\\200-\\400]' ) Yes, the '\\400' improperly flows into the next byte. Unfortunately, the SIGSEGV isn't very helpful to the average developer. An error-check during the compilation of the RE should have produced an exception. The intent was: import re re.compile ( '[\\200-\\377]' ) ==================================================================== Audit trail: Tue Jul 11 08:25:57 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM A.M. Kuchling Bug Importer Bug Importer 2000-07-31T21:10:00Z Jitterbug-Id: 343 Submitted-By: atkins@gweep.net Date: Wed, 31 May 2000 17:37:15 -0400 (EDT) Version: 1.5.2 OS: Linux - RH6.1 The following causes a SIGSEGV: import re re.compile ( '[\\200-\\400]' ) Yes, the '\\400' improperly flows into the next byte. Unfortunately, the SIGSEGV isn't very helpful to the average developer. An error-check during the compilation of the RE should have produced an exception. The intent was: import re re.compile ( '[\\200-\\377]' ) ==================================================================== Audit trail: Tue Jul 11 08:25:57 2000 guido moved from incoming to open A.M. Kuchling 2000-08-02T13:42:00Z Fixed; check_escape() wasn't using the lowest 8 bits of the second octal escape, as it was supposed to do. 2000-07-31T21:10:00Z sf210652 Jitterbug-Id: 344 Submitted-By: pai@tiac.net Date: Fri, 2 Jun 2000 13:59:21 -0400 (EDT) Version: 1.5.2 OS: NT I entered and saved an area calculation problem presented in one of the tutorials. When I run it, it gets to the input statement, then gets stuck -- it accepts the input, but gives me a new line and continues to look for input when press the return key. Here's the program: # Area Calculation Program print "Welcome to the Area Calculation Program" print "_______________________________________" print # Print out the menu: print "Please select a shape:" print "1 Rectangle" print "2 Circle" # Get the user's choice: shape = input ("> ") # Calculate the area: if shape == 1: height = input("Please enter the height: ") width = input("Please enter the width: ") area = height * width print "The area is",area else: radius = input("Please enter the radius: ") area = 3.14*(radius**2) print "The area is",area print "done" ==================================================================== Audit trail: Tue Jul 11 08:25:58 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM Thomas Wouters idle Bug Importer Bug Importer 2000-07-31T21:10:00Z Jitterbug-Id: 344 Submitted-By: pai@tiac.net Date: Fri, 2 Jun 2000 13:59:21 -0400 (EDT) Version: 1.5.2 OS: NT I entered and saved an area calculation problem presented in one of the tutorials. When I run it, it gets to the input statement, then gets stuck -- it accepts the input, but gives me a new line and continues to look for input when press the return key. Here's the program: # Area Calculation Program print "Welcome to the Area Calculation Program" print "_______________________________________" print # Print out the menu: print "Please select a shape:" print "1 Rectangle" print "2 Circle" # Get the user's choice: shape = input ("> ") # Calculate the area: if shape == 1: height = input("Please enter the height: ") width = input("Please enter the width: ") area = height * width print "The area is",area else: radius = input("Please enter the radius: ") area = 3.14*(radius**2) print "The area is",area print "done" ==================================================================== Audit trail: Tue Jul 11 08:25:58 2000 guido moved from incoming to open Thomas Wouters 2000-08-05T18:41:00Z This is an old bug in IDLE, since fixed (in IDLE 0.5, IIRC.) The problem is that though the *output* of the script, including the prompts for input, are going to a seperate window, the input is taken from the 'interactive' window. Type in your responses in the 'interactive' window and it'll work correctly. Or get a newer IDLE, from www.python.org/idle/ (strongly recommended.) 2000-07-31T21:10:00Z sf210653 Jitterbug-Id: 346 Submitted-By: jparkey@rapidbs.com Date: Mon, 5 Jun 2000 12:06:34 -0400 (EDT) Version: 1.5.2 OS: NT (build 132) Assigning a function object to an instance variable leaks memory. Run the programme below with the Windows task manager up to see the effect. class fred: def __init__(self): self.indirectFunc = self.theFunc def theFunc(self): return "blah" def test(): f = fred() del f if __name__ == "__main__": for x in xrange(1000): test() ==================================================================== Audit trail: Tue Jul 11 08:25:58 2000 guido moved from incoming to open Bug Importer REJECTED MEDIUM not-a-bug Bug Importer Bug Importer 2000-07-31T21:10:00Z Jitterbug-Id: 346 Submitted-By: jparkey@rapidbs.com Date: Mon, 5 Jun 2000 12:06:34 -0400 (EDT) Version: 1.5.2 OS: NT (build 132) Assigning a function object to an instance variable leaks memory. Run the programme below with the Windows task manager up to see the effect. class fred: def __init__(self): self.indirectFunc = self.theFunc def theFunc(self): return "blah" def test(): f = fred() del f if __name__ == "__main__": for x in xrange(1000): test() ==================================================================== Audit trail: Tue Jul 11 08:25:58 2000 guido moved from incoming to open Bug Importer 2000-08-01T21:01:00Z From: "Tim Peters" <tim_one@email.msn.com> Subject: RE: [Python-bugs-list] Assigning function objects to instance variable causes memory leak (PR#346) Date: Mon, 5 Jun 2000 21:30:40 -0400 Assigning a function object is actually harmless. The problem here is that you have an instance I, create a bound method object bound to I, then store the latter as an attribute of I: this creates a cycle (I.indirectFunc points to the bound method object, which in turn points back to I). This is a well-known case of cyclic trash that CPython's reference counting cannot reclaim (that is, it's not a bug, in that it's functioning as designed). Your only hopes for avoiding this behavior-- short of changing your code not to do this --are to use JPython, or wait for CPython to grow another flavor of storage reclamation. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > jparkey@rapidbs.com > Sent: Monday, June 05, 2000 12:07 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] Assigning function objects to instance > variable causes memory leak (PR#346) > > > Full_Name: John Parkey > Version: 1.5.2 > OS: NT (build 132) > Submission from: mail.rapidbs.com (195.92.50.66) > > > Assigning a function object to an instance variable leaks memory. Run the > programme below with the Windows task manager up to see the effect. > > > class fred: > def __init__(self): > self.indirectFunc = self.theFunc > > def theFunc(self): > return "blah" > > def test(): > f = fred() > del f > > > if __name__ == "__main__": > for x in xrange(1000): > test() > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > Bug Importer 2000-08-01T21:01:00Z From: "Mark Hammond" <mhammond@skippinet.com.au> Subject: RE: [Python-bugs-list] Assigning function objects to instance variable causes memory leak (PR#346) Date: Tue, 6 Jun 2000 09:54:29 +1000 John also mailed me this personally. I have already responded that this is not a bug, but a known circular reference, and outlined a few ways aound it. Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > jparkey@rapidbs.com > Sent: Tuesday, 6 June 2000 2:07 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] Assigning function objects to instance > variable causes memory leak (PR#346) > > > Full_Name: John Parkey > Version: 1.5.2 > OS: NT (build 132) > Submission from: mail.rapidbs.com (195.92.50.66) > > > Assigning a function object to an instance variable leaks > memory. Run the > programme below with the Windows task manager up to see the effect. > > > class fred: > def __init__(self): > self.indirectFunc = self.theFunc > > def theFunc(self): > return "blah" > > def test(): > f = fred() > del f > > > if __name__ == "__main__": > for x in xrange(1000): > test() > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > 2000-07-31T21:10:00Z sf210654 Jitterbug-Id: 347 Submitted-By: fvdp@decis.be Date: Mon, 5 Jun 2000 13:12:35 -0400 (EDT) Version: 1.5.1 OS: Windows NT 4 There is a bug in the test for non-nullity of a complex number. e.g. not (1j), not (4+0j) both return 1. (they should return 0, like (not n) for any non-null number n.) correction in <complexobject.c>: '||' instead of '&&' in complex_nonzero(v): static int complex_nonzero(v) PyComplexObject *v; { return v->cval.real != 0.0 || v->cval.imag != 0.0; } (Warning: I did not test my correction ;-) LEGALESE: I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. ==================================================================== Audit trail: Tue Jul 11 08:25:58 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:10:00Z Jitterbug-Id: 347 Submitted-By: fvdp@decis.be Date: Mon, 5 Jun 2000 13:12:35 -0400 (EDT) Version: 1.5.1 OS: Windows NT 4 There is a bug in the test for non-nullity of a complex number. e.g. not (1j), not (4+0j) both return 1. (they should return 0, like (not n) for any non-null number n.) correction in <complexobject.c>: '||' instead of '&&' in complex_nonzero(v): static int complex_nonzero(v) PyComplexObject *v; { return v->cval.real != 0.0 || v->cval.imag != 0.0; } (Warning: I did not test my correction ;-) LEGALESE: I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. ==================================================================== Audit trail: Tue Jul 11 08:25:58 2000 guido moved from incoming to open Bug Importer 2000-08-01T21:01:00Z From: "Tim Peters" <tim_one@email.msn.com> Subject: RE: [Python-bugs-list] bug in complex_nonzero (PR#347) Date: Mon, 5 Jun 2000 13:54:04 -0400 Frédéric, you should upgrade to Python 1.5.2! This was fixed a long time ago (1.5.2 was released more than a year ago). > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of fvdp@decis.be > Sent: Monday, June 05, 2000 1:13 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] bug in complex_nonzero (PR#347) > > > Full_Name: Frédéric van der Plancke > Version: 1.5.1 > OS: Windows NT 4 > Submission from: i0913.bfp-s.euronet.be (212.65.51.151) > > > There is a bug in the test for non-nullity of a complex number. > e.g. not (1j), not (4+0j) both return 1. > (they should return 0, like (not n) for any non-null number n.) > > correction in <complexobject.c>: > '||' instead of '&&' in complex_nonzero(v): > > static int > complex_nonzero(v) > PyComplexObject *v; > { > return v->cval.real != 0.0 || v->cval.imag != 0.0; > } > > (Warning: I did not test my correction ;-) > > LEGALESE: > I confirm that, to the best of my knowledge and belief, this > contribution is free of any claims of third parties under > copyright, patent or other rights or interests ("claims"). To > the extent that I have any such claims, I hereby grant to CNRI a > nonexclusive, irrevocable, royalty-free, worldwide license to > reproduce, distribute, perform and/or display publicly, prepare > derivative versions, and otherwise use this contribution as part > of the Python software and its related documentation, or any > derivative versions thereof, at no cost to CNRI or its licensed > users, and to authorize others to do so. > > I acknowledge that CNRI may, at its sole discretion, decide > whether or not to incorporate this contribution in the Python > software and its related documentation. I further grant CNRI > permission to use my name and other identifying information > provided to CNRI by me for use in connection with the Python > software and its related documentation. > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list 2000-07-31T21:10:00Z sf210655 Jitterbug-Id: 349 Submitted-By: ctalley@caci.com Date: Thu, 8 Jun 2000 15:52:19 -0400 (EDT) Version: 1.5.2 OS: W95 When using this code, the third line is skipped. That is, the prompt appears, but the program doesn't pause to accept input data. It goes right to the fourth line and pauses there. I end up with a null string for "fromaddr". username=raw_input('Enter FTP server account username: ') password=getpass.getpass('Enter FTP server account password: ') fromaddr=raw_input('Enter your e-mail address: ') toaddr=raw_input('Enter e-mail address for notification: ') When using this code, everything works (although echo of the password isn't suppressed.) username=raw_input('Enter FTP server account username: ') password=raw_input('Enter FTP server account password: ') fromaddr=raw_input('Enter your e-mail address: ') toaddr=raw_input('Enter e-mail address for notification: ') The difference between the two code segments is that the first uses the getpass method on the second line and the second uses raw_input. What I think is happening is that getpass is leaving some garbage in a buffer somewhere which is seen by raw_input as data. raw_input happily accepts the data and goes to the next line. I've devised several workarounds including "flush_input_buffer=raw_input('')" immediately following the call to getpass. It's ugly, but it works. Thanks, Carl Talley ==================================================================== Audit trail: Tue Jul 11 08:25:59 2000 guido moved from incoming to open Bug Importer REJECTED MEDIUM platform-specific Mark Hammond Bug Importer Bug Importer 2000-07-31T21:10:00Z Jitterbug-Id: 349 Submitted-By: ctalley@caci.com Date: Thu, 8 Jun 2000 15:52:19 -0400 (EDT) Version: 1.5.2 OS: W95 When using this code, the third line is skipped. That is, the prompt appears, but the program doesn't pause to accept input data. It goes right to the fourth line and pauses there. I end up with a null string for "fromaddr". username=raw_input('Enter FTP server account username: ') password=getpass.getpass('Enter FTP server account password: ') fromaddr=raw_input('Enter your e-mail address: ') toaddr=raw_input('Enter e-mail address for notification: ') When using this code, everything works (although echo of the password isn't suppressed.) username=raw_input('Enter FTP server account username: ') password=raw_input('Enter FTP server account password: ') fromaddr=raw_input('Enter your e-mail address: ') toaddr=raw_input('Enter e-mail address for notification: ') The difference between the two code segments is that the first uses the getpass method on the second line and the second uses raw_input. What I think is happening is that getpass is leaving some garbage in a buffer somewhere which is seen by raw_input as data. raw_input happily accepts the data and goes to the next line. I've devised several workarounds including "flush_input_buffer=raw_input('')" immediately following the call to getpass. It's ugly, but it works. Thanks, Carl Talley ==================================================================== Audit trail: Tue Jul 11 08:25:59 2000 guido moved from incoming to open Jeremy Hylton 2000-09-07T22:04:00Z Please do triage on this bug. Guido van Rossum 2000-09-13T10:23:00Z Confirmed with Python 2.0b1 on Win98SE. The bug does not occur on Linux. Tim, the getpass code for Windows is different than on Unix, so please have a look! Tim Peters 2000-09-14T09:05:00Z Mark, I assigned this to you on the chance you know a better trick. Note that I already closed it as "Won't Fix", so if you *don't* know a better trick you don't have to do anything here. This can't be fixed on Windows. As the MS docs say, "The console I/O routines are not compatible with stream I/O or low-level I/O library routines", and getpass uses the console I/O routines on Windows. Mixing console I/O with C stdio is undefined, and C stdio doesn't provide a way to do non-echo'ing input itself. About the best you can do is to define your own raw_input variant that uses console I/O too. For example, def phony_raw_input(prompt=""): from msvcrt import putch, getche for ch in prompt: putch(ch) s = "" while 1: c = getche() if c in "\r\n": break elif c == '\003': raise KeyboardInterrupt elif c == '\b': s = s[:-1] else: s = s + c putch('\r') putch('\n') return s Use phony_raw_input instead of raw_input in your example and it will work as you hoped. It may screw up the *next* read from stdin, though! All of the keyboard buffer, MS-DOS buffer, and stdio buffers get mixed into this, and MS doesn't define or guarantee the way all those interact across Windows flavors. Amc1 2002-06-11T10:01:00Z I've currently written a module which attempts to fix this problem, which you can get from here: http://ccec.sf.net/getpassfix.html However, as I've mentioned in the documentation, it is a hack, but the "platform" based solution should become a more suitable candidate as it is tested. 2000-07-31T21:11:00Z sf210656 Jitterbug-Id: 352 Submitted-By: gpk@bell-labs.com Date: Fri, 9 Jun 2000 22:45:05 -0400 (EDT) Version: 1.6 CVS today OS: Solaris 2.6 When using IDLE's shell window Debug->Go to file/line, you have to be overly careful what you select. Specifically, if you select a region that contains a newline, IDLE won't be able to find a file and line number. For example, if you select v-- from there File "/export/h1/gpk/schoolweb.local/schoolweb/parse.py", line 199, in __str__ ^-- to there (i.e. 2 characters in, on the following line), you will get the following error message: "No special line: X the line you point to doesn't look like a file name followed by a line number." That is unfortunate, as it's really convenient to make a quick flick down from one line to the next, to select a complete line. By the way, the error box requires you to click "OK". That's a bug. It isn't OK. It's a crime against the King's English, committed by the minions of Bill Gates. You should not be following their lead. ==================================================================== Audit trail: Tue Jul 11 08:25:59 2000 guido moved from incoming to open Bug Importer REJECTED LOW Guido van Rossum idle Bug Importer Bug Importer 2000-07-31T21:11:00Z Jitterbug-Id: 352 Submitted-By: gpk@bell-labs.com Date: Fri, 9 Jun 2000 22:45:05 -0400 (EDT) Version: 1.6 CVS today OS: Solaris 2.6 When using IDLE's shell window Debug->Go to file/line, you have to be overly careful what you select. Specifically, if you select a region that contains a newline, IDLE won't be able to find a file and line number. For example, if you select v-- from there File "/export/h1/gpk/schoolweb.local/schoolweb/parse.py", line 199, in __str__ ^-- to there (i.e. 2 characters in, on the following line), you will get the following error message: "No special line: X the line you point to doesn't look like a file name followed by a line number." That is unfortunate, as it's really convenient to make a quick flick down from one line to the next, to select a complete line. By the way, the error box requires you to click "OK". That's a bug. It isn't OK. It's a crime against the King's English, committed by the minions of Bill Gates. You should not be following their lead. ==================================================================== Audit trail: Tue Jul 11 08:25:59 2000 guido moved from incoming to open Jeremy Hylton 2000-09-07T22:03:00Z Please do triage on this bug. barry 2000-09-16T21:56:00Z Guido is the IDLE god. Guido van Rossum 2000-09-19T01:46:00Z I can't reproduce this. It works fine for me, no matter where I start or end the selection. I remember that I fixed something in this area, but that was back in March -- and you say that you are using the CVS tree. I have no idea what you are talking about in your comment about "OK". :-) 2000-07-31T21:11:00Z sf210658 Jitterbug-Id: 353 Submitted-By: giusedia@libero.it Date: Sun, 11 Jun 2000 18:19:32 -0400 (EDT) Version: 1.5 OS: W2k When installing pyton 1.5 in my w2k, i noticed an error message when starting IDLE(Pyton gui)as admin.The error was some dll not found, tk80.dll and tcl80.dll, in the c:\programmi\python\dlls dir. The program then continued normally. I fixed it copying them there and now starts normally. But IDLE(Pyton gui)keeps not starting at all while in user mode.Bye ==================================================================== Audit trail: Tue Jul 11 08:25:59 2000 guido moved from incoming to open Bug Importer FIXRELEASED LOW not-a-bug Thomas Wouters tkinter Bug Importer Bug Importer 2000-07-31T21:11:00Z Jitterbug-Id: 353 Submitted-By: giusedia@libero.it Date: Sun, 11 Jun 2000 18:19:32 -0400 (EDT) Version: 1.5 OS: W2k When installing pyton 1.5 in my w2k, i noticed an error message when starting IDLE(Pyton gui)as admin.The error was some dll not found, tk80.dll and tcl80.dll, in the c:\programmi\python\dlls dir. The program then continued normally. I fixed it copying them there and now starts normally. But IDLE(Pyton gui)keeps not starting at all while in user mode.Bye ==================================================================== Audit trail: Tue Jul 11 08:25:59 2000 guido moved from incoming to open Thomas Wouters 2000-08-03T12:20:00Z This problem is not specific to Windows 2000. For Python 1.5.2 and earlier, you need to install Tcl/Tk yourself, before installing Python. Just as the install instructions tells you to. This will be 'fixed' in 1.6 and later, which include a Tcl/Tk installer. 2000-07-31T21:11:00Z sf210659 Jitterbug-Id: 354 Submitted-By: gpk@bell-labs.com Date: Tue, 13 Jun 2000 10:05:35 -0400 (EDT) Version: 1.6a2+ OS: Solaris sparc 2.6 Alt-w is advertised to copy the selected text. It doesn't. It pops up the 'window' menu. However, even if you are in the 'edit' menu, alt-w apparently does nothing. I can select text, do alt-E alt-W, move the pointer, then do ctrl-Y, and nothing pops up. By the way, 'ctl-U ctl-U ctl-S' is an absurdly long sequence for something as common as searching for text. ==================================================================== Audit trail: Tue Jul 11 08:26:00 2000 guido moved from incoming to open Bug Importer REJECTED LOW feature-request Guido van Rossum idle Bug Importer Bug Importer 2000-07-31T21:11:00Z Jitterbug-Id: 354 Submitted-By: gpk@bell-labs.com Date: Tue, 13 Jun 2000 10:05:35 -0400 (EDT) Version: 1.6a2+ OS: Solaris sparc 2.6 Alt-w is advertised to copy the selected text. It doesn't. It pops up the 'window' menu. However, even if you are in the 'edit' menu, alt-w apparently does nothing. I can select text, do alt-E alt-W, move the pointer, then do ctrl-Y, and nothing pops up. By the way, 'ctl-U ctl-U ctl-S' is an absurdly long sequence for something as common as searching for text. ==================================================================== Audit trail: Tue Jul 11 08:26:00 2000 guido moved from incoming to open Jeremy Hylton 2000-09-07T22:01:00Z Please do triage on this bug. Guido van Rossum 2000-10-06T17:19:00Z This is still broken in IDLE 0.6 in Python 2.0. I doubt that I'll have time to fix it -- the keyboard bindings in general are utterly weird and inconsistent. So I'll add an item to PEP-42 (the wish-list) and close this bug report. 2000-07-31T21:11:00Z sf210660 Jitterbug-Id: 355 Submitted-By: gpk@bell-labs.com Date: Tue, 13 Jun 2000 11:30:14 -0400 (EDT) Version: yesterday's CVS OS: Solaris 2.6 If you type ctrl-f5 to run a script twice in sucession, IDLE will incorrectly pop up a window saying "Not Saved. Please Save First." If you save (even though you haven't changed anything, and even though there are no asterisks around the window title), then ctrl-f5 will work again. This *doesn't* happen if you run the script twice in succession from the menu. ==================================================================== Audit trail: Tue Jul 11 08:26:00 2000 guido moved from incoming to open Bug Importer FIXRELEASED LOW feature-request Guido van Rossum idle Bug Importer Bug Importer 2000-07-31T21:11:00Z Jitterbug-Id: 355 Submitted-By: gpk@bell-labs.com Date: Tue, 13 Jun 2000 11:30:14 -0400 (EDT) Version: yesterday's CVS OS: Solaris 2.6 If you type ctrl-f5 to run a script twice in sucession, IDLE will incorrectly pop up a window saying "Not Saved. Please Save First." If you save (even though you haven't changed anything, and even though there are no asterisks around the window title), then ctrl-f5 will work again. This *doesn't* happen if you run the script twice in succession from the menu. ==================================================================== Audit trail: Tue Jul 11 08:26:00 2000 guido moved from incoming to open Bug Importer 2000-08-01T21:01:00Z From: Guido van Rossum <guido@python.org> Subject: Re: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) Date: Tue, 20 Jun 2000 18:10:35 -0500 > > I think I understand this. It's happened to me too. Pressing ^F5 > > changes the focus to the PyShell window. Pressing ^F5 again then > > indeed complains about that window being unsaved. > > > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > Ah. Sure enough. Perhaps the best thing to do > is just to have the little error message explain > which window is unsaved. Include the title > of the unsaved window in the error box, maybe. > > I'd be happy to send a patch, but the paperwork > would be terrible... No need for paperwork, just the disclaimer text. But I think the better patch would be to make PyShell a special case and make it rerun the last window that had the focus. --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-08-01T21:01:00Z From: Greg Kochanski <gpk@bell-labs.com> Subject: Re: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) Date: Tue, 20 Jun 2000 17:25:37 -0400 Guido van Rossum wrote: > > I think I understand this. It's happened to me too. Pressing ^F5 > changes the focus to the PyShell window. Pressing ^F5 again then > indeed complains about that window being unsaved. > > --Guido van Rossum (home page: http://www.python.org/~guido/) Ah. Sure enough. Perhaps the best thing to do is just to have the little error message explain which window is unsaved. Include the title of the unsaved window in the error box, maybe. I'd be happy to send a patch, but the paperwork would be terrible... Bug Importer 2000-08-01T21:01:00Z From: Guido van Rossum <guido@python.org> Subject: Re: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) Date: Tue, 20 Jun 2000 16:42:57 -0500 I think I understand this. It's happened to me too. Pressing ^F5 changes the focus to the PyShell window. Pressing ^F5 again then indeed complains about that window being unsaved. --Guido van Rossum (home page: http://www.python.org/~guido/) [Tim] > Pretty mysterious! Doesn't happen under IDLE 0.5 for me. Running under > Windows, but darned hard to see why that would matter. Can anyone else try > this under Solaris 2.6? May have something to do with the specific script > you're running, Greg; e.g., does it happen if the script file contains just > > print "Hi!" > > ? > > > -----Original Message----- > > From: python-bugs-list-admin@python.org > > [mailto:python-bugs-list-admin@python.org]On Behalf Of gpk@bell-labs.com > > Sent: Tuesday, June 13, 2000 11:30 AM > > To: python-bugs-list@python.org > > Cc: bugs-py@python.org > > Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) > > > > > > Full_Name: Greg Kochanski > > Version: yesterday's CVS > > OS: Solaris 2.6 > > Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130) > > > > > > If you type ctrl-f5 to run a script twice in sucession, > > IDLE will incorrectly pop up a window saying > > "Not Saved. Please Save First." > > > > If you save (even though you haven't changed anything, > > and even though there are no asterisks around the window > > title), then ctrl-f5 will work again. > > > > This *doesn't* happen if you run the script twice in > > succession from the menu. > > > > > > > > _______________________________________________ > > Python-bugs-list maillist - Python-bugs-list@python.org > > http://www.python.org/mailman/listinfo/python-bugs-list > > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list Bug Importer 2000-08-01T21:01:00Z From: "Tim Peters" <tim_one@email.msn.com> Subject: RE: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) Date: Tue, 13 Jun 2000 11:55:09 -0400 Pretty mysterious! Doesn't happen under IDLE 0.5 for me. Running under Windows, but darned hard to see why that would matter. Can anyone else try this under Solaris 2.6? May have something to do with the specific script you're running, Greg; e.g., does it happen if the script file contains just print "Hi!" ? > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of gpk@bell-labs.com > Sent: Tuesday, June 13, 2000 11:30 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) > > > Full_Name: Greg Kochanski > Version: yesterday's CVS > OS: Solaris 2.6 > Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130) > > > If you type ctrl-f5 to run a script twice in sucession, > IDLE will incorrectly pop up a window saying > "Not Saved. Please Save First." > > If you save (even though you haven't changed anything, > and even though there are no asterisks around the window > title), then ctrl-f5 will work again. > > This *doesn't* happen if you run the script twice in > succession from the menu. > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > Jeremy Hylton 2000-09-07T22:06:00Z Please do triage on this bug. Tim Peters 2000-09-15T05:54:00Z Assigned to Guido. Guido, know whether he ever mailed you a patch? Guido van Rossum 2000-09-15T15:46:00Z I added the filename to the error message as proposed. 2000-07-31T21:11:00Z sf210661 Jitterbug-Id: 356 Submitted-By: mredar@yahoo.com Date: Tue, 13 Jun 2000 16:05:59 -0400 (EDT) Version: 1.5.2 OS: linux I am currently starting to use the cgi module for python. In general it's quite nice, I love the builtin "test" function--very handy. I do have a quibble with the handling of query strings by the parser. In the HTML 4 specification, appendix B it is stated: B.2.2 Ampersands in URI attribute values The URI that is constructed when a form is submitted may be used as an anchor-style link (e.g., the href attribute for the A element). Unfortunately, the use of the "&" character to separate form fields interacts with its use in SGML attribute values to delimit character entity references. For example, to use the URI "http://host/?x=1&y=2" as a linking URI, it must be written <A href="http://host/?x=1&#38;y=2"> or <A href="http://host/?x=1&amp;y=2">. We recommend that HTTP server implementors, and in particular, CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner. The recommended handling of ';' as field delimiters is not implemented in this module. Do you have any plans to implement this feature? My current company is going to use the ';' separator and it works with other cgi packages (perl & java servlets). I'd love to use python, but this is a stumbling block. Thanks, Mark ==================================================================== Audit trail: Tue Jul 11 08:26:00 2000 guido moved from incoming to open Bug Importer FIXRELEASED LOW feature-request Jeremy Hylton extension-modules Bug Importer Bug Importer 2000-07-31T21:11:00Z Jitterbug-Id: 356 Submitted-By: mredar@yahoo.com Date: Tue, 13 Jun 2000 16:05:59 -0400 (EDT) Version: 1.5.2 OS: linux I am currently starting to use the cgi module for python. In general it's quite nice, I love the builtin "test" function--very handy. I do have a quibble with the handling of query strings by the parser. In the HTML 4 specification, appendix B it is stated: B.2.2 Ampersands in URI attribute values The URI that is constructed when a form is submitted may be used as an anchor-style link (e.g., the href attribute for the A element). Unfortunately, the use of the "&" character to separate form fields interacts with its use in SGML attribute values to delimit character entity references. For example, to use the URI "http://host/?x=1&y=2" as a linking URI, it must be written <A href="http://host/?x=1&#38;y=2"> or <A href="http://host/?x=1&amp;y=2">. We recommend that HTTP server implementors, and in particular, CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner. The recommended handling of ';' as field delimiters is not implemented in this module. Do you have any plans to implement this feature? My current company is going to use the ';' separator and it works with other cgi packages (perl & java servlets). I'd love to use python, but this is a stumbling block. Thanks, Mark ==================================================================== Audit trail: Tue Jul 11 08:26:00 2000 guido moved from incoming to open Jeremy Hylton 2000-09-15T20:07:00Z fixed in rev 1.51 of cgi.py 2000-07-31T21:11:00Z sf210662 Jitterbug-Id: 358 Submitted-By: jbearce@copeland.com Date: Thu, 15 Jun 2000 19:37:00 -0400 (EDT) Version: 1.5.2 OS: RedHat Linux 6.2 For very long headers returned from a web server rfc822.readheaders does not correctly build the header. The following patch fixes it in my situation but I don't know if I broke anything else: Example Header: Location: https://www.website.com:443/tengah/Dpc/vContent.jhtml?page_type=3&PLANID=4&CONTENTPAGEID=0&TengahSession=312442259237-529/2748412123003458168/-1407548368/4/7002/7002/7004/7004 This ends up as https://www.website.com:443/tengah/Dpc/vContent.jhtml?page_type=3&PLA and the rest of the header (along with any headers following this one) get returned as part of the message. --- /usr/lib/python1.5/rfc822.py.orig Thu Jun 15 19:35:42 2000 +++ /usr/lib/python1.5/rfc822.py Thu Jun 15 19:36:00 2000 @@ -125,6 +125,7 @@ self.status = '' headerseen = "" firstline = 1 + lastheader = '' startofline = unread = tell = None if hasattr(self.fp, 'unread'): unread = self.fp.unread @@ -150,16 +151,22 @@ continue elif self.iscomment(line): # It's a comment. Ignore it. + lastheader = '' continue elif self.islast(line): # Note! No pushback here! The delimiter line gets eaten. + lastheader = '' break headerseen = self.isheader(line) if headerseen: # It's a legal header line, save it. list.append(line) self.dict[headerseen] = string.strip(line[len(headerseen)+2:]) + lastheader = headerseen continue + elif lastheader: + list.append(line) + self.dict[lastheader] = self.dict[lastheader] + string.strip(line) else: # It's not a header line; throw it back and stop here. if not self.dict: ==================================================================== Audit trail: Tue Jul 11 08:26:01 2000 guido moved from incoming to open Bug Importer REJECTED LOW irreproducible barry python-library Bug Importer Bug Importer 2000-07-31T21:11:00Z Jitterbug-Id: 358 Submitted-By: jbearce@copeland.com Date: Thu, 15 Jun 2000 19:37:00 -0400 (EDT) Version: 1.5.2 OS: RedHat Linux 6.2 For very long headers returned from a web server rfc822.readheaders does not correctly build the header. The following patch fixes it in my situation but I don't know if I broke anything else: Example Header: Location: https://www.website.com:443/tengah/Dpc/vContent.jhtml?page_type=3&PLANID=4&CONTENTPAGEID=0&TengahSession=312442259237-529/2748412123003458168/-1407548368/4/7002/7002/7004/7004 This ends up as https://www.website.com:443/tengah/Dpc/vContent.jhtml?page_type=3&PLA and the rest of the header (along with any headers following this one) get returned as part of the message. --- /usr/lib/python1.5/rfc822.py.orig Thu Jun 15 19:35:42 2000 +++ /usr/lib/python1.5/rfc822.py Thu Jun 15 19:36:00 2000 @@ -125,6 +125,7 @@ self.status = '' headerseen = "" firstline = 1 + lastheader = '' startofline = unread = tell = None if hasattr(self.fp, 'unread'): unread = self.fp.unread @@ -150,16 +151,22 @@ continue elif self.iscomment(line): # It's a comment. Ignore it. + lastheader = '' continue elif self.islast(line): # Note! No pushback here! The delimiter line gets eaten. + lastheader = '' break headerseen = self.isheader(line) if headerseen: # It's a legal header line, save it. list.append(line) self.dict[headerseen] = string.strip(line[len(headerseen)+2:]) + lastheader = headerseen continue + elif lastheader: + list.append(line) + self.dict[lastheader] = self.dict[lastheader] + string.strip(line) else: # It's not a header line; throw it back and stop here. if not self.dict: ==================================================================== Audit trail: Tue Jul 11 08:26:01 2000 guido moved from incoming to open Martin von Löwis 2000-09-17T11:48:00Z I can't reproduce the problem. In 2.0b1, >>> s="Location: https://www.website.com:443/tengah/Dpc/vContent.jhtml?page_type=3&PLANID=4&CONTENTPAGEID=0&TengahSession=312442259237-529/2748412123003458168/-1407548368/4/7002/7002/7004/7004\r\n\r\n" >>> t=rfc822.Message(cStringIO.StringIO(s)) >>> t['location'] 'https://www.website.com:443/tengah/Dpc/vContent.jhtml?page_type=3&PLANID=4&CONTENTPAGEID=0&TengahSession=312442259237-529/2748412123003458168/-1407548368/4/7002/7002/7004/7004' works fine for me. If the line break between Location: and the URL in the original report was intentional, rfc822.Message is right in rejecting the header: Continuation lines must start with white space. Guido van Rossum 2000-09-22T18:03:00Z Can't reproduce it either. Let's not waste time with this. 2000-07-31T21:11:00Z sf210663 Jitterbug-Id: 359 Submitted-By: harishbk@inf.com Date: Fri, 16 Jun 2000 03:46:58 -0400 (EDT) Version: 1.5.2 OS: OSF1 version 4.0f code: #! /usr/local/bin/python import getpass pas=getpass.getpass() when it is run password : harish it is echoing password input. How can we avoid echoing it. ==================================================================== Audit trail: Tue Jul 11 08:26:01 2000 guido moved from incoming to open Bug Importer REJECTED LOW not-a-bug extension-modules Bug Importer Bug Importer 2000-07-31T21:11:00Z Jitterbug-Id: 359 Submitted-By: harishbk@inf.com Date: Fri, 16 Jun 2000 03:46:58 -0400 (EDT) Version: 1.5.2 OS: OSF1 version 4.0f code: #! /usr/local/bin/python import getpass pas=getpass.getpass() when it is run password : harish it is echoing password input. How can we avoid echoing it. ==================================================================== Audit trail: Tue Jul 11 08:26:01 2000 guido moved from incoming to open Bug Importer 2000-08-01T21:01:00Z From: "M.-A. Lemburg" <mal@lemburg.com> Subject: Re: [Python-bugs-list] getpass() echo password input (PR#359) Date: Fri, 16 Jun 2000 10:03:55 +0200 harishbk@inf.com wrote: > > Full_Name: harish > Version: 1.5.2 > OS: OSF1 version 4.0f > Submission from: (NULL) (202.54.39.82) > > code: > > #! /usr/local/bin/python > > import getpass > pas=getpass.getpass() > > when it is run > password : harish > > it is echoing password input. How can we avoid echoing it. You will need to compile Python with termios support enabled to have getpass() turn off echoing. (Edit Modules/Setup and rerun 'make install'.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ 2000-07-31T21:11:00Z sf210664 Jitterbug-Id: 36 Submitted-By: chenna@embl-heidelberg.de Date: Fri, 23 Jul 1999 06:51:43 -0400 (EDT) Version: 1.5.1 OS: OSF1 Hello I get Stack overflow: pid 14731, proc emparse1.py, addr 0x11fdfffd8, pc 0x120068cd8 Segmentation fault when I run the following. The problem is re module unable to search for the pattern that is too large, but this is a requirement for my application in biology. I enclose the source code with this. Please email me the solution as soon as possible Thanks Ramu ___________________________ #!/usr/pub/bin/python1.5 # # # # (C) Chenna Ramu, EMBL, Heidelberg, Germany # # parser for biological databases # import string import sys import re parserDict = { 'id' : r'((^ID [^\n]+\n)+)' , 'ac' : r'((^AC [^\n]+\n)+)' , 'dt' : r'((^DT [^\n]+\n)+)' , 'de' : r'((^DE [^\n]+\n)+)' , 'gn' : r'((^GN [^\n]+\n)+)' , 'os' : r'((^OS [^\n]+\n)+)' , 'oc' : r'((^OC [^\n]+\n)+)' , 'ref' : r'((' r'(^RN [^\n]+\n)' r'((^RP [^\n]+\n)+)' r'((^RX [^\n]+\n)?)' r'((^RA [^\n]+\n)+)' r'((^RT [^\n]+\n)*)' r'((^RL [^\n]+\n)+)' r')+)', 'cc' : r'((^CC [^\n]+\n)+)' , 'dr' : r'((^DR [^\n]+\n)+)' , 'kw' : r'((^KW [^\n]+\n)+)' , 'ft' : r'((^FT [^\n]+\n)+)' , 'sq' : r'(^SQ [^\n]+\n)' \ r'((^ [^\n]+\n)+)' } _hrefLink = {'embl':['<A href=%s>%s</A>','^DR ([^;]+)']} #should be like this hrefLink = {'EMBL':"<A href=http://www/wgetz?-e+[%s-id:%s]>%s</a>", 'MIM':"<A href=http://www/wgetz?-e+[%s-id:%s]>%s</a>"} em_rep = r'(^DR )(?P<dbase>[^;]+); (?P<id>[^;]+)' class embl: def __init__(self,parserDict={}): self.parserDict = {} self.reDict = {} #keep the compiled re's self.fields = [] if parserDict: self.Init(parserDict) def Init(self,parserDict): self.parserDict = parserDict self.fields = parserDict.keys() for j in self.fields: setattr(self, j, None) self.reDict[j] = re.compile(parserDict[j],re.MULTILINE) def Parse(self,str): if not self.parserDict: print "No parser specified" return for k,v in parserDict.items(): ## tmp = re.compile(v,re.MULTILINE) # move this to __init__ tmp = self.reDict[k] mat = tmp.search(str) if mat: setattr(self, k, mat.group() ) def Field(self,name): try: return getattr(self,name) except AttributeError: return None def PrintFields(self): flds = self.fields for j in flds: print "==> ",j print getattr(self,j) def ReParse(self,str,retToken,pat): """ str:string to parse, retToken:return token, pat:parser """ _p = re.compile(pat) m = _p.search(str) if m: return m.group(retToken) else: return None def Href(match): """ Replaces the hrefs """ dbase = match.group('dbase') id = match.group('id') try: defi = hrefLink[dbase] except KeyError: defi = None if defi: tmp = match.group(1) + dbase + '; '+defi %(dbase,id,id) else: tmp = match.group(1)+ dbase + '; ' + id return tmp def test(fileName): sys.path.insert(0,'/home/chenna/py') ## from seqFormat import * e = embl(parserDict) # f = open('acha_mouse.dat','r') f = open(fileName,'r') a = f.readlines() f.close() a = string.join(a,'') e.Parse(a) e.PrintFields() import string print ' the fields are ',e.fields ## seq = string.split(e.sq,';')[-1] ## s = Seq(seq,'test') ## print 'check===>',s.seq ## s.SeqPrint('swiss') seqLen = e.ReParse(e.sq[0:50],'seqLen',r'^SQ [^ ]+ *(?P<seqLen>(\d+))') print e.sq print "length of the sequence ",seqLen print e.ref dr = e.dr print dr p = re.compile(em_rep,re.M) dr = p.sub(Href,dr) print dr print e.Field('id') print e.Field('dr') print e.Field('mm') return def test1(dumm=None): tmp = ['SQ Sequence 1041931 BP; 8972 A; 5950 C; 6264 G; 8224 T; 0 other;\n'] for j in range(1,17365): t = ' ' + 'tcagtcagtg ' * 6 + '\n' tmp.append(t) a = string.join(tmp) e = embl(parserDict) e.Parse(a) e.PrintFields() if __name__ == '__main__': try: test1(sys.argv[1]) except: test1() ==================================================================== Audit trail: Sat Jul 24 16:53:53 1999 guido changed notes Sat Jul 24 16:53:53 1999 guido moved from incoming to open Sat Jul 24 17:04:17 1999 guido changed notes Bug Importer REJECTED MEDIUM A.M. Kuchling extension-modules Bug Importer Bug Importer 2000-07-31T21:11:00Z Jitterbug-Id: 36 Submitted-By: chenna@embl-heidelberg.de Date: Fri, 23 Jul 1999 06:51:43 -0400 (EDT) Version: 1.5.1 OS: OSF1 Hello I get Stack overflow: pid 14731, proc emparse1.py, addr 0x11fdfffd8, pc 0x120068cd8 Segmentation fault when I run the following. The problem is re module unable to search for the pattern that is too large, but this is a requirement for my application in biology. I enclose the source code with this. Please email me the solution as soon as possible Thanks Ramu ___________________________ #!/usr/pub/bin/python1.5 # # # # (C) Chenna Ramu, EMBL, Heidelberg, Germany # # parser for biological databases # import string import sys import re parserDict = { 'id' : r'((^ID [^\n]+\n)+)' , 'ac' : r'((^AC [^\n]+\n)+)' , 'dt' : r'((^DT [^\n]+\n)+)' , 'de' : r'((^DE [^\n]+\n)+)' , 'gn' : r'((^GN [^\n]+\n)+)' , 'os' : r'((^OS [^\n]+\n)+)' , 'oc' : r'((^OC [^\n]+\n)+)' , 'ref' : r'((' r'(^RN [^\n]+\n)' r'((^RP [^\n]+\n)+)' r'((^RX [^\n]+\n)?)' r'((^RA [^\n]+\n)+)' r'((^RT [^\n]+\n)*)' r'((^RL [^\n]+\n)+)' r')+)', 'cc' : r'((^CC [^\n]+\n)+)' , 'dr' : r'((^DR [^\n]+\n)+)' , 'kw' : r'((^KW [^\n]+\n)+)' , 'ft' : r'((^FT [^\n]+\n)+)' , 'sq' : r'(^SQ [^\n]+\n)' \ r'((^ [^\n]+\n)+)' } _hrefLink = {'embl':['<A href=%s>%s</A>','^DR ([^;]+)']} #should be like this hrefLink = {'EMBL':"<A href=http://www/wgetz?-e+[%s-id:%s]>%s</a>", 'MIM':"<A href=http://www/wgetz?-e+[%s-id:%s]>%s</a>"} em_rep = r'(^DR )(?P<dbase>[^;]+); (?P<id>[^;]+)' class embl: def __init__(self,parserDict={}): self.parserDict = {} self.reDict = {} #keep the compiled re's self.fields = [] if parserDict: self.Init(parserDict) def Init(self,parserDict): self.parserDict = parserDict self.fields = parserDict.keys() for j in self.fields: setattr(self, j, None) self.reDict[j] = re.compile(parserDict[j],re.MULTILINE) def Parse(self,str): if not self.parserDict: print "No parser specified" return for k,v in parserDict.items(): ## tmp = re.compile(v,re.MULTILINE) # move this to __init__ tmp = self.reDict[k] mat = tmp.search(str) if mat: setattr(self, k, mat.group() ) def Field(self,name): try: return getattr(self,name) except AttributeError: return None def PrintFields(self): flds = self.fields for j in flds: print "==> ",j print getattr(self,j) def ReParse(self,str,retToken,pat): """ str:string to parse, retToken:return token, pat:parser """ _p = re.compile(pat) m = _p.search(str) if m: return m.group(retToken) else: return None def Href(match): """ Replaces the hrefs """ dbase = match.group('dbase') id = match.group('id') try: defi = hrefLink[dbase] except KeyError: defi = None if defi: tmp = match.group(1) + dbase + '; '+defi %(dbase,id,id) else: tmp = match.group(1)+ dbase + '; ' + id return tmp def test(fileName): sys.path.insert(0,'/home/chenna/py') ## from seqFormat import * e = embl(parserDict) # f = open('acha_mouse.dat','r') f = open(fileName,'r') a = f.readlines() f.close() a = string.join(a,'') e.Parse(a) e.PrintFields() import string print ' the fields are ',e.fields ## seq = string.split(e.sq,';')[-1] ## s = Seq(seq,'test') ## print 'check===>',s.seq ## s.SeqPrint('swiss') seqLen = e.ReParse(e.sq[0:50],'seqLen',r'^SQ [^ ]+ *(?P<seqLen>(\d+))') print e.sq print "length of the sequence ",seqLen print e.ref dr = e.dr print dr p = re.compile(em_rep,re.M) dr = p.sub(Href,dr) print dr print e.Field('id') print e.Field('dr') print e.Field('mm') return def test1(dumm=None): tmp = ['SQ Sequence 1041931 BP; 8972 A; 5950 C; 6264 G; 8224 T; 0 other;\n'] for j in range(1,17365): t = ' ' + 'tcagtcagtg ' * 6 + '\n' tmp.append(t) a = string.join(tmp) e = embl(parserDict) e.Parse(a) e.PrintFields() if __name__ == '__main__': try: test1(sys.argv[1]) except: test1() ==================================================================== Audit trail: Sat Jul 24 16:53:53 1999 guido changed notes Sat Jul 24 16:53:53 1999 guido moved from incoming to open Sat Jul 24 17:04:17 1999 guido changed notes Thomas Wouters 2000-08-06T20:53:00Z Fair chance this is already fixed, either in 1.5.2 remodule, or in the new 'sre' by Fredrik. Maybe /F can say something useful here. Fredrik Lundh 2000-08-07T12:07:00Z It works fine under SRE, but bombs under PRE using a recent 2.0 build (tested on Windows). A.M. Kuchling 2000-08-18T20:37:00Z Boiled down test case: import string import pre as re pat = re.compile('(^ [^\n]+\n)+', re.MULTILINE) str = 17365 * ( ' ' + 'tcagtcagtg ' * 6 + '\n' ) pat.search( str ) The problem stems from nesting [^\n]+ inside a group that is then repeated. PCRE does a C recursion after matching [^\n]+, so on a long string the engine ends up nesting very deeply and filling the stack. With my knowledge of the engine, I see no way to rewrite the pattern to avoid this, so the program would have to be restructured to do its work differently. Not easily fixable without tearing PCRE apart; since SRE seems to survive this pattern, let's just count our blessings. :) 2000-07-31T21:12:00Z sf210665 Jitterbug-Id: 360 Submitted-By: philipp.jocham@salomon.at Date: Fri, 16 Jun 2000 08:47:06 -0400 (EDT) Version: 1.5.2 OS: HP-UX 11.00 There are two missing details in the configure process to make this work out of the box. First: The function pthread_create isn't found in library libpthread.a but in libcma.a, because pthread_create is just a macro in sys/pthread.h pointing to __pthread_create_system After patching ./configure directly and running ./configure --with-thread (now detecting the correct library /usr/lib/libpthread.a) I also added -lcl to Modules/Makefile at LIBS= -lnet -lnsl -ldld -lpthread -lcl otherwise importing of modules with threads didn't work (in this case oci_.sl from DCOracle). I'm not sure about the correct syntax or wether it's the correct place and method, but I would suggest a solution like the following code snippet. [...] AC_MSG_CHECKING(for --with-thread) [...] AC_DEFINE(_POSIX_THREADS) LIBS="$LIBS -lpthread -lcl" LIBOBJS="$LIBOBJS thread.o"], [ AC_CHECK_LIB(pthread, __pthread_create_system, [AC_DEFINE(WITH_THREAD) [...] I hope this helps to make installation process smoother. Fell free to contact me, if there are further questions. Philipp -- I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. ==================================================================== Audit trail: Tue Jul 11 08:26:01 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM platform-specific Martin von Löwis threads Bug Importer Bug Importer 2000-07-31T21:12:00Z Jitterbug-Id: 360 Submitted-By: philipp.jocham@salomon.at Date: Fri, 16 Jun 2000 08:47:06 -0400 (EDT) Version: 1.5.2 OS: HP-UX 11.00 There are two missing details in the configure process to make this work out of the box. First: The function pthread_create isn't found in library libpthread.a but in libcma.a, because pthread_create is just a macro in sys/pthread.h pointing to __pthread_create_system After patching ./configure directly and running ./configure --with-thread (now detecting the correct library /usr/lib/libpthread.a) I also added -lcl to Modules/Makefile at LIBS= -lnet -lnsl -ldld -lpthread -lcl otherwise importing of modules with threads didn't work (in this case oci_.sl from DCOracle). I'm not sure about the correct syntax or wether it's the correct place and method, but I would suggest a solution like the following code snippet. [...] AC_MSG_CHECKING(for --with-thread) [...] AC_DEFINE(_POSIX_THREADS) LIBS="$LIBS -lpthread -lcl" LIBOBJS="$LIBOBJS thread.o"], [ AC_CHECK_LIB(pthread, __pthread_create_system, [AC_DEFINE(WITH_THREAD) [...] I hope this helps to make installation process smoother. Fell free to contact me, if there are further questions. Philipp -- I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. ==================================================================== Audit trail: Tue Jul 11 08:26:01 2000 guido moved from incoming to open Jeremy Hylton 2000-09-07T22:05:00Z Please do triage on this bug. Guido van Rossum 2000-09-22T09:56:00Z Taking this because I'm considering to redesign the thread configuration section in configure.in anyway -- there's a similar bug report for Alpha OSF1. Guido van Rossum 2000-09-25T13:10:00Z I'm hoping that this was fixed by recent changes. Sent an email to the original submittor to verify. Guido van Rossum 2000-10-06T17:40:00Z I have two reports from people for whom configure, build and run with threads now works on HP-UX 10 and 11. I'm not sure what to do about this report... What's different on Philipp's system??? Edg-users 2000-10-10T11:55:00Z I can confirm that the bug still exists in 2.0c1. It works fine on HP-UX 10.20 (which only has libcma), but not on HP-UX 11 (which both has libcma and libpthread). The pthread_create function is not defined as a macro though, but as a static function: static int pthread_create(pthread_t *tid, const pthread_attr_t *attr, void *(*start_routine)(void *), void *arg) { return(__pthread_create_system(tid, attr, start_routine, arg)); } I don't see an easy way to work around this. I'm not a configure expert, but perhaps the script should first check whether this code compiles and links: #include <pthread.h> int main() { pthread_create(0,0,0,0); return 0; } and if not, fall back on the other tests ? Guido van Rossum 2000-10-13T14:45:00Z OK, so the correct thing to do seems to be to somehow add #include <pthread.h> to the tests for thread libraries. I'm afraid I won't be able to fix this in 2.0final, but I'll think about fixing it in 2.1 (or 2.0.1, whichever comes first :-). Guido van Rossum 2000-10-30T17:48:00Z Philipp submitted a patch to configure.in that fixes the problem for him and doesn't look like it would break things for others. configure.in, CVS revision 1.175. Bug Importer 2000-11-01T17:18:00Z Ick! Why check for anything with __ prepended to the name? Isn't that like checking for a "hidden" function, which might not be there in a followup version? On HP-UX 11.00, pthread_create is in /usr/lib/libc.sl anyway. The proper way to check for pthread_create is: AC_TRY_LINK([#include <pthread.h> void * start_routine (void *arg) { exit (0); }], [ pthread_create (NULL, NULL, start_routine, NULL)], [ AC_MSG_RESULT(yes)], [ AC_MSG_RESULT(no)]) I modified configure.in in 2.0 to remove the patch you included in CVS 1.175 and added a test to include <pthread.h> similar to the above (linked without -lpthread and with -lpthread). I'm testing now. Will provide a patch when things are tested. Also, I don't think threads on HP-UX 10.20 will work unless you have the DCE libraries installed. Anyhow, I'd probably avoid threads on 10.20. Bug Importer 2000-11-02T15:25:00Z Ok, check out the configure.in patch I created against Python 2.0: ftp://ftp.thewrittenword.com/outgoing/pub/python-2.0.patch I tested it under HP-UX 11.00 and it works just fine. The thread test worked too. -- albert chin (china@thewrittenword.com) Guido van Rossum 2000-11-02T16:38:00Z Reopened because there's a dissenting opinion. Tww-china 2001-05-07T05:36:00Z You can find a patch to fix this against python 2.1 at: ftp://ftp.thewrittenword.com/outgoing/pub/python-2.1-416696.patch You'll need to rerun autoconf to test. Rptownsend 2001-06-14T08:20:00Z I applied the patch from thewrittenword's site, but when I ran autoconf it generated a corrupt configure script. There problem occurs around lines 3895-3906: if test "$USE_THREAD_MODULE" != "#" then # If the above checks didn't disable threads, (at least) OSF1 # needs this '-threads' argument during linking. case $ac_sys_system in OSF1 fi LDLAST=-threads;; esac fi fi fi The case statement has been trashed by the extra 'fi' token. I tried manually editing it like this: if test "$USE_THREAD_MODULE" != "#" then # If the above checks didn't disable threads, (at least) OSF1 # needs this '-threads' argument during linking. case $ac_sys_system in OSF1) LDLAST=-threads;; esac fi fi fi But it still fails with an 'else' not matched at line 3422. I can't see where the extra 'fi' should go. Rptownsend 2001-06-19T10:07:00Z I have now applied the new patch file 'python-2.1.patch' available at: ftp://ftp.thewrittenword.com/outgoing/pub I can now successfully build Python 2.1 with threads enabled, on HP-UX 11. Guido van Rossum 2001-07-27T15:37:00Z For all of those in search for an easy solution: HP makes binaries available. See http://hpux.connect.org.uk/hppd/hpux/Languages/python-2.1/ Guido van Rossum 2001-07-27T17:31:00Z Alas, not. Those binaries don't have threads enabled. HP doesn't know how to do it either. Guido van Rossum 2001-08-07T19:26:00Z Closing this for lack of progress. If someone figures out what to do with threads on HPUX-11, please submit a fresh *patch*. Rptownsend 2001-08-08T12:44:00Z On the 19th June I posted a comment here ref the patch file: 'python-2.1.patch' from ftp://ftp.thewrittenword.com/outgoing/pub After applying this patch to Python 2.1 source, I successfully built a Python interpreter on HP-UX 11.0 with threads enabled. (I have tested it with several examples from Mark Lutz's book using the thread and threading modules and it works fine). Is there some reason why you do not accept this patch ? It would be really useful if this fix could be included for Python 2.2 :-) Guido van Rossum 2001-08-08T14:56:00Z Actually, now that you mention it, yes, there's a reason not to accept that patch (which I hadn't seen before -- sorry). It appears to be patching tons of unrelated things, and some of the diffs in it appear to be diffs between different Python versions. Also, it patches configure instead of configure.in. configure is a generated file. Ditto for config.h.in. In other words, that patch may fix your problem, but I can't check it in. Perhaps you could work on a *minimal* patch that solves the problem, and which works with the current CVS (or at least the 2.2a1 release). Then I'll look again. Since you show interest in doing this, I've reopened the bug report. Tww-china 2001-08-08T15:11:00Z I'd rather see a new configure option, --with-cma-threads, similar to --with-dec-threads, to enable the CMA thread support for HP-UX 10.20. We'll try to work on a configure.in patch against CVS for HP-UX 11.00. Tww-china 2001-10-04T06:22:00Z Ok, new patch against HEAD (2.2) at ftp://ftp.thewrittenword.com/outgoing/pub/python-210665.patch. BTW, I've axed the addition of determining if "cc -Kpthread" works. This is gross. Worst case, add it after all of the other pthread checks. The HP-UX C compiler will link a test program with -Kpthread. It'll just issue a warning. I see you've made an exception to setting ac_cv_kpthread if the compiler is GCC. Ick! The IBM C compiler also issues a warning about -Kpthread but compiles the test program. The Sun, Compaq, and SGI compilers do error out though. With this patch, test_thread succeeds. Guido van Rossum 2001-10-04T15:23:00Z I'm assigning this to Martin, since he checked in the code that tests for -Kpthread, mentioning Patch #418659: Fixes for UnixWare and ReliantUnix. Martin von Löwis 2001-10-04T23:08:00Z Just taking out the -Kpthread test is not acceptable. It will mean that thread support will break systems that require it. Likewise, taking it as a fallback will fail on the very same system. Some of those systems (e.g. UnixWare) do provide a libpthread and a pthread_create function within, but the documentation explicitly says that you must not use -lpthread. So we *must* use -Kpthread were available. What exactly is the problem on HP/UX? If the compiler links the test program, why don't threads work then? Can you give a C program that shows that threads are not available when just passing -Kpthread? I agree that special-casing gcc is a hack, but what I need is a solution, not removal of the existing feature. Also, what exact problem is solved with your change "for pthread_create in -lpthread": Why do you need a test program; why is AC_CHECK_LIB not good enough? Tww-china 2001-10-04T23:23:00Z Well, when -Kpthread was introduced, it should not have caused a regression on an existing solution. It breaks HP-UX 11.00 (not that it worked before though). And, it will break AIX. The problem is that: $ cc foo.c -Kpthread *will* generate an a.out that is executable. The compiler just complains about invalid options: cc: warning 422: Unknown option "K" ignored. cc: error 1400: Option t usage: -t c,name where c may be 1 or more of pc0al. Ditto for the IBM xlc compiler: $ xlc foo.c -Kpthread xlc: 1501-210 command option t contains an incorrect subargument So, the test for -Kpthread has to be more robust. Regarding AC_CHECK_LIB for pthread_create, the following will not work: AC_CHECK_LIB(pthread, pthread_create) By doing this, you mistakenly assume that pthread_create() equates to an entry in libpthread named pthread_create. This is not true on HP-UX 11.00 (nor Tru64 UNIX). The header file <pthread.h> on HP-UX 11.00 includes <sys/pthread.h> which has pthread_create() equating to __pthread_create_system. By using the method I posted, we workaround whatever semantics the system uses to provide pthread_create. I will try to work up a solution for -Kpthread. Can I get access to a UnixWare system to test? Martin von Löwis 2001-10-05T15:21:00Z I still don't see the breakage on AIX. The compiler will complain about the option; ok. If the binary is executable (and really uses threads), what is the problem? In any case, if you come up with an improved test, I can try it out. On the pthread_create change: +1. I'd like to see a comment on why you need to link there, though. Tww-china 2001-10-05T17:13:00Z Well, when -Kpthread was introduced, it should not have caused a regression on an existing solution. It breaks HP-UX 11.00 (not that it worked before though). And, it will break AIX. The problem is that: $ cc foo.c -Kpthread *will* generate an a.out that is executable. The compiler just complains about invalid options: cc: warning 422: Unknown option "K" ignored. cc: error 1400: Option t usage: -t c,name where c may be 1 or more of pc0al. Ditto for the IBM xlc compiler: $ xlc foo.c -Kpthread xlc: 1501-210 command option t contains an incorrect subargument So, the test for -Kpthread has to be more robust. Regarding AC_CHECK_LIB for pthread_create, the following will not work: AC_CHECK_LIB(pthread, pthread_create) By doing this, you mistakenly assume that pthread_create() equates to an entry in libpthread named pthread_create. This is not true on HP-UX 11.00 (nor Tru64 UNIX). The header file <pthread.h> on HP-UX 11.00 includes <sys/pthread.h> which has pthread_create() equating to __pthread_create_system. By using the method I posted, we workaround whatever semantics the system uses to provide pthread_create. I will try to work up a solution for -Kpthread. Can I get access to a UnixWare system to test? Martin von Löwis 2001-10-08T13:21:00Z I have now made the -Kpthread more robust by running a program; this allows to remove the gcc check (atleast for Linux and Solaris). The same check should work on all systems that require special options for pthread support; please confirm whether it solves the AIX problem. I've also applied your patch to check pthread_create linkage through including pthread.h; please report whether configuration now succeeds on HP/UX. Martin von Löwis 2001-10-24T17:20:00Z According to Richard Townsend, the core of this problem has been fixed in the CVS. The last related check-in was configure.in 1.268. 2000-07-31T21:12:00Z sf210666 Jitterbug-Id: 361 Submitted-By: cfandrich@8cs.com Date: Fri, 16 Jun 2000 20:08:33 -0400 (EDT) Version: 1.5.2 OS: Windows I'm embedding Python in an application. For now, all I'm doing is initializing and finalizing Python. When I run my app I get a memory leak of 12288 bytes. The memory is malloc'ed by dictresize() which is called by PyDict_SetItem() which is called by PyString_InternInPlace(). For now, I've added PyDict_Clear(interned); interned = NULL; to PyString_Fini(). So far it works fine, but I don't know if it's safe to do in the grand scheme of things. -Chris ==================================================================== Audit trail: Tue Jul 11 08:26:01 2000 guido moved from incoming to open Bug Importer REJECTED LOW Guido van Rossum Bug Importer Bug Importer 2000-07-31T21:12:00Z Jitterbug-Id: 361 Submitted-By: cfandrich@8cs.com Date: Fri, 16 Jun 2000 20:08:33 -0400 (EDT) Version: 1.5.2 OS: Windows I'm embedding Python in an application. For now, all I'm doing is initializing and finalizing Python. When I run my app I get a memory leak of 12288 bytes. The memory is malloc'ed by dictresize() which is called by PyDict_SetItem() which is called by PyString_InternInPlace(). For now, I've added PyDict_Clear(interned); interned = NULL; to PyString_Fini(). So far it works fine, but I don't know if it's safe to do in the grand scheme of things. -Chris ==================================================================== Audit trail: Tue Jul 11 08:26:01 2000 guido moved from incoming to open Bug Importer 2000-08-01T21:01:00Z From: "M.-A. Lemburg" <mal@lemburg.com> Subject: Re: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361) Date: Sat, 17 Jun 2000 10:53:20 +0200 cfandrich@8cs.com wrote: > > Full_Name: Christopher Fandrich > Version: 1.5.2 > OS: Windows > Submission from: (NULL) (208.41.174.4) > > I'm embedding Python in an application. For now, all I'm doing is initializing > and finalizing Python. > > When I run my app I get a memory leak of 12288 bytes. The memory is malloc'ed > by dictresize() which is called by PyDict_SetItem() which is called by > PyString_InternInPlace(). > > For now, I've added > PyDict_Clear(interned); > interned = NULL; > to PyString_Fini(). So far it works fine, but I don't know if it's safe to do > in the grand scheme of things. I would suggest adding code to dealloc the interned dict iff it is empty after the sweeping action in PyString_Fini(). I have a feeling that this is not the case though, since interned strings are used quite a lot in the core interpreter (e.g. in classobject.c) and these are usually not recovered. Perhaps we ought to add some code which takes care of cleaning up all remaining garbage left over after the call to call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing of all interned strings and cached ints/floats and associated free lists or dicts. We'd need new APIs in string|float|intobject.c to implement this. Thoughts ? Patches ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ Jeremy Hylton 2000-09-07T22:04:00Z Please do triage on this bug. Guido van Rossum 2000-09-13T10:26:00Z You shouldn't worry about this memory leak. The interned dict is shared by all interpreters and it's not safe to clear it. If you repeatedly initialize and finalize Python, you shouldn't see the memory leak increase. (What leak detection tool do you use anyway? Since the interned dict is still accessible through a global, it shouldn't be called a leak!) 2000-07-31T21:12:00Z sf210667 Jitterbug-Id: 365 Submitted-By: r32813@email.sps.mot.com Date: Wed, 21 Jun 2000 12:00:54 -0400 (EDT) Version: 1.5.2 OS: AIX 4.3.1 The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when this command was run:- select.select(waitList, [], [], timeWait) This command worked fine in Python 1.5.1 build and also fine on Python 1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on 2 AIX machines that we have. ==================================================================== Audit trail: Tue Jul 11 08:24:19 2000 guido moved from incoming to open Bug Importer REJECTED MEDIUM platform-specific A.M. Kuchling extension-modules Bug Importer Bug Importer 2000-07-31T21:12:00Z Jitterbug-Id: 365 Submitted-By: r32813@email.sps.mot.com Date: Wed, 21 Jun 2000 12:00:54 -0400 (EDT) Version: 1.5.2 OS: AIX 4.3.1 The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when this command was run:- select.select(waitList, [], [], timeWait) This command worked fine in Python 1.5.1 build and also fine on Python 1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on 2 AIX machines that we have. ==================================================================== Audit trail: Tue Jul 11 08:24:19 2000 guido moved from incoming to open Bug Importer 2000-08-01T21:01:00Z From: Guido van Rossum <guido@python.org> Subject: Re: [Python-bugs-list] select module: Bug in select.select() (PR#365) Date: Fri, 23 Jun 2000 11:01:40 -0500 > Below is the dbx information from the coredump. This only occurs when the > select.select() function is used within a thread. This same error occurs on > both Python 1.5.1 and Python 1.5.2 when AIX 4.3.1. This problem does not > occur on AIX 4.1.4. > > $ dbx -I ./Modules ./python core > Type 'help' for help. > reading symbolic information ... > [using memory image in core] > > Segmentation fault in initselect at line 235 in file "Modules/selectmodule.c" > ($t2) > 235 PyObject *tout = Py_None; Thanks. Could you do this again and also type the "bt" (backtrace) command? That would perhaps be more helpful. We can't reproduce this here since we don't have access to AIX! (Even if we ha,d it would be low priority :-( ). --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-08-01T21:01:00Z From: "Wahmeng Wong" <r32813@email.sps.mot.com> Subject: Re: [Python-bugs-list] select module: Bug in select.select() (PR#365) Date: Thu, 22 Jun 2000 19:02:11 -0700 This is a multi-part message in MIME format. --------------F9E74BCE6963FE221E423528 Content-Type: multipart/alternative; boundary="------------FF8E270086909CA1DBDDA697" --------------FF8E270086909CA1DBDDA697 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Guido, Below is the dbx information from the coredump. This only occurs when the select.select() function is used within a thread. This same error occurs on both Python 1.5.1 and Python 1.5.2 when AIX 4.3.1. This problem does not occur on AIX 4.1.4. $ dbx -I ./Modules ./python core Type 'help' for help. reading symbolic information ... [using memory image in core] Segmentation fault in initselect at line 235 in file "Modules/selectmodule.c" ($t2) 235 PyObject *tout = Py_None; We have been able to reproduce the coredump by modifying the test_select.py to perform the test within a thread. Attached is the modified file called test_thread_select.py. Just place this file in the Lib/test directory to see this problem. Thanks for all your help. Regards, Wah Meng Guido van Rossum wrote: > > The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when > > this command was run:- > > > > select.select(waitList, [], [], timeWait) > > > > This command worked fine in Python 1.5.1 build and also fine on Python > > 1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on > > 2 AIX machines that we have. > > Could you give us some more information? You're indicating that it's > platform specific; we don't have an AIX box. I'm guessing it's not > obvious that our code is wrong, but it may violate some guidelines > given by AIX manuals. If we ever want to fix this, we'll need to > interact with you. the first thing we need is a decent stack trace; > we'll take it from there. > > If you could investigate this on your own and come up with a fix, that > would probably the best solution... > > --Guido van Rossum (home page: http://www.python.org/~guido/) --------------FF8E270086909CA1DBDDA697 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Hi Guido, <p>Below is the dbx information from the coredump. This only occurs when the select.select() function is used within a thread. This same error occurs on both Python 1.5.1 and Python 1.5.2 when AIX 4.3.1. This problem does not occur on AIX 4.1.4. <p><tt>$ dbx -I ./Modules ./python core</tt> <br><tt>Type 'help' for help.</tt> <br><tt>reading symbolic information ...</tt> <br><tt>[using memory image in core]</tt><tt></tt> <p><tt>Segmentation fault in initselect at line 235 in file "Modules/selectmodule.c" ($t2)</tt> <br><tt>&nbsp; 235&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PyObject *tout = Py_None;</tt> <p>We have been able to reproduce the coredump by modifying the test_select.py to perform the test within a thread. Attached is the modified file called test_thread_select.py. Just place this file in the Lib/test directory to see this problem. <p>Thanks for all your help. <p>Regards, <br>Wah Meng <p>Guido van Rossum wrote: <blockquote TYPE=CITE>>&nbsp; The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when <br>>&nbsp; this command was run:- <br>> <br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; select.select(waitList, [], [], timeWait) <br>> <br>>&nbsp; This command worked fine in Python 1.5.1 build and also fine on Python <br>>&nbsp; 1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on <br>>&nbsp; 2 AIX machines that we have. <p>Could you give us some more information?&nbsp; You're indicating that it's <br>platform specific; we don't have an AIX box.&nbsp; I'm guessing it's not <br>obvious that our code is wrong, but it may violate some guidelines <br>given by AIX manuals.&nbsp; If we ever want to fix this, we'll need to <br>interact with you.&nbsp; the first thing we need is a decent stack trace; <br>we'll take it from there. <p>If you could investigate this on your own and come up with a fix, that <br>would probably the best solution... <p>--Guido van Rossum (home page: <a href="http://www.python.org/~guido/">http://www.python.org/~guido/</a>)</blockquote> </html> --------------FF8E270086909CA1DBDDA697-- --------------F9E74BCE6963FE221E423528 Content-Type: application/x-unknown-content-type-Python.File; name="test_thread_select.py" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="test_thread_select.py" IyBUZXN0aW5nIHNlbGVjdCBtb2R1bGUNCmZyb20gdGVzdF9zdXBwb3J0IGltcG9ydCB2ZXJi b3NlDQppbXBvcnQgc2VsZWN0LCB0aHJlYWQsIFF1ZXVlDQppbXBvcnQgb3MNCg0KIyB0ZXN0 IHNvbWUga25vd24gZXJyb3IgY29uZGl0aW9ucw0KdHJ5Og0KICAgIHJmZCwgd2ZkLCB4ZmQg PSBzZWxlY3Quc2VsZWN0KDEsIDIsIDMpDQpleGNlcHQgVHlwZUVycm9yOg0KICAgIHBhc3MN CmVsc2U6DQogICAgcHJpbnQgJ2V4cGVjdGVkIFR5cGVFcnJvciBleGNlcHRpb24gbm90IHJh aXNlZCcNCg0KY2xhc3MgTm9wZToNCiAgICBwYXNzDQoNCmNsYXNzIEFsbW9zdDoNCiAgICBk ZWYgZmlsZW5vKHNlbGYpOg0KICAgICAgICByZXR1cm4gJ2ZpbGVubycNCiAgICANCnRyeToN CiAgICByZmQsIHdmZCwgeGZkID0gc2VsZWN0LnNlbGVjdChbTm9wZSgpXSwgW10sIFtdKQ0K ZXhjZXB0IFR5cGVFcnJvcjoNCiAgICBwYXNzDQplbHNlOg0KICAgIHByaW50ICdleHBlY3Rl ZCBUeXBlRXJyb3IgZXhjZXB0aW9uIG5vdCByYWlzZWQnDQoNCnRyeToNCiAgICByZmQsIHdm ZCwgeGZkID0gc2VsZWN0LnNlbGVjdChbQWxtb3N0KCldLCBbXSwgW10pDQpleGNlcHQgVHlw ZUVycm9yOg0KICAgIHBhc3MNCmVsc2U6DQogICAgcHJpbnQgJ2V4cGVjdGVkIFR5cGVFcnJv ciBleGNlcHRpb24gbm90IHJhaXNlZCcNCg0KDQpkZWYgdGVzdChxKToNCiAgICAgICAgaW1w b3J0IHN5cw0KICAgICAgICBpZiBzeXMucGxhdGZvcm1bOjNdIGluICgnd2luJywgJ21hYycs ICdvczInKToNCiAgICAgICAgICAgICAgICBpZiB2ZXJib3NlOg0KICAgICAgICAgICAgICAg ICAgICAgICAgcHJpbnQgIkNhbid0IHRlc3Qgc2VsZWN0IGVhc2lseSBvbiIsIHN5cy5wbGF0 Zm9ybQ0KICAgICAgICAgICAgICAgIHJldHVybg0KICAgICAgICBjbWQgPSAnZm9yIGkgaW4g MCAxIDIgMyA0IDUgNiA3IDggOTsgZG8gZWNobyB0ZXN0aW5nLi4uOyBzbGVlcCAxOyBkb25l Jw0KICAgICAgICBwID0gb3MucG9wZW4oY21kLCAncicpDQogICAgICAgIGZvciB0b3V0IGlu ICgwLCAxLCAyLCA0LCA4LCAxNikgKyAoTm9uZSwpKjEwOg0KICAgICAgICAgICAgICAgIGlm IHZlcmJvc2U6DQogICAgICAgICAgICAgICAgICAgICAgICBwcmludCAndGltZW91dCA9Jywg dG91dA0KICAgICAgICAgICAgICAgIHJmZCwgd2ZkLCB4ZmQgPSBzZWxlY3Quc2VsZWN0KFtw XSwgW10sIFtdLCB0b3V0KQ0KIyMgICAgICAgICAgICAgIHByaW50IHJmZCwgd2ZkLCB4ZmQN CiAgICAgICAgICAgICAgICBpZiAocmZkLCB3ZmQsIHhmZCkgPT0gKFtdLCBbXSwgW10pOg0K ICAgICAgICAgICAgICAgICAgICAgICAgY29udGludWUNCiAgICAgICAgICAgICAgICBpZiAo cmZkLCB3ZmQsIHhmZCkgPT0gKFtwXSwgW10sIFtdKToNCiAgICAgICAgICAgICAgICAgICAg ICAgIGxpbmUgPSBwLnJlYWRsaW5lKCkNCiAgICAgICAgICAgICAgICAgICAgICAgIGlmIHZl cmJvc2U6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByaW50IGBsaW5lYA0K ICAgICAgICAgICAgICAgICAgICAgICAgaWYgbm90IGxpbmU6DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGlmIHZlcmJvc2U6DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcHJpbnQgJ0VPRicNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgYnJlYWsNCiAgICAgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlDQogICAgICAg ICAgICAgICAgcHJpbnQgJ0hlaD8nDQogICAgICAgIHAuY2xvc2UoKQ0KICAgICAgICBxLnB1 dCgxKQ0KDQoNCnEgPSBRdWV1ZS5RdWV1ZSgxKQ0KdGhyZWFkLnN0YXJ0X25ld190aHJlYWQo dGVzdCwocSwpKQ0KI3dhaXQgZm9yIHRocmVhZCB0byBjb21wbGV0ZSB0ZXN0IGZ1bmN0aW9u DQpkb25lID0gcS5nZXQoKQ0KcHJpbnQgJ3RocmVhZCBjb21wbGV0ZWQgdGVzdCwgZXhpdGlu ZycNCg0K --------------F9E74BCE6963FE221E423528-- Bug Importer 2000-08-01T21:01:00Z From: Guido van Rossum <guido@python.org> Subject: Re: [Python-bugs-list] select module: Bug in select.select() (PR#365) Date: Wed, 21 Jun 2000 17:08:33 -0500 > The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when > this command was run:- > > select.select(waitList, [], [], timeWait) > > This command worked fine in Python 1.5.1 build and also fine on Python > 1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on > 2 AIX machines that we have. Could you give us some more information? You're indicating that it's platform specific; we don't have an AIX box. I'm guessing it's not obvious that our code is wrong, but it may violate some guidelines given by AIX manuals. If we ever want to fix this, we'll need to interact with you. the first thing we need is a decent stack trace; we'll take it from there. If you could investigate this on your own and come up with a fix, that would probably the best solution... --Guido van Rossum (home page: http://www.python.org/~guido/) Tim Peters 2000-09-23T04:55:00Z Just putting the fellow's test_thread_select.py here as plain text (it's given only as base64 below): # Testing select module from test_support import verbose import select, thread, Queue import os # test some known error conditions try: rfd, wfd, xfd = select.select(1, 2, 3) except TypeError: pass else: print 'expected TypeError exception not raised' class Nope: pass class Almost: def fileno(self): return 'fileno' try: rfd, wfd, xfd = select.select([Nope()], [], []) except TypeError: pass else: print 'expected TypeError exception not raised' try: rfd, wfd, xfd = select.select([Almost()], [], []) except TypeError: pass else: print 'expected TypeError exception not raised' def test(q): import sys if sys.platform[:3] in ('win', 'mac', 'os2'): if verbose: print "Can't test select easily on", sys.platform return cmd = 'for i in 0 1 2 3 4 5 6 7 8 9; do echo testing...; sleep 1; done' p = os.popen(cmd, 'r') for tout in (0, 1, 2, 4, 8, 16) + (None,)*10: if verbose: print 'timeout =', tout rfd, wfd, xfd = select.select([p], [], [], tout) ## print rfd, wfd, xfd if (rfd, wfd, xfd) == ([], [], []): continue if (rfd, wfd, xfd) == ([p], [], []): line = p.readline() if verbose: print `line` if not line: if verbose: print 'EOF' break continue print 'Heh?' p.close() q.put(1) q = Queue.Queue(1) thread.start_new_thread(test,(q,)) #wait for thread to complete test function done = q.get() print 'thread completed test, exiting' A.M. Kuchling 2000-09-28T22:21:00Z It seems impossible to reproduce this without actually having an AIX box, and IBM has no equivalent of Compaq's test drive, unfortunately. At first blush, it's difficult to come up with a hypothesis; why would the *tout = Py_None line cause a segfault? Perhaps a refcounting bug decreased the RC of _Py_None_struct to 0 and caused it to be deallocated, but that shouldn't crash on that line of code. I'm going to mark this "Works for Me", pending further reports from the original submitter, or from anyone else. Bug Importer 2002-01-04T05:05:00Z this appears to be a stack problem, which would explain the mysterious backtrace. on AIX (4.3.3), the FD_SETSIZE is 32k, so at 12 bytes per array and 3 arrays of 32k, that is a little over 1Mb on the stack. there is already some code to handle this for Windows, so adding an additional check for AIX should fix the problem. of course it would be nicer for a solution that didn't need to allocate and free all that memory every time select is called. Guido van Rossum 2002-01-04T05:15:00Z Try Python 2.2. This allocates the sets on the heap if FS_SETSIZE is > 1024 regardless of platform. If you want a less memory-intensive solution, try poll(). 2000-07-31T21:12:00Z sf210668 Jitterbug-Id: 366 Submitted-By: rob.hathaway@freeuk.com Date: Fri, 23 Jun 2000 06:31:51 -0400 (EDT) Version: 1.6 OS: windows All, I recently loaded the latest (1.6) version of Python onto my PC (running win95). I then loaded wxPython on top and attempted to run the demo from the command line (python demo.py) while in the wxPython demo directory. The following error message was issued: Fatal Python Error: PyThreadStateGet: No Current Thread. I then reloaded 1.5.2 and wxPython and the demo runs fine. I then loaded 1.6 onto a win98 and win2k OS and attempted to run the wxPython demo again always with the same result. ==================================================================== Audit trail: Tue Jul 11 08:24:19 2000 guido moved from incoming to open Bug Importer REJECTED MEDIUM platform-specific windows Bug Importer Bug Importer 2000-07-31T21:12:00Z Jitterbug-Id: 366 Submitted-By: rob.hathaway@freeuk.com Date: Fri, 23 Jun 2000 06:31:51 -0400 (EDT) Version: 1.6 OS: windows All, I recently loaded the latest (1.6) version of Python onto my PC (running win95). I then loaded wxPython on top and attempted to run the demo from the command line (python demo.py) while in the wxPython demo directory. The following error message was issued: Fatal Python Error: PyThreadStateGet: No Current Thread. I then reloaded 1.5.2 and wxPython and the demo runs fine. I then loaded 1.6 onto a win98 and win2k OS and attempted to run the wxPython demo again always with the same result. ==================================================================== Audit trail: Tue Jul 11 08:24:19 2000 guido moved from incoming to open Bug Importer 2000-08-01T21:01:00Z From: "Mark Hammond" <mhammond@skippinet.com.au> Subject: RE: [Python-bugs-list] Python1.6 and wxPython incompatibility (PR#366) Date: Fri, 23 Jun 2000 23:31:57 +1000 Im afraid this is simply a symptom of a Python extension built for Python 1.5 being loaded with 1.6. You have no choice other than to wait for a Python 1.6 specific version of wxPython. Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > rob.hathaway@freeuk.com > Sent: Friday, 23 June 2000 8:32 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] Python1.6 and wxPython incompatibility > (PR#366) > > > Full_Name: Rob Hathaway > Version: 1.6 > OS: windows > Submission from: sot-mod08.interalpha.net (195.26.225.8) > > > All, > I recently loaded the latest (1.6) version of Python onto my > PC (running > win95). I then loaded wxPython on top and attempted to run the > demo from the > command line (python demo.py) while in the wxPython demo directory. The > following error message was issued: Fatal Python Error: > PyThreadStateGet: No > Current Thread. > I then reloaded 1.5.2 and wxPython and the demo runs fine. I > then loaded 1.6 > onto a win98 and win2k OS and attempted to run the wxPython demo > again always > with the same result. > > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > Thomas Wouters 2000-08-05T21:43:00Z This bug is likely to stay, at least for a while. Python 1.6 will have a more obvious error message, but that won't change things until you upgrade from 1.6 to 2.0. 2000-07-31T21:12:00Z sf210669 Jitterbug-Id: 368 Submitted-By: rozen@rgv.hp.com Date: Fri, 23 Jun 2000 15:31:19 -0400 (EDT) Version: 1.5.2 OS: Linux With Tcl/Tk, bind tag sequence returns the string which is the command. With Python, widget.bind('sequence') seems to return a reference to the command not the command. The following reproduces the problem on my machine. Try running the file and observe the print output. Pretty strange. #! /usr/bin/env python from Tkinter import * root = Tk() def init(): pass def greeting(str): import Dialog Dialog.Dialog(title="greetings", text=str, bitmap="",default=0,strings=("cont",)) class New_Toplevel_1: def __init__(self, master=None): self.ent17 = Entry (master) self.ent17.place(in_=master,x=45,y=50) self.ent17.configure(background="plum") self.ent17.configure(font="helvetica 14 bold") self.ent17.configure(foreground="black") self.ent17.configure(insertbackground="black") self.ent17.configure(selectbackground="black") self.ent17.configure(selectforeground="ivory") self.hello = StringVar() self.ent17.configure(textvariable=self.hello) self.ent17.configure(width="35") self.ent17.bind('q',lambda e: greeting('q')) x = self.ent17.bind() print 'x =', x x = self.ent17.bind('q') print 'x =', x # I expected x to be "lambda e: greeting('q')" # I actually got the following # x = set _tkinter_break [135926416<lambda> %# %b %f %h %k %s %t %w %x %y %A %E %K %N %W %T %X %Y] # if {"$_tkinter_break" == "break"} break def vp_start_gui(): global w root.title('New_Toplevel_1') root.geometry('500x200+216+41') root.configure(bg='wheat') w = New_Toplevel_1 (root) root.mainloop() if __name__ == '__main__': vp_start_gui() ==================================================================== Audit trail: Tue Jul 11 08:24:20 2000 guido moved from incoming to open Bug Importer REJECTED MEDIUM not-a-bug tkinter Bug Importer Bug Importer 2000-07-31T21:12:00Z Jitterbug-Id: 368 Submitted-By: rozen@rgv.hp.com Date: Fri, 23 Jun 2000 15:31:19 -0400 (EDT) Version: 1.5.2 OS: Linux With Tcl/Tk, bind tag sequence returns the string which is the command. With Python, widget.bind('sequence') seems to return a reference to the command not the command. The following reproduces the problem on my machine. Try running the file and observe the print output. Pretty strange. #! /usr/bin/env python from Tkinter import * root = Tk() def init(): pass def greeting(str): import Dialog Dialog.Dialog(title="greetings", text=str, bitmap="",default=0,strings=("cont",)) class New_Toplevel_1: def __init__(self, master=None): self.ent17 = Entry (master) self.ent17.place(in_=master,x=45,y=50) self.ent17.configure(background="plum") self.ent17.configure(font="helvetica 14 bold") self.ent17.configure(foreground="black") self.ent17.configure(insertbackground="black") self.ent17.configure(selectbackground="black") self.ent17.configure(selectforeground="ivory") self.hello = StringVar() self.ent17.configure(textvariable=self.hello) self.ent17.configure(width="35") self.ent17.bind('q',lambda e: greeting('q')) x = self.ent17.bind() print 'x =', x x = self.ent17.bind('q') print 'x =', x # I expected x to be "lambda e: greeting('q')" # I actually got the following # x = set _tkinter_break [135926416<lambda> %# %b %f %h %k %s %t %w %x %y %A %E %K %N %W %T %X %Y] # if {"$_tkinter_break" == "break"} break def vp_start_gui(): global w root.title('New_Toplevel_1') root.geometry('500x200+216+41') root.configure(bg='wheat') w = New_Toplevel_1 (root) root.mainloop() if __name__ == '__main__': vp_start_gui() ==================================================================== Audit trail: Tue Jul 11 08:24:20 2000 guido moved from incoming to open Bug Importer 2000-08-01T21:01:00Z From: Guido van Rossum <guido@python.org> Subject: Re: [Python-bugs-list] Tkinter: widget.bind('sequence') incorrect (PR#368) Date: Fri, 23 Jun 2000 15:46:04 -0500 > With Tcl/Tk, bind tag sequence returns the string which is the command. > With Python, widget.bind('sequence') seems to return a reference to the > command not the command. > > The following reproduces the problem on my machine. Try running the file > and observe the print output. Pretty strange. The string returned is in fact the command bound -- this is a wrapper function. Since (typically) the argument to bind is a Python function, not a Tcl command, a wrapper is used to pass the event data to the Python function. This doesn't qualify as a bug -- it's just different. --Guido van Rossum (home page: http://www.python.org/~guido/) Thomas Wouters 2000-08-06T17:39:00Z Like Guido said, not a bug, just different. 2000-07-31T21:12:00Z sf210670 Jitterbug-Id: 374 Submitted-By: tpeters@beopen.com Date: Thu, 29 Jun 2000 02:25:18 -0400 (EDT) Version: 1.6a2 OS: Windows Copying this over from the SourceForge bug manager: https://sourceforge.net/bugs/?func=detailbug&group_id=5470&bug_id=108381 Here's the original complaint: On Win32, os.listdir raises "No such process" when the directory does not exist. The error returned from GetLastError really is ERROR_PATH_NOT_FOUND, not ESRCH. Here's confirmation under Win98 1.6a2: C:\Python16>python Python 1.6a2 (#0, Apr 6 2000, 11:45:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import os >>> os.listdir('/cow') Traceback (most recent call last): File "<stdin>", line 1, in ? OSError: [Errno 3] No such process: '/cow' >>> ==================================================================== Audit trail: Tue Jul 11 08:24:21 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM platform-specific Mark Hammond windows Bug Importer Bug Importer 2000-07-31T21:12:00Z Jitterbug-Id: 374 Submitted-By: tpeters@beopen.com Date: Thu, 29 Jun 2000 02:25:18 -0400 (EDT) Version: 1.6a2 OS: Windows Copying this over from the SourceForge bug manager: https://sourceforge.net/bugs/?func=detailbug&group_id=5470&bug_id=108381 Here's the original complaint: On Win32, os.listdir raises "No such process" when the directory does not exist. The error returned from GetLastError really is ERROR_PATH_NOT_FOUND, not ESRCH. Here's confirmation under Win98 1.6a2: C:\Python16>python Python 1.6a2 (#0, Apr 6 2000, 11:45:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import os >>> os.listdir('/cow') Traceback (most recent call last): File "<stdin>", line 1, in ? OSError: [Errno 3] No such process: '/cow' >>> ==================================================================== Audit trail: Tue Jul 11 08:24:21 2000 guido moved from incoming to open 2000-07-31T21:12:00Z sf210671 Jitterbug-Id: 376 Submitted-By: fstajano@uk.research.att.com Date: Thu, 29 Jun 2000 12:49:44 -0400 (EDT) Version: 1.6a2 OS: Windows 98 and 2000 This is a problem of the underlying widget set and not of Idle itself, but Idle is where I encountered it (I normally use Emacs), and since Python 1.6 is the unicode version I suppose it's worth looking into anyway (what good is it to have international chars if you can't input them ;-)). If, on Windows, you use a keyboard layout with dead keys, such as "United States - International", then Idle does not respond properly to dead keys. In particular, double-quote comes out as single-quote; single-quote comes out as space; and accented characters come out as non-accented. The lack of support for the accented chars is a minor nuisance, but the problems with quotes are a major one -- Idle is almost unusable under these circumstances. Not as bad as Pythonwin, though, which just crashes. [As you will know, the US-I keyboard defines things like single-quote and double-quote as dead keys so that one can produce accents and umlauts respectively by following the dead key with the appropriate vowel. To produce a double-quote on its own, you have to press double-quote followed by space.] ==================================================================== Audit trail: Tue Jul 11 08:24:21 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM x-3rd-party Fredrik Lundh tkinter Bug Importer Bug Importer 2000-07-31T21:12:00Z Jitterbug-Id: 376 Submitted-By: fstajano@uk.research.att.com Date: Thu, 29 Jun 2000 12:49:44 -0400 (EDT) Version: 1.6a2 OS: Windows 98 and 2000 This is a problem of the underlying widget set and not of Idle itself, but Idle is where I encountered it (I normally use Emacs), and since Python 1.6 is the unicode version I suppose it's worth looking into anyway (what good is it to have international chars if you can't input them ;-)). If, on Windows, you use a keyboard layout with dead keys, such as "United States - International", then Idle does not respond properly to dead keys. In particular, double-quote comes out as single-quote; single-quote comes out as space; and accented characters come out as non-accented. The lack of support for the accented chars is a minor nuisance, but the problems with quotes are a major one -- Idle is almost unusable under these circumstances. Not as bad as Pythonwin, though, which just crashes. [As you will know, the US-I keyboard defines things like single-quote and double-quote as dead keys so that one can produce accents and umlauts respectively by following the dead key with the appropriate vowel. To produce a double-quote on its own, you have to press double-quote followed by space.] ==================================================================== Audit trail: Tue Jul 11 08:24:21 2000 guido moved from incoming to open Fredrik Lundh 2000-08-28T07:37:00Z This is supposed to be fixed in Tk 8.3 and later; from the 8.3.0 changes document: 2000-02-08 (bug fix) fixed incorrect handling of CapsLock on Win9* and the use of dead keys on international keyboards (spjuth) (haven't verified it yet, since 1.6's Tkinter causes my Win95 box to crash, no matter what Tk version I'm using) Martin von Löwis 2000-09-19T17:19:00Z I can confirm that the problem occurs with 1.6a2 but is fixed in 2.0b1; likely due to the more recent Tk version. Guido van Rossum 2000-10-01T04:20:00Z Closing based on Martin's comment. 2000-07-31T21:12:00Z sf210672 Jitterbug-Id: 378 Submitted-By: epx@conectiva.com Date: Fri, 30 Jun 2000 16:10:23 -0400 (EDT) Version: 1.5.2 OS: Linux glibc 2.1.3 kernel 2.2.16 Modules/posixmodule,c, function convertenviron(), uses a dirty trick when parsing POSIX environment variables. All variables are formatted as <variable>=<value> Example: KDEDIR=/usr Python changes '=' to '\0' for a moment while parsing, in the line *p = '\0' But, if LD_PRELOAD variable is present, it SIGSEGVs in this command. I guess this variable is in a mprotect()ed page for security reasons. The environment variable parser should strdup() the variables or change the parsing algorithm so it no longer writes directly the environment var. array. ==================================================================== Audit trail: Tue Jul 11 08:24:21 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM extension-modules Bug Importer Bug Importer 2000-07-31T21:12:00Z Jitterbug-Id: 378 Submitted-By: epx@conectiva.com Date: Fri, 30 Jun 2000 16:10:23 -0400 (EDT) Version: 1.5.2 OS: Linux glibc 2.1.3 kernel 2.2.16 Modules/posixmodule,c, function convertenviron(), uses a dirty trick when parsing POSIX environment variables. All variables are formatted as <variable>=<value> Example: KDEDIR=/usr Python changes '=' to '\0' for a moment while parsing, in the line *p = '\0' But, if LD_PRELOAD variable is present, it SIGSEGVs in this command. I guess this variable is in a mprotect()ed page for security reasons. The environment variable parser should strdup() the variables or change the parsing algorithm so it no longer writes directly the environment var. array. ==================================================================== Audit trail: Tue Jul 11 08:24:21 2000 guido moved from incoming to open Thomas Wouters 2000-08-03T15:20:00Z Fixed by revision 2.113 of posixmodule.c, checked in by Guido. Code now uses PyString_FromStringAndSize to 'substring' the environment variables, rather than writing \0's in them. 2000-07-31T21:12:00Z sf210673 Jitterbug-Id: 380 Submitted-By: 2jerry@writeme.com Date: Mon, 3 Jul 2000 17:14:02 -0400 (EDT) Version: 1.5.2 (win32api build 129) OS: pc win98 next to code: full_path_lst = map(os.path.abspath, sys.path) according to that sys.path include the source directory at the first place of sys.path. I noticed that if I call the module in its own directory (python -i module.py) the first item of sys.path is ''. That all ok: abspath function in os module call getcwd() function if path is Null. ... good day for UNIX like men (as me :)) ... but in NT or WIN 98 workstation: os.path.abspath call :win32api.GetFullPathName(path) in ntpath module and win32api.GetFullPathName('') return '' and not current directory. Maybe is it a functionality .. but is os-depend functionality available for a longtime ? Jerome.vacher alias Jerry the foolish dracomorpheus. ==================================================================== Audit trail: Tue Jul 11 08:24:22 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM platform-specific Mark Hammond windows Bug Importer Bug Importer 2000-07-31T21:12:00Z Jitterbug-Id: 380 Submitted-By: 2jerry@writeme.com Date: Mon, 3 Jul 2000 17:14:02 -0400 (EDT) Version: 1.5.2 (win32api build 129) OS: pc win98 next to code: full_path_lst = map(os.path.abspath, sys.path) according to that sys.path include the source directory at the first place of sys.path. I noticed that if I call the module in its own directory (python -i module.py) the first item of sys.path is ''. That all ok: abspath function in os module call getcwd() function if path is Null. ... good day for UNIX like men (as me :)) ... but in NT or WIN 98 workstation: os.path.abspath call :win32api.GetFullPathName(path) in ntpath module and win32api.GetFullPathName('') return '' and not current directory. Maybe is it a functionality .. but is os-depend functionality available for a longtime ? Jerome.vacher alias Jerry the foolish dracomorpheus. ==================================================================== Audit trail: Tue Jul 11 08:24:22 2000 guido moved from incoming to open Bug Importer 2000-08-01T21:01:00Z From: "Fred L. Drake, Jr." <fdrake@beopen.com> Subject: RE: [Python-bugs-list] win32api.GetFullPathName (build 129) (PR#380) Date: Tue, 4 Jul 2000 13:34:24 -0400 (EDT) Mark Hammond writes: > Can anyone else here confirm that: > > a) os.abspath('') on Linux does indeed return the CWD. Yes, that's right. > b) It is supposed to :-) I think that's the right thing to do. -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member Bug Importer 2000-08-01T21:01:00Z From: "Mark Hammond" <mhammond@skippinet.com.au> Subject: RE: [Python-bugs-list] win32api.GetFullPathName (build 129) (PR#380) Date: Tue, 4 Jul 2000 16:19:30 +1000 Can anyone else here confirm that: a) os.abspath('') on Linux does indeed return the CWD. b) It is supposed to :-) If confirmed, this would be a bug in ntpath.py. It catches win32api exceptions, and returns the input name in that case. This would be triggered by: >>> win32api.GetFullPathName('') Traceback (most recent call last): File "<stdin>", line 1, in ? pywintypes.api_error: (127, 'GetFullPathName', 'The specified procedure could not be found.') Is this indeed something we should fix? Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > 2jerry@writeme.com > Sent: Tuesday, 4 July 2000 7:14 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] win32api.GetFullPathName (build 129) > (PR#380) > > > Full_Name: Jerome VACHER > Version: 1.5.2 (win32api build 129) > OS: pc win98 > Submission from: ppp-55.dialup-166.worldonline.fr (212.83.166.55) > > > next to code: > full_path_lst = map(os.path.abspath, sys.path) > > according to that sys.path include the source directory at the > first place of > sys.path. > > I noticed that if I call the module in its own directory (python > -i module.py) > the first item of sys.path is ''. > That all ok: abspath function in os module call getcwd() > function if path is > Null. > ... > good day for UNIX like men (as me :)) > ... > but in NT or WIN 98 workstation: > os.path.abspath call :win32api.GetFullPathName(path) in ntpath module > and > win32api.GetFullPathName('') return '' and not current directory. > > Maybe is it a functionality .. but is os-depend functionality > available for a > longtime ? > > Jerome.vacher alias Jerry the foolish dracomorpheus. > > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list Thomas Wouters 2000-08-06T20:56:00Z Possibly already fixed, or at least Mark has looked at it :) Mark Hammond 2000-08-06T22:55:00Z This is not a bug in win32api.GetFullPathName(), but rather the use of GetFullPathName() to implement os.abspath(). Bug summary changed accordingly. Confirmed as a bug, and I will fix it! Mark Hammond 2000-08-14T06:22:00Z ntpath.py and test_ntpath.py checked in with the fix! 2000-07-31T21:13:00Z sf210674 Jitterbug-Id: 381 Submitted-By: naris@ensim.com Date: Mon, 3 Jul 2000 21:29:25 -0400 (EDT) Version: 1.5.2 OS: RedHat 6.1 read_lines_to_outerboundary chews up memory. there's a while (1) loop that does a readline(), which is probably not good, as you could have a binary file that doesn't have an endline til the end, and thus readline would read the entire file into memory. i did the following: dd'd a 100MB /dev/zero file and used zope to upload it. it chewed up a large amount of memory. there seems to be bug reports about text files and windows systems (and needing to use python -u), but this problem is unrelated. i am using a unix browser -> unix web server. ==================================================================== Audit trail: Tue Jul 11 08:24:22 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM feature-request barry python-library Bug Importer Bug Importer 2000-07-31T21:13:00Z Jitterbug-Id: 381 Submitted-By: naris@ensim.com Date: Mon, 3 Jul 2000 21:29:25 -0400 (EDT) Version: 1.5.2 OS: RedHat 6.1 read_lines_to_outerboundary chews up memory. there's a while (1) loop that does a readline(), which is probably not good, as you could have a binary file that doesn't have an endline til the end, and thus readline would read the entire file into memory. i did the following: dd'd a 100MB /dev/zero file and used zope to upload it. it chewed up a large amount of memory. there seems to be bug reports about text files and windows systems (and needing to use python -u), but this problem is unrelated. i am using a unix browser -> unix web server. ==================================================================== Audit trail: Tue Jul 11 08:24:22 2000 guido moved from incoming to open Naris 2000-08-24T19:38:00Z there's a bug i submitted to zope that deals with a second problem with read_lines_to_outerboundary, which will also cause a memory leak. the read_lines_to_outerboundary has an unnecessary line self.lines.append(line). removing will fix it this second problem. barry 2000-09-25T22:06:00Z Agreed that readlines() isn't the best thing to use in the face of large binary uploads. I've added this feature request to PEP 42 (and am closing this bug report). Removing self.lines might be more problematic, since although it's not documented as part of the public interface for FieldStorage, it is possible that existing code is using it, and that code would break. Naris 2000-09-27T10:38:00Z i feel the self.lines.append() is is a pretty serious problem...have you got any second opinions on how to proceed? if its not part of the public interface for FieldStorage, then wouldn't it be somewhat safe to remove it (you might anger some people, but they could always stick to using the old cgi.py)? my argument is that if they changed the socket connect/bind functions to reject connect(host,port) in favor of connect((host,port)), then we should certainly be able to remove this self.lines.append() :-) what do you think? barry 2000-11-06T18:39:00Z We've decided to remove the self.lines attribute for Python 2.1. This part of the bug report is identical to 119806. No one can remember why self.lines was there in the first place, so we'll remove it and see who complains. 2000-07-31T21:13:00Z sf210675 Jitterbug-Id: 383 Submitted-By: gregor@hoffleit.de Date: Tue, 4 Jul 2000 12:07:06 -0400 (EDT) Version: CVS version (06/04/00) OS: Debian potato (i386) When I use the current CVS version of Python to build on a Debian potato system with GNU Pth 1.2.3 installed, test_fork1 fails with an error (see below), and test_thread takes significantly longer to complete than when I build the same sources with native LinuxThreads. When running test.regrtest.main(), this happens: clapton:3> LD_LIBRARY_PATH=`pwd` ./python Python 2.0b1 (#0, Jul 4 2000, 17:06:15) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> from test import regrtest >>> regrtest.main() test_grammar test_opcodes ... test_extcall test_fcntl test_fork1 test test_fork1 crashed -- exceptions.AssertionError : Unhandled exception in thread: Traceback (most recent call last): File "./Lib/test/test_fork1.py", line 30, in f alive[id] = os.getpid() AttributeError: 'None' object has no attribute 'getpid' Unhandled exception in thread: Traceback (most recent call last): File "./Lib/test/test_fork1.py", line 32, in f time.sleep(SHORTSLEEP) TypeError: illegal argument type for built-in operation Unhandled exception in thread: Traceback (most recent call last): File "./Lib/test/test_fork1.py", line 30, in f alive[id] = os.getpid() AttributeError: 'None' object has no attribute 'getpid' Unhandled exception in thread: Traceback (most recent call last): File "./Lib/test/test_fork1.py", line 30, in f alive[id] = os.getpid() AttributeError: 'None' object has no attribute 'getpid' test_format test_gc ... When running test.test_fork1(), I get this: clapton:3> LD_LIBRARY_PATH=`pwd` ./python Python 2.0b1 (#0, Jul 4 2000, 17:06:15) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> from test import test_fork1 Traceback (most recent call last): File "<stdin>", line 1, in ? File "./Lib/test/test_fork1.py", line 68, in ? main() File "./Lib/test/test_fork1.py", line 44, in main assert a == range(NUM_THREADS) AssertionError >>> test_thread takes very long to complete (5 min compared to 40 sec with LinuxThreads); when you look at the following log, you'll see that it tends to calls the threads serially !? clapton:3> LD_LIBRARY_PATH=`pwd` ./python Python 2.0b1 (#0, Jul 4 2000, 17:06:15) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> from test import test_thread creating task 1 creating task 2 creating task 3 task 1 will run for 2.1 sec task 1 done creating task 4 task 2 will run for 3.2 sec creating task 5 task 2 done creating task task 3 will run for 9.1 6 sec task 3 done creating task 7 task 4 will run for 2.5 sec task 4 done creating task 8 task 5 will run for 0.9 sec task 5 done creating task 9 task 6 will run for 7.4 sec task 6 done creating task 10 waiting for all tasks to complete task 7 will run for 5.3 sec task 7 done task 8 will run for 2.6 sec task 8 done task 9 will run for 2.7 sec task 9 done task 10 will run for 0.9 sec task 10 done all tasks done *** Barrier Test *** task 0 will run for 0.0 sec task 0 entering barrier 0 task 1 will run for 6.2 sec task 1 entering barrier 0 task 7 will run for 7.0 sec task 7 entering barrier 0 task 3 will run for 5.9 sec task 3 entering barrier 0 task 4 will run for 4.5 sec task 4 entering barrier 0 task 5 will run for 9.2 sec task 5 entering barrier 0 task 6 will run for 1.4 sec task 6 entering barrier 0 task 2 will run for 6.0 sec task 2 entering barrier 0 task 8 will run for 2.4 sec task 8 entering barrier 0 task 9 will run for 9.6 sec task 9 entering barrier 0 task 9 leaving barrier 0 task 0 leaving barrier 0 task task 1 leaving barrier 0 0 will run for 0.0 sec task 0 entering barrier 1 task 7 leaving barrier 0 task 9 will run for 0.8 sec task 9 entering barrier task 3 leaving barrier 0 1 task 1 task 4 leaving barrier 0 will run for 6.1 sec task 5 leaving barrier 0 task 1 entering barrier 1 task 6 leaving barrier 0 task 7 will run for 7.9 sec task 2 leaving barrier 0 task 7 entering barrier 1 task 3 task 8 leaving barrier 0 will run for 7.8 sec task 3 entering barrier 1 task 4 will run for 5.7 sec task 4 entering barrier 1 task 5 will run for 2.0 sec task 5 entering barrier 1 task 6 will run for 0.5 sec task 6 entering barrier 1 task 2 will run for 7.4 sec task 2 entering barrier 1 task 8 will run for 1.0 sec task 8 entering barrier 1 task 8 leaving barrier 1 task 7 leaving barrier 1 task 9 leaving barrier 1 task 1 leaving barrier 1 task 8 will run for 6.9 sec task 0 leaving barrier 1 task 8 entering barrier 2 task 0 will run for task 4 leaving barrier 1 0.0 sec task 7 will run for 4.3 sec task 0 entering barrier 2 task 3 leaving barrier 1 task 7 entering barrier 2 task 5 leaving barrier 1 task 6 leaving barrier 1 task 9 will run for 8.2 sec task task 2 leaving barrier 9 entering barrier 2 1 task 5 will run for 8.9 sec task 5 entering barrier 2 task 2 will run for 8.3 sec task 2 entering barrier 2 task 3 will run for 4.5 sec task 3 entering barrier 2 task 1 will run for 7.0 sec task 1 entering barrier 2 task 6 will run for 1.9 sec task 6 entering barrier 2 task 4 will run for 0.2 sec task 4 entering barrier 2 task 4 leaving barrier 2 task 8 leaving barrier 2 task 9 leaving barrier 2 task 7 leaving barrier 2 task 5 leaving barrier 2 task 0 leaving barrier 2 task 2 leaving barrier 2 task 3 leaving barrier 2 task 1 leaving barrier 2 task 6 leaving barrier 2 all tasks done while this is the log of the same test with Python 1.5.2 and LinuxThreads: clapton:3> python Python 1.5.2 (#0, Apr 3 2000, 14:46:48) [GCC 2.95.2 20000313 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from test import test_thread creating task 1 creating task 2 creating task 3 creating task 4 creating task 5 creating task 6 creating task 7 creating task 8 creating task 9 creating task 10 waiting for all tasks to complete task 1 will run for 8.9 sec task 2 will run for 8.3 sec task 3 will run for 9.1 sec task 5 will run for 6.0 sec task 4 will run for 7.5 sec task 6 will run for 4.7 sec task 7 will run for 4.2 sec task 8 will run for 7.0 sec task 9 will run for 8.7 sec task 10 will run for 9.5 sec task 7 done task 6 done task 5 done task 8 done task 4 done task 2 done task 9 done task 1 done task 3 done task 10 done all tasks done *** Barrier Test *** task 0 will run for 0.0 sec task 1 will run for 2.8 sec task 0 entering barrier 0 task 2 will run for 5.3 sec task 3 will run for 9.2 sec task 5 will run for 8.0 sec task 4 will run for 8.9 sec task 6 will run for 5.0 sec task 7 will run for 1.3 sec task 8 will run for 5.6 sec task 9 will run for 4.7 sec task 7 entering barrier 0 task 1 entering barrier 0 task 9 entering barrier 0 task 6 entering barrier 0 task 2 entering barrier 0 task 8 entering barrier 0 task 5 entering barrier 0 task 4 entering barrier 0 task 3 entering barrier 0 task 3 leaving barrier 0 task 3 will run for 0.1 sec task 0 leaving barrier 0 task 0 will run for 0.0 sec task 7 leaving barrier 0 task 7 will run for 6.6 sec task 1 leaving barrier 0 task 1 will run for 1.0 sec task 9 leaving barrier 0 task 9 will run for 8.2 sec task 6 leaving barrier 0 task 6 will run for 1.0 sec task 2 leaving barrier 0 task 2 will run for 9.2 sec task 8 leaving barrier 0 task 8 will run for 4.4 sec task 5 leaving barrier 0 task 5 will run for 9.6 sec task 4 leaving barrier 0 task 4 will run for 1.7 sec task 0 entering barrier 1 task 3 entering barrier 1 task 1 entering barrier 1 task 6 entering barrier 1 task 4 entering barrier 1 task 8 entering barrier 1 task 7 entering barrier 1 task 9 entering barrier 1 task 2 entering barrier 1 task 5 entering barrier 1 task 5 leaving barrier 1 task 5 will run for 6.6 sec task 0 leaving barrier 1 task 0 will run for 0.0 sec task 3 leaving barrier 1 task 3 will run for 8.5 sec task 1 leaving barrier 1 task 1 will run for 0.1 sec task 6 leaving barrier 1 task 6 will run for 4.7 sec task 4 leaving barrier 1 task 4 will run for 4.7 sec task 8 leaving barrier 1 task 8 will run for 1.7 sec task 7 leaving barrier 1 task 7 will run for 1.8 sec task 9 leaving barrier 1 task 9 will run for 2.8 sec task 2 leaving barrier 1 task 2 will run for 3.3 sec task 0 entering barrier 2 task 1 entering barrier 2 task 8 entering barrier 2 task 7 entering barrier 2 task 9 entering barrier 2 task 2 entering barrier 2 task 6 entering barrier 2 task 4 entering barrier 2 task 5 entering barrier 2 task 3 entering barrier 2 task 3 leaving barrier 2 task 0 leaving barrier 2 task 1 leaving barrier 2 task 8 leaving barrier 2 task 7 leaving barrier 2 task 9 leaving barrier 2 task 2 leaving barrier 2 task 6 leaving barrier 2 task 4 leaving barrier 2 task 5 leaving barrier 2 all tasks done >>> ==================================================================== Audit trail: Tue Jul 11 08:24:22 2000 guido moved from incoming to open Bug Importer REJECTED LOW x-3rd-party Jeremy Hylton python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:13:00Z Jitterbug-Id: 383 Submitted-By: gregor@hoffleit.de Date: Tue, 4 Jul 2000 12:07:06 -0400 (EDT) Version: CVS version (06/04/00) OS: Debian potato (i386) When I use the current CVS version of Python to build on a Debian potato system with GNU Pth 1.2.3 installed, test_fork1 fails with an error (see below), and test_thread takes significantly longer to complete than when I build the same sources with native LinuxThreads. When running test.regrtest.main(), this happens: clapton:3> LD_LIBRARY_PATH=`pwd` ./python Python 2.0b1 (#0, Jul 4 2000, 17:06:15) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> from test import regrtest >>> regrtest.main() test_grammar test_opcodes ... test_extcall test_fcntl test_fork1 test test_fork1 crashed -- exceptions.AssertionError : Unhandled exception in thread: Traceback (most recent call last): File "./Lib/test/test_fork1.py", line 30, in f alive[id] = os.getpid() AttributeError: 'None' object has no attribute 'getpid' Unhandled exception in thread: Traceback (most recent call last): File "./Lib/test/test_fork1.py", line 32, in f time.sleep(SHORTSLEEP) TypeError: illegal argument type for built-in operation Unhandled exception in thread: Traceback (most recent call last): File "./Lib/test/test_fork1.py", line 30, in f alive[id] = os.getpid() AttributeError: 'None' object has no attribute 'getpid' Unhandled exception in thread: Traceback (most recent call last): File "./Lib/test/test_fork1.py", line 30, in f alive[id] = os.getpid() AttributeError: 'None' object has no attribute 'getpid' test_format test_gc ... When running test.test_fork1(), I get this: clapton:3> LD_LIBRARY_PATH=`pwd` ./python Python 2.0b1 (#0, Jul 4 2000, 17:06:15) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> from test import test_fork1 Traceback (most recent call last): File "<stdin>", line 1, in ? File "./Lib/test/test_fork1.py", line 68, in ? main() File "./Lib/test/test_fork1.py", line 44, in main assert a == range(NUM_THREADS) AssertionError >>> test_thread takes very long to complete (5 min compared to 40 sec with LinuxThreads); when you look at the following log, you'll see that it tends to calls the threads serially !? clapton:3> LD_LIBRARY_PATH=`pwd` ./python Python 2.0b1 (#0, Jul 4 2000, 17:06:15) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> from test import test_thread creating task 1 creating task 2 creating task 3 task 1 will run for 2.1 sec task 1 done creating task 4 task 2 will run for 3.2 sec creating task 5 task 2 done creating task task 3 will run for 9.1 6 sec task 3 done creating task 7 task 4 will run for 2.5 sec task 4 done creating task 8 task 5 will run for 0.9 sec task 5 done creating task 9 task 6 will run for 7.4 sec task 6 done creating task 10 waiting for all tasks to complete task 7 will run for 5.3 sec task 7 done task 8 will run for 2.6 sec task 8 done task 9 will run for 2.7 sec task 9 done task 10 will run for 0.9 sec task 10 done all tasks done *** Barrier Test *** task 0 will run for 0.0 sec task 0 entering barrier 0 task 1 will run for 6.2 sec task 1 entering barrier 0 task 7 will run for 7.0 sec task 7 entering barrier 0 task 3 will run for 5.9 sec task 3 entering barrier 0 task 4 will run for 4.5 sec task 4 entering barrier 0 task 5 will run for 9.2 sec task 5 entering barrier 0 task 6 will run for 1.4 sec task 6 entering barrier 0 task 2 will run for 6.0 sec task 2 entering barrier 0 task 8 will run for 2.4 sec task 8 entering barrier 0 task 9 will run for 9.6 sec task 9 entering barrier 0 task 9 leaving barrier 0 task 0 leaving barrier 0 task task 1 leaving barrier 0 0 will run for 0.0 sec task 0 entering barrier 1 task 7 leaving barrier 0 task 9 will run for 0.8 sec task 9 entering barrier task 3 leaving barrier 0 1 task 1 task 4 leaving barrier 0 will run for 6.1 sec task 5 leaving barrier 0 task 1 entering barrier 1 task 6 leaving barrier 0 task 7 will run for 7.9 sec task 2 leaving barrier 0 task 7 entering barrier 1 task 3 task 8 leaving barrier 0 will run for 7.8 sec task 3 entering barrier 1 task 4 will run for 5.7 sec task 4 entering barrier 1 task 5 will run for 2.0 sec task 5 entering barrier 1 task 6 will run for 0.5 sec task 6 entering barrier 1 task 2 will run for 7.4 sec task 2 entering barrier 1 task 8 will run for 1.0 sec task 8 entering barrier 1 task 8 leaving barrier 1 task 7 leaving barrier 1 task 9 leaving barrier 1 task 1 leaving barrier 1 task 8 will run for 6.9 sec task 0 leaving barrier 1 task 8 entering barrier 2 task 0 will run for task 4 leaving barrier 1 0.0 sec task 7 will run for 4.3 sec task 0 entering barrier 2 task 3 leaving barrier 1 task 7 entering barrier 2 task 5 leaving barrier 1 task 6 leaving barrier 1 task 9 will run for 8.2 sec task task 2 leaving barrier 9 entering barrier 2 1 task 5 will run for 8.9 sec task 5 entering barrier 2 task 2 will run for 8.3 sec task 2 entering barrier 2 task 3 will run for 4.5 sec task 3 entering barrier 2 task 1 will run for 7.0 sec task 1 entering barrier 2 task 6 will run for 1.9 sec task 6 entering barrier 2 task 4 will run for 0.2 sec task 4 entering barrier 2 task 4 leaving barrier 2 task 8 leaving barrier 2 task 9 leaving barrier 2 task 7 leaving barrier 2 task 5 leaving barrier 2 task 0 leaving barrier 2 task 2 leaving barrier 2 task 3 leaving barrier 2 task 1 leaving barrier 2 task 6 leaving barrier 2 all tasks done while this is the log of the same test with Python 1.5.2 and LinuxThreads: clapton:3> python Python 1.5.2 (#0, Apr 3 2000, 14:46:48) [GCC 2.95.2 20000313 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from test import test_thread creating task 1 creating task 2 creating task 3 creating task 4 creating task 5 creating task 6 creating task 7 creating task 8 creating task 9 creating task 10 waiting for all tasks to complete task 1 will run for 8.9 sec task 2 will run for 8.3 sec task 3 will run for 9.1 sec task 5 will run for 6.0 sec task 4 will run for 7.5 sec task 6 will run for 4.7 sec task 7 will run for 4.2 sec task 8 will run for 7.0 sec task 9 will run for 8.7 sec task 10 will run for 9.5 sec task 7 done task 6 done task 5 done task 8 done task 4 done task 2 done task 9 done task 1 done task 3 done task 10 done all tasks done *** Barrier Test *** task 0 will run for 0.0 sec task 1 will run for 2.8 sec task 0 entering barrier 0 task 2 will run for 5.3 sec task 3 will run for 9.2 sec task 5 will run for 8.0 sec task 4 will run for 8.9 sec task 6 will run for 5.0 sec task 7 will run for 1.3 sec task 8 will run for 5.6 sec task 9 will run for 4.7 sec task 7 entering barrier 0 task 1 entering barrier 0 task 9 entering barrier 0 task 6 entering barrier 0 task 2 entering barrier 0 task 8 entering barrier 0 task 5 entering barrier 0 task 4 entering barrier 0 task 3 entering barrier 0 task 3 leaving barrier 0 task 3 will run for 0.1 sec task 0 leaving barrier 0 task 0 will run for 0.0 sec task 7 leaving barrier 0 task 7 will run for 6.6 sec task 1 leaving barrier 0 task 1 will run for 1.0 sec task 9 leaving barrier 0 task 9 will run for 8.2 sec task 6 leaving barrier 0 task 6 will run for 1.0 sec task 2 leaving barrier 0 task 2 will run for 9.2 sec task 8 leaving barrier 0 task 8 will run for 4.4 sec task 5 leaving barrier 0 task 5 will run for 9.6 sec task 4 leaving barrier 0 task 4 will run for 1.7 sec task 0 entering barrier 1 task 3 entering barrier 1 task 1 entering barrier 1 task 6 entering barrier 1 task 4 entering barrier 1 task 8 entering barrier 1 task 7 entering barrier 1 task 9 entering barrier 1 task 2 entering barrier 1 task 5 entering barrier 1 task 5 leaving barrier 1 task 5 will run for 6.6 sec task 0 leaving barrier 1 task 0 will run for 0.0 sec task 3 leaving barrier 1 task 3 will run for 8.5 sec task 1 leaving barrier 1 task 1 will run for 0.1 sec task 6 leaving barrier 1 task 6 will run for 4.7 sec task 4 leaving barrier 1 task 4 will run for 4.7 sec task 8 leaving barrier 1 task 8 will run for 1.7 sec task 7 leaving barrier 1 task 7 will run for 1.8 sec task 9 leaving barrier 1 task 9 will run for 2.8 sec task 2 leaving barrier 1 task 2 will run for 3.3 sec task 0 entering barrier 2 task 1 entering barrier 2 task 8 entering barrier 2 task 7 entering barrier 2 task 9 entering barrier 2 task 2 entering barrier 2 task 6 entering barrier 2 task 4 entering barrier 2 task 5 entering barrier 2 task 3 entering barrier 2 task 3 leaving barrier 2 task 0 leaving barrier 2 task 1 leaving barrier 2 task 8 leaving barrier 2 task 7 leaving barrier 2 task 9 leaving barrier 2 task 2 leaving barrier 2 task 6 leaving barrier 2 task 4 leaving barrier 2 task 5 leaving barrier 2 all tasks done >>> ==================================================================== Audit trail: Tue Jul 11 08:24:22 2000 guido moved from incoming to open Jeremy Hylton 2000-08-23T17:31:00Z Another report of test_fork1 problems. Plan to resolve before 2.0b1. Tim Peters 2000-08-23T17:36:00Z Jeremy, my chances of helping someone with a problem specific to "Debian potato system with GNU Pth 1.2.3" are nil. Assigned back to you since you seem to believe it's feasible <wink>. Jeremy Hylton 2000-08-31T21:53:00Z Haven't heard back from the submittor. This sounds like a problem with a buggy GNU Pth package; not a Python bug. Bug Importer 2000-09-01T21:15:00Z I submitted the original pth support. pth has what I would consider a bug in that signals do not interrupt sleep(), usleep(), or select(), the latter being what Python uses to sleep. I'm going to look at this some more myself as soon as I can get the current CVS to configure with pth. -- andy@dustman.net Bug Importer 2000-09-01T21:22:00Z Another thing which may be a factor in this case: Since pth threads are user-space and so all run in the same process, the test used in signalmodule.c:125 doesn't work, i.e. if (getpid() == main_pid) { It probably needs to be something more like this: if (PyThread_get_thread_ident() != main_thread) { I submitted a patch to fix this around the time of the CNRI split, so it probably got lost. -- andy@dustman.net Adustman 2000-09-07T00:08:00Z I submitted patch 101437 which should fix this. Jeremy Hylton 2000-09-15T18:06:00Z The only substance left in this bug report is Andy Dustman's note about a different bug. He's already submitted a patch for it, so we'll use that to track the problem. 2000-07-31T21:13:00Z sf210676 Jitterbug-Id: 385 Submitted-By: aron@gweep.net Date: Tue, 4 Jul 2000 19:07:55 -0400 (EDT) Version: 1.5.2 OS: Red Hat Linux 6.1 (2.1.12-20) The following scripts cause a hang at the denoted line. To execute this code, copy the first bit to master.py and the second to slave.py (both should be in the same directory). Then, "cd" to that directory and "python master.py". Manually killing the program is necessary. This script has also been tested on a Solaris 5.7 box and worked. ---master.py--- import popen2 r,w,e = popen2.popen3 ( 'python slave.py' ) r.readlines() # Hangs here e.readlines() r.close() e.close() w.close() ---end--- ---slave.py--- import sys e = sys.stderr.write w = sys.stdout.write e(400*'this is a test\n') w(400*'this is another test\n') ---end--- ==================================================================== Audit trail: Tue Jul 11 08:24:23 2000 guido moved from incoming to open Bug Importer REJECTED MEDIUM not-a-bug Fred Drake extension-modules Bug Importer Bug Importer 2000-07-31T21:13:00Z Jitterbug-Id: 385 Submitted-By: aron@gweep.net Date: Tue, 4 Jul 2000 19:07:55 -0400 (EDT) Version: 1.5.2 OS: Red Hat Linux 6.1 (2.1.12-20) The following scripts cause a hang at the denoted line. To execute this code, copy the first bit to master.py and the second to slave.py (both should be in the same directory). Then, "cd" to that directory and "python master.py". Manually killing the program is necessary. This script has also been tested on a Solaris 5.7 box and worked. ---master.py--- import popen2 r,w,e = popen2.popen3 ( 'python slave.py' ) r.readlines() # Hangs here e.readlines() r.close() e.close() w.close() ---end--- ---slave.py--- import sys e = sys.stderr.write w = sys.stdout.write e(400*'this is a test\n') w(400*'this is another test\n') ---end--- ==================================================================== Audit trail: Tue Jul 11 08:24:23 2000 guido moved from incoming to open Jeremy Hylton 2000-09-07T22:03:00Z Please do triage on this bug. Martin von Löwis 2000-09-20T20:39:00Z That is a bug in the application code. The slave tries to write 6000 bytes to stderr, and blocks after writing 4096 (number measured on Linux, more generally, after _PC_PIPE_BUF bytes). The server starts reading on stdin, and blocks also, so you get a deadlock. The proper solution is to use import popen2 r,w,e = popen2.popen3 ( 'python slave.py' ) e.readlines() r.readlines() r.close() e.close() w.close() as the server, and import sys,posix e = sys.stderr.write w = sys.stdout.write e(400*'this is a test\n') posix.close(2) w(400*'this is another test\n') as the slave. Notice that stderr must be closed after writing all data, or readlines won't return. Also notice that posix.close must be used, as sys.stderr.close() won't close stderr (apparently due to concerns that assigning to sys.stderr will silently close is, so no further errors can be printed). 2000-07-31T21:13:00Z sf210677 Jitterbug-Id: 388 Submitted-By: markus.oberhumer@jk.uni-linz.ac.at Date: Wed, 5 Jul 2000 09:38:11 -0400 (EDT) Version: python CVS OS: all Tkinter.Wm.wm_state() lacks a missing "newstate=None" optional parameter. Tkinter.Text lacks some important methods: [xy]view_moveto, [xy]view_scroll Canvas.CanvasItem & Canvas.Group: - bind lacks an optional "add" param - unbind lacks an optional "funcid" param - tkraise/lower should call self.canvas.tag_XXXX - bbox() return value is inconsistent with Canvas.bbox() ==================================================================== Audit trail: Tue Jul 11 08:24:23 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM Guido van Rossum tkinter Bug Importer Bug Importer 2000-07-31T21:13:00Z Jitterbug-Id: 388 Submitted-By: markus.oberhumer@jk.uni-linz.ac.at Date: Wed, 5 Jul 2000 09:38:11 -0400 (EDT) Version: python CVS OS: all Tkinter.Wm.wm_state() lacks a missing "newstate=None" optional parameter. Tkinter.Text lacks some important methods: [xy]view_moveto, [xy]view_scroll Canvas.CanvasItem & Canvas.Group: - bind lacks an optional "add" param - unbind lacks an optional "funcid" param - tkraise/lower should call self.canvas.tag_XXXX - bbox() return value is inconsistent with Canvas.bbox() ==================================================================== Audit trail: Tue Jul 11 08:24:23 2000 guido moved from incoming to open Fredrik Lundh 2000-08-09T19:17:00Z the first two items are fixed. I'll look at the Canvas.py stuff later. Guido van Rossum 2000-10-01T04:21:00Z Later being when? Guido van Rossum 2000-10-03T15:22:00Z I'll do this so Fredrik can work on SRE. Guido van Rossum 2000-10-06T00:39:00Z Fixed the remaining items, *except* bbox() -- this would change the API and it's better not to break existing code. I've marked this module as obsolete now; it really shouldn't be used for new projects! It's better to go directly with the Tkinter.Canvas class. 2000-07-31T21:13:00Z sf210678 Jitterbug-Id: 39 Submitted-By: piers@cs.su.oz.au Date: Fri, 30 Jul 1999 01:34:24 -0400 (EDT) Version: 1.5.2 OS: Solaris The following mail header, when parsed by rfc822, returns an incorrect address from the method getaddr: From nobody@bounces.amazon.com Thu Jul 29 18:09:07 1999 Date: Thu, 29 Jul 1999 00:05:26 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=z Subject: A Message from Amazon.com Delivers From: Amazon.com <delivers-news2@amazon.com> >>> import rfc822 >>> fd=open('mail/amazon.com') >>> M=rfc822.Message(fd, 1) >>> M.getaddr('From') ('', 'Amazon.com') Python version is: Python 1.5.2 (#10, May 11 1999, 15:32:03) [GCC 2.8.1] on sunos5 ==================================================================== Audit trail: Fri Jul 30 08:25:26 1999 guido moved from incoming to open Bug Importer REJECTED LOW feature-request barry python-library Bug Importer Bug Importer 2000-07-31T21:13:00Z Jitterbug-Id: 39 Submitted-By: piers@cs.su.oz.au Date: Fri, 30 Jul 1999 01:34:24 -0400 (EDT) Version: 1.5.2 OS: Solaris The following mail header, when parsed by rfc822, returns an incorrect address from the method getaddr: From nobody@bounces.amazon.com Thu Jul 29 18:09:07 1999 Date: Thu, 29 Jul 1999 00:05:26 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=z Subject: A Message from Amazon.com Delivers From: Amazon.com <delivers-news2@amazon.com> >>> import rfc822 >>> fd=open('mail/amazon.com') >>> M=rfc822.Message(fd, 1) >>> M.getaddr('From') ('', 'Amazon.com') Python version is: Python 1.5.2 (#10, May 11 1999, 15:32:03) [GCC 2.8.1] on sunos5 ==================================================================== Audit trail: Fri Jul 30 08:25:26 1999 guido moved from incoming to open Bug Importer 2000-08-01T21:01:00Z From: Sjoerd Mullender <sjoerd@oratrix.nl> Subject: Re: [Python-bugs-list] rfc822.Message getaddr method bug (PR#39) Date: Mon, 02 Aug 1999 14:09:40 +0200 On Fri, Jul 30 1999 piers@cs.su.oz.au wrote: > Full_Name: Piers Lauder > Version: 1.5.2 > OS: Solaris > Submission from: metra.ucc.usyd.edu.au (129.78.64.5) > > > The following mail header, when parsed by rfc822, returns an incorrect > address from the method getaddr: > > From nobody@bounces.amazon.com Thu Jul 29 18:09:07 1999 > Date: Thu, 29 Jul 1999 00:05:26 -0700 > MIME-Version: 1.0 > Content-Type: multipart/alternative; boundary=z > Subject: A Message from Amazon.com Delivers > From: Amazon.com <delivers-news2@amazon.com> > > >>> import rfc822 > >>> fd=open('mail/amazon.com') > >>> M=rfc822.Message(fd, 1) > >>> M.getaddr('From') > ('', 'Amazon.com') > > Python version is: > Python 1.5.2 (#10, May 11 1999, 15:32:03) [GCC 2.8.1] on sunos5 It's an incorrect mail header. The period in Amazon.com is not allowed there but the name has to be quoted with double quotes. But I guess rfc822.py could (and should) be lenient and let you get away with this. -- Sjoerd Mullender <sjoerd.mullender@oratrix.com> Jeremy Hylton 2000-09-07T22:01:00Z Please do triage on this bug. Jeremy Hylton 2000-09-12T15:54:00Z Barry -- you're the resident mail guy. You might think about adding this feature post 2.0. barry 2000-09-25T15:59:00Z Sjoerd's right. I've added this feature request to PEP 42 so we can close this bug report. 2000-07-31T21:14:00Z sf210679 Jitterbug-Id: 394 Submitted-By: akuchlin@mems-exchange.org Date: Fri, 7 Jul 2000 09:03:04 -0400 (EDT) Version: 2.0cvs OS: Reported by jtravis@cse.unl.edu (Jon Travis) in comp.lang.python: There is a small bug while running some of the profiling code from within the profiler. Specifically: import profile x = profile.Profile() x.run("x.dump_stats('/tmp/foo')") Traceback (most recent call last): File "<stdin>", line 1, in ? File "./Lib/profile.py", line 347, in run return self.runctx(cmd, dict, dict) File "./Lib/profile.py", line 353, in runctx exec cmd in globals, locals File "<string>", line 1, in ? File "./Lib/profile.py", line 322, in dump_stats self.create_stats() File "./Lib/profile.py", line 327, in create_stats self.simulate_cmd_complete() File "./Lib/profile.py", line 312, in simulate_cmd_complete self.t = self.get_time() - t File "./Lib/profile.py", line 191, in trace_dispatch_i if self.dispatch[event](frame,t): File "./Lib/profile.py", line 248, in trace_dispatch_return pt, ptt, pct, pfn, pframe, pcur = rcur TypeError: unpack non-sequence I have a small 2 liner fix, but I doubt it is correct, merely a band-aid, so I won't post it. -- Jon ==================================================================== Audit trail: Tue Jul 11 08:24:32 2000 guido moved from incoming to open Bug Importer REJECTED MEDIUM Tim Peters python-library Bug Importer Bug Importer 2000-07-31T21:14:00Z Jitterbug-Id: 394 Submitted-By: akuchlin@mems-exchange.org Date: Fri, 7 Jul 2000 09:03:04 -0400 (EDT) Version: 2.0cvs OS: Reported by jtravis@cse.unl.edu (Jon Travis) in comp.lang.python: There is a small bug while running some of the profiling code from within the profiler. Specifically: import profile x = profile.Profile() x.run("x.dump_stats('/tmp/foo')") Traceback (most recent call last): File "<stdin>", line 1, in ? File "./Lib/profile.py", line 347, in run return self.runctx(cmd, dict, dict) File "./Lib/profile.py", line 353, in runctx exec cmd in globals, locals File "<string>", line 1, in ? File "./Lib/profile.py", line 322, in dump_stats self.create_stats() File "./Lib/profile.py", line 327, in create_stats self.simulate_cmd_complete() File "./Lib/profile.py", line 312, in simulate_cmd_complete self.t = self.get_time() - t File "./Lib/profile.py", line 191, in trace_dispatch_i if self.dispatch[event](frame,t): File "./Lib/profile.py", line 248, in trace_dispatch_return pt, ptt, pct, pfn, pframe, pcur = rcur TypeError: unpack non-sequence I have a small 2 liner fix, but I doubt it is correct, merely a band-aid, so I won't post it. -- Jon ==================================================================== Audit trail: Tue Jul 11 08:24:32 2000 guido moved from incoming to open Jeremy Hylton 2000-09-07T22:06:00Z Please do triage on this bug. Tim Peters 2000-09-19T06:38:00Z Closed with "WontFix". For speed, the profiler maintains a stack of frame summary info in self.cur (as a nested 6-tuple), intended to parallel the actual call stack. One of the first things dump_stats does is to call simulate_cmd_complete, which unwinds the shadow stack in self.cur, under the (reasonable!) assumption that the command being profiled is finished. But when you try to profile dump_stats itself, the cmd being profiled (i.e., dump_stats) is *not* finished at that time, and simulate_cmd_complete drains away the shadow stack info for dump_stats and create_stats and simulate_cmd_complete while they're still active. When those functions *actually* return, then, the shadow stack is empty (i.e. self.cur is None), and attempting to unwind it some more goes boom. The only rational response is "so don't do that". The *old* profiler probably could have tolerated this abuse, as it stored info in the actual frames' local dicts, so there was nothing to get out of synch. The shadow frame gimmick made it run much faster, but also created the possibility for perversely introspective profiling to get the shadow stack out of synch with the true stack. If you simply must profile Profile's dump_stats itself (or simulate_cmd_complete, or create_stats), write a subclass of Profile that keeps track of the runtime stack in some other, more paranoid way. I don't see a way to do that without giving up speed, and speed in the std Profile class is a priority. 2000-07-31T21:14:00Z sf210680 Jitterbug-Id: 397 Submitted-By: jeremy@beopen.com Date: Thu, 13 Jul 2000 21:42:47 -0400 (EDT) Version: CVS Thu Jul 13 21:43:09 EDT 2000 OS: The pos attribute of a match object is supposed to match the value of the optional pos argument passed to match or search. The default value of the argument is zero. The current implementation sets pos to be the start of the match instead. This program demonstrates: import re buf = "abcdef" rx = re.compile("b(c)") mo = rx.search(buf) print mo.pos, mo.endpos print mo.start(1), mo.end(1) bitdiddle:/tmp> python1.5 retest.py 0 6 2 3 bitdiddle:/tmp> python retest.py 1 6 2 3 ==================================================================== Audit trail: Fri Jul 14 11:35:54 2000 jeremy moved from incoming to open Bug Importer FIXRELEASED MEDIUM Jeremy Hylton extension-modules Bug Importer Bug Importer 2000-07-31T21:14:00Z Jitterbug-Id: 397 Submitted-By: jeremy@beopen.com Date: Thu, 13 Jul 2000 21:42:47 -0400 (EDT) Version: CVS Thu Jul 13 21:43:09 EDT 2000 OS: The pos attribute of a match object is supposed to match the value of the optional pos argument passed to match or search. The default value of the argument is zero. The current implementation sets pos to be the start of the match instead. This program demonstrates: import re buf = "abcdef" rx = re.compile("b(c)") mo = rx.search(buf) print mo.pos, mo.endpos print mo.start(1), mo.end(1) bitdiddle:/tmp> python1.5 retest.py 0 6 2 3 bitdiddle:/tmp> python retest.py 1 6 2 3 ==================================================================== Audit trail: Fri Jul 14 11:35:54 2000 jeremy moved from incoming to open Thomas Wouters 2000-08-06T20:50:00Z Jeremy, this looks fixed. (I get the '1.5' behaviour in both 'sre' and 'pre' in current CVS snapshots.) Please re-open this bugreport (and assign to effbot, I assume) if you still see the bug (and mark it platform-dependant -- I don't see it on BSDI or Linux, in any case.) 2000-07-31T21:14:00Z sf210681 Jitterbug-Id: 398 Submitted-By: ingo.adler@synacon.ch Date: Fri, 14 Jul 2000 05:10:25 -0400 (EDT) Version: 1.5.2 OS: win nt I have a simple loop, which produces memory leaks at every call (36 bytes): { Py_SetProgramName("pythontest.exe"); Py_Initialize(); initxmodulec(); PyRun_SimpleString("print \"... Python started ...\""); PyRun_SimpleString("import xmodule"); PyRun_SimpleString("from xmodule import *"); // The Loop PyRun_SimpleString( "y = Y()\n" "for i in range(1000):\n" "\tx = y.getX()\n" "\tx.getNumber()\n" ); PyRun_SimpleString("print \"... Python finished ...\""); Py_Finalize(); } X and Y are my classes implemented in C++, connected to Python via Swig Shadow Classes: class X { public: float getNumber() { return 12.2; } }; class Y { X* pX; public: Y() { pX = new X; } ~Y() { delete pX; } X* getX() { return pX; } }; The classes and python are compiled statically with CBuilder5.0, Swig1.3a3 (same problem with swig1.1). I tested the application with "CodeGuard", which shows the memory leaks. For every call in the loop there is an entry like this (I translated it to English): Error. 0x300010 (Thread 0x013B): resource leak: memory block (0x15422F0) was never released memory leak (0x015422F0) [size: 36 Byte] was assigned with malloc call stack: 0x0045ED5D(=pythontest.exe:0x01:05DD5D) G:\Projects\src\fortuna\Python\Objects\stringobject.c#145 0x00401EFD(=pythontest.exe:0x01:000EFD) G:\Projects\src\fortuna\test\xmodule_wrap.c#769 0x0040255D(=pythontest.exe:0x01:00155D) G:\Projects\src\fortuna\test\xmodule_wrap.c#941 0x0041BA79(=pythontest.exe:0x01:01AA79) G:\Projects\src\fortuna\Python\Python\ceval.c#2359 0x0041B912(=pythontest.exe:0x01:01A912) G:\Projects\src\fortuna\Python\Python\ceval.c#2324 0x0040EE3E(=pythontest.exe:0x01:00DE3E) G:\Projects\src\fortuna\Python\Python\bltinmodule.c#12 The Code for line 941: #define Y_getX(_swigobj) (_swigobj->getX()) static PyObject *_wrap_Y_getX(PyObject *self, PyObject *args) { Y *_arg0; PyObject *_resultobj,*_argo0=0; X *_result; self = self; if(!PyArg_ParseTuple(args,"O:Y_getX",&_argo0)) return NULL; if ((SWIG_ConvertPtr(_argo0,(void **) &_arg0,SWIGTYPE_Y_p,1)) == -1) return NULL; _result = (X *)Y_getX(_arg0); /*941*/ _resultobj = SWIG_NewPointerObj((void *) _result, SWIGTYPE_X_p); return _resultobj; } The Code for line 769: SWIGSTATICRUNTIME(PyObject *) SWIG_NewPointerObj(void *ptr, _swig_type_info *type) { char result[512]; PyObject *robj; if (!ptr) { Py_INCREF(Py_None); return Py_None; } #ifdef SWIG_COBJECT_TYPES robj = PyCObject_FromVoidPtrAndDesc((void *) ptr, type->name, NULL); #else SWIG_MakePtr(result,ptr,type); /*769*/ robj = PyString_FromString(result); #endif return robj; } Ingo Adler ==================================================================== Audit trail: Tue Jul 25 07:27:50 2000 guido changed notes Tue Jul 25 07:27:50 2000 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM barry python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:14:00Z Jitterbug-Id: 398 Submitted-By: ingo.adler@synacon.ch Date: Fri, 14 Jul 2000 05:10:25 -0400 (EDT) Version: 1.5.2 OS: win nt I have a simple loop, which produces memory leaks at every call (36 bytes): { Py_SetProgramName("pythontest.exe"); Py_Initialize(); initxmodulec(); PyRun_SimpleString("print \"... Python started ...\""); PyRun_SimpleString("import xmodule"); PyRun_SimpleString("from xmodule import *"); // The Loop PyRun_SimpleString( "y = Y()\n" "for i in range(1000):\n" "\tx = y.getX()\n" "\tx.getNumber()\n" ); PyRun_SimpleString("print \"... Python finished ...\""); Py_Finalize(); } X and Y are my classes implemented in C++, connected to Python via Swig Shadow Classes: class X { public: float getNumber() { return 12.2; } }; class Y { X* pX; public: Y() { pX = new X; } ~Y() { delete pX; } X* getX() { return pX; } }; The classes and python are compiled statically with CBuilder5.0, Swig1.3a3 (same problem with swig1.1). I tested the application with "CodeGuard", which shows the memory leaks. For every call in the loop there is an entry like this (I translated it to English): Error. 0x300010 (Thread 0x013B): resource leak: memory block (0x15422F0) was never released memory leak (0x015422F0) [size: 36 Byte] was assigned with malloc call stack: 0x0045ED5D(=pythontest.exe:0x01:05DD5D) G:\Projects\src\fortuna\Python\Objects\stringobject.c#145 0x00401EFD(=pythontest.exe:0x01:000EFD) G:\Projects\src\fortuna\test\xmodule_wrap.c#769 0x0040255D(=pythontest.exe:0x01:00155D) G:\Projects\src\fortuna\test\xmodule_wrap.c#941 0x0041BA79(=pythontest.exe:0x01:01AA79) G:\Projects\src\fortuna\Python\Python\ceval.c#2359 0x0041B912(=pythontest.exe:0x01:01A912) G:\Projects\src\fortuna\Python\Python\ceval.c#2324 0x0040EE3E(=pythontest.exe:0x01:00DE3E) G:\Projects\src\fortuna\Python\Python\bltinmodule.c#12 The Code for line 941: #define Y_getX(_swigobj) (_swigobj->getX()) static PyObject *_wrap_Y_getX(PyObject *self, PyObject *args) { Y *_arg0; PyObject *_resultobj,*_argo0=0; X *_result; self = self; if(!PyArg_ParseTuple(args,"O:Y_getX",&_argo0)) return NULL; if ((SWIG_ConvertPtr(_argo0,(void **) &_arg0,SWIGTYPE_Y_p,1)) == -1) return NULL; _result = (X *)Y_getX(_arg0); /*941*/ _resultobj = SWIG_NewPointerObj((void *) _result, SWIGTYPE_X_p); return _resultobj; } The Code for line 769: SWIGSTATICRUNTIME(PyObject *) SWIG_NewPointerObj(void *ptr, _swig_type_info *type) { char result[512]; PyObject *robj; if (!ptr) { Py_INCREF(Py_None); return Py_None; } #ifdef SWIG_COBJECT_TYPES robj = PyCObject_FromVoidPtrAndDesc((void *) ptr, type->name, NULL); #else SWIG_MakePtr(result,ptr,type); /*769*/ robj = PyString_FromString(result); #endif return robj; } Ingo Adler ==================================================================== Audit trail: Tue Jul 25 07:27:50 2000 guido changed notes Tue Jul 25 07:27:50 2000 guido moved from incoming to open Bug Importer 2000-08-01T21:01:00Z Actually, it's hard to say whether this is worth fixing... Could it be a SWIG problem? Bug Importer 2000-08-01T21:01:00Z From: Ingo Adler <ingo.adler@synacon.ch> Subject: Re: [Python-bugs-list] memory leak in loops (PR#398) Date: Tue, 25 Jul 2000 01:34:22 +0200 This is a multi-part message in MIME format. --------------72A23DA082087CB843E12C92 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Mark, I could repro the memory leaks (they seem to be the same) with a much smaller program: int main(int argc, char* argv[]) { Py_SetProgramName("pythontest.exe"); Py_Initialize(); PyRun_SimpleString("print \"... Python started ...\""); PyRun_SimpleString("print \"... Python finished ...\""); Py_Finalize(); return 0; } There seems to be a more general problem, which includes my special problem. Output of Code Guard (translated to English). BoundsChecker shows the same leaks. Ingo Output: Memory Block (0x014EB9B4) [Size: 37 Byte] was assigned with malloc Aufrufhierarchie: 0x0043515A(=pythontest.exe:0x01:03415A) D:\projects\Python\Objects\stringobject.c#95 0x0043A8EB(=pythontest.exe:0x01:0398EB) D:\projects\Python\Python\marshal.c#483 0x0043A9A1(=pythontest.exe:0x01:0399A1) D:\projects\Python\Python\marshal.c#504 0x0043AB88(=pythontest.exe:0x01:039B88) D:\projects\Python\Python\marshal.c#568 0x0043AD37(=pythontest.exe:0x01:039D37) D:\projects\Python\Python\marshal.c#624 0x0042BC54(=pythontest.exe:0x01:02AC54) D:\projects\Python\Python\import.c#575 ------------------------------------------ Error 00078. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14E4858) was never freed Memory Block (0x014E4858) [Size: 31 Byte] was assigned with malloc Aufrufhierarchie: 0x0043526B(=pythontest.exe:0x01:03426B) D:\projects\Python\Objects\stringobject.c#145 0x00425400(=pythontest.exe:0x01:024400) D:\projects\Python\Objects\dictobject.c#1084 0x00433896(=pythontest.exe:0x01:032896) D:\projects\Python\Objects\moduleobject.c#56 0x0042B993(=pythontest.exe:0x01:02A993) D:\projects\Python\Python\import.c#428 0x0043B0C9(=pythontest.exe:0x01:03A0C9) D:\projects\Python\Python\modsupport.c#82 0x0040C68A(=pythontest.exe:0x01:00B68A) D:\projects\Python\Python\bltinmodule.c#2393 ------------------------------------------ Error 00079. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14E47D0) was never freed Memory Block (0x014E47D0) [Size: 28 Byte] was assigned with malloc Aufrufhierarchie: 0x00433CB3(=pythontest.exe:0x01:032CB3) D:\projects\Python\Objects\object.c#122 0x00424115(=pythontest.exe:0x01:023115) D:\projects\Python\Objects\dictobject.c#124 0x004367D3(=pythontest.exe:0x01:0357D3) D:\projects\Python\Objects\stringobject.c#1075 0x00425418(=pythontest.exe:0x01:024418) D:\projects\Python\Objects\dictobject.c#1087 0x0043387A(=pythontest.exe:0x01:03287A) D:\projects\Python\Objects\moduleobject.c#54 0x0042B993(=pythontest.exe:0x01:02A993) D:\projects\Python\Python\import.c#428 ------------------------------------------ Error 00080. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14E47AC) was never freed Memory Block (0x014E47AC) [Size: 32 Byte] was assigned with malloc Aufrufhierarchie: 0x0043526B(=pythontest.exe:0x01:03426B) D:\projects\Python\Objects\stringobject.c#145 0x00425400(=pythontest.exe:0x01:024400) D:\projects\Python\Objects\dictobject.c#1084 0x0043387A(=pythontest.exe:0x01:03287A) D:\projects\Python\Objects\moduleobject.c#54 0x0042B993(=pythontest.exe:0x01:02A993) D:\projects\Python\Python\import.c#428 0x0043B0C9(=pythontest.exe:0x01:03A0C9) D:\projects\Python\Python\modsupport.c#82 0x0040C68A(=pythontest.exe:0x01:00B68A) D:\projects\Python\Python\bltinmodule.c#2393 ------------------------------------------ Error 00081. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14E46E4) was never freed Memory Block (0x014E46E4) [Size: 35 Byte] was assigned with malloc Aufrufhierarchie: 0x0043526B(=pythontest.exe:0x01:03426B) D:\projects\Python\Objects\stringobject.c#145 0x004240F7(=pythontest.exe:0x01:0230F7) D:\projects\Python\Objects\dictobject.c#120 0x0043C27B(=pythontest.exe:0x01:03B27B) D:\projects\Python\Python\pythonrun.c#132 0x00402934(=pythontest.exe:0x01:001934) G:\Projects\src\test\pythonmain.cpp#15 0x3257DC12(=CC3250MT.DLL:0x01:07CC12) ------------------------------------------ Error 00082. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x1524000) was never freed Memory Block (0x01524000) [Size: 12288 Byte] was assigned with malloc Aufrufhierarchie: 0x004243A7(=pythontest.exe:0x01:0233A7) D:\projects\Python\Objects\dictobject.c#280 0x004245C4(=pythontest.exe:0x01:0235C4) D:\projects\Python\Objects\dictobject.c#370 0x00436837(=pythontest.exe:0x01:035837) D:\projects\Python\Objects\stringobject.c#1086 0x00415CA9(=pythontest.exe:0x01:014CA9) D:\projects\Python\Python\compile.c#249 0x0043AC12(=pythontest.exe:0x01:039C12) D:\projects\Python\Python\marshal.c#578 0x0043A9A1(=pythontest.exe:0x01:0399A1) D:\projects\Python\Python\marshal.c#504 ------------------------------------------ Error 00083. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14EFC9C) was never freed Memory Block (0x014EFC9C) [Size: 35 Byte] was assigned with malloc Aufrufhierarchie: 0x0043526B(=pythontest.exe:0x01:03426B) D:\projects\Python\Objects\stringobject.c#145 0x0043685E(=pythontest.exe:0x01:03585E) D:\projects\Python\Objects\stringobject.c#1098 0x00411EE6(=pythontest.exe:0x01:010EE6) D:\projects\Python\Objects\classobject.c#126 0x004118FB(=pythontest.exe:0x01:0108FB) D:\projects\Python\Python\ceval.c#2720 0x0040EE08(=pythontest.exe:0x01:00DE08) D:\projects\Python\Python\ceval.c#1167 0x0040D597(=pythontest.exe:0x01:00C597) D:\projects\Python\Python\ceval.c#324 ------------------------------------------ Error 00084. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14EFC74) was never freed Memory Block (0x014EFC74) [Size: 35 Byte] was assigned with malloc Aufrufhierarchie: 0x0043526B(=pythontest.exe:0x01:03426B) D:\projects\Python\Objects\stringobject.c#145 0x0043685E(=pythontest.exe:0x01:03585E) D:\projects\Python\Objects\stringobject.c#1098 0x00411ED6(=pythontest.exe:0x01:010ED6) D:\projects\Python\Objects\classobject.c#125 0x004118FB(=pythontest.exe:0x01:0108FB) D:\projects\Python\Python\ceval.c#2720 0x0040EE08(=pythontest.exe:0x01:00DE08) D:\projects\Python\Python\ceval.c#1167 0x0040D597(=pythontest.exe:0x01:00C597) D:\projects\Python\Python\ceval.c#324 ------------------------------------------ Error 00085. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14EFC4C) was never freed Memory Block (0x014EFC4C) [Size: 35 Byte] was assigned with malloc Aufrufhierarchie: 0x0043526B(=pythontest.exe:0x01:03426B) D:\projects\Python\Objects\stringobject.c#145 0x0043685E(=pythontest.exe:0x01:03585E) D:\projects\Python\Objects\stringobject.c#1098 0x00411EC6(=pythontest.exe:0x01:010EC6) D:\projects\Python\Objects\classobject.c#124 0x004118FB(=pythontest.exe:0x01:0108FB) D:\projects\Python\Python\ceval.c#2720 0x0040EE08(=pythontest.exe:0x01:00DE08) D:\projects\Python\Python\ceval.c#1167 0x0040D597(=pythontest.exe:0x01:00C597) D:\projects\Python\Python\ceval.c#324 ------------------------------------------ Error 00086. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14F19CC) was never freed Memory Block (0x014F19CC) [Size: 47 Byte] was assigned with malloc Aufrufhierarchie: 0x0043526B(=pythontest.exe:0x01:03426B) D:\projects\Python\Objects\stringobject.c#145 0x00431E97(=pythontest.exe:0x01:030E97) D:\projects\Python\Objects\listobject.c#309 0x0041137E(=pythontest.exe:0x01:01037E) D:\projects\Python\Python\ceval.c#2512 0x0040F906(=pythontest.exe:0x01:00E906) D:\projects\Python\Python\ceval.c#1503 0x0040D597(=pythontest.exe:0x01:00C597) D:\projects\Python\Python\ceval.c#324 0x0042BAD4(=pythontest.exe:0x01:02AAD4) D:\projects\Python\Python\import.c#485 ------------------------------------------ Error 00087. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14F596C) was never freed Memory Block (0x014F596C) [Size: 32 Byte] was assigned with malloc Aufrufhierarchie: 0x0043526B(=pythontest.exe:0x01:03426B) D:\projects\Python\Objects\stringobject.c#145 0x0043685E(=pythontest.exe:0x01:03585E) D:\projects\Python\Objects\stringobject.c#1098 0x0042CED6(=pythontest.exe:0x01:02BED6) D:\projects\Python\Python\import.c#1513 0x0042CD19(=pythontest.exe:0x01:02BD19) D:\projects\Python\Python\import.c#1441 0x0042CE6A(=pythontest.exe:0x01:02BE6A) D:\projects\Python\Python\import.c#1489 0x00409B32(=pythontest.exe:0x01:008B32) D:\projects\Python\Python\bltinmodule.c#65 ------------------------------------------ Error 00088. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14EB870) was never freed Memory Block (0x014EB870) [Size: 32 Byte] was assigned with malloc Aufrufhierarchie: 0x0043515A(=pythontest.exe:0x01:03415A) D:\projects\Python\Objects\stringobject.c#95 0x0043A8EB(=pythontest.exe:0x01:0398EB) D:\projects\Python\Python\marshal.c#483 0x0043A9A1(=pythontest.exe:0x01:0399A1) D:\projects\Python\Python\marshal.c#504 0x0043AB88(=pythontest.exe:0x01:039B88) D:\projects\Python\Python\marshal.c#568 0x0043A9A1(=pythontest.exe:0x01:0399A1) D:\projects\Python\Python\marshal.c#504 0x0043AB76(=pythontest.exe:0x01:039B76) D:\projects\Python\Python\marshal.c#567 ------------------------------------------ Error 00089. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14EFBDC) was never freed Memory Block (0x014EFBDC) [Size: 34 Byte] was assigned with malloc Aufrufhierarchie: 0x0043526B(=pythontest.exe:0x01:03426B) D:\projects\Python\Objects\stringobject.c#145 0x0043685E(=pythontest.exe:0x01:03585E) D:\projects\Python\Objects\stringobject.c#1098 0x00411C9E(=pythontest.exe:0x01:010C9E) D:\projects\Python\Objects\classobject.c#58 0x004118FB(=pythontest.exe:0x01:0108FB) D:\projects\Python\Python\ceval.c#2720 0x0040EE08(=pythontest.exe:0x01:00DE08) D:\projects\Python\Python\ceval.c#1167 0x0040D597(=pythontest.exe:0x01:00C597) D:\projects\Python\Python\ceval.c#324 ------------------------------------------ Error 00090. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14E74C4) was never freed Memory Block (0x014E74C4) [Size: 988 Byte] was assigned with malloc Aufrufhierarchie: 0x00430B62(=pythontest.exe:0x01:02FB62) D:\projects\Python\Objects\intobject.c#113 0x00430BFD(=pythontest.exe:0x01:02FBFD) D:\projects\Python\Objects\intobject.c#163 0x0040C6FC(=pythontest.exe:0x01:00B6FC) D:\projects\Python\Python\bltinmodule.c#2404 0x0043C29A(=pythontest.exe:0x01:03B29A) D:\projects\Python\Python\pythonrun.c#136 0x00402934(=pythontest.exe:0x01:001934) G:\Projects\src\test\pythonmain.cpp#15 0x3257DC12(=CC3250MT.DLL:0x01:07CC12) ------------------------------------------ Error 00091. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14E96C4) was never freed Memory Block (0x014E96C4) [Size: 174 Byte] was assigned with malloc Aufrufhierarchie: 0x0042B0D9(=pythontest.exe:0x01:02A0D9) D:\projects\Python\PC\getpathp.c#403 0x0042B2D5(=pythontest.exe:0x01:02A2D5) D:\projects\Python\PC\getpathp.c#508 0x0043E40C(=pythontest.exe:0x01:03D40C) D:\projects\Python\Python\sysmodule.c#413 0x0043C2CA(=pythontest.exe:0x01:03B2CA) D:\projects\Python\Python\pythonrun.c#142 0x00402934(=pythontest.exe:0x01:001934) G:\Projects\src\test\pythonmain.cpp#15 0x3257DC12(=CC3250MT.DLL:0x01:07CC12) ------------------------------------------ Error 00092. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14EF660) was never freed Memory Block (0x014EF660) [Size: 36 Byte] was assigned with malloc Aufrufhierarchie: 0x0043526B(=pythontest.exe:0x01:03426B) D:\projects\Python\Objects\stringobject.c#145 0x00425400(=pythontest.exe:0x01:024400) D:\projects\Python\Objects\dictobject.c#1084 0x0042BA54(=pythontest.exe:0x01:02AA54) D:\projects\Python\Python\import.c#466 0x0042BF73(=pythontest.exe:0x01:02AF73) D:\projects\Python\Python\import.c#724 0x0042C876(=pythontest.exe:0x01:02B876) D:\projects\Python\Python\import.c#1202 0x0042D51E(=pythontest.exe:0x01:02C51E) D:\projects\Python\Python\import.c#1755 ------------------------------------------ Error 00093. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x15211C8) was never freed Memory Block (0x015211C8) [Size: 31 Byte] was assigned with malloc Aufrufhierarchie: 0x0043526B(=pythontest.exe:0x01:03426B) D:\projects\Python\Objects\stringobject.c#145 0x0043685E(=pythontest.exe:0x01:03585E) D:\projects\Python\Objects\stringobject.c#1098 0x004129EE(=pythontest.exe:0x01:0119EE) D:\projects\Python\Objects\classobject.c#517 0x004246DD(=pythontest.exe:0x01:0236DD) D:\projects\Python\Objects\dictobject.c#419 0x0042546E(=pythontest.exe:0x01:02446E) D:\projects\Python\Objects\dictobject.c#1103 0x0043DF2E(=pythontest.exe:0x01:03CF2E) D:\projects\Python\Python\sysmodule.c#95 ------------------------------------------ Aufgerufene Funktionen: delete (35 Mal) getchar (1 Mal) fflush (2 Mal) fputs (2 Mal) fwrite (2 Mal) vsprintf (2 Mal) strrchr (14 Mal) fclose (14 Mal) strspn (251 Mal) fread (2021 Mal) _fgetc (40 Mal) fstat (7 Mal) fopen (72 Mal) strncmp (19 Mal) strcmp (423 Mal) stat (21 Mal) strncpy (32 Mal) strchr (125 Mal) sprintf (2 Mal) memcmp (1349 Mal) memset (133 Mal) strcpy (834 Mal) strlen (784 Mal) SysFreeMem (87 Mal) SysGetMem (87 Mal) realloc (88 Mal) memcpy (837 Mal) delete[] (2 Mal) free (4936 Mal) new[] (14 Mal) new (40 Mal) calloc (5 Mal) malloc (4946 Mal) Verwendete Resource-Arten: Datei-Stream (14 Allocs, 5 max) Datei-Handle (14 Allocs, 5 max) Objekt-Array (14 Allocs, 13 max) Objekt (40 Allocs, 28 max) Memory Block (5039 Allocs, 2448 max) Verwendete Module: 00400000 07/25/2000 01:06:08 G:\Projects\src\bin\pythontest.exe 0CD00000 02/03/2000 06:00:00 g:\programme\borland\cbuilder5\bin\CG32.DLL 201A0000 02/22/2000 05:20:00 C:\WINNT.45\TRAYHOOK.dll 32500000 02/03/2000 06:00:00 G:\Projects\src\bin\CC3250MT.DLL 40000000 02/03/2000 05:01:00 C:\WINNT.45\System32\VCL50.BPL 41000000 02/03/2000 06:00:00 G:\Projects\src\bin\BORLNDMM.DLL 52180000 08/09/1996 00:00:00 C:\WINNT.45\system32\version.dll 61220000 12/07/1999 16:03:46 G:\Programme\Microsoft Hardware\Mouse\MSH_ZWF.dll 65340000 02/18/2000 16:16:02 C:\WINNT.45\system32\oleaut32.dll 70970000 05/09/1998 13:57:06 C:\WINNT.45\system32\SHELL32.dll 70BD0000 03/18/1999 00:00:00 C:\WINNT.45\system32\SHLWAPI.dll 71190000 07/22/1999 21:09:08 C:\WINNT.45\system32\MSIDLE.DLL 71590000 03/18/1999 00:00:00 C:\WINNT.45\system32\COMCTL32.dll 73060000 05/13/1999 12:05:00 C:\WINNT.45\System32\winspool.drv 77660000 05/13/1999 12:05:00 C:\WINNT.45\System32\MSWSOCK.dll 77666C35 05/13/1999 12:05:00 C:\WINNT.45\system32\wsock32.dll 77690000 05/13/1999 12:05:00 C:\WINNT.45\system32\WS2HELP.dll 776A0000 05/13/1999 12:05:00 C:\WINNT.45\system32\WS2_32.dll 77710000 05/13/1999 12:05:00 C:\WINNT.45\system32\mpr.dll 77920000 05/13/1999 12:05:00 C:\WINNT.45\System32\oledlg.dll 779B0000 08/09/1996 00:00:00 C:\WINNT.45\system32\LZ32.dll 77B80000 05/13/1999 12:05:00 C:\WINNT.45\system32\ole32.dll 77D80000 05/13/1999 12:05:00 C:\WINNT.45\system32\comdlg32.dll 77DC0000 05/13/1999 12:05:00 C:\WINNT.45\system32\ADVAPI32.dll 77E10000 05/13/1999 12:05:00 C:\WINNT.45\system32\RPCRT4.dll 77E70000 05/13/1999 12:05:00 C:\WINNT.45\system32\user32.dll 77ED0000 05/13/1999 12:05:00 C:\WINNT.45\system32\GDI32.dll 77F00000 05/13/1999 12:05:00 C:\WINNT.45\system32\kernel32.dll 77F70000 05/13/1999 12:05:00 C:\WINNT.45\System32\ntdll.dll 78000000 12/07/1999 05:00:00 C:\WINNT.45\system32\MSVCRT.dll ========================================== Mark Hammond wrote: > > I could reproduce the problem with Developer Studio 6.0. > > > > If anyone wants the project to test it - I can provide it. > > If you can repro the problem in just a few lines of C/C++ code but with no > SWIG generated code, I would be interested. Otherwise, I suggest you do > some more work to narrow the problem down some more; as described, there is > still too much work to be done to narrow down the problem to the cause for > me to be interested (or anyone else given the feedback to date!) > > Mark. --------------72A23DA082087CB843E12C92 Content-Type: text/x-vcard; charset=us-ascii; name="ingo.adler.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Ingo Adler Content-Disposition: attachment; filename="ingo.adler.vcf" begin:vcard n:Adler;Ingo tel;fax:+41-41-7103244 tel;work:+41-41-8111500 x-mozilla-html:FALSE org:Synacon GmbH adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland version:2.1 email;internet:ingo.adler@synacon.ch fn:Ingo Adler end:vcard --------------72A23DA082087CB843E12C92-- Bug Importer 2000-08-01T21:01:00Z From: "Mark Hammond" <mhammond@skippinet.com.au> Subject: RE: [Python-bugs-list] memory leak in loops (PR#398) Date: Mon, 17 Jul 2000 22:16:54 -0400 > I could reproduce the problem with Developer Studio 6.0. > > If anyone wants the project to test it - I can provide it. If you can repro the problem in just a few lines of C/C++ code but with no SWIG generated code, I would be interested. Otherwise, I suggest you do some more work to narrow the problem down some more; as described, there is still too much work to be done to narrow down the problem to the cause for me to be interested (or anyone else given the feedback to date!) Mark. Bug Importer 2000-08-01T21:01:00Z From: Ingo Adler <ingo.adler@synacon.ch> Subject: Re: [Python-bugs-list] memory leak in loops (PR#398) Date: Fri, 14 Jul 2000 12:45:02 +0100 This is a multi-part message in MIME format. --------------82393A6779ADCFC3A2ADE19E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I could reproduce the problem with Developer Studio 6.0. If anyone wants the project to test it - I can provide it. Ingo Adler --------------82393A6779ADCFC3A2ADE19E Content-Type: text/x-vcard; charset=us-ascii; name="ingo.adler.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Ingo Adler Content-Disposition: attachment; filename="ingo.adler.vcf" begin:vcard n:Adler;Ingo tel;cell:+41-79-3786792 tel;fax:+41-41-7103244 tel;home:+41-41-7103268 tel;work:+41-41-8111500 x-mozilla-html:FALSE url:www.synacon.ch org:Synacon GmbH adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland version:2.1 email;internet:ingo.adler@synacon.ch title:Dipl.-Inform. fn:Ingo Adler end:vcard --------------82393A6779ADCFC3A2ADE19E-- Bug Importer 2000-08-01T21:01:00Z From: "M.-A. Lemburg" <mal@lemburg.com> Subject: Re: [Python-bugs-list] memory leak in loops (PR#398) Date: Fri, 14 Jul 2000 12:13:13 +0200 Ingo Adler wrote: > > > > // The Loop > > > PyRun_SimpleString( > > > "y = Y()\n" > > > "for i in range(1000):\n" > > > "\tx = y.getX()\n" > > > "\tx.getNumber()\n" > > > > Could be that SWIG doesn't get a chance to cleanup the shadow > > object for x and y. Try adding > > > > del x,y > > > > as final script line. > > > > Note that SWIG uses Python strings to represent pointers in > > C++. It uses an internal table to store these. > > > > I changed the code to: > > PyRun_SimpleString( > "y = Y()\n" > "for i in range(1000):\n" > "\tx = y.getX()\n" > "\tx.getNumber()\n" > "\tdel x\n" > ); > > It doesn't change anything. > > The memory leak only occurs when I call x.getNumber() in the loop. Otherwise x = > y.getX() is memory leak free. Two other possibilities: 1. Python interns the string object used by SWIG to represent the point. It should then free the memory in the Py_Finalize() call. If it doesn't, there's a bug to be found ;-) 2. SWIG has the leak. Try using the alternative method of defining SWIG_COBJECT_TYPES (don't know how this is done -- it seems to be new in SWIG). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ Bug Importer 2000-08-01T21:01:00Z From: Ingo Adler <ingo.adler@synacon.ch> Subject: Re: [Python-bugs-list] memory leak in loops (PR#398) Date: Fri, 14 Jul 2000 11:40:42 +0100 This is a multi-part message in MIME format. --------------6D29988B97CCE77010389AE2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > // The Loop > > PyRun_SimpleString( > > "y = Y()\n" > > "for i in range(1000):\n" > > "\tx = y.getX()\n" > > "\tx.getNumber()\n" > > Could be that SWIG doesn't get a chance to cleanup the shadow > object for x and y. Try adding > > del x,y > > as final script line. > > Note that SWIG uses Python strings to represent pointers in > C++. It uses an internal table to store these. > I changed the code to: PyRun_SimpleString( "y = Y()\n" "for i in range(1000):\n" "\tx = y.getX()\n" "\tx.getNumber()\n" "\tdel x\n" ); It doesn't change anything. The memory leak only occurs when I call x.getNumber() in the loop. Otherwise x = y.getX() is memory leak free. Ingo Adler --------------6D29988B97CCE77010389AE2 Content-Type: text/x-vcard; charset=us-ascii; name="ingo.adler.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Ingo Adler Content-Disposition: attachment; filename="ingo.adler.vcf" begin:vcard n:Adler;Ingo tel;cell:+41-79-3786792 tel;fax:+41-41-7103244 tel;home:+41-41-7103268 tel;work:+41-41-8111500 x-mozilla-html:FALSE url:www.synacon.ch org:Synacon GmbH adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland version:2.1 email;internet:ingo.adler@synacon.ch title:Dipl.-Inform. fn:Ingo Adler end:vcard --------------6D29988B97CCE77010389AE2-- Bug Importer 2000-08-01T21:01:00Z From: "M.-A. Lemburg" <mal@lemburg.com> Subject: Re: [Python-bugs-list] memory leak in loops (PR#398) Date: Fri, 14 Jul 2000 11:22:51 +0200 ingo.adler@synacon.ch wrote: > > Full_Name: ingo adler > Version: 1.5.2 > OS: win nt > Submission from: megazh-d-201.agrinet.ch (212.28.158.201) > > I have a simple loop, which produces memory leaks at every call (36 bytes): > > { > Py_SetProgramName("pythontest.exe"); > Py_Initialize(); > > initxmodulec(); > > PyRun_SimpleString("print \"... Python started ...\""); > > PyRun_SimpleString("import xmodule"); > PyRun_SimpleString("from xmodule import *"); > > // The Loop > PyRun_SimpleString( > "y = Y()\n" > "for i in range(1000):\n" > "\tx = y.getX()\n" > "\tx.getNumber()\n" Could be that SWIG doesn't get a chance to cleanup the shadow object for x and y. Try adding del x,y as final script line. Note that SWIG uses Python strings to represent pointers in C++. It uses an internal table to store these. > ); > > PyRun_SimpleString("print \"... Python finished ...\""); > Py_Finalize(); > } > > X and Y are my classes implemented in C++, connected to Python via Swig Shadow > Classes: > > class X { > > public: > float getNumber() > { > return 12.2; > } > }; > > class Y { > X* pX; > > public: > Y() > { > pX = new X; > } > > ~Y() > { > delete pX; > } > > X* getX() > { > return pX; > } > }; > > The classes and python are compiled statically with CBuilder5.0, Swig1.3a3 (same > problem with swig1.1). > > I tested the application with "CodeGuard", which shows the memory leaks. > For every call in the loop there is an entry like this (I translated it to > English): > > Error. 0x300010 (Thread 0x013B): > resource leak: memory block (0x15422F0) was never released > > memory leak (0x015422F0) [size: 36 Byte] was assigned with malloc > call stack: > 0x0045ED5D(=pythontest.exe:0x01:05DD5D) > G:\Projects\src\fortuna\Python\Objects\stringobject.c#145 > 0x00401EFD(=pythontest.exe:0x01:000EFD) > G:\Projects\src\fortuna\test\xmodule_wrap.c#769 > 0x0040255D(=pythontest.exe:0x01:00155D) > G:\Projects\src\fortuna\test\xmodule_wrap.c#941 > 0x0041BA79(=pythontest.exe:0x01:01AA79) > G:\Projects\src\fortuna\Python\Python\ceval.c#2359 > 0x0041B912(=pythontest.exe:0x01:01A912) > G:\Projects\src\fortuna\Python\Python\ceval.c#2324 > 0x0040EE3E(=pythontest.exe:0x01:00DE3E) > G:\Projects\src\fortuna\Python\Python\bltinmodule.c#12 > > The Code for line 941: > > #define Y_getX(_swigobj) (_swigobj->getX()) > static PyObject *_wrap_Y_getX(PyObject *self, PyObject *args) { > Y *_arg0; > PyObject *_resultobj,*_argo0=0; > X *_result; > self = self; > if(!PyArg_ParseTuple(args,"O:Y_getX",&_argo0)) > return NULL; > if ((SWIG_ConvertPtr(_argo0,(void **) &_arg0,SWIGTYPE_Y_p,1)) == -1) return > NULL; > _result = (X *)Y_getX(_arg0); > /*941*/ _resultobj = SWIG_NewPointerObj((void *) _result, SWIGTYPE_X_p); > return _resultobj; > } > > The Code for line 769: > > SWIGSTATICRUNTIME(PyObject *) > SWIG_NewPointerObj(void *ptr, _swig_type_info *type) { > char result[512]; > PyObject *robj; > if (!ptr) { > Py_INCREF(Py_None); > return Py_None; > } > #ifdef SWIG_COBJECT_TYPES > robj = PyCObject_FromVoidPtrAndDesc((void *) ptr, type->name, NULL); > #else > SWIG_MakePtr(result,ptr,type); > /*769*/ robj = PyString_FromString(result); > #endif > return robj; > } > > Ingo Adler > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ barry 2000-09-25T19:54:00Z I don't believe there is a Python bug worth fixing here. I've done some memory use testing with Python 2.0b2 using Insure++ on Linux, both with the regular interpreter, and with the small example embedded script given below. There are "technical" memory leaks but they are almost all related to either leaks in the OS, or global memory still in use at the time Python exits. An example of the former is leaks in strerror() - nothing we can do about that. An example of the latter are leaks in the string intern dictionary, and we've already decided not to do anything about that. There no identifiable chunks of memory leaked every time through the loop so I believe the problems reported below are either related to swig, have been fixed for Python 2.0, or are of the variety described above. Tregnago 2000-10-03T14:52:00Z I'm working on an embedded application. I've looked with CodeGuard and it detect few memory leaks( similar as reported below ) only executing "Py_Initialize()" immediatly followed by "Py_Finalize()". Are you sure that this basic example is leaks free in your case? I'm in big problems with that, and I can't find a way to escape from that. barry 2000-10-03T16:00:00Z Re-opening since there really are memory leaks we can fix. barry 2000-10-03T16:35:00Z I found a couple of leaks that aren't explained by valid in-reference memory at program exit, or leaks in OS libraries. Fixes are found in the following files/versions: Python/import.c 2.153 Objects/unicodeobject.c 2.65 The last is probably the version that contains the patch. I haven't actually checked it in yet -- I'm waiting for confirmation from the unicode expert. I'm still closing this bug report as fixed. With these patches, all memory leaks now are of the variety described previously. barry 2000-10-03T20:46:00Z Just to update, the patch is contained in Objects/unicodeobject.c version 2.66 2000-07-31T21:14:00Z sf210682 Jitterbug-Id: 4 Submitted-By: MHammond@skippinet.com.au Date: Mon, 12 Jul 1999 15:38:43 -0400 (EDT) Version: 1.5.2 OS: Windows [Resubmitted by GvR] It is a problem that bugged me for _ages_. Since the years I first wrote the Pythonwin debugger Ive learnt alot about how it works :-) The problem is simply: when the frame being debugged is self.botframe, it is impossible to continue - only "step" works. A "continue" command functions as a step until you start debugging a frame below self.botframe. It is less of a problem with pdb, but makes a GUI debugger clunky - if you start a debug session by stepping into a module, the "go" command seems broken. The simplest way to demonstrate the problem is to create a module, and add a "pdb.set_trace()" statement at the top_level (ie, at indent level 0). You will not be able to "continue" until you enter a function. My solution was this: instead of run() calling "exec" directly, it calls another internal function. This internal function contains a single line - the "exec", and therefore never needs to be debugged directly. Then stop_here is modified accordingly. The end result is that "self.botframe" becomes an "intermediate" frame, and is never actually stopped at - ie, self.botframe effectivly becomes one frame _below_ the bottom frame the user is interested in. Im not yet trying to propose a patch, just to discuss this and see if the "right thing" can be determined and put into pdb. Thanks, Mark. ==================================================================== Audit trail: Mon Jul 12 15:39:35 1999 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM python-2.3 Christian Tismer python-library Bug Importer Bug Importer 2000-07-31T21:14:00Z Jitterbug-Id: 4 Submitted-By: MHammond@skippinet.com.au Date: Mon, 12 Jul 1999 15:38:43 -0400 (EDT) Version: 1.5.2 OS: Windows [Resubmitted by GvR] It is a problem that bugged me for _ages_. Since the years I first wrote the Pythonwin debugger Ive learnt alot about how it works :-) The problem is simply: when the frame being debugged is self.botframe, it is impossible to continue - only "step" works. A "continue" command functions as a step until you start debugging a frame below self.botframe. It is less of a problem with pdb, but makes a GUI debugger clunky - if you start a debug session by stepping into a module, the "go" command seems broken. The simplest way to demonstrate the problem is to create a module, and add a "pdb.set_trace()" statement at the top_level (ie, at indent level 0). You will not be able to "continue" until you enter a function. My solution was this: instead of run() calling "exec" directly, it calls another internal function. This internal function contains a single line - the "exec", and therefore never needs to be debugged directly. Then stop_here is modified accordingly. The end result is that "self.botframe" becomes an "intermediate" frame, and is never actually stopped at - ie, self.botframe effectivly becomes one frame _below_ the bottom frame the user is interested in. Im not yet trying to propose a patch, just to discuss this and see if the "right thing" can be determined and put into pdb. Thanks, Mark. ==================================================================== Audit trail: Mon Jul 12 15:39:35 1999 guido moved from incoming to open Bug Importer 2000-10-17T14:18:00Z My common workaround is to always create a function called debug(): that calls the function in the module I am debugging. Instead of doing a runcall for my function I do a runcall on debug. Bug Importer 2000-10-17T14:19:00Z Sorry I forgot to sigh the comment for 2000-Oct-17 07:18 David Hurt davehurt@flash.net Jeremy Hylton 2002-03-01T22:30:00Z Is this really a bug? Or just a feature request? Perhaps we should move it to 42 and close the report. Guido van Rossum 2002-03-01T22:55:00Z Yes, it's really a bug -- it's an annoyance, you have to hit contine twice. Christian Tismer 2002-05-23T20:55:00Z There appears to be a simple solution. I'm not used to pdb very much, so I cannot fur sure say that my patch doesn't affect any extension of it, but it seems to work just fine. Idea: Allow botframe not to be a frame at all, but also None. This makes it possible to use f_back in line 67: self.botframe = frame.f_back ##!!CT In stop_here, we just omit the first two lines: def stop_here(self, frame): ##!!CT if self.stopframe is None: ##!!CT return 1 if frame is self.stopframe: return 1 while frame is not None and frame is not self.stopframe: if frame is self.botframe: return 1 frame = frame.f_back return 0 By this trick, botframe is llowed to be one level "on top" of the topmost frame, and we see the topmost frame behave as nicely as every other. -- chris Christian Tismer 2002-05-23T20:57:00Z Other attachments Guido van Rossum 2002-05-24T19:36:00Z You know, I cannot reproduce the problem! I created this module: import pdb def foo(): x = 12 y = 2 z = x**y print z return pdb.set_trace() print 12 print "hello world" foo() When I run it I get the pdb prompt. When I hit "continue" at the prompt, the whole program executes. Before we start messing with this I'd like to be able to reproduce the problem so I can confirm that it goes away! Mark Hammond 2002-05-25T04:17:00Z This appears to have been fixed magically in Python 2.2. Using Python 2.1 with the sample demonstrates the bug, while 2.2 and current CVS both work correctly. Haven't tried 2.1.1 A scan of the pdb and bdb logs don't show an obvious candidate that fixed the bug, but to be quite honest, I don't care *how* it was fixed now that it is <wink> Guido van Rossum 2002-05-25T11:56:00Z OK, closing. Christian: please *don't* check it it! Christian Tismer 2002-05-26T08:58:00Z Ok, I didn't check ti in, but I disagree to close it! Do you think I would supply a patch if there weren't a problem? The problem was reported to me by an IronPort Python user who simply had the problem that pdb.runcall on a given function *does not* run, but always single steps. Your test doesn't get at the problem, since you don't set a breakpoint, which is necessary to make it show up! Here we go: - write a simple program with some 10 lines - start it with runcall - set a breakpoint - continue and it will definately step! With my patch, it works as expected. Furthermore, Mark's F5 command is documented to "start the program in the debugger". It never did so. With the patch, it does. Let's bring it to the end it deserves. regards - chris Guido van Rossum 2002-05-27T17:11:00Z Can you be more specific in your example? I don't understand how I start a 10-line program with runcall, since runcall requires a function. I also want to know exactly which syntax you use to set the breakpoint. Christian Tismer 2002-05-27T23:44:00Z # test program for bdb buglet. # usage: # import pdb, bdbtest # pdb.runcall(bdbtest.test) # # then, in the debugger, type "b 13": def test(): a=0 a=1 a=2 a=3 a=4 a=5 a=6 a=7 a=8 a=9 # the breakpoint will be at "a=4" # now try to continue with "c", and you # will see it still single stepping. Guido van Rossum 2002-05-28T00:53:00Z OK, you convinced me. Do you want to check it in or should I do it? If you want to do it, go ahead, and mark it as a 2.1 and 2.2 bugfix candidate. And thanks for this solution! (I tried this in IDLE, and there's a benign effect there, too. :-) Neal Norwitz 2002-05-29T01:33:00Z Checked in as bdb.py 1.38/1.39 for current (fixed whitespace), 1.33.6.2 for 2.2 1.31.2.1 for 2.1 Hopefully I got it right. Closing. UNSPECIFIED text/plain IiIiRGVidWdnZXIgYmFzaWNzIiIiDQoNCmltcG9ydCBzeXMNCmltcG9ydCBvcw0KaW1wb3J0IHR5 cGVzDQoNCl9fYWxsX18gPSBbIkJkYlF1aXQiLCJCZGIiLCJCcmVha3BvaW50Il0NCg0KQmRiUXVp dCA9ICdiZGIuQmRiUXVpdCcgIyBFeGNlcHRpb24gdG8gZ2l2ZSB1cCBjb21wbGV0ZWx5DQoNCg0K Y2xhc3MgQmRiOg0KDQogICAgIiIiR2VuZXJpYyBQeXRob24gZGVidWdnZXIgYmFzZSBjbGFzcy4N Cg0KICAgIFRoaXMgY2xhc3MgdGFrZXMgY2FyZSBvZiBkZXRhaWxzIG9mIHRoZSB0cmFjZSBmYWNp bGl0eTsNCiAgICBhIGRlcml2ZWQgY2xhc3Mgc2hvdWxkIGltcGxlbWVudCB1c2VyIGludGVyYWN0 aW9uLg0KICAgIFRoZSBzdGFuZGFyZCBkZWJ1Z2dlciBjbGFzcyAocGRiLlBkYikgaXMgYW4gZXhh bXBsZS4NCiAgICAiIiINCg0KICAgIGRlZiBfX2luaXRfXyhzZWxmKToNCiAgICAgICAgc2VsZi5i cmVha3MgPSB7fQ0KICAgICAgICBzZWxmLmZuY2FjaGUgPSB7fQ0KDQogICAgZGVmIGNhbm9uaWMo c2VsZiwgZmlsZW5hbWUpOg0KICAgICAgICBpZiBmaWxlbmFtZSA9PSAiPCIgKyBmaWxlbmFtZVsx Oi0xXSArICI+IjoNCiAgICAgICAgICAgIHJldHVybiBmaWxlbmFtZQ0KICAgICAgICBjYW5vbmlj ID0gc2VsZi5mbmNhY2hlLmdldChmaWxlbmFtZSkNCiAgICAgICAgaWYgbm90IGNhbm9uaWM6DQog ICAgICAgICAgICBjYW5vbmljID0gb3MucGF0aC5hYnNwYXRoKGZpbGVuYW1lKQ0KICAgICAgICAg ICAgY2Fub25pYyA9IG9zLnBhdGgubm9ybWNhc2UoY2Fub25pYykNCiAgICAgICAgICAgIHNlbGYu Zm5jYWNoZVtmaWxlbmFtZV0gPSBjYW5vbmljDQogICAgICAgIHJldHVybiBjYW5vbmljDQoNCiAg ICBkZWYgcmVzZXQoc2VsZik6DQogICAgICAgIGltcG9ydCBsaW5lY2FjaGUNCiAgICAgICAgbGlu ZWNhY2hlLmNoZWNrY2FjaGUoKQ0KICAgICAgICBzZWxmLmJvdGZyYW1lID0gTm9uZQ0KICAgICAg ICBzZWxmLnN0b3BmcmFtZSA9IE5vbmUNCiAgICAgICAgc2VsZi5yZXR1cm5mcmFtZSA9IE5vbmUN CiAgICAgICAgc2VsZi5xdWl0dGluZyA9IDANCg0KICAgIGRlZiB0cmFjZV9kaXNwYXRjaChzZWxm LCBmcmFtZSwgZXZlbnQsIGFyZyk6DQogICAgICAgIGlmIHNlbGYucXVpdHRpbmc6DQogICAgICAg ICAgICByZXR1cm4gIyBOb25lDQogICAgICAgIGlmIGV2ZW50ID09ICdsaW5lJzoNCiAgICAgICAg ICAgIHJldHVybiBzZWxmLmRpc3BhdGNoX2xpbmUoZnJhbWUpDQogICAgICAgIGlmIGV2ZW50ID09 ICdjYWxsJzoNCiAgICAgICAgICAgIHJldHVybiBzZWxmLmRpc3BhdGNoX2NhbGwoZnJhbWUsIGFy ZykNCiAgICAgICAgaWYgZXZlbnQgPT0gJ3JldHVybic6DQogICAgICAgICAgICByZXR1cm4gc2Vs Zi5kaXNwYXRjaF9yZXR1cm4oZnJhbWUsIGFyZykNCiAgICAgICAgaWYgZXZlbnQgPT0gJ2V4Y2Vw dGlvbic6DQogICAgICAgICAgICByZXR1cm4gc2VsZi5kaXNwYXRjaF9leGNlcHRpb24oZnJhbWUs IGFyZykNCiAgICAgICAgcHJpbnQgJ2JkYi5CZGIuZGlzcGF0Y2g6IHVua25vd24gZGVidWdnaW5n IGV2ZW50OicsIGBldmVudGANCiAgICAgICAgcmV0dXJuIHNlbGYudHJhY2VfZGlzcGF0Y2gNCg0K ICAgIGRlZiBkaXNwYXRjaF9saW5lKHNlbGYsIGZyYW1lKToNCiAgICAgICAgaWYgc2VsZi5zdG9w X2hlcmUoZnJhbWUpIG9yIHNlbGYuYnJlYWtfaGVyZShmcmFtZSk6DQogICAgICAgICAgICBzZWxm LnVzZXJfbGluZShmcmFtZSkNCiAgICAgICAgICAgIGlmIHNlbGYucXVpdHRpbmc6IHJhaXNlIEJk YlF1aXQNCiAgICAgICAgcmV0dXJuIHNlbGYudHJhY2VfZGlzcGF0Y2gNCg0KICAgIGRlZiBkaXNw YXRjaF9jYWxsKHNlbGYsIGZyYW1lLCBhcmcpOg0KICAgICAgICAjIFhYWCAnYXJnJyBpcyBubyBs b25nZXIgdXNlZA0KICAgICAgICBpZiBzZWxmLmJvdGZyYW1lIGlzIE5vbmU6DQogICAgICAgICAg ICAjIEZpcnN0IGNhbGwgb2YgZGlzcGF0Y2ggc2luY2UgcmVzZXQoKQ0KICAgICAgICAgICAgc2Vs Zi5ib3RmcmFtZSA9IGZyYW1lLmZfYmFjayAjIyEhQ1QNCiAgICAgICAgICAgIHJldHVybiBzZWxm LnRyYWNlX2Rpc3BhdGNoDQogICAgICAgIGlmIG5vdCAoc2VsZi5zdG9wX2hlcmUoZnJhbWUpIG9y IHNlbGYuYnJlYWtfYW55d2hlcmUoZnJhbWUpKToNCiAgICAgICAgICAgICMgTm8gbmVlZCB0byB0 cmFjZSB0aGlzIGZ1bmN0aW9uDQogICAgICAgICAgICByZXR1cm4gIyBOb25lDQogICAgICAgIHNl bGYudXNlcl9jYWxsKGZyYW1lLCBhcmcpDQogICAgICAgIGlmIHNlbGYucXVpdHRpbmc6IHJhaXNl IEJkYlF1aXQNCiAgICAgICAgcmV0dXJuIHNlbGYudHJhY2VfZGlzcGF0Y2gNCg0KICAgIGRlZiBk aXNwYXRjaF9yZXR1cm4oc2VsZiwgZnJhbWUsIGFyZyk6DQogICAgICAgIGlmIHNlbGYuc3RvcF9o ZXJlKGZyYW1lKSBvciBmcmFtZSA9PSBzZWxmLnJldHVybmZyYW1lOg0KICAgICAgICAgICAgc2Vs Zi51c2VyX3JldHVybihmcmFtZSwgYXJnKQ0KICAgICAgICAgICAgaWYgc2VsZi5xdWl0dGluZzog cmFpc2UgQmRiUXVpdA0KICAgICAgICByZXR1cm4gc2VsZi50cmFjZV9kaXNwYXRjaA0KDQogICAg ZGVmIGRpc3BhdGNoX2V4Y2VwdGlvbihzZWxmLCBmcmFtZSwgYXJnKToNCiAgICAgICAgaWYgc2Vs Zi5zdG9wX2hlcmUoZnJhbWUpOg0KICAgICAgICAgICAgc2VsZi51c2VyX2V4Y2VwdGlvbihmcmFt ZSwgYXJnKQ0KICAgICAgICAgICAgaWYgc2VsZi5xdWl0dGluZzogcmFpc2UgQmRiUXVpdA0KICAg ICAgICByZXR1cm4gc2VsZi50cmFjZV9kaXNwYXRjaA0KDQogICAgIyBOb3JtYWxseSBkZXJpdmVk IGNsYXNzZXMgZG9uJ3Qgb3ZlcnJpZGUgdGhlIGZvbGxvd2luZw0KICAgICMgbWV0aG9kcywgYnV0 IHRoZXkgbWF5IGlmIHRoZXkgd2FudCB0byByZWRlZmluZSB0aGUNCiAgICAjIGRlZmluaXRpb24g b2Ygc3RvcHBpbmcgYW5kIGJyZWFrcG9pbnRzLg0KDQogICAgZGVmIHN0b3BfaGVyZShzZWxmLCBm cmFtZSk6DQogICAgICAgICMjISFDVCBpZiBzZWxmLnN0b3BmcmFtZSBpcyBOb25lOg0KICAgICAg ICAjIyEhQ1QgICAgIHJldHVybiAxDQogICAgICAgIGlmIGZyYW1lIGlzIHNlbGYuc3RvcGZyYW1l Og0KICAgICAgICAgICAgcmV0dXJuIDENCiAgICAgICAgd2hpbGUgZnJhbWUgaXMgbm90IE5vbmUg YW5kIGZyYW1lIGlzIG5vdCBzZWxmLnN0b3BmcmFtZToNCiAgICAgICAgICAgIGlmIGZyYW1lIGlz IHNlbGYuYm90ZnJhbWU6DQogICAgICAgICAgICAgICAgcmV0dXJuIDENCiAgICAgICAgICAgIGZy YW1lID0gZnJhbWUuZl9iYWNrDQogICAgICAgIHJldHVybiAwDQoNCiAgICBkZWYgYnJlYWtfaGVy ZShzZWxmLCBmcmFtZSk6DQogICAgICAgIGZpbGVuYW1lID0gc2VsZi5jYW5vbmljKGZyYW1lLmZf Y29kZS5jb19maWxlbmFtZSkNCiAgICAgICAgaWYgbm90IHNlbGYuYnJlYWtzLmhhc19rZXkoZmls ZW5hbWUpOg0KICAgICAgICAgICAgcmV0dXJuIDANCiAgICAgICAgbGluZW5vID0gZnJhbWUuZl9s aW5lbm8NCiAgICAgICAgaWYgbm90IGxpbmVubyBpbiBzZWxmLmJyZWFrc1tmaWxlbmFtZV06DQog ICAgICAgICAgICByZXR1cm4gMA0KICAgICAgICAjIGZsYWcgc2F5cyBvayB0byBkZWxldGUgdGVt cC4gYnANCiAgICAgICAgKGJwLCBmbGFnKSA9IGVmZmVjdGl2ZShmaWxlbmFtZSwgbGluZW5vLCBm cmFtZSkNCiAgICAgICAgaWYgYnA6DQogICAgICAgICAgICBzZWxmLmN1cnJlbnRicCA9IGJwLm51 bWJlcg0KICAgICAgICAgICAgaWYgKGZsYWcgYW5kIGJwLnRlbXBvcmFyeSk6DQogICAgICAgICAg ICAgICAgc2VsZi5kb19jbGVhcihzdHIoYnAubnVtYmVyKSkNCiAgICAgICAgICAgIHJldHVybiAx DQogICAgICAgIGVsc2U6DQogICAgICAgICAgICByZXR1cm4gMA0KDQogICAgZGVmIGRvX2NsZWFy KHNlbGYsIGFyZyk6DQogICAgICAgIHJhaXNlIE5vdEltcGxlbWVudGVkRXJyb3IsICJzdWJjbGFz cyBvZiBiZGIgbXVzdCBpbXBsZW1lbnQgZG9fY2xlYXIoKSINCg0KICAgIGRlZiBicmVha19hbnl3 aGVyZShzZWxmLCBmcmFtZSk6DQogICAgICAgIHJldHVybiBzZWxmLmJyZWFrcy5oYXNfa2V5KA0K ICAgICAgICAgICAgc2VsZi5jYW5vbmljKGZyYW1lLmZfY29kZS5jb19maWxlbmFtZSkpDQoNCiAg ICAjIERlcml2ZWQgY2xhc3NlcyBzaG91bGQgb3ZlcnJpZGUgdGhlIHVzZXJfKiBtZXRob2RzDQog ICAgIyB0byBnYWluIGNvbnRyb2wuDQoNCiAgICBkZWYgdXNlcl9jYWxsKHNlbGYsIGZyYW1lLCBh cmd1bWVudF9saXN0KToNCiAgICAgICAgIiIiVGhpcyBtZXRob2QgaXMgY2FsbGVkIHdoZW4gdGhl cmUgaXMgdGhlIHJlbW90ZSBwb3NzaWJpbGl0eQ0KICAgICAgICB0aGF0IHdlIGV2ZXIgbmVlZCB0 byBzdG9wIGluIHRoaXMgZnVuY3Rpb24uIiIiDQogICAgICAgIHBhc3MNCg0KICAgIGRlZiB1c2Vy X2xpbmUoc2VsZiwgZnJhbWUpOg0KICAgICAgICAiIiJUaGlzIG1ldGhvZCBpcyBjYWxsZWQgd2hl biB3ZSBzdG9wIG9yIGJyZWFrIGF0IHRoaXMgbGluZS4iIiINCiAgICAgICAgcGFzcw0KDQogICAg ZGVmIHVzZXJfcmV0dXJuKHNlbGYsIGZyYW1lLCByZXR1cm5fdmFsdWUpOg0KICAgICAgICAiIiJU aGlzIG1ldGhvZCBpcyBjYWxsZWQgd2hlbiBhIHJldHVybiB0cmFwIGlzIHNldCBoZXJlLiIiIg0K ICAgICAgICBwYXNzDQoNCiAgICBkZWYgdXNlcl9leGNlcHRpb24oc2VsZiwgZnJhbWUsIChleGNf dHlwZSwgZXhjX3ZhbHVlLCBleGNfdHJhY2ViYWNrKSk6DQogICAgICAgICIiIlRoaXMgbWV0aG9k IGlzIGNhbGxlZCBpZiBhbiBleGNlcHRpb24gb2NjdXJzLA0KICAgICAgICBidXQgb25seSBpZiB3 ZSBhcmUgdG8gc3RvcCBhdCBvciBqdXN0IGJlbG93IHRoaXMgbGV2ZWwuIiIiDQogICAgICAgIHBh c3MNCg0KICAgICMgRGVyaXZlZCBjbGFzc2VzIGFuZCBjbGllbnRzIGNhbiBjYWxsIHRoZSBmb2xs b3dpbmcgbWV0aG9kcw0KICAgICMgdG8gYWZmZWN0IHRoZSBzdGVwcGluZyBzdGF0ZS4NCg0KICAg IGRlZiBzZXRfc3RlcChzZWxmKToNCiAgICAgICAgIiIiU3RvcCBhZnRlciBvbmUgbGluZSBvZiBj b2RlLiIiIg0KICAgICAgICBzZWxmLnN0b3BmcmFtZSA9IE5vbmUNCiAgICAgICAgc2VsZi5yZXR1 cm5mcmFtZSA9IE5vbmUNCiAgICAgICAgc2VsZi5xdWl0dGluZyA9IDANCg0KICAgIGRlZiBzZXRf bmV4dChzZWxmLCBmcmFtZSk6DQogICAgICAgICIiIlN0b3Agb24gdGhlIG5leHQgbGluZSBpbiBv ciBiZWxvdyB0aGUgZ2l2ZW4gZnJhbWUuIiIiDQogICAgICAgIHNlbGYuc3RvcGZyYW1lID0gZnJh bWUNCiAgICAgICAgc2VsZi5yZXR1cm5mcmFtZSA9IE5vbmUNCiAgICAgICAgc2VsZi5xdWl0dGlu ZyA9IDANCg0KICAgIGRlZiBzZXRfcmV0dXJuKHNlbGYsIGZyYW1lKToNCiAgICAgICAgIiIiU3Rv cCB3aGVuIHJldHVybmluZyBmcm9tIHRoZSBnaXZlbiBmcmFtZS4iIiINCiAgICAgICAgc2VsZi5z dG9wZnJhbWUgPSBmcmFtZS5mX2JhY2sNCiAgICAgICAgc2VsZi5yZXR1cm5mcmFtZSA9IGZyYW1l DQogICAgICAgIHNlbGYucXVpdHRpbmcgPSAwDQoNCiAgICBkZWYgc2V0X3RyYWNlKHNlbGYpOg0K ICAgICAgICAiIiJTdGFydCBkZWJ1Z2dpbmcgZnJvbSBoZXJlLiIiIg0KICAgICAgICB0cnk6DQog ICAgICAgICAgICAxICsgJycNCiAgICAgICAgZXhjZXB0Og0KICAgICAgICAgICAgZnJhbWUgPSBz eXMuZXhjX2luZm8oKVsyXS50Yl9mcmFtZS5mX2JhY2sNCiAgICAgICAgc2VsZi5yZXNldCgpDQog ICAgICAgIHdoaWxlIGZyYW1lOg0KICAgICAgICAgICAgZnJhbWUuZl90cmFjZSA9IHNlbGYudHJh Y2VfZGlzcGF0Y2gNCiAgICAgICAgICAgIHNlbGYuYm90ZnJhbWUgPSBmcmFtZQ0KICAgICAgICAg ICAgZnJhbWUgPSBmcmFtZS5mX2JhY2sNCiAgICAgICAgc2VsZi5zZXRfc3RlcCgpDQogICAgICAg IHN5cy5zZXR0cmFjZShzZWxmLnRyYWNlX2Rpc3BhdGNoKQ0KDQogICAgZGVmIHNldF9jb250aW51 ZShzZWxmKToNCiAgICAgICAgIyBEb24ndCBzdG9wIGV4Y2VwdCBhdCBicmVha3BvaW50cyBvciB3 aGVuIGZpbmlzaGVkDQogICAgICAgIHNlbGYuc3RvcGZyYW1lID0gc2VsZi5ib3RmcmFtZQ0KICAg ICAgICBzZWxmLnJldHVybmZyYW1lID0gTm9uZQ0KICAgICAgICBzZWxmLnF1aXR0aW5nID0gMA0K ICAgICAgICBpZiBub3Qgc2VsZi5icmVha3M6DQogICAgICAgICAgICAjIG5vIGJyZWFrcG9pbnRz OyBydW4gd2l0aG91dCBkZWJ1Z2dlciBvdmVyaGVhZA0KICAgICAgICAgICAgc3lzLnNldHRyYWNl KE5vbmUpDQogICAgICAgICAgICB0cnk6DQogICAgICAgICAgICAgICAgMSArICcnICAjIHJhaXNl IGFuIGV4Y2VwdGlvbg0KICAgICAgICAgICAgZXhjZXB0Og0KICAgICAgICAgICAgICAgIGZyYW1l ID0gc3lzLmV4Y19pbmZvKClbMl0udGJfZnJhbWUuZl9iYWNrDQogICAgICAgICAgICB3aGlsZSBm cmFtZSBhbmQgZnJhbWUgaXMgbm90IHNlbGYuYm90ZnJhbWU6DQogICAgICAgICAgICAgICAgZGVs IGZyYW1lLmZfdHJhY2UNCiAgICAgICAgICAgICAgICBmcmFtZSA9IGZyYW1lLmZfYmFjaw0KDQog ICAgZGVmIHNldF9xdWl0KHNlbGYpOg0KICAgICAgICBzZWxmLnN0b3BmcmFtZSA9IHNlbGYuYm90 ZnJhbWUNCiAgICAgICAgc2VsZi5yZXR1cm5mcmFtZSA9IE5vbmUNCiAgICAgICAgc2VsZi5xdWl0 dGluZyA9IDENCiAgICAgICAgc3lzLnNldHRyYWNlKE5vbmUpDQoNCiAgICAjIERlcml2ZWQgY2xh c3NlcyBhbmQgY2xpZW50cyBjYW4gY2FsbCB0aGUgZm9sbG93aW5nIG1ldGhvZHMNCiAgICAjIHRv IG1hbmlwdWxhdGUgYnJlYWtwb2ludHMuICBUaGVzZSBtZXRob2RzIHJldHVybiBhbg0KICAgICMg ZXJyb3IgbWVzc2FnZSBpcyBzb21ldGhpbmcgd2VudCB3cm9uZywgTm9uZSBpZiBhbGwgaXMgd2Vs bC4NCiAgICAjIFNldF9icmVhayBwcmludHMgb3V0IHRoZSBicmVha3BvaW50IGxpbmUgYW5kIGZp bGU6bGluZW5vLg0KICAgICMgQ2FsbCBzZWxmLmdldF8qYnJlYWsqKCkgdG8gc2VlIHRoZSBicmVh a3BvaW50cyBvciBiZXR0ZXINCiAgICAjIGZvciBicCBpbiBCcmVha3BvaW50LmJwYnludW1iZXI6 IGlmIGJwOiBicC5icHByaW50KCkuDQoNCiAgICBkZWYgc2V0X2JyZWFrKHNlbGYsIGZpbGVuYW1l LCBsaW5lbm8sIHRlbXBvcmFyeT0wLCBjb25kID0gTm9uZSk6DQogICAgICAgIGZpbGVuYW1lID0g c2VsZi5jYW5vbmljKGZpbGVuYW1lKQ0KICAgICAgICBpbXBvcnQgbGluZWNhY2hlICMgSW1wb3J0 IGFzIGxhdGUgYXMgcG9zc2libGUNCiAgICAgICAgbGluZSA9IGxpbmVjYWNoZS5nZXRsaW5lKGZp bGVuYW1lLCBsaW5lbm8pDQogICAgICAgIGlmIG5vdCBsaW5lOg0KICAgICAgICAgICAgcmV0dXJu ICdMaW5lICVzOiVkIGRvZXMgbm90IGV4aXN0JyAlIChmaWxlbmFtZSwNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgbGluZW5vKQ0KICAgICAgICBpZiBub3Qgc2VsZi5icmVha3Mu aGFzX2tleShmaWxlbmFtZSk6DQogICAgICAgICAgICBzZWxmLmJyZWFrc1tmaWxlbmFtZV0gPSBb XQ0KICAgICAgICBsaXN0ID0gc2VsZi5icmVha3NbZmlsZW5hbWVdDQogICAgICAgIGlmIG5vdCBs aW5lbm8gaW4gbGlzdDoNCiAgICAgICAgICAgIGxpc3QuYXBwZW5kKGxpbmVubykNCiAgICAgICAg YnAgPSBCcmVha3BvaW50KGZpbGVuYW1lLCBsaW5lbm8sIHRlbXBvcmFyeSwgY29uZCkNCg0KICAg IGRlZiBjbGVhcl9icmVhayhzZWxmLCBmaWxlbmFtZSwgbGluZW5vKToNCiAgICAgICAgZmlsZW5h bWUgPSBzZWxmLmNhbm9uaWMoZmlsZW5hbWUpDQogICAgICAgIGlmIG5vdCBzZWxmLmJyZWFrcy5o YXNfa2V5KGZpbGVuYW1lKToNCiAgICAgICAgICAgIHJldHVybiAnVGhlcmUgYXJlIG5vIGJyZWFr cG9pbnRzIGluICVzJyAlIGZpbGVuYW1lDQogICAgICAgIGlmIGxpbmVubyBub3QgaW4gc2VsZi5i cmVha3NbZmlsZW5hbWVdOg0KICAgICAgICAgICAgcmV0dXJuICdUaGVyZSBpcyBubyBicmVha3Bv aW50IGF0ICVzOiVkJyAlIChmaWxlbmFtZSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGxpbmVubykNCiAgICAgICAgIyBJZiB0aGVyZSdzIG9ubHkgb25lIGJwIGluIHRoZSBs aXN0IGZvciB0aGF0IGZpbGUsbGluZQ0KICAgICAgICAjIHBhaXIsIHRoZW4gcmVtb3ZlIHRoZSBi cmVha3MgZW50cnkNCiAgICAgICAgZm9yIGJwIGluIEJyZWFrcG9pbnQuYnBsaXN0W2ZpbGVuYW1l LCBsaW5lbm9dWzpdOg0KICAgICAgICAgICAgYnAuZGVsZXRlTWUoKQ0KICAgICAgICBpZiBub3Qg QnJlYWtwb2ludC5icGxpc3QuaGFzX2tleSgoZmlsZW5hbWUsIGxpbmVubykpOg0KICAgICAgICAg ICAgc2VsZi5icmVha3NbZmlsZW5hbWVdLnJlbW92ZShsaW5lbm8pDQogICAgICAgIGlmIG5vdCBz ZWxmLmJyZWFrc1tmaWxlbmFtZV06DQogICAgICAgICAgICBkZWwgc2VsZi5icmVha3NbZmlsZW5h bWVdDQoNCiAgICBkZWYgY2xlYXJfYnBieW51bWJlcihzZWxmLCBhcmcpOg0KICAgICAgICB0cnk6 DQogICAgICAgICAgICBudW1iZXIgPSBpbnQoYXJnKQ0KICAgICAgICBleGNlcHQ6DQogICAgICAg ICAgICByZXR1cm4gJ05vbi1udW1lcmljIGJyZWFrcG9pbnQgbnVtYmVyICglcyknICUgYXJnDQog ICAgICAgIHRyeToNCiAgICAgICAgICAgIGJwID0gQnJlYWtwb2ludC5icGJ5bnVtYmVyW251bWJl cl0NCiAgICAgICAgZXhjZXB0IEluZGV4RXJyb3I6DQogICAgICAgICAgICByZXR1cm4gJ0JyZWFr cG9pbnQgbnVtYmVyICglZCkgb3V0IG9mIHJhbmdlJyAlIG51bWJlcg0KICAgICAgICBpZiBub3Qg YnA6DQogICAgICAgICAgICByZXR1cm4gJ0JyZWFrcG9pbnQgKCVkKSBhbHJlYWR5IGRlbGV0ZWQn ICUgbnVtYmVyDQogICAgICAgIHNlbGYuY2xlYXJfYnJlYWsoYnAuZmlsZSwgYnAubGluZSkNCg0K ICAgIGRlZiBjbGVhcl9hbGxfZmlsZV9icmVha3Moc2VsZiwgZmlsZW5hbWUpOg0KICAgICAgICBm aWxlbmFtZSA9IHNlbGYuY2Fub25pYyhmaWxlbmFtZSkNCiAgICAgICAgaWYgbm90IHNlbGYuYnJl YWtzLmhhc19rZXkoZmlsZW5hbWUpOg0KICAgICAgICAgICAgcmV0dXJuICdUaGVyZSBhcmUgbm8g YnJlYWtwb2ludHMgaW4gJXMnICUgZmlsZW5hbWUNCiAgICAgICAgZm9yIGxpbmUgaW4gc2VsZi5i cmVha3NbZmlsZW5hbWVdOg0KICAgICAgICAgICAgYmxpc3QgPSBCcmVha3BvaW50LmJwbGlzdFtm aWxlbmFtZSwgbGluZV0NCiAgICAgICAgICAgIGZvciBicCBpbiBibGlzdDoNCiAgICAgICAgICAg ICAgICBicC5kZWxldGVNZSgpDQogICAgICAgIGRlbCBzZWxmLmJyZWFrc1tmaWxlbmFtZV0NCg0K ICAgIGRlZiBjbGVhcl9hbGxfYnJlYWtzKHNlbGYpOg0KICAgICAgICBpZiBub3Qgc2VsZi5icmVh a3M6DQogICAgICAgICAgICByZXR1cm4gJ1RoZXJlIGFyZSBubyBicmVha3BvaW50cycNCiAgICAg ICAgZm9yIGJwIGluIEJyZWFrcG9pbnQuYnBieW51bWJlcjoNCiAgICAgICAgICAgIGlmIGJwOg0K ICAgICAgICAgICAgICAgIGJwLmRlbGV0ZU1lKCkNCiAgICAgICAgc2VsZi5icmVha3MgPSB7fQ0K DQogICAgZGVmIGdldF9icmVhayhzZWxmLCBmaWxlbmFtZSwgbGluZW5vKToNCiAgICAgICAgZmls ZW5hbWUgPSBzZWxmLmNhbm9uaWMoZmlsZW5hbWUpDQogICAgICAgIHJldHVybiBzZWxmLmJyZWFr cy5oYXNfa2V5KGZpbGVuYW1lKSBhbmQgXA0KICAgICAgICAgICAgbGluZW5vIGluIHNlbGYuYnJl YWtzW2ZpbGVuYW1lXQ0KDQogICAgZGVmIGdldF9icmVha3Moc2VsZiwgZmlsZW5hbWUsIGxpbmVu byk6DQogICAgICAgIGZpbGVuYW1lID0gc2VsZi5jYW5vbmljKGZpbGVuYW1lKQ0KICAgICAgICBy ZXR1cm4gc2VsZi5icmVha3MuaGFzX2tleShmaWxlbmFtZSkgYW5kIFwNCiAgICAgICAgICAgIGxp bmVubyBpbiBzZWxmLmJyZWFrc1tmaWxlbmFtZV0gYW5kIFwNCiAgICAgICAgICAgIEJyZWFrcG9p bnQuYnBsaXN0W2ZpbGVuYW1lLCBsaW5lbm9dIG9yIFtdDQoNCiAgICBkZWYgZ2V0X2ZpbGVfYnJl YWtzKHNlbGYsIGZpbGVuYW1lKToNCiAgICAgICAgZmlsZW5hbWUgPSBzZWxmLmNhbm9uaWMoZmls ZW5hbWUpDQogICAgICAgIGlmIHNlbGYuYnJlYWtzLmhhc19rZXkoZmlsZW5hbWUpOg0KICAgICAg ICAgICAgcmV0dXJuIHNlbGYuYnJlYWtzW2ZpbGVuYW1lXQ0KICAgICAgICBlbHNlOg0KICAgICAg ICAgICAgcmV0dXJuIFtdDQoNCiAgICBkZWYgZ2V0X2FsbF9icmVha3Moc2VsZik6DQogICAgICAg IHJldHVybiBzZWxmLmJyZWFrcw0KDQogICAgIyBEZXJpdmVkIGNsYXNzZXMgYW5kIGNsaWVudHMg Y2FuIGNhbGwgdGhlIGZvbGxvd2luZyBtZXRob2QNCiAgICAjIHRvIGdldCBhIGRhdGEgc3RydWN0 dXJlIHJlcHJlc2VudGluZyBhIHN0YWNrIHRyYWNlLg0KDQogICAgZGVmIGdldF9zdGFjayhzZWxm LCBmLCB0KToNCiAgICAgICAgc3RhY2sgPSBbXQ0KICAgICAgICBpZiB0IGFuZCB0LnRiX2ZyYW1l IGlzIGY6DQogICAgICAgICAgICB0ID0gdC50Yl9uZXh0DQogICAgICAgIHdoaWxlIGYgaXMgbm90 IE5vbmU6DQogICAgICAgICAgICBzdGFjay5hcHBlbmQoKGYsIGYuZl9saW5lbm8pKQ0KICAgICAg ICAgICAgaWYgZiBpcyBzZWxmLmJvdGZyYW1lOg0KICAgICAgICAgICAgICAgIGJyZWFrDQogICAg ICAgICAgICBmID0gZi5mX2JhY2sNCiAgICAgICAgc3RhY2sucmV2ZXJzZSgpDQogICAgICAgIGkg PSBtYXgoMCwgbGVuKHN0YWNrKSAtIDEpDQogICAgICAgIHdoaWxlIHQgaXMgbm90IE5vbmU6DQog ICAgICAgICAgICBzdGFjay5hcHBlbmQoKHQudGJfZnJhbWUsIHQudGJfbGluZW5vKSkNCiAgICAg ICAgICAgIHQgPSB0LnRiX25leHQNCiAgICAgICAgcmV0dXJuIHN0YWNrLCBpDQoNCiAgICAjDQoN CiAgICBkZWYgZm9ybWF0X3N0YWNrX2VudHJ5KHNlbGYsIGZyYW1lX2xpbmVubywgbHByZWZpeD0n OiAnKToNCiAgICAgICAgaW1wb3J0IGxpbmVjYWNoZSwgcmVwcg0KICAgICAgICBmcmFtZSwgbGlu ZW5vID0gZnJhbWVfbGluZW5vDQogICAgICAgIGZpbGVuYW1lID0gc2VsZi5jYW5vbmljKGZyYW1l LmZfY29kZS5jb19maWxlbmFtZSkNCiAgICAgICAgcyA9IGZpbGVuYW1lICsgJygnICsgYGxpbmVu b2AgKyAnKScNCiAgICAgICAgaWYgZnJhbWUuZl9jb2RlLmNvX25hbWU6DQogICAgICAgICAgICBz ID0gcyArIGZyYW1lLmZfY29kZS5jb19uYW1lDQogICAgICAgIGVsc2U6DQogICAgICAgICAgICBz ID0gcyArICI8bGFtYmRhPiINCiAgICAgICAgaWYgZnJhbWUuZl9sb2NhbHMuaGFzX2tleSgnX19h cmdzX18nKToNCiAgICAgICAgICAgIGFyZ3MgPSBmcmFtZS5mX2xvY2Fsc1snX19hcmdzX18nXQ0K ICAgICAgICBlbHNlOg0KICAgICAgICAgICAgYXJncyA9IE5vbmUNCiAgICAgICAgaWYgYXJnczoN CiAgICAgICAgICAgIHMgPSBzICsgcmVwci5yZXByKGFyZ3MpDQogICAgICAgIGVsc2U6DQogICAg ICAgICAgICBzID0gcyArICcoKScNCiAgICAgICAgaWYgZnJhbWUuZl9sb2NhbHMuaGFzX2tleSgn X19yZXR1cm5fXycpOg0KICAgICAgICAgICAgcnYgPSBmcmFtZS5mX2xvY2Fsc1snX19yZXR1cm5f XyddDQogICAgICAgICAgICBzID0gcyArICctPicNCiAgICAgICAgICAgIHMgPSBzICsgcmVwci5y ZXByKHJ2KQ0KICAgICAgICBsaW5lID0gbGluZWNhY2hlLmdldGxpbmUoZmlsZW5hbWUsIGxpbmVu bykNCiAgICAgICAgaWYgbGluZTogcyA9IHMgKyBscHJlZml4ICsgbGluZS5zdHJpcCgpDQogICAg ICAgIHJldHVybiBzDQoNCiAgICAjIFRoZSBmb2xsb3dpbmcgdHdvIG1ldGhvZHMgY2FuIGJlIGNh bGxlZCBieSBjbGllbnRzIHRvIHVzZQ0KICAgICMgYSBkZWJ1Z2dlciB0byBkZWJ1ZyBhIHN0YXRl bWVudCwgZ2l2ZW4gYXMgYSBzdHJpbmcuDQoNCiAgICBkZWYgcnVuKHNlbGYsIGNtZCwgZ2xvYmFs cz1Ob25lLCBsb2NhbHM9Tm9uZSk6DQogICAgICAgIGlmIGdsb2JhbHMgaXMgTm9uZToNCiAgICAg ICAgICAgIGltcG9ydCBfX21haW5fXw0KICAgICAgICAgICAgZ2xvYmFscyA9IF9fbWFpbl9fLl9f ZGljdF9fDQogICAgICAgIGlmIGxvY2FscyBpcyBOb25lOg0KICAgICAgICAgICAgbG9jYWxzID0g Z2xvYmFscw0KICAgICAgICBzZWxmLnJlc2V0KCkNCiAgICAgICAgc3lzLnNldHRyYWNlKHNlbGYu dHJhY2VfZGlzcGF0Y2gpDQogICAgICAgIGlmIG5vdCBpc2luc3RhbmNlKGNtZCwgdHlwZXMuQ29k ZVR5cGUpOg0KICAgICAgICAgICAgY21kID0gY21kKydcbicNCiAgICAgICAgdHJ5Og0KICAgICAg ICAgICAgdHJ5Og0KICAgICAgICAgICAgICAgIGV4ZWMgY21kIGluIGdsb2JhbHMsIGxvY2Fscw0K ICAgICAgICAgICAgZXhjZXB0IEJkYlF1aXQ6DQogICAgICAgICAgICAgICAgcGFzcw0KICAgICAg ICBmaW5hbGx5Og0KICAgICAgICAgICAgc2VsZi5xdWl0dGluZyA9IDENCiAgICAgICAgICAgIHN5 cy5zZXR0cmFjZShOb25lKQ0KDQogICAgZGVmIHJ1bmV2YWwoc2VsZiwgZXhwciwgZ2xvYmFscz1O b25lLCBsb2NhbHM9Tm9uZSk6DQogICAgICAgIGlmIGdsb2JhbHMgaXMgTm9uZToNCiAgICAgICAg ICAgIGltcG9ydCBfX21haW5fXw0KICAgICAgICAgICAgZ2xvYmFscyA9IF9fbWFpbl9fLl9fZGlj dF9fDQogICAgICAgIGlmIGxvY2FscyBpcyBOb25lOg0KICAgICAgICAgICAgbG9jYWxzID0gZ2xv YmFscw0KICAgICAgICBzZWxmLnJlc2V0KCkNCiAgICAgICAgc3lzLnNldHRyYWNlKHNlbGYudHJh Y2VfZGlzcGF0Y2gpDQogICAgICAgIGlmIG5vdCBpc2luc3RhbmNlKGV4cHIsIHR5cGVzLkNvZGVU eXBlKToNCiAgICAgICAgICAgIGV4cHIgPSBleHByKydcbicNCiAgICAgICAgdHJ5Og0KICAgICAg ICAgICAgdHJ5Og0KICAgICAgICAgICAgICAgIHJldHVybiBldmFsKGV4cHIsIGdsb2JhbHMsIGxv Y2FscykNCiAgICAgICAgICAgIGV4Y2VwdCBCZGJRdWl0Og0KICAgICAgICAgICAgICAgIHBhc3MN CiAgICAgICAgZmluYWxseToNCiAgICAgICAgICAgIHNlbGYucXVpdHRpbmcgPSAxDQogICAgICAg ICAgICBzeXMuc2V0dHJhY2UoTm9uZSkNCg0KICAgIGRlZiBydW5jdHgoc2VsZiwgY21kLCBnbG9i YWxzLCBsb2NhbHMpOg0KICAgICAgICAjIEIvVyBjb21wYXRpYmlsaXR5DQogICAgICAgIHNlbGYu cnVuKGNtZCwgZ2xvYmFscywgbG9jYWxzKQ0KDQogICAgIyBUaGlzIG1ldGhvZCBpcyBtb3JlIHVz ZWZ1bCB0byBkZWJ1ZyBhIHNpbmdsZSBmdW5jdGlvbiBjYWxsLg0KDQogICAgZGVmIHJ1bmNhbGwo c2VsZiwgZnVuYywgKmFyZ3MpOg0KICAgICAgICBzZWxmLnJlc2V0KCkNCiAgICAgICAgc3lzLnNl dHRyYWNlKHNlbGYudHJhY2VfZGlzcGF0Y2gpDQogICAgICAgIHJlcyA9IE5vbmUNCiAgICAgICAg dHJ5Og0KICAgICAgICAgICAgdHJ5Og0KICAgICAgICAgICAgICAgIHJlcyA9IGFwcGx5KGZ1bmMs IGFyZ3MpDQogICAgICAgICAgICBleGNlcHQgQmRiUXVpdDoNCiAgICAgICAgICAgICAgICBwYXNz DQogICAgICAgIGZpbmFsbHk6DQogICAgICAgICAgICBzZWxmLnF1aXR0aW5nID0gMQ0KICAgICAg ICAgICAgc3lzLnNldHRyYWNlKE5vbmUpDQogICAgICAgIHJldHVybiByZXMNCg0KDQpkZWYgc2V0 X3RyYWNlKCk6DQogICAgQmRiKCkuc2V0X3RyYWNlKCkNCg0KDQpjbGFzcyBCcmVha3BvaW50Og0K DQogICAgIiIiQnJlYWtwb2ludCBjbGFzcw0KDQogICAgSW1wbGVtZW50cyB0ZW1wb3JhcnkgYnJl YWtwb2ludHMsIGlnbm9yZSBjb3VudHMsIGRpc2FibGluZyBhbmQNCiAgICAocmUpLWVuYWJsaW5n LCBhbmQgY29uZGl0aW9uYWxzLg0KDQogICAgQnJlYWtwb2ludHMgYXJlIGluZGV4ZWQgYnkgbnVt YmVyIHRocm91Z2ggYnBieW51bWJlciBhbmQgYnkNCiAgICB0aGUgZmlsZSxsaW5lIHR1cGxlIHVz aW5nIGJwbGlzdC4gIFRoZSBmb3JtZXIgcG9pbnRzIHRvIGENCiAgICBzaW5nbGUgaW5zdGFuY2Ug b2YgY2xhc3MgQnJlYWtwb2ludC4gIFRoZSBsYXR0ZXIgcG9pbnRzIHRvIGENCiAgICBsaXN0IG9m IHN1Y2ggaW5zdGFuY2VzIHNpbmNlIHRoZXJlIG1heSBiZSBtb3JlIHRoYW4gb25lDQogICAgYnJl YWtwb2ludCBwZXIgbGluZS4NCg0KICAgICIiIg0KDQogICAgIyBYWFggS2VlcGluZyBzdGF0ZSBp biB0aGUgY2xhc3MgaXMgYSBtaXN0YWtlIC0tIHRoaXMgbWVhbnMNCiAgICAjIHlvdSBjYW5ub3Qg aGF2ZSBtb3JlIHRoYW4gb25lIGFjdGl2ZSBCZGIgaW5zdGFuY2UuDQoNCiAgICBuZXh0ID0gMSAg ICAgICAgIyBOZXh0IGJwIHRvIGJlIGFzc2lnbmVkDQogICAgYnBsaXN0ID0ge30gICAgICMgaW5k ZXhlZCBieSAoZmlsZSwgbGluZW5vKSB0dXBsZQ0KICAgIGJwYnludW1iZXIgPSBbTm9uZV0gIyBF YWNoIGVudHJ5IGlzIE5vbmUgb3IgYW4gaW5zdGFuY2Ugb2YgQnB0DQogICAgICAgICAgICAgICAg IyBpbmRleCAwIGlzIHVudXNlZCwgZXhjZXB0IGZvciBtYXJraW5nIGFuDQogICAgICAgICAgICAg ICAgIyBlZmZlY3RpdmUgYnJlYWsgLi4uLiBzZWUgZWZmZWN0aXZlKCkNCg0KICAgIGRlZiBfX2lu aXRfXyhzZWxmLCBmaWxlLCBsaW5lLCB0ZW1wb3Jhcnk9MCwgY29uZCA9IE5vbmUpOg0KICAgICAg ICBzZWxmLmZpbGUgPSBmaWxlICAgICMgVGhpcyBiZXR0ZXIgYmUgaW4gY2Fub25pY2FsIGZvcm0h DQogICAgICAgIHNlbGYubGluZSA9IGxpbmUNCiAgICAgICAgc2VsZi50ZW1wb3JhcnkgPSB0ZW1w b3JhcnkNCiAgICAgICAgc2VsZi5jb25kID0gY29uZA0KICAgICAgICBzZWxmLmVuYWJsZWQgPSAx DQogICAgICAgIHNlbGYuaWdub3JlID0gMA0KICAgICAgICBzZWxmLmhpdHMgPSAwDQogICAgICAg IHNlbGYubnVtYmVyID0gQnJlYWtwb2ludC5uZXh0DQogICAgICAgIEJyZWFrcG9pbnQubmV4dCA9 IEJyZWFrcG9pbnQubmV4dCArIDENCiAgICAgICAgIyBCdWlsZCB0aGUgdHdvIGxpc3RzDQogICAg ICAgIHNlbGYuYnBieW51bWJlci5hcHBlbmQoc2VsZikNCiAgICAgICAgaWYgc2VsZi5icGxpc3Qu aGFzX2tleSgoZmlsZSwgbGluZSkpOg0KICAgICAgICAgICAgc2VsZi5icGxpc3RbZmlsZSwgbGlu ZV0uYXBwZW5kKHNlbGYpDQogICAgICAgIGVsc2U6DQogICAgICAgICAgICBzZWxmLmJwbGlzdFtm aWxlLCBsaW5lXSA9IFtzZWxmXQ0KDQoNCiAgICBkZWYgZGVsZXRlTWUoc2VsZik6DQogICAgICAg IGluZGV4ID0gKHNlbGYuZmlsZSwgc2VsZi5saW5lKQ0KICAgICAgICBzZWxmLmJwYnludW1iZXJb c2VsZi5udW1iZXJdID0gTm9uZSAgICMgTm8gbG9uZ2VyIGluIGxpc3QNCiAgICAgICAgc2VsZi5i cGxpc3RbaW5kZXhdLnJlbW92ZShzZWxmKQ0KICAgICAgICBpZiBub3Qgc2VsZi5icGxpc3RbaW5k ZXhdOg0KICAgICAgICAgICAgIyBObyBtb3JlIGJwIGZvciB0aGlzIGY6bCBjb21ibw0KICAgICAg ICAgICAgZGVsIHNlbGYuYnBsaXN0W2luZGV4XQ0KDQogICAgZGVmIGVuYWJsZShzZWxmKToNCiAg ICAgICAgc2VsZi5lbmFibGVkID0gMQ0KDQogICAgZGVmIGRpc2FibGUoc2VsZik6DQogICAgICAg IHNlbGYuZW5hYmxlZCA9IDANCg0KICAgIGRlZiBicHByaW50KHNlbGYpOg0KICAgICAgICBpZiBz ZWxmLnRlbXBvcmFyeToNCiAgICAgICAgICAgIGRpc3AgPSAnZGVsICAnDQogICAgICAgIGVsc2U6 DQogICAgICAgICAgICBkaXNwID0gJ2tlZXAgJw0KICAgICAgICBpZiBzZWxmLmVuYWJsZWQ6DQog ICAgICAgICAgICBkaXNwID0gZGlzcCArICd5ZXMnDQogICAgICAgIGVsc2U6DQogICAgICAgICAg ICBkaXNwID0gZGlzcCArICdubyAnDQogICAgICAgIHByaW50ICclLTRkYnJlYWtwb2ludCAgICAl cyBhdCAlczolZCcgJSAoc2VsZi5udW1iZXIsIGRpc3AsDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHNlbGYuZmlsZSwgc2VsZi5saW5lKQ0KICAgICAgICBpZiBzZWxmLmNvbmQ6DQogICAg ICAgICAgICBwcmludCAnXHRzdG9wIG9ubHkgaWYgJXMnICUgKHNlbGYuY29uZCwpDQogICAgICAg IGlmIHNlbGYuaWdub3JlOg0KICAgICAgICAgICAgcHJpbnQgJ1x0aWdub3JlIG5leHQgJWQgaGl0 cycgJSAoc2VsZi5pZ25vcmUpDQogICAgICAgIGlmIChzZWxmLmhpdHMpOg0KICAgICAgICAgICAg aWYgKHNlbGYuaGl0cyA+IDEpOiBzcyA9ICdzJw0KICAgICAgICAgICAgZWxzZTogc3MgPSAnJw0K ICAgICAgICAgICAgcHJpbnQgKCdcdGJyZWFrcG9pbnQgYWxyZWFkeSBoaXQgJWQgdGltZSVzJyAl DQogICAgICAgICAgICAgICAgICAgKHNlbGYuaGl0cywgc3MpKQ0KDQojIC0tLS0tLS0tLS0tZW5k IG9mIEJyZWFrcG9pbnQgY2xhc3MtLS0tLS0tLS0tDQoNCiMgRGV0ZXJtaW5lcyBpZiB0aGVyZSBp cyBhbiBlZmZlY3RpdmUgKGFjdGl2ZSkgYnJlYWtwb2ludCBhdCB0aGlzDQojIGxpbmUgb2YgY29k ZS4gIFJldHVybnMgYnJlYWtwb2ludCBudW1iZXIgb3IgMCBpZiBub25lDQpkZWYgZWZmZWN0aXZl KGZpbGUsIGxpbmUsIGZyYW1lKToNCiAgICAiIiJEZXRlcm1pbmUgd2hpY2ggYnJlYWtwb2ludCBm b3IgdGhpcyBmaWxlOmxpbmUgaXMgdG8gYmUgYWN0ZWQgdXBvbi4NCg0KICAgIENhbGxlZCBvbmx5 IGlmIHdlIGtub3cgdGhlcmUgaXMgYSBicHQgYXQgdGhpcw0KICAgIGxvY2F0aW9uLiAgUmV0dXJu cyBicmVha3BvaW50IHRoYXQgd2FzIHRyaWdnZXJlZCBhbmQgYSBmbGFnDQogICAgdGhhdCBpbmRp Y2F0ZXMgaWYgaXQgaXMgb2sgdG8gZGVsZXRlIGEgdGVtcG9yYXJ5IGJwLg0KDQogICAgIiIiDQog ICAgcG9zc2libGVzID0gQnJlYWtwb2ludC5icGxpc3RbZmlsZSxsaW5lXQ0KICAgIGZvciBpIGlu IHJhbmdlKDAsIGxlbihwb3NzaWJsZXMpKToNCiAgICAgICAgYiA9IHBvc3NpYmxlc1tpXQ0KICAg ICAgICBpZiBiLmVuYWJsZWQgPT0gMDoNCiAgICAgICAgICAgIGNvbnRpbnVlDQogICAgICAgICMg Q291bnQgZXZlcnkgaGl0IHdoZW4gYnAgaXMgZW5hYmxlZA0KICAgICAgICBiLmhpdHMgPSBiLmhp dHMgKyAxDQogICAgICAgIGlmIG5vdCBiLmNvbmQ6DQogICAgICAgICAgICAjIElmIHVuY29uZGl0 aW9uYWwsIGFuZCBpZ25vcmluZywNCiAgICAgICAgICAgICMgZ28gb24gdG8gbmV4dCwgZWxzZSBi cmVhaw0KICAgICAgICAgICAgaWYgYi5pZ25vcmUgPiAwOg0KICAgICAgICAgICAgICAgIGIuaWdu b3JlID0gYi5pZ25vcmUgLTENCiAgICAgICAgICAgICAgICBjb250aW51ZQ0KICAgICAgICAgICAg ZWxzZToNCiAgICAgICAgICAgICAgICAjIGJyZWFrcG9pbnQgYW5kIG1hcmtlciB0aGF0J3Mgb2sN CiAgICAgICAgICAgICAgICAjIHRvIGRlbGV0ZSBpZiB0ZW1wb3JhcnkNCiAgICAgICAgICAgICAg ICByZXR1cm4gKGIsMSkNCiAgICAgICAgZWxzZToNCiAgICAgICAgICAgICMgQ29uZGl0aW9uYWwg YnAuDQogICAgICAgICAgICAjIElnbm9yZSBjb3VudCBhcHBsaWVzIG9ubHkgdG8gdGhvc2UgYnB0 IGhpdHMgd2hlcmUgdGhlDQogICAgICAgICAgICAjIGNvbmRpdGlvbiBldmFsdWF0ZXMgdG8gdHJ1 ZS4NCiAgICAgICAgICAgIHRyeToNCiAgICAgICAgICAgICAgICB2YWwgPSBldmFsKGIuY29uZCwg ZnJhbWUuZl9nbG9iYWxzLA0KICAgICAgICAgICAgICAgICAgICAgICBmcmFtZS5mX2xvY2FscykN CiAgICAgICAgICAgICAgICBpZiB2YWw6DQogICAgICAgICAgICAgICAgICAgIGlmIGIuaWdub3Jl ID4gMDoNCiAgICAgICAgICAgICAgICAgICAgICAgIGIuaWdub3JlID0gYi5pZ25vcmUgLTENCiAg ICAgICAgICAgICAgICAgICAgICAgICMgY29udGludWUNCiAgICAgICAgICAgICAgICAgICAgZWxz ZToNCiAgICAgICAgICAgICAgICAgICAgICAgIHJldHVybiAoYiwxKQ0KICAgICAgICAgICAgICAg ICMgZWxzZToNCiAgICAgICAgICAgICAgICAjICAgY29udGludWUNCiAgICAgICAgICAgIGV4Y2Vw dDoNCiAgICAgICAgICAgICAgICAjIGlmIGV2YWwgZmFpbHMsIG1vc3QgY29uc2VydmF0aXZlDQog ICAgICAgICAgICAgICAgIyB0aGluZyBpcyB0byBzdG9wIG9uIGJyZWFrcG9pbnQNCiAgICAgICAg ICAgICAgICAjIHJlZ2FyZGxlc3Mgb2YgaWdub3JlIGNvdW50Lg0KICAgICAgICAgICAgICAgICMg RG9uJ3QgZGVsZXRlIHRlbXBvcmFyeSwNCiAgICAgICAgICAgICAgICAjIGFzIGFub3RoZXIgaGlu dCB0byB1c2VyLg0KICAgICAgICAgICAgICAgIHJldHVybiAoYiwwKQ0KICAgIHJldHVybiAoTm9u ZSwgTm9uZSkNCg0KIyAtLS0tLS0tLS0tLS0tLS0tLS0tLSB0ZXN0aW5nIC0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNCmNsYXNzIFRkYihCZGIpOg0KICAgIGRlZiB1c2VyX2NhbGwoc2VsZiwgZnJhbWUs IGFyZ3MpOg0KICAgICAgICBuYW1lID0gZnJhbWUuZl9jb2RlLmNvX25hbWUNCiAgICAgICAgaWYg bm90IG5hbWU6IG5hbWUgPSAnPz8/Jw0KICAgICAgICBwcmludCAnKysrIGNhbGwnLCBuYW1lLCBh cmdzDQogICAgZGVmIHVzZXJfbGluZShzZWxmLCBmcmFtZSk6DQogICAgICAgIGltcG9ydCBsaW5l Y2FjaGUNCiAgICAgICAgbmFtZSA9IGZyYW1lLmZfY29kZS5jb19uYW1lDQogICAgICAgIGlmIG5v dCBuYW1lOiBuYW1lID0gJz8/PycNCiAgICAgICAgZm4gPSBzZWxmLmNhbm9uaWMoZnJhbWUuZl9j b2RlLmNvX2ZpbGVuYW1lKQ0KICAgICAgICBsaW5lID0gbGluZWNhY2hlLmdldGxpbmUoZm4sIGZy YW1lLmZfbGluZW5vKQ0KICAgICAgICBwcmludCAnKysrJywgZm4sIGZyYW1lLmZfbGluZW5vLCBu YW1lLCAnOicsIGxpbmUuc3RyaXAoKQ0KICAgIGRlZiB1c2VyX3JldHVybihzZWxmLCBmcmFtZSwg cmV0dmFsKToNCiAgICAgICAgcHJpbnQgJysrKyByZXR1cm4nLCByZXR2YWwNCiAgICBkZWYgdXNl cl9leGNlcHRpb24oc2VsZiwgZnJhbWUsIGV4Y19zdHVmZik6DQogICAgICAgIHByaW50ICcrKysg ZXhjZXB0aW9uJywgZXhjX3N0dWZmDQogICAgICAgIHNlbGYuc2V0X2NvbnRpbnVlKCkNCg0KZGVm IGZvbyhuKToNCiAgICBwcmludCAnZm9vKCcsIG4sICcpJw0KICAgIHggPSBiYXIobioxMCkNCiAg ICBwcmludCAnYmFyIHJldHVybmVkJywgeA0KDQpkZWYgYmFyKGEpOg0KICAgIHByaW50ICdiYXIo JywgYSwgJyknDQogICAgcmV0dXJuIGEvMg0KDQpkZWYgdGVzdCgpOg0KICAgIHQgPSBUZGIoKQ0K ICAgIHQucnVuKCdpbXBvcnQgYmRiOyBiZGIuZm9vKDEwKScpDQoNCiMgZW5kDQo= UNSPECIFIED text/plain IyB0ZXN0IHByb2dyYW0gZm9yIGJkYiBidWdsZXQuCiMgdXNhZ2U6CiMgaW1wb3J0IHBkYiwgYmRi dGVzdAojIHBkYi5ydW5jYWxsKGJkYnRlc3QudGVzdCkKIwojIHRoZW4sIGluIHRoZSBkZWJ1Z2dl ciwgdHlwZSAiYiAxMyI6CgpkZWYgdGVzdCgpOgoJYT0wCglhPTEKCWE9MgoJYT0zCglhPTQKCWE9 NQoJYT02CglhPTcKCWE9OAoJYT05CgojIHRoZSBicmVha3BvaW50IHdpbGwgYmUgYXQgImE9NCIK IyBub3cgdHJ5IHRvIGNvbnRpbnVlIHdpdGggImMiLCBhbmQgeW91CiMgd2lsbCBzZWUgaXQgc3Rp bGwgc2luZ2xlIHN0ZXBwaW5nLgo= 2000-07-31T21:14:00Z sf210683 Jitterbug-Id: 403 Submitted-By: falk.lehmann@gmx.net Date: Mon, 17 Jul 2000 21:59:56 -0400 (EDT) Version: 1.6a2 OS: WinNT 4.0 I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00. The compiler stops with some warnings and an error message: K:\Projects\Python-1.6a2\Modules\socketmodule.c(2081) : error C2099: initializer is not a constant K:\Projects\Python-1.6a2\Modules\socketmodule.c(1947) : warning C4047: 'function' : 'int ' differs in levels of indirection from 'void *' K:\Projects\Python-1.6a2\Modules\socketmodule.c(1947) : warning C4024: 'memset' : different types for formal and actual parameter 2 K:\Projects\Python-1.6a2\Modules\socketmodule.c(1948) : warning C4047: 'function' : 'int ' differs in levels of indirection from 'void *' K:\Projects\Python-1.6a2\Modules\socketmodule.c(1948) : warning C4024: 'memset' : different types for formal and actual parameter 2 K:\Projects\Python-1.6a2\Modules\socketmodule.c(1933) : warning C4101: 'str' : unreferenced local variable K:\Projects\Python-1.6a2\Modules\socketmodule.c(2083) : warning C4047: 'initializing' : 'int ' differs in levels of indirection from 'char [4]' K:\Projects\Python-1.6a2\Modules\socketmodule.c(2084) : warning C4047: 'initializing' : 'char *' differs in levels of indirection from 'unsigned int ' K:\Projects\Python-1.6a2\Modules\socketmodule.c(2087) : warning C4047: 'initializing' : 'int ' differs in levels of indirection from 'void (__cdecl *)(struct _object *)' K:\Projects\Python-1.6a2\Modules\socketmodule.c(2089) : warning C4047: 'initializing' : 'int (__cdecl *)(struct _object *,struct _iobuf *,int )' differs in levels of indirection from 'struct _object *(__cdecl *)(struct _object *,char *)' Thanks in advance for fixing (at least the error). Falk ==================================================================== Audit trail: Tue Jul 25 07:25:55 2000 guido changed notes Tue Jul 25 07:25:55 2000 guido moved from incoming to open Bug Importer REJECTED MEDIUM feature-request Moshez-users windows Bug Importer Bug Importer 2000-07-31T21:14:00Z Jitterbug-Id: 403 Submitted-By: falk.lehmann@gmx.net Date: Mon, 17 Jul 2000 21:59:56 -0400 (EDT) Version: 1.6a2 OS: WinNT 4.0 I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00. The compiler stops with some warnings and an error message: K:\Projects\Python-1.6a2\Modules\socketmodule.c(2081) : error C2099: initializer is not a constant K:\Projects\Python-1.6a2\Modules\socketmodule.c(1947) : warning C4047: 'function' : 'int ' differs in levels of indirection from 'void *' K:\Projects\Python-1.6a2\Modules\socketmodule.c(1947) : warning C4024: 'memset' : different types for formal and actual parameter 2 K:\Projects\Python-1.6a2\Modules\socketmodule.c(1948) : warning C4047: 'function' : 'int ' differs in levels of indirection from 'void *' K:\Projects\Python-1.6a2\Modules\socketmodule.c(1948) : warning C4024: 'memset' : different types for formal and actual parameter 2 K:\Projects\Python-1.6a2\Modules\socketmodule.c(1933) : warning C4101: 'str' : unreferenced local variable K:\Projects\Python-1.6a2\Modules\socketmodule.c(2083) : warning C4047: 'initializing' : 'int ' differs in levels of indirection from 'char [4]' K:\Projects\Python-1.6a2\Modules\socketmodule.c(2084) : warning C4047: 'initializing' : 'char *' differs in levels of indirection from 'unsigned int ' K:\Projects\Python-1.6a2\Modules\socketmodule.c(2087) : warning C4047: 'initializing' : 'int ' differs in levels of indirection from 'void (__cdecl *)(struct _object *)' K:\Projects\Python-1.6a2\Modules\socketmodule.c(2089) : warning C4047: 'initializing' : 'int (__cdecl *)(struct _object *,struct _iobuf *,int )' differs in levels of indirection from 'struct _object *(__cdecl *)(struct _object *,char *)' Thanks in advance for fixing (at least the error). Falk ==================================================================== Audit trail: Tue Jul 25 07:25:55 2000 guido changed notes Tue Jul 25 07:25:55 2000 guido moved from incoming to open Bug Importer 2000-08-01T21:01:00Z From: Guido van Rossum <guido@beopen.com> Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403) Date: Mon, 24 Jul 2000 11:35:24 -0500 > I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00. Please try the current CVS tree (on its way to 2.0); we have no problems compiling this on VC 6.0. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) Bug Importer 2000-08-01T21:02:00Z Windows compile fails when using openSSL. Bug Importer 2000-08-01T21:02:00Z From: Guido van Rossum <guido@beopen.com> Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403) Date: Mon, 24 Jul 2000 14:00:20 -0500 > sorry, but forgot to write, that I switched on the USE_SSL macro. > And then the _socket module does not compile. It appears that the Python SSL code hasn't been ported to Windows. We'll add this to our TODO list, but it's low priority... Perhaps you could give it a shot yourself? See www.python.org/patches/ for how to contribute. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) Bug Importer 2000-08-01T21:02:00Z From: Falk Lehmann <Falk.Lehmann@gmx.net> Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403) Date: Mon, 24 Jul 2000 13:46:45 -0500 [magical fwd by GvR] Guido, sorry, but forgot to write, that I switched on the USE_SSL macro. And then the _socket module does not compile. Falk > > I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00. > > Please try the current CVS tree (on its way to 2.0); we have no > problems compiling this on VC 6.0. > > --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) > Jeremy Hylton 2000-08-23T17:35:00Z This is a bug. Standard extensions modules should compile, even on obscure platforms like Windows NT. Need a Windows user with time to install OpenSSL to fix this. Guido van Rossum 2000-08-30T19:01:00Z Let's not worry about this for 2.0. While the OpenSSL support is part of the socket module, we don't have the resources right now to port that support to Windows. Jeremy Hylton 2000-09-07T22:05:00Z Please do triage on this bug. Fred Drake 2000-09-07T22:08:00Z As we've discussed, this is not an issue for 2.0. Assigned to Tim for resurrection when appropriate since this is Windows-specific. Tim Peters 2000-09-16T02:07:00Z Moved to PEP42, awaiting a volunteer can do this. Bug Importer 2001-08-06T19:48:00Z Now that Python 2.1 is out, it sure would be nice to run Python URL-grabbers on Win systems! The list o' messages for this item suggests that you'be been waiting since September 2000 for a volunteer to fix PR #403, and if I could I would but I can't. Do the Lords of SourceForge have a guess at the odds that this will make it into a version of the Win distribution for Python anytime "soon" (eg, by, say, Halloween 2001)? Thanks! Peter Tim Peters 2001-08-06T21:23:00Z Reassigned to Moshe, cuz he's the last person I recall making any kind of serious noise about cleaning up the SLL mess. Peter, you don't need SSL support to grab URLs on Windows! It sounds like you're waiting for something you don't need. socketmodule.c works fine on Windows Python, and has for years; it's only the SSL *extension* nobody has ported to Windows. 2000-07-31T21:14:00Z sf210684 Jitterbug-Id: 406 Submitted-By: howard_b_golden@yahoo.com Date: Thu, 20 Jul 2000 20:18:12 -0400 (EDT) Version: 1.5.2 OS: Windows 9x/NT/2000 On Windows 9x/NT/2000, os.system() doesn't return the exit code because COMMAND.COM doesn't. To make os.system() on Windows work like os.system() on Unix (a Good Idea-TM), implement os.system on Windows using code similar to what was suggested by Cary Evans in http://www.python.org/pipermail/python-list/1999-May/009409.html . (Note: It seems to me that this change is consistent with the recent change to posixmodule.c to make os.popen() work the same on Windows as Unix.) ==================================================================== Audit trail: Tue Jul 25 07:27:58 2000 guido moved from incoming to open Bug Importer REJECTED MEDIUM platform-specific windows Bug Importer Bug Importer 2000-07-31T21:14:00Z Jitterbug-Id: 406 Submitted-By: howard_b_golden@yahoo.com Date: Thu, 20 Jul 2000 20:18:12 -0400 (EDT) Version: 1.5.2 OS: Windows 9x/NT/2000 On Windows 9x/NT/2000, os.system() doesn't return the exit code because COMMAND.COM doesn't. To make os.system() on Windows work like os.system() on Unix (a Good Idea-TM), implement os.system on Windows using code similar to what was suggested by Cary Evans in http://www.python.org/pipermail/python-list/1999-May/009409.html . (Note: It seems to me that this change is consistent with the recent change to posixmodule.c to make os.popen() work the same on Windows as Unix.) ==================================================================== Audit trail: Tue Jul 25 07:27:58 2000 guido moved from incoming to open Bug Importer 2000-08-01T21:02:00Z From: "Tim Peters" <tim_one@email.msn.com> Subject: RE: [Python-bugs-list] "Fix" os.system() on Windows (PR#406) Date: Sun, 23 Jul 2000 16:42:46 -0400 [Howard B. Golden] > So it can be done, but it's not a simple fix, because you have to > distinguish between command.com builtin commands and external > commands. I'll look at Tcl to see what's involved. It sounds like > it's far more trouble than it's worth! Alas, it's much worse than just guessing which cmds are builtin on your current flavor of Windows. > It is my "wish" to clean up MS's design glitches, but I guess they > put them there for a reason (incompatibility, perhaps?). Not really. DOS and Windows ran on much feebler systems than, e.g., Unix ever ran on, and MS has decades of backward compatibility to worry about too. For example, you'll find a bunch of code in the Tcl source trying to fake pipes on versions of Windows too old to support them directly (Tcl's flavor of "system" is called "exec", and tries to give robust portable meaning to the usual cmdline metasymbols too, like ">" and "|"). The *kind* of executable under Windows can also make a difference, as stuff compiled for the 16-bit subsystem can act differently than that compiled for the 32-bit one, and the ancient Win32s subsystem throws in its own surprises. Tcl tries to make sense out of all of that -- and you *do* need to make sense of it all if you want it to be as usable as it is under Unix. Even so, the Tcl manpages bristle with warnings about things that can still go wrong with "exec" under Windows. It's simply a mess. > ... > Buying a "real shell" is a great idea, in general, but it doesn't fix > the problem on Windows in general, unless you can get everyone to buy > the shell, too. Right -- there's no clear way out of this. > Thanks to you both for considering the suggestion! Oh, it's been under consideration for years <wink>. Last time somebody got excited about this was 1-2 years ago. They ran off to look at the Tcl source too, and were never heard from again <wink/sigh>. Bug Importer 2000-08-01T21:02:00Z From: "Howard B. Golden" <howard_b_golden@yahoo.com> Subject: RE: [Python-bugs-list] "Fix" os.system() on Windows (PR#406) Date: Sun, 23 Jul 2000 13:29:35 -0700 (PDT) Tim Peters wrote: > [Mark Hammond] > > I'm afraid there is a backwards compatibility issue here. > Existing > > code that uses a command.com builtin command will break. > > Indeed, Tcl contains thousands of lines of miserable Win-specific > code > trying to make their version of "system" work correctly. It's A > Project! So it can be done, but it's not a simple fix, because you have to distinguish between command.com builtin commands and external commands. I'll look at Tcl to see what's involved. It sounds like it's far more trouble than it's worth! It is my "wish" to clean up MS's design glitches, but I guess they put them there for a reason (incompatibility, perhaps?). > > Interestingly, this bug in Windows appears to be fixed in > > Windows 2000. I'll check. > IIRC, the correct exit code comes back in NT too -- a command.com > vs cmd.exe > thing (command.com *always* returns a 0 exit code). I had this problem on NT 4.0, too (presumably with cmd.exe). I'll double check. > MS's "system" > does > return the exit code of the thing it spawns, so it's the command > shell that > screws us, not Python's or MS's implementation of "system". The > easiest fix > is to buy a "real shell" and set COMSPEC to point to it (the MS > system uses > COMSPEC to figure out which shell to spawn). Buying a "real shell" is a great idea, in general, but it doesn't fix the problem on Windows in general, unless you can get everyone to buy the shell, too. Thanks to you both for considering the suggestion! Howard __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ Bug Importer 2000-08-01T21:02:00Z From: "Tim Peters" <tim_one@email.msn.com> Subject: RE: [Python-bugs-list] "Fix" os.system() on Windows (PR#406) Date: Sun, 23 Jul 2000 01:06:45 -0400 [Mark Hammond] > I'm afraid there is a backwards compatibility issue here. Existing > code that uses a command.com builtin command will break. Indeed, Tcl contains thousands of lines of miserable Win-specific code trying to make their version of "system" work correctly. It's A Project! > ... > Interestingly, this bug in Windows appears to be fixed in > Windows 2000. IIRC, the correct exit code comes back in NT too -- a command.com vs cmd.exe thing (command.com *always* returns a 0 exit code). MS's "system" does return the exit code of the thing it spawns, so it's the command shell that screws us, not Python's or MS's implementation of "system". The easiest fix is to buy a "real shell" and set COMSPEC to point to it (the MS system uses COMSPEC to figure out which shell to spawn). Here on Win98: C:\tmp>type testit.cpp int main() { return 32; } C:\tmp>cl testit.cpp Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved. testit.cpp Microsoft (R) Incremental Linker Version 6.00.8447 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. /out:testit.exe testit.obj C:\tmp>set COMSPEC=\tmp\testit.exe C:\tmp>\python16\python Python 1.6a2 (#0, Apr 6 2000, 11:45:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import os >>> os.system("blah") 32 >>> That shows Win98 does indeed return the exit code of the shell that gets spawned -- this is a command.com bug. In the absence of a shell that works correctly, not much Python can do about it. Bug Importer 2000-08-01T21:02:00Z From: "Mark Hammond" <mhammond@skippinet.com.au> Subject: RE: [Python-bugs-list] "Fix" os.system() on Windows (PR#406) Date: Sun, 23 Jul 2000 13:46:02 +1000 > To make os.system() on Windows work like os.system() on Unix (a > Good Idea-TM), > implement os.system on Windows using code similar to what was > suggested by Cary > Evans in > http://www.python.org/pipermail/python-list/1999-May/009409.html . I'm afraid there is a backwards compatibility issue here. Existing code that uses a command.com builtin command will break. Eg, the following code works now, but would not work with the proposed patch. os.system("copy whatever somewhereelse") > (Note: It seems to me that this change is consistent with the > recent change to > posixmodule.c to make os.popen() work the same on Windows as Unix.) I agree in principle - however, any fix must not break existing code. Interestingly, this bug in Windows appears to be fixed in Windows 2000. Eg: >>> os.system('python.exe -c "import sys;sys.exit(2)') 'python.exe' is not recognized as an internal or external command, operable program or batch file. 1 >>> os.system('\\src\\python-cvs\\pcbuild\\python.exe -c "import sys;sys.exit(2)') 2 >>> os.system('\\src\\python-cvs\\pcbuild\\python.exe -c "import sys;sys.exit(255)') 255 >>> Mark. Jeremy Hylton 2000-08-01T21:04:00Z Making os.system work on Windows the way it does on Unix requires a lot of complex code (see Perl & Tcl). We'd rather that Windows programmers use the win32 api. 2000-07-31T21:14:00Z sf210685 Jitterbug-Id: 408 Submitted-By: thomas.mangin@free.fr Date: Sun, 23 Jul 2000 08:39:25 -0400 (EDT) Version: 1.5.2 OS: Linux This report is not a "Bug" report but more a library "Misbehaviouring" report. I am concern about os.path.isdir return code. (this can probably applied to isfile) The return code express a boolean value : the file is a directory or not. But I notice that if you don't have read access into the directory where the file is stored, the function always return 0. Or the path can refer a directory, returning 0 simply isn't right. I beleve an exception must be raised to inform the programmer about this access right problem and must be silently ignored. ==================================================================== Audit trail: Mon Jul 24 18:32:17 2000 jeremy moved from incoming to open Bug Importer REJECTED MEDIUM Guido van Rossum Bug Importer Bug Importer 2000-07-31T21:14:00Z Jitterbug-Id: 408 Submitted-By: thomas.mangin@free.fr Date: Sun, 23 Jul 2000 08:39:25 -0400 (EDT) Version: 1.5.2 OS: Linux This report is not a "Bug" report but more a library "Misbehaviouring" report. I am concern about os.path.isdir return code. (this can probably applied to isfile) The return code express a boolean value : the file is a directory or not. But I notice that if you don't have read access into the directory where the file is stored, the function always return 0. Or the path can refer a directory, returning 0 simply isn't right. I beleve an exception must be raised to inform the programmer about this access right problem and must be silently ignored. ==================================================================== Audit trail: Mon Jul 24 18:32:17 2000 jeremy moved from incoming to open Jeremy Hylton 2000-09-07T22:04:00Z Please do triage on this bug. Guido van Rossum 2000-09-13T10:29:00Z You are wrong. isdir() should never raise an exception. What good is it to know that it is a directory if you can't access it? If you want an exception, use os.stat(). 2000-07-31T21:14:00Z sf210686 Jitterbug-Id: 409 Submitted-By: pierre@saiph.com Date: Sun, 23 Jul 2000 13:41:59 -0400 (EDT) Version: 1.5.2 OS: sparc solaris cStringIO is supposed to be the C version of For some reason, it does not provide the readlines method. The obvious turnaround is to use StringIO instead: no hurry to fix, at least on my side. ==================================================================== Audit trail: Mon Jul 24 18:41:02 2000 jeremy moved from incoming to open Bug Importer FIXRELEASED MEDIUM feature-request barry extension-modules Bug Importer Bug Importer 2000-07-31T21:14:00Z Jitterbug-Id: 409 Submitted-By: pierre@saiph.com Date: Sun, 23 Jul 2000 13:41:59 -0400 (EDT) Version: 1.5.2 OS: sparc solaris cStringIO is supposed to be the C version of For some reason, it does not provide the readlines method. The obvious turnaround is to use StringIO instead: no hurry to fix, at least on my side. ==================================================================== Audit trail: Mon Jul 24 18:41:02 2000 jeremy moved from incoming to open Martin von Löwis 2000-09-05T20:11:00Z Fixed in Patch #101423, http://sourceforge.net/patch/?func=detailpatch&patch_id=101423&group_id=5470 Jeremy Hylton 2000-09-07T22:03:00Z Please do triage on this bug. barry 2000-09-16T22:00:00Z Added to PEP 42 Martin von Löwis 2000-09-19T13:41:00Z Fixed in cStringIO.c 2.26 2000-07-31T21:14:00Z sf210687 Jitterbug-Id: 414 Submitted-By: arb@anand.org Date: Wed, 26 Jul 2000 12:23:32 -0400 (EDT) Version: 1.5.2 OS: i386-Redhat-linux 6.2 I'm using the "mailbox" module that comes with python. I'm trying to use the maildir class in there, but I think it's not following the maildir protocol properly. The maildir protocol specifies that in a Maildir, a message file can have any name that is unique, as long as it doesn't begin with a period. However, the maildir class looks for valid message filenames, by checking to see if the filename has more than 1 period in it, ie. consists of 3 or more sections separated by periods. Typically, this is the sort of name one finds in a Maildir, because the Maildir protocol page describes one simple way of creating a unique filename, ie. by using the timestamp, pid of the writer, and the hostname. However, when I insert messages into a maildir which don't follow that system of generating unique filenames, the maildir class of the module doesn't see them. Additioanlly, it _does_ see message files which begin with a period, eg. .12345678.1234.hostname. This is also a violation of the maildir protocol. I believe that a maildir reader should simply look at all files in a maildir, no matter what the name, except for those that begin with a period. ==================================================================== Audit trail: Wed Jul 26 18:15:33 2000 guido moved from incoming to open Bug Importer FIXRELEASED LOW Fred Drake python-library Bug Importer Bug Importer 2000-07-31T21:14:00Z Jitterbug-Id: 414 Submitted-By: arb@anand.org Date: Wed, 26 Jul 2000 12:23:32 -0400 (EDT) Version: 1.5.2 OS: i386-Redhat-linux 6.2 I'm using the "mailbox" module that comes with python. I'm trying to use the maildir class in there, but I think it's not following the maildir protocol properly. The maildir protocol specifies that in a Maildir, a message file can have any name that is unique, as long as it doesn't begin with a period. However, the maildir class looks for valid message filenames, by checking to see if the filename has more than 1 period in it, ie. consists of 3 or more sections separated by periods. Typically, this is the sort of name one finds in a Maildir, because the Maildir protocol page describes one simple way of creating a unique filename, ie. by using the timestamp, pid of the writer, and the hostname. However, when I insert messages into a maildir which don't follow that system of generating unique filenames, the maildir class of the module doesn't see them. Additioanlly, it _does_ see message files which begin with a period, eg. .12345678.1234.hostname. This is also a violation of the maildir protocol. I believe that a maildir reader should simply look at all files in a maildir, no matter what the name, except for those that begin with a period. ==================================================================== Audit trail: Wed Jul 26 18:15:33 2000 guido moved from incoming to open Bug Importer 2000-08-01T21:02:00Z From: Guido van Rossum <guido@beopen.com> Subject: Re: [Python-bugs-list] mailbox module's maildir class broken? (PR#414) Date: Wed, 26 Jul 2000 17:31:29 -0500 > I'm using the "mailbox" module that comes with python. I'm trying to > use the maildir class in there, but I think it's not following the > maildir protocol properly. The maildir protocol specifies that in a > Maildir, a message file can have any name that is unique, as long as > it doesn't begin with a period. However, the maildir class looks > for valid message filenames, by checking to see if the filename has > more than 1 period in it, ie. consists of 3 or more sections > separated by periods. Typically, this is the sort of name one finds > in a Maildir, because the Maildir protocol page describes one simple > way of creating a unique filename, ie. by using the timestamp, pid > of the writer, and the hostname. However, when I insert messages > into a maildir which don't follow that system of generating unique > filenames, the maildir class of the module doesn't see > them. Additioanlly, it _does_ see message files which begin with a > period, eg. .12345678.1234.hostname. This is also a violation of the > maildir protocol. I believe that a maildir reader should simply look > at all files in a maildir, no matter what the name, except for those > that begin with a period. You're probably right. I've never used that code, and according to the logs it was contributed to Mike Meyer (no email known). Perhaps you would be willing to create a patch? See http://www.python.org/patches/ for submission guidelines. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) Thomas Wouters 2000-08-05T18:45:00Z This bug is still present. Fred is/was working on the 'mailbox' module, but I do not know whether he'll fix this, too. If not, I'll do it, it's not that big a chance. Jeremy Hylton 2000-09-07T22:01:00Z Please do triage on this bug. Fred Drake 2000-09-22T18:42:00Z Fixed in Lib/mailbox.py revision 1.24. 2000-07-31T21:14:00Z sf210688 Jitterbug-Id: 43 Submitted-By: Guido van Rossum <guido@CNRI.Reston.VA.US> Date: Fri, 30 Jul 1999 13:52:16 -0400 Version: None OS: None ------- Forwarded Message Date: Tue, 20 Jul 1999 10:53:34 +0300 From: Reuben Sumner <rasumner@iname.com> To: guido@python.org Subject: Py_REF_COUNT I posted a message through DejaNews which didn't seem to propogate (at least it didn't reach here). Try the following in a Python with Py_REF_DEBUG but without Py_TRACE_REFS class C: def __init__(self): pass while 1: c=C() Stop it after a while and look at the reference count printed! Python is not actually using all that memory though. With Py_TRACE_REFS things are ok. I can't figure it out. The class instance dealloc routine is rather hairy. With Py_TRACE_REFS some code of mine is doing some really bizarre things but I would rather deal with one thing at a time. Python version is 1.5.2 (tried on at least two platforms, both using gcc) Many thanks, Reuben ------- End of Forwarded Message ==================================================================== Audit trail: Wed Aug 04 12:12:39 1999 guido moved from incoming to open Bug Importer FIXRELEASED LOW Tim Peters python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:14:00Z Jitterbug-Id: 43 Submitted-By: Guido van Rossum <guido@CNRI.Reston.VA.US> Date: Fri, 30 Jul 1999 13:52:16 -0400 Version: None OS: None ------- Forwarded Message Date: Tue, 20 Jul 1999 10:53:34 +0300 From: Reuben Sumner <rasumner@iname.com> To: guido@python.org Subject: Py_REF_COUNT I posted a message through DejaNews which didn't seem to propogate (at least it didn't reach here). Try the following in a Python with Py_REF_DEBUG but without Py_TRACE_REFS class C: def __init__(self): pass while 1: c=C() Stop it after a while and look at the reference count printed! Python is not actually using all that memory though. With Py_TRACE_REFS things are ok. I can't figure it out. The class instance dealloc routine is rather hairy. With Py_TRACE_REFS some code of mine is doing some really bizarre things but I would rather deal with one thing at a time. Python version is 1.5.2 (tried on at least two platforms, both using gcc) Many thanks, Reuben ------- End of Forwarded Message ==================================================================== Audit trail: Wed Aug 04 12:12:39 1999 guido moved from incoming to open Jeremy Hylton 2000-08-28T18:52:00Z This report is a bit too vague to be useful. I've queried the original poster to see if he is still having problems. Jeremy Hylton 2000-09-07T22:06:00Z Please do triage on this bug. Tim Peters 2000-09-17T14:40:00Z Fixed and closed. Checkin comment: Fix for SF bug 110688: Instance deallocation neglected to account for that Py_INCREF boosts global _Py_RefTotal when Py_REF_DEBUG is defined by Py_TRACE_REFS isn't. There are, IMO, way too many preprocessor gimmicks in use for refcount debugging (at least 3 distinct true/false symbols, but not all 8 combos are supported by the code, etc etc), and no coherent documentation of this stuff -- 'twas too painful to track this one down. 2000-07-31T21:15:00Z sf210689 Jitterbug-Id: 45 Submitted-By: skip@mojam.com Date: Wed, 4 Aug 1999 11:55:04 -0400 (EDT) Version: 1.5.2 OS: Linux I just tried using the readline/rlcompleter stuff in my own program for the first time. I noticed that when using the completion key to complete an input from a set of choices it tacks on an extra space to the end of the string. This seems like a bug to me. There's no way for the program to know if the enter typed the space explicitly or if it was appended by raw_input(). Is this perhaps a readline bug? I haven't delved into the source code at this point. Here's a script that demonstrates the problem. Try running it three times, once entering s TAB RET once entering spam RET and once entering spam SPC RET You will see that the first and third cases are indistinguishable. #!/usr/bin/env python import string, readline, rlcompleter, sys class Completer: def __init__(self): self.list = [] def complete(self, text, state): if state == 0: self.matches = self.get_matches(text) try: return self.matches[state] except IndexError: return None def set_choices(self, list): self.list = list def get_matches(self, text): matches = [] for elt in self.list: if string.find(elt, text) == 0: matches.append(elt) return matches completer = Completer() def select_from_list(list): completer.set_choices(list) readline.parse_and_bind("tab: complete") readline.set_completer(completer.complete) sys.stderr.write("Select from [%s]: " % string.join(list, "|")) result = raw_input() return result result = select_from_list(["spam", "ham", "eggs", "juice"]) print `result`, ord(result[-1]) ==================================================================== Audit trail: Wed Aug 04 12:12:40 1999 guido moved from incoming to open Bug Importer REJECTED MEDIUM not-a-bug Thomas Wouters extension-modules Bug Importer Bug Importer 2000-07-31T21:15:00Z Jitterbug-Id: 45 Submitted-By: skip@mojam.com Date: Wed, 4 Aug 1999 11:55:04 -0400 (EDT) Version: 1.5.2 OS: Linux I just tried using the readline/rlcompleter stuff in my own program for the first time. I noticed that when using the completion key to complete an input from a set of choices it tacks on an extra space to the end of the string. This seems like a bug to me. There's no way for the program to know if the enter typed the space explicitly or if it was appended by raw_input(). Is this perhaps a readline bug? I haven't delved into the source code at this point. Here's a script that demonstrates the problem. Try running it three times, once entering s TAB RET once entering spam RET and once entering spam SPC RET You will see that the first and third cases are indistinguishable. #!/usr/bin/env python import string, readline, rlcompleter, sys class Completer: def __init__(self): self.list = [] def complete(self, text, state): if state == 0: self.matches = self.get_matches(text) try: return self.matches[state] except IndexError: return None def set_choices(self, list): self.list = list def get_matches(self, text): matches = [] for elt in self.list: if string.find(elt, text) == 0: matches.append(elt) return matches completer = Completer() def select_from_list(list): completer.set_choices(list) readline.parse_and_bind("tab: complete") readline.set_completer(completer.complete) sys.stderr.write("Select from [%s]: " % string.join(list, "|")) result = raw_input() return result result = select_from_list(["spam", "ham", "eggs", "juice"]) print `result`, ord(result[-1]) ==================================================================== Audit trail: Wed Aug 04 12:12:40 1999 guido moved from incoming to open Bug Importer 2000-08-01T21:02:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] PRIVATE: Extra space bug in readline/rlcompleter/raw_input? (PR#45) Date: Wed, 04 Aug 1999 12:09:13 -0400 > I just tried using the readline/rlcompleter stuff in my own > program for the first time. I noticed that when using the > completion key to complete an input from a set of choices it > tacks on an extra space to the end of the string. This seems > like a bug to me. There's no way for the program to know if the > enter typed the space explicitly or if it was appended by > raw_input(). Is this perhaps a readline bug? I haven't delved > into the source code at this point. As far as I know this is a problem with the completion strategy hardcoded in the GNU readline code. I don't know of a fix. --Guido van Rossum (home page: http://www.python.org/~guido/) Thomas Wouters 2000-08-06T20:34:00Z I agree with Guido: the extra space is added by Readline, for the simple purpose of distinguishing between a successful, unambiguous completion, and a half-finished completion that stopped at the first 'junction'. In other words, in the 'namespace' containing 'eggs', 'spamandham' and 'spamandeggs', eg<TAB> will complete to 'eggs<SPACE>' because it's a finished completion, but spa<TAB> will complete to 'spamand', (without a space), so you know you have more possible completions. If you disambiguate by continuing it with 'h', and then press TAB again, it gets expanded into 'spamandham<SPACE>'. One possible solution is to never return a single possibility, but always a dummy possibility as well. Not very pretty, and not very nice if you use TABTAB (list all possible completions) but it should work. The other solutions is to provide a replacement for readline :-) 2000-07-31T21:15:00Z sf210690 Jitterbug-Id: 50 Submitted-By: bobalex@uppercase.xerox.com Date: Wed, 11 Aug 1999 19:19:16 -0400 (EDT) Version: 1.5.2 OS: WinNT os.environ for Windows appears to be a map-type object that converts its keys to upper case. Retrieval using a mixed case key works in some cases, but some overloaded "operators" don't seem to do the right thing unless I pass an all-upper-case key. E.g.: >>> os.environ["x"] = "y" # Stores pair {"X": "y"} >>> os.environ["x"] # Works, indicates an effort is made 'y' # to retrieve mixed case keys >>> os.environ.get("x", "NOT FOUND") # Doesn't see the key "x" 'NOT FOUND' >>> os.environ.get("X", "NOT FOUND") # Works with all-upper-case key 'y' >>> del os.environ["x"] # Doesn't see the key "x" Traceback (innermost last): File "<stdin>", line 1, in ? File "E:\Program Files\Python\Lib\UserDict.py", line 16, in __delitem__ def __delitem__(self, key): del self.data[key] KeyError: x >>> del os.environ["X"] # Works with all-upper-case key ==================================================================== Audit trail: Mon Aug 30 12:33:44 1999 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM Guido van Rossum windows Bug Importer Bug Importer 2000-07-31T21:15:00Z Jitterbug-Id: 50 Submitted-By: bobalex@uppercase.xerox.com Date: Wed, 11 Aug 1999 19:19:16 -0400 (EDT) Version: 1.5.2 OS: WinNT os.environ for Windows appears to be a map-type object that converts its keys to upper case. Retrieval using a mixed case key works in some cases, but some overloaded "operators" don't seem to do the right thing unless I pass an all-upper-case key. E.g.: >>> os.environ["x"] = "y" # Stores pair {"X": "y"} >>> os.environ["x"] # Works, indicates an effort is made 'y' # to retrieve mixed case keys >>> os.environ.get("x", "NOT FOUND") # Doesn't see the key "x" 'NOT FOUND' >>> os.environ.get("X", "NOT FOUND") # Works with all-upper-case key 'y' >>> del os.environ["x"] # Doesn't see the key "x" Traceback (innermost last): File "<stdin>", line 1, in ? File "E:\Program Files\Python\Lib\UserDict.py", line 16, in __delitem__ def __delitem__(self, key): del self.data[key] KeyError: x >>> del os.environ["X"] # Works with all-upper-case key ==================================================================== Audit trail: Mon Aug 30 12:33:44 1999 guido moved from incoming to open Fred Drake 2000-09-07T17:34:00Z Fixed at some point in the past. Tested OK using 2.0b1 on Win2K. Jeremy Hylton 2000-09-07T22:04:00Z Please do triage on this bug. Guido van Rossum 2000-09-13T10:30:00Z This was fixed by os.py version 1.31 in April 2000, by Fred Gansevles. 2000-07-31T21:15:00Z sf210691 Jitterbug-Id: 53 Submitted-By: tm@funcom.com Date: Mon, 16 Aug 1999 09:58:05 -0400 (EDT) Version: latest from CVS OS: Linux 2.2.10 libc5.3.12 When doing make test on the latest(as of 16 Aug 1999) python version, the popen2 and socket tests fail. output from test_popen2: testing popen2... Traceback (innermost last): File "test_popen2.py", line 16, in ? main() File "test_popen2.py", line 14, in main popen2._test() File "../../Lib/popen2.py", line 84, in _test r, w = popen2('cat') File "../../Lib/popen2.py", line 73, in popen2 inst = Popen3(cmd, 0, bufsize) File "../../Lib/popen2.py", line 24, in __init__ os.close(0) OSError: [Errno 9] Bad file number Traceback (innermost last): File "test_popen2.py", line 16, in ? main() File "test_popen2.py", line 14, in main popen2._test() File "../../Lib/popen2.py", line 87, in _test assert r.read() == teststr AssertionError output from test_socket: socket.error Traceback (innermost last): File "test_socket.py", line 71, in ? ip = socket.gethostbyname(hostname) socket.error: host not found ==================================================================== Audit trail: Mon Aug 16 10:13:57 1999 guido changed notes Mon Aug 16 10:13:57 1999 guido moved from incoming to notabug Mon Aug 16 10:15:22 1999 guido sent reply 1 Mon Aug 16 13:33:03 1999 guido changed notes Mon Aug 16 14:24:25 1999 guido changed notes Mon Aug 16 14:24:25 1999 guido moved from notabug to open Wed Jul 26 18:27:01 2000 guido resent 53.reply.1 Bug Importer FIXRELEASED MEDIUM not-a-bug extension-modules Bug Importer Bug Importer 2000-07-31T21:15:00Z Jitterbug-Id: 53 Submitted-By: tm@funcom.com Date: Mon, 16 Aug 1999 09:58:05 -0400 (EDT) Version: latest from CVS OS: Linux 2.2.10 libc5.3.12 When doing make test on the latest(as of 16 Aug 1999) python version, the popen2 and socket tests fail. output from test_popen2: testing popen2... Traceback (innermost last): File "test_popen2.py", line 16, in ? main() File "test_popen2.py", line 14, in main popen2._test() File "../../Lib/popen2.py", line 84, in _test r, w = popen2('cat') File "../../Lib/popen2.py", line 73, in popen2 inst = Popen3(cmd, 0, bufsize) File "../../Lib/popen2.py", line 24, in __init__ os.close(0) OSError: [Errno 9] Bad file number Traceback (innermost last): File "test_popen2.py", line 16, in ? main() File "test_popen2.py", line 14, in main popen2._test() File "../../Lib/popen2.py", line 87, in _test assert r.read() == teststr AssertionError output from test_socket: socket.error Traceback (innermost last): File "test_socket.py", line 71, in ? ip = socket.gethostbyname(hostname) socket.error: host not found ==================================================================== Audit trail: Mon Aug 16 10:13:57 1999 guido changed notes Mon Aug 16 10:13:57 1999 guido moved from incoming to notabug Mon Aug 16 10:15:22 1999 guido sent reply 1 Mon Aug 16 13:33:03 1999 guido changed notes Mon Aug 16 14:24:25 1999 guido changed notes Mon Aug 16 14:24:25 1999 guido moved from notabug to open Wed Jul 26 18:27:01 2000 guido resent 53.reply.1 Bug Importer 2000-08-01T21:02:00Z His Linux has a 5-arg gethostbyname() instead of a 6-arg gethostbyname(). This should really be determined in a more foolproof way in the configure script! Bug Importer 2000-08-01T21:02:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] Re: popen2 and socket. (PR#53) Date: Mon, 16 Aug 1999 14:22:49 -0400 > I finally found it, in socketmodule.c O replaced this: > > #elif defined(linux) > #define HAVE_GETHOSTBYNAME_R_6_ARG > #else > > with this: > > #elif defined(linux) > #define HAVE_GETHOSTBYNAME_R_5_ARG > #else > > And everything worked. Strange that nobody else has noticed this, > maybe it's a libc versus glibc thing or something. > > Anyway, thanks for your time. Ah, thanks! As you say, this is probably dependent on your libc version. A better solution should be found, really... I'll mark the bug report as "open". --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-08-01T21:02:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] Re: popen2 and socket. (PR#53) Date: Mon, 16 Aug 1999 13:21:56 -0400 > Something else is going on, I built python 1.5.1 and 1.5.2 on the > exact same machine with exact same configure statements: > > Python 1.5.2 (#9, Aug 16 1999, 19:08:25) [GCC egcs-2.91.66 19990314 (egcs-1.1.2 on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> import socket > >>> socket.gethostbyname("cnn.com") > Traceback (innermost last): > File "<stdin>", line 1, in ? > socket.error: host not found > >>> > > Python 1.5.1 (#4, Aug 16 1999, 18:15:50) [GCC egcs-2.91.66 19990314 (e on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> import socket > >>> socket.gethostbyname("cnn.com") > '207.25.71.12' > >>> > > gethostbyname("localhost") gives the same result, works in 1.5.1, but > not in 1.5.2. Hm, all this works fine on any machine I can test it on, and I haven't heard this problem reported before. So I speculate that somehow your Python 1.5.2 build is broken. I don't know how you help you any further; perhaps you can try the newsgroup -- or just download Oliver Andrich's RPMs... --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-08-01T21:02:00Z From: Terje Malmedal <tm@funcom.com> Subject: Re: [Python-bugs-list] Re: popen2 and socket. (PR#53) Date: Mon, 16 Aug 1999 20:17:39 +0200 [Guido van Rossum] >> Something else is going on, I built python 1.5.1 and 1.5.2 on the >> exact same machine with exact same configure statements: >> >> Python 1.5.2 (#9, Aug 16 1999, 19:08:25) [GCC egcs-2.91.66 19990314 (egcs-1.1.2 on linux2 >> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >> >>> import socket >> >>> socket.gethostbyname("cnn.com") >> Traceback (innermost last): >> File "<stdin>", line 1, in ? >> socket.error: host not found >> >>> >> >> Python 1.5.1 (#4, Aug 16 1999, 18:15:50) [GCC egcs-2.91.66 19990314 (e on linux2 >> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >> >>> import socket >> >>> socket.gethostbyname("cnn.com") >> '207.25.71.12' >> >>> >> >> gethostbyname("localhost") gives the same result, works in 1.5.1, but >> not in 1.5.2. > Hm, all this works fine on any machine I can test it on, and I haven't > heard this problem reported before. So I speculate that somehow your > Python 1.5.2 build is broken. I don't know how you help you any > further; perhaps you can try the newsgroup -- or just download Oliver > Andrich's RPMs... I finally found it, in socketmodule.c O replaced this: #elif defined(linux) #define HAVE_GETHOSTBYNAME_R_6_ARG #else with this: #elif defined(linux) #define HAVE_GETHOSTBYNAME_R_5_ARG #else And everything worked. Strange that nobody else has noticed this, maybe it's a libc versus glibc thing or something. Anyway, thanks for your time. -- - Terje tm@funcom.com Bug Importer 2000-08-01T21:02:00Z From: Terje Malmedal <tm@funcom.com> Subject: Re: [Python-bugs-list] Re: popen2 and socket. (PR#53) Date: Mon, 16 Aug 1999 19:17:59 +0200 [Guido van Rossum] >> [Guido van Rossum] >> > This is not a Python bug. >> > Your network environment has not been set up properly. >> >> Yes it is. The machine is connected to the internet. Everything else, >> including Apache and Perl are able to use the network. >> >> I forgot to mention that Python 1.5.1 works with no problems. > The specific problem is with the DNS. The failing line in > test_socket.py checks that the DNS lookup for the result of > gethostname() succeeds. In your case, it fails. There are tons of > possible reasons why it would fail: perhaps gethostname() returns a > host without a domain, or perhaps your hostname isn't registered in > your DNS. You may be able to fix it by editing /etc/hosts. Something else is going on, I built python 1.5.1 and 1.5.2 on the exact same machine with exact same configure statements: Python 1.5.2 (#9, Aug 16 1999, 19:08:25) [GCC egcs-2.91.66 19990314 (egcs-1.1.2 on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import socket >>> socket.gethostbyname("cnn.com") Traceback (innermost last): File "<stdin>", line 1, in ? socket.error: host not found >>> Python 1.5.1 (#4, Aug 16 1999, 18:15:50) [GCC egcs-2.91.66 19990314 (e on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import socket >>> socket.gethostbyname("cnn.com") '207.25.71.12' >>> gethostbyname("localhost") gives the same result, works in 1.5.1, but not in 1.5.2. -- - Terje tm@funcom.com Bug Importer 2000-08-01T21:02:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] Re: popen2 and socket. (PR#53) Date: Mon, 16 Aug 1999 11:36:25 -0400 > [Guido van Rossum] > > This is not a Python bug. > > Your network environment has not been set up properly. > > Yes it is. The machine is connected to the internet. Everything else, > including Apache and Perl are able to use the network. > > I forgot to mention that Python 1.5.1 works with no problems. The specific problem is with the DNS. The failing line in test_socket.py checks that the DNS lookup for the result of gethostname() succeeds. In your case, it fails. There are tons of possible reasons why it would fail: perhaps gethostname() returns a host without a domain, or perhaps your hostname isn't registered in your DNS. You may be able to fix it by editing /etc/hosts. If (as you say) the rest of the network works fine, you don't have to worry about the two failing tests. --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-08-01T21:02:00Z From: Terje Malmedal <tm@funcom.com> Subject: Re: popen2 and socket. (PR#53) Date: Mon, 16 Aug 1999 16:41:58 +0200 [Guido van Rossum] > This is not a Python bug. > Your network environment has not been set up properly. Yes it is. The machine is connected to the internet. Everything else, including Apache and Perl are able to use the network. I forgot to mention that Python 1.5.1 works with no problems. > Don't worry unless you want to use sockets > (in that case you have to figure out how to set > up your Linux networking; Python will automatically follow). -- - Terje tm@funcom.com Bug Importer 2000-08-01T21:02:00Z From: Guido van Rossum <bugs-py@python.org> Subject: Re: popen2 and socket. (PR#53) Date: Mon Aug 16 10:15:22 1999 This is not a Python bug. Your network environment has not been set up properly. Don't worry unless you want to use sockets (in that case you have to figure out how to set up your Linux networking; Python will automatically follow). 2000-07-31T21:15:00Z sf210692 Jitterbug-Id: 67 Submitted-By: andrew@fc.hp.com Date: Thu, 26 Aug 1999 16:20:02 -0400 (EDT) Version: 1.5.1 OS: When using urllib.URLopener(proxy) (instead of setting _PROXY env variables and calling urllib.openurl(), you get the following error message: File "./watchdog.py", line 118, in main url.open(urltocheck) File "/usr/lib/python1.5/urllib.py", line 158, in open return getattr(self, name)(url) File "/usr/lib/python1.5/urllib.py", line 258, in open_http return addinfourl(fp, headers, "http:" + url) TypeError: illegal argument type for built-in operation When using explicti proxies, url is a tuple instead of a string. You can't concatanate a tuple to a string, so the operation fails. ==================================================================== Audit trail: Mon Aug 30 12:40:45 1999 guido moved from incoming to open Bug Importer FIXRELEASED MEDIUM Jeremy Hylton python-library Bug Importer Bug Importer 2000-07-31T21:15:00Z Jitterbug-Id: 67 Submitted-By: andrew@fc.hp.com Date: Thu, 26 Aug 1999 16:20:02 -0400 (EDT) Version: 1.5.1 OS: When using urllib.URLopener(proxy) (instead of setting _PROXY env variables and calling urllib.openurl(), you get the following error message: File "./watchdog.py", line 118, in main url.open(urltocheck) File "/usr/lib/python1.5/urllib.py", line 158, in open return getattr(self, name)(url) File "/usr/lib/python1.5/urllib.py", line 258, in open_http return addinfourl(fp, headers, "http:" + url) TypeError: illegal argument type for built-in operation When using explicti proxies, url is a tuple instead of a string. You can't concatanate a tuple to a string, so the operation fails. ==================================================================== Audit trail: Mon Aug 30 12:40:45 1999 guido moved from incoming to open Martin von Löwis 2000-09-05T20:27:00Z This is likely incorrect usage of the module. The proxy argument must be a dictionary mapping strings of protocol names to strings of URLs. Jeremy Hylton 2000-09-07T22:05:00Z Please do triage on this bug. Fred Drake 2000-09-14T20:34:00Z Assigned to Jeremy since he's more familiar with this module. Jeremy Hylton 2000-09-15T19:13:00Z This report doesn't make any sense. The method that raises the exception open_http explicitly checks for a url that is a tuple and sets the local var url to be the second element of the tuple. I suspect Martin is right; the submittor used the module incorrectly. Will check by email, but am closing this anyway. 2000-07-31T21:28:00Z sf210693 Jitterbug-Id: 119 Submitted-By: jsb@brodkey.com Date: Tue, 26 Oct 1999 21:37:22 -0400 (EDT) Version: 1.52 OS: Mandrake 6.1 test_long output: long / * % divmod long bit-operation identities long str/hex/oct/atol long miscellaneous operations Traceback (innermost last): File "/home/jerry/python/Python-1.5.2/Lib/test/test_long.py", line 251, in ? test_misc() File "/home/jerry/python/Python-1.5.2/Lib/test/test_long.py", line 225, in test_misc raise TestFailed, "int(long(-sys.maxint-1)) overflowed!" test_support -- test failed: int(long(-sys.maxint-1)) overflowed! test_socket output: socket.error Traceback (innermost last): File "/home/jerry/python/Python-1.5.2/Lib/test/test_socket.py", line 71, in ? ip = socket.gethostbyname(hostname) socket.error: host not found test_types output: 6. Built-in types 6.1 Truth value testing 6.2 Boolean operations 6.3 Comparisons 6.4 Numeric types (mostly conversions) 6.4.1 32-bit integers 6.4.2 Long integers Traceback (innermost last): File "/home/jerry/python/Python-1.5.2/Lib/test/test_types.py", line 89, in ? if int(long(x)) != x: raise TestFailed, 'long op' OverflowError: long int too long to convert ==================================================================== Audit trail: Thu Oct 28 18:55:27 1999 guido changed notes Thu Oct 28 18:55:27 1999 guido moved from incoming to platformbug Bug Importer REJECTED MEDIUM platform-specific Bug Importer Bug Importer 2000-07-31T21:28:00Z Jitterbug-Id: 119 Submitted-By: jsb@brodkey.com Date: Tue, 26 Oct 1999 21:37:22 -0400 (EDT) Version: 1.52 OS: Mandrake 6.1 test_long output: long / * % divmod long bit-operation identities long str/hex/oct/atol long miscellaneous operations Traceback (innermost last): File "/home/jerry/python/Python-1.5.2/Lib/test/test_long.py", line 251, in ? test_misc() File "/home/jerry/python/Python-1.5.2/Lib/test/test_long.py", line 225, in test_misc raise TestFailed, "int(long(-sys.maxint-1)) overflowed!" test_support -- test failed: int(long(-sys.maxint-1)) overflowed! test_socket output: socket.error Traceback (innermost last): File "/home/jerry/python/Python-1.5.2/Lib/test/test_socket.py", line 71, in ? ip = socket.gethostbyname(hostname) socket.error: host not found test_types output: 6. Built-in types 6.1 Truth value testing 6.2 Boolean operations 6.3 Comparisons 6.4 Numeric types (mostly conversions) 6.4.1 32-bit integers 6.4.2 Long integers Traceback (innermost last): File "/home/jerry/python/Python-1.5.2/Lib/test/test_types.py", line 89, in ? if int(long(x)) != x: raise TestFailed, 'long op' OverflowError: long int too long to convert ==================================================================== Audit trail: Thu Oct 28 18:55:27 1999 guido changed notes Thu Oct 28 18:55:27 1999 guido moved from incoming to platformbug Bug Importer 2000-08-01T21:02:00Z This is caused by an optimizer bug (maybe for a particular CPU). Bug Importer 2000-08-01T21:02:00Z From: "Tim Peters" <tim_one@email.msn.com> Subject: RE: [Python-bugs-list] 3 failed tests after install (PR#119) Date: Wed, 27 Oct 1999 23:22:38 -0400 [Jerald s brodkey [mailto:jsb@brodkey.com]] > Thanks for the answer. I recompiled it without optimization and > now and now all tests passed except test_socket which is to be expected. OK! See http://www.deja.com/getdoc.xp?AN=503937876 for a thread about the cause and the cure (it's a known compiler bug). > However: > > Guido also sent an answer and asked if I would run the following > interactively: > sys.maxint > -sys.maxint-1 > long(-sys.maxint-1) > int(long(-sys.maxint-1)) > > I did that on the system compiled with optimization as well as the new one > without. > > All give same output: > Traceback (innermost last): > File"<stdin>" line 1, in ? > NameError: sys > > I gather this is a problem? Na, it just appears you've never used Python before. Spend a little time reading the tutorial -- you'll like it! What Guido didn't tell you (because any Python programmer would know this) is that you first need to enter the line import sys Until you do that, the name "sys" doesn't mean anything to Python, and that's why you're getting the NameError exceptions. See the thread referenced above for the kind of output you *should* see when you enter this. Bug Importer 2000-08-01T21:02:00Z From: "Tim Peters" <tim_one@email.msn.com> Subject: RE: [Python-bugs-list] 3 failed tests after install (PR#119) Date: Wed, 27 Oct 1999 00:53:49 -0400 > Full_Name: jerald s brodkey > Version: 1.52 > OS: Mandrake 6.1 > Submission from: dyn1-tnt1-120.cleveland.oh.ameritech.net > (199.179.175.120) What kind of CPU? > test_support -- test failed: int(long(-sys.maxint-1)) overflowed! Last time I saw this it was eventually traced to a compiler optimization bug, on an Intel platform running some flavor of Unix. If you recompile Python with optimization turned off, and the problem goes away, it's almost certainly the same problem. DejaNews can be used in that case to track down the details. Bug Importer 2000-08-01T21:02:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] 3 failed tests after install (PR#119) Date: Tue, 26 Oct 1999 22:34:23 -0400 There's no reason to submit this as a bug report yet -- most likely this is a platform bug. > Full_Name: jerald s brodkey > Version: 1.52 > OS: Mandrake 6.1 > Submission from: dyn1-tnt1-120.cleveland.oh.ameritech.net (199.179.175.120) > > test_long output: > long / * % divmod > long bit-operation identities > long str/hex/oct/atol > long miscellaneous operations > Traceback (innermost last): > File "/home/jerry/python/Python-1.5.2/Lib/test/test_long.py", line 251, in ? > test_misc() > File "/home/jerry/python/Python-1.5.2/Lib/test/test_long.py", line 225, in > test_misc > raise TestFailed, "int(long(-sys.maxint-1)) overflowed!" > test_support -- test failed: int(long(-sys.maxint-1)) overflowed! Hm. Strange. Can you enter Python interactively and try to print the values of these expressions? sys.maxint -sys.maxint-1 long(-sys.maxint-1) int(long(-sys.maxint-1)) Please save the session and mail to me. > test_socket output: > socket.error > Traceback (innermost last): > File "/home/jerry/python/Python-1.5.2/Lib/test/test_socket.py", line 71, in ? > ip = socket.gethostbyname(hostname) > socket.error: host not found This is common if your internet configuration doesn't have a DNS setup; you can ignore it. > test_types output: > 6. Built-in types > 6.1 Truth value testing > 6.2 Boolean operations > 6.3 Comparisons > 6.4 Numeric types (mostly conversions) > 6.4.1 32-bit integers > 6.4.2 Long integers > Traceback (innermost last): > File "/home/jerry/python/Python-1.5.2/Lib/test/test_types.py", line 89, in ? > if int(long(x)) != x: raise TestFailed, 'long op' > OverflowError: long int too long to convert Looks like the same one you had before. What kind of hardware are you using? I wonder if there's some kind of mismatch between the compiler and the hardware for certain long integer or floating point ops. Did you build this Python yourself or are you running the tests on a binary that came with the OS? (Doesn't Mandrake come with Python? I know Red Hat does!) --Guido van Rossum (home page: http://www.python.org/~guido/) Thomas Wouters 2000-08-06T16:39:00Z Compiler optimizer bugs, probably fixed in recent Mandrake (because they stopped using pgcc, IIRC.) 2000-07-31T21:28:00Z sf210694 Jitterbug-Id: 120 Submitted-By: xfb52@dial.pipex.com Date: Fri, 29 Oct 1999 14:33:55 -0400 (EDT) Version: 1.5.2 OS: FreeBSD 3.2 When python is compiled with thread support and readline, ^C no longer works properly (interpreter goes into an infinite loop). (Tried with readline 2.0, 2.2 and 4.0). The same system compiled without readline but with threads works fine, and compiled without threads but with readline works fine. The error seems to centre around the signal handler installed by call_readline in Modules/readline.c which does not call signal_handler in Modules/signalmodule.c (which is what happens without readline). I have found an inadequate fix which works with readline-4.0 (but not earlier realeases). This makes ^C work but only after a RETURN is pressed. Whilst not perfect, it does at least allow readline and threads. Hopefully this may point someone who can better understand the signal handling to find a better fix. I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. --Alex *** Modules/readline.c Fri Oct 29 19:31:13 1999 --- Modules/readline.c.ORIG Fri Oct 29 19:14:27 1999 *************** *** 34,40 **** extern int rl_bind_key_in_map(); extern int rl_initialize(); extern int add_history(); - extern int rl_catch_signals; extern Function *rl_event_hook; #endif --- 34,39 ---- *************** *** 233,239 **** static void setup_readline() { - rl_catch_signals=0; rl_readline_name = "python"; /* Force rebind of TAB to insert-tab */ rl_bind_key('\t', rl_insert); --- 232,237 ---- *************** *** 277,283 **** int n; char *p; RETSIGTYPE (*old_inthandler)(); ! /* old_inthandler = signal(SIGINT, onintr); */ if (setjmp(jbuf)) { #ifdef HAVE_SIGRELSE /* This seems necessary on SunOS 4.1 (Rasmus Hahn) */ --- 275,281 ---- int n; char *p; RETSIGTYPE (*old_inthandler)(); ! old_inthandler = signal(SIGINT, onintr); if (setjmp(jbuf)) { #ifdef HAVE_SIGRELSE /* This seems necessary on SunOS 4.1 (Rasmus Hahn) */ *************** *** 288,294 **** } rl_event_hook = PyOS_InputHook; p = readline(prompt); ! /* signal(SIGINT, old_inthandler); */ if (p == NULL) { p = malloc(1); if (p != NULL) --- 286,292 ---- } rl_event_hook = PyOS_InputHook; p = readline(prompt); ! signal(SIGINT, old_inthandler); if (p == NULL) { p = malloc(1); if (p != NULL) ==================================================================== Audit trail: Tue Nov 02 20:44:47 1999 guido changed notes Tue Nov 02 20:44:47 1999 guido moved from incoming to platformbug Wed Nov 03 10:41:38 1999 guido changed notes Wed Nov 03 10:41:39 1999 guido changed notes Wed Nov 03 10:44:43 1999 guido changed notes Bug Importer REJECTED MEDIUM platform-specific Guido van Rossum Bug Importer Bug Importer 2000-07-31T21:28:00Z Jitterbug-Id: 120 Submitted-By: xfb52@dial.pipex.com Date: Fri, 29 Oct 1999 14:33:55 -0400 (EDT) Version: 1.5.2 OS: FreeBSD 3.2 When python is compiled with thread support and readline, ^C no longer works properly (interpreter goes into an infinite loop). (Tried with readline 2.0, 2.2 and 4.0). The same system compiled without readline but with threads works fine, and compiled without threads but with readline works fine. The error seems to centre around the signal handler installed by call_readline in Modules/readline.c which does not call signal_handler in Modules/signalmodule.c (which is what happens without readline). I have found an inadequate fix which works with readline-4.0 (but not earlier realeases). This makes ^C work but only after a RETURN is pressed. Whilst not perfect, it does at least allow readline and threads. Hopefully this may point someone who can better understand the signal handling to find a better fix. I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. --Alex *** Modules/readline.c Fri Oct 29 19:31:13 1999 --- Modules/readline.c.ORIG Fri Oct 29 19:14:27 1999 *************** *** 34,40 **** extern int rl_bind_key_in_map(); extern int rl_initialize(); extern int add_history(); - extern int rl_catch_signals; extern Function *rl_event_hook; #endif --- 34,39 ---- *************** *** 233,239 **** static void setup_readline() { - rl_catch_signals=0; rl_readline_name = "python"; /* Force rebind of TAB to insert-tab */ rl_bind_key('\t', rl_insert); --- 232,237 ---- *************** *** 277,283 **** int n; char *p; RETSIGTYPE (*old_inthandler)(); ! /* old_inthandler = signal(SIGINT, onintr); */ if (setjmp(jbuf)) { #ifdef HAVE_SIGRELSE /* This seems necessary on SunOS 4.1 (Rasmus Hahn) */ --- 275,281 ---- int n; char *p; RETSIGTYPE (*old_inthandler)(); ! old_inthandler = signal(SIGINT, onintr); if (setjmp(jbuf)) { #ifdef HAVE_SIGRELSE /* This seems necessary on SunOS 4.1 (Rasmus Hahn) */ *************** *** 288,294 **** } rl_event_hook = PyOS_InputHook; p = readline(prompt); ! /* signal(SIGINT, old_inthandler); */ if (p == NULL) { p = malloc(1); if (p != NULL) --- 286,292 ---- } rl_event_hook = PyOS_InputHook; p = readline(prompt); ! signal(SIGINT, old_inthandler); if (p == NULL) { p = malloc(1); if (p != NULL) ==================================================================== Audit trail: Tue Nov 02 20:44:47 1999 guido changed notes Tue Nov 02 20:44:47 1999 guido moved from incoming to platformbug Wed Nov 03 10:41:38 1999 guido changed notes Wed Nov 03 10:41:39 1999 guido changed notes Wed Nov 03 10:44:43 1999 guido changed notes Bug Importer 2000-08-01T21:02:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] PRIVATE: Threads and readline (PR#120) Date: Mon, 01 Nov 1999 17:53:46 -0500 > When python is compiled with thread support and readline, ^C no longer > works properly (interpreter goes into an infinite loop). > (Tried with readline 2.0, 2.2 and 4.0). Thanks for your bug report. I see that you are using FreeBSD. Could it be a FreeBSD related problem? I don't see the same thing on Solaris or Red Hat Linux. Also, can you describe exactly how you reproduce the problem? --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-08-01T21:02:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] PRIVATE: Threads and readline (PR#120) Date: Wed, 03 Nov 1999 10:40:18 -0500 Resolution. ------- Forwarded Message Date: Wed, 03 Nov 1999 15:24:59 +0000 From: Alex Zbyslaw <xfb52@dial.pipex.com> To: guido@cnri.reston.va.us Subject: Re: [Python-bugs-list] PRIVATE: Threads and readline I believe that you were right and that this is a FreeBSD bug. I finally traced the problem back to the use of the setjmp/longjmp in readline.c. For whatever reason, this messes up on FreeBSD. I'll post my final patches on comp.lang.python myself. Please consider the problem closed. Thanks for following up. I think I'll stick to FreeBSD. I grew up on BSD4.2/3 and system v still gives me the heebie jeebies :-) All the best, - --Alex ------- End of Forwarded Message Bug Importer 2000-08-01T21:03:00Z There is a problem with threads + readline + signals on FreeBSD. Apparently readline is using longjmp and this messes things up. (I told you longjmp was evil. :-) Bug Importer 2000-08-01T21:03:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Alex Zbyslaw: RE: Re: [Python-bugs-list] PRIVATE: Threads and readline (PR#120) Date: Mon, 08 Nov 1999 10:30:24 -0500 ------- Forwarded Message Date: Sat, 06 Nov 1999 11:17:00 +0000 From: Alex Zbyslaw <xfb52@dial.pipex.com> To: guido@cnri.reston.va.us Subject: RE: Re: [Python-bugs-list] PRIVATE: Threads and readline This is the message I posted today on comp.lang.python. Btw, I forgot to mention that to compile for thread support on FreeBSD 3.2 (and I would think 3.3) you only need to specify "-pthread" on the link line. That automatically links in the threaded C libraries. Everything else from the standard configure would appear to be correct. All the best, - --Alex Subject: Re: Control-C on Unix misbehaviour? Date: Sat, 06 Nov 1999 11:08:05 +0000 Quinn Dunkan wrote: > > On Mon, 18 Oct 1999 15:47:52 +0200, flight@mathi.uni-heidelberg.de > Here's a data point for Irix6: > If you hit ^C at the >>> prompt with readline loaded (python 1.5), python > stops responding. Further ^Cs do nothing, in fact the only way I've found > to get out is to kill from another shell or hit ^z kill %. I had exactly the same problem on FreeBSD 3.2 but ONLY when I had thread support enabled. I have eventually tracked the problem down to a bad interaction (read library/kernel bug) between threads/sigjmp and interrupted reads. I have created two "fixes" which can be applied either to a) python or b) python and readline which fix the problems differently. The fixes are pretty trivial and so far they work for me. You can check them out at http://www.xfb52.dial.pipex.com/patches/python.shtml I don't know how they may affect people who have had ^C dumping them into a shell. No one else has mentioned whether they had thread support enabled or not. >From extensive poking around I am quite sure that this misbehaviour is not a bug in either Python or readline. Good luck, - --Alex ------- End of Forwarded Message Bug Importer 2000-08-01T21:03:00Z From: Jack Jansen <jack@oratrix.nl> Subject: Re: [Python-bugs-list] PRIVATE: Threads and readline (PR#120) Date: Wed, 03 Nov 1999 23:32:19 +0100 > As another bizarre data point: when I run a threaded python interpreter > on a program which does not use threads, and pipe the output to less, > less gets very confused and fails to update about half the screen, > leaving it blank. This happens after hitting SPACE a couple of times. > All the data is there, and if I jump less to the end of input and then > go back through the the data, I can see it all normally. Same program > and unthreaded python and less works just fine. If you have ANY idea > why adding thread support could affect a program further down a pipe I'd > love to know. As I like puzzles I spent some time thinking on this, and it must be either (a) kernel bug, (b) a very strange stdio bug or (c) an incorrect observation. If your system supports memory-mapped I/O and stdio uses it and it can somehow signal that a whole buffer is available while it isn't but only the tail end is available (because it uses an overlapping memcopy which goes back-to-front, for instance) the reader in the pipe might wakeup too early and see null bytes. But if this was a bet I think I'd put my money on (c) (but absolutely no offense meant!). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm Bug Importer 2000-08-01T21:03:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] PRIVATE: Threads and readline (PR#120) Date: Wed, 03 Nov 1999 10:42:33 -0500 ------- Forwarded Message Date: Tue, 02 Nov 1999 11:57:23 +0000 From: Alex Zbyslaw <xfb52@dial.pipex.com> To: guido@cnri.reston.va.us Subject: RE: Re: [Python-bugs-list] PRIVATE: Threads and readline >> When python is compiled with thread support and readline, ^C no longer >> works properly (interpreter goes into an infinite loop). >> (Tried with readline 2.0, 2.2 and 4.0). >Thanks for your bug report. I see that you are using FreeBSD. Could >it be a FreeBSD related problem? I don't see the same thing on >Solaris or Red Hat Linux. > >Also, can you describe exactly how you reproduce the problem? > >--Guido van Rossum (home page: http://www.python.org/~guido/) Thanks for your mail, Guido. Yes, I suppose it could be a FreeBSD problem, though I was originally put on to the readline connection by some articles in comp.lang.python which mentioned extremely similar symptoms under Debian Linux. What those articles did not mention was the thread connection which I guessed for myself. See articles titled "Control-C on Unix meisbehaviour?" on 18th Oct 1999. People in that thread reported similar problems on various systems, whilst others had no problem on apparently identical systems. No one mentioned if they had thread support. Creating the problem is, for me, simple. I compile python 1.5.2 with thread support enabled. (Thread and signal tests are passed by make test and a quickie thread program works as expected). If I go into the interpreter python and type ^C, everything goes into an infinite loop. If I recompile python without threads, but with readline, then go into the interpreter then press ^C I get KeyboardInterrupt as expected. If I recompile with threads but without readline, then again, I get KeyboardInterrupt as expected. In all three cases, pressing ^C while a program is running gets correct behaviour. >From what I can determine: The readline module was written so that it bypassed any signal handler installed by the readline library. It institutes its own handler in readline.c (onintr) which catches the interrupt and returns NULL (which somewhere back down the line is interpreted as KeyboardInterrupt). However, with threads enabled (but no readline) there seems to be a different behaviour, where the interrupt is caught by the regular signal handler (I forget the name but its in my bug report - in signalmodule.c). My guess was that with threads enabled this signal handler was doing something important. But with readline support turned on, this handler was not being called which caused some problem occur. I did try adapting the code in readline.c to call this signal handler itself, but that didn't seem to work (though I forget what happened). What my patch does is to forget about the local signal handler 'onintr' and, instead, stick with whatever the "default" signal handler is. readline_4.0 allows you to turn off any signal handling in the readline library itself, so the "default" handler will be whatever python installs (in signalmodule.c). This then "works" in that pressing ^C does not generate an infinite loop. But the call_readline function in readline.c does not immediately return NULL, so you have to press RETURN before the KeyboardInterrupt is generated. I never did figure out a way to both call the default signal handler and return a NULL from call_readline -- which I believe would cause "correct" ^C behaviour. My C is somewhat rusty as I spend my time in Python (by choice) and Perl (by neccessity). I'm not sure what else I can tell you about the problem, but if there is any more data I could provide for you, please ask. As another bizarre data point: when I run a threaded python interpreter on a program which does not use threads, and pipe the output to less, less gets very confused and fails to update about half the screen, leaving it blank. This happens after hitting SPACE a couple of times. All the data is there, and if I jump less to the end of input and then go back through the the data, I can see it all normally. Same program and unthreaded python and less works just fine. If you have ANY idea why adding thread support could affect a program further down a pipe I'd love to know. By the way, I have no objection to making my bug report and patch public, as long as there is some way to remove my email address from it. I have had only one piece of spam in the last year and I'd like to keep it that way :-) As the good cafe owner said "Spam's orf"! Although it's not perfect, the patch has made threaded python usable for me. If there are other people out there in the same boat and it helped them, that would be great. - -- Phone: 0131 468 2422 Email: xfb52@dial.pipex.com ------- End of Forwarded Message Jeremy Hylton 2000-09-07T22:04:00Z Please do triage on this bug. Guido van Rossum 2000-09-13T10:36:00Z According to the comments, at least part of this is a FreeBSD specific kernel problem and solved for that platform. Th rest (signals, threads, readline) is a duplicate of bug #110611. Closing this one. 2000-07-31T21:28:00Z sf210695 Jitterbug-Id: 144 Submitted-By: robert.harrison@pnl.gov Date: Fri, 3 Dec 1999 01:35:19 -0500 (EST) Version: 1.5.2 OS: IRIX64 6.5 On an SGI (IRIX64 6.5, MIPSpro Compilers: Version 7.3.1m, -n32) Python-1.5.2/Objects/complexobject.c does not compile correctly with optimization. The problem shows up as a bus error in PyComplex_ImagAsDouble when importing Numeric Python. All works fine when this one file is compiled with -O0 (-O1 and higher fail). I assume that this is probably just a compiler error. ==================================================================== Audit trail: Fri Dec 03 10:39:28 1999 guido changed notes Fri Dec 03 10:39:28 1999 guido moved from incoming to platformbug Bug Importer REJECTED LOW platform-specific Fred Drake python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:28:00Z Jitterbug-Id: 144 Submitted-By: robert.harrison@pnl.gov Date: Fri, 3 Dec 1999 01:35:19 -0500 (EST) Version: 1.5.2 OS: IRIX64 6.5 On an SGI (IRIX64 6.5, MIPSpro Compilers: Version 7.3.1m, -n32) Python-1.5.2/Objects/complexobject.c does not compile correctly with optimization. The problem shows up as a bus error in PyComplex_ImagAsDouble when importing Numeric Python. All works fine when this one file is compiled with -O0 (-O1 and higher fail). I assume that this is probably just a compiler error. ==================================================================== Audit trail: Fri Dec 03 10:39:28 1999 guido changed notes Fri Dec 03 10:39:28 1999 guido moved from incoming to platformbug Jeremy Hylton 2000-09-07T22:03:00Z Please do triage on this bug. barry 2000-09-16T22:02:00Z Assigning to Fred, but we really need somebody with the specified OS to do platform specific testing. Fred Drake 2000-09-16T22:10:00Z Sent a message to the original submitter asking if this is still a problem, and indicated that we don't have access to any SGI IRIX systems on which to perform testing. Guido van Rossum 2000-09-22T03:46:00Z Set priority really low. SGI optimizer bugs are a common pain, but not worth losing sleep over. Maybe just close it with "Wont Fix"? Fred Drake 2000-09-29T17:44:00Z Added a note to the README file explaining the optimization bug and how to build so that the complex object is compiled without optimization. Closing this as "Won't Fix." 2000-07-31T21:29:00Z sf210696 Jitterbug-Id: 149 Submitted-By: python.org@netfinances.com Date: Sat, 4 Dec 1999 22:03:43 -0500 (EST) Version: 1.5.2 OS: RedHat Linux 6.0 strptime throws a ValueError exception when I feed it the hour 02, and a minute value equal to 40 or greater the following session illustrates: 1017:26:fred@firestorm:~/public_html >python Python 1.5.2 (#2, Dec 3 1999, 23:56:19) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from time import strptime >>> t = strptime('0230','%H%M') >>> t (1900, 1, 0, 23, 0, 0, 6, 1, 0) >>> t = strptime('0240','%H%M') Traceback (innermost last): File "<stdin>", line 1, in ? ValueError: format mismatch >>> t = strptime('0140','%H%M') >>> t = strptime('0340','%H%M') >>> t = strptime('0345','%H%M') >>> t = strptime('0339','%H%M') >>> t = strptime('0240','%H%M') Traceback (innermost last): File "<stdin>", line 1, in ? ValueError: format mismatch >>> t = strptime('0245','%H%M') Traceback (innermost last): File "<stdin>", line 1, in ? ValueError: format mismatch >>> t = strptime('0250','%H%M') Traceback (innermost last): File "<stdin>", line 1, in ? ValueError: format mismatch >>> t = strptime('0259','%H%M') Traceback (innermost last): File "<stdin>", line 1, in ? ValueError: format mismatch >>> ==================================================================== Audit trail: Tue Dec 14 17:22:29 1999 guido sent reply 1 Tue Dec 14 17:22:48 1999 guido resent 149.reply.1 Tue Dec 14 17:24:30 1999 guido sent reply 2 Tue Dec 14 17:24:51 1999 guido changed notes Tue Dec 14 17:24:51 1999 guido moved from incoming to platformbug Bug Importer REJECTED LOW platform-specific Jeremy Hylton extension-modules Bug Importer Bug Importer 2000-07-31T21:29:00Z Jitterbug-Id: 149 Submitted-By: python.org@netfinances.com Date: Sat, 4 Dec 1999 22:03:43 -0500 (EST) Version: 1.5.2 OS: RedHat Linux 6.0 strptime throws a ValueError exception when I feed it the hour 02, and a minute value equal to 40 or greater the following session illustrates: 1017:26:fred@firestorm:~/public_html >python Python 1.5.2 (#2, Dec 3 1999, 23:56:19) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from time import strptime >>> t = strptime('0230','%H%M') >>> t (1900, 1, 0, 23, 0, 0, 6, 1, 0) >>> t = strptime('0240','%H%M') Traceback (innermost last): File "<stdin>", line 1, in ? ValueError: format mismatch >>> t = strptime('0140','%H%M') >>> t = strptime('0340','%H%M') >>> t = strptime('0345','%H%M') >>> t = strptime('0339','%H%M') >>> t = strptime('0240','%H%M') Traceback (innermost last): File "<stdin>", line 1, in ? ValueError: format mismatch >>> t = strptime('0245','%H%M') Traceback (innermost last): File "<stdin>", line 1, in ? ValueError: format mismatch >>> t = strptime('0250','%H%M') Traceback (innermost last): File "<stdin>", line 1, in ? ValueError: format mismatch >>> t = strptime('0259','%H%M') Traceback (innermost last): File "<stdin>", line 1, in ? ValueError: format mismatch >>> ==================================================================== Audit trail: Tue Dec 14 17:22:29 1999 guido sent reply 1 Tue Dec 14 17:22:48 1999 guido resent 149.reply.1 Tue Dec 14 17:24:30 1999 guido sent reply 2 Tue Dec 14 17:24:51 1999 guido changed notes Tue Dec 14 17:24:51 1999 guido moved from incoming to platformbug Bug Importer 2000-08-01T21:03:00Z Must be the strptime() implementation in his C library. Bug Importer 2000-08-01T21:03:00Z From: Guido van Rossum <bugs-py@python.org> Subject: Re: strptime error (PR#149) Date: Tue Dec 14 17:24:30 1999 > strptime throws a ValueError exception when I feed it the hour 02, and a minute > value > equal to 40 or greater the following session illustrates: Very strange. I can't reproduce this; I presume your platform's strptime() has a problem. --Guido van Rossum Bug Importer 2000-08-01T21:03:00Z From: Guido van Rossum <bugs-py@python.org> Subject: Re: strptime error (PR#149) Date: Tue Dec 14 17:22:29 1999 Jeremy Hylton 2000-09-07T22:01:00Z Please do triage on this bug. Jeremy Hylton 2000-09-15T18:11:00Z a problem with the platform's strptime 2000-07-31T21:29:00Z sf210697 Jitterbug-Id: 152 Submitted-By: cjc26@cornell.edu Date: Tue, 7 Dec 1999 22:55:18 -0500 (EST) Version: 1.5.2 OS: FreeBSD 3.3-STABLE math.log(0) and math.log(0.0) both cause the interpreter to dump core. Sample output: bridget:~$ uname -a FreeBSD bridget.mindriot.net 3.3-STABLE FreeBSD 3.3-STABLE #19: Fri Oct 8 20:01:29 EDT 1999 root@tankgrrl.bridget.mindriot.net:/usr/src/sys/compile/CJC26 i386 bridget:~$ python Python 1.5.2 (#25, Jun 21 1999, 18:19:49) [GCC egcs-2.91.60 19981201 (egcs-1.1.1 on freebsd3 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import math >>> math.log(0) Floating point exception (core dumped) ==================================================================== Audit trail: Tue Dec 14 17:14:07 1999 guido changed notes Tue Dec 14 17:14:07 1999 guido moved from incoming to platformbug Bug Importer REJECTED MEDIUM platform-specific Bug Importer Bug Importer 2000-07-31T21:29:00Z Jitterbug-Id: 152 Submitted-By: cjc26@cornell.edu Date: Tue, 7 Dec 1999 22:55:18 -0500 (EST) Version: 1.5.2 OS: FreeBSD 3.3-STABLE math.log(0) and math.log(0.0) both cause the interpreter to dump core. Sample output: bridget:~$ uname -a FreeBSD bridget.mindriot.net 3.3-STABLE FreeBSD 3.3-STABLE #19: Fri Oct 8 20:01:29 EDT 1999 root@tankgrrl.bridget.mindriot.net:/usr/src/sys/compile/CJC26 i386 bridget:~$ python Python 1.5.2 (#25, Jun 21 1999, 18:19:49) [GCC egcs-2.91.60 19981201 (egcs-1.1.1 on freebsd3 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import math >>> math.log(0) Floating point exception (core dumped) ==================================================================== Audit trail: Tue Dec 14 17:14:07 1999 guido changed notes Tue Dec 14 17:14:07 1999 guido moved from incoming to platformbug Bug Importer 2000-08-01T21:03:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] math.log(0) dumps core (PR#152) Date: Tue, 07 Dec 1999 23:13:34 -0500 > Full_Name: Cliff Crawford > Version: 1.5.2 > OS: FreeBSD 3.3-STABLE > Submission from: ith1-379.twcny.rr.com (24.24.11.121) > > > math.log(0) and math.log(0.0) both cause the interpreter to dump core. > Sample output: > > bridget:~$ uname -a > FreeBSD bridget.mindriot.net 3.3-STABLE FreeBSD 3.3-STABLE #19: Fri Oct 8 > 20:01:29 EDT 1999 > root@tankgrrl.bridget.mindriot.net:/usr/src/sys/compile/CJC26 i386 > bridget:~$ python > Python 1.5.2 (#25, Jun 21 1999, 18:19:49) [GCC egcs-2.91.60 19981201 > (egcs-1.1.1 on freebsd3 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> import math > >>> math.log(0) > Floating point exception (core dumped) I'm sorry, but this is a bug in the C math library of your platform. The C function is supposed to return an error which Python translates into an exception; on correct platforms the following behavior is observed: >>> import math >>> math.log(0) Traceback (innermost last): File "<pyshell#1>", line 1, in ? math.log(0) OverflowError: math range error >>> math.log(0.0) Traceback (innermost last): File "<pyshell#2>", line 1, in ? math.log(0.0) OverflowError: math range error >>> --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-08-01T21:03:00Z Bug in FreeBSD 3.3 math library. Thomas Wouters 2000-08-05T18:33:00Z Closed the bugreport, as it's a bug in a platform library (of an old version of the OS in question.) (I'm not sure if 'Wont fix' is the right resolution. Maybe we need a 'Not a bug' resolution ?) 2000-07-31T21:29:00Z sf210698 Jitterbug-Id: 164 Submitted-By: python-bugreport@derf.net Date: Tue, 21 Dec 1999 08:27:27 -0500 (EST) Version: 1.5.2 OS: RedHat 5.2; Linux 2.2.12 time.strptime() seems to fail when the time zone ('%Z') appears in the format string. when it is omitted from the format string (and from the string being parsed), strptime() works fine. here is a sample script which demonstrates the bug: ------ #!/usr/bin/python import time timetuple0 = time.localtime(time.time()) print timetuple0 format1 = '%a %b %d %H:%M:%S %Y' timestring1 = time.strftime( format1 , timetuple0 ) print timestring1 timetuple1 = time.strptime( timestring1 , format1 ) print timetuple1 format2 = '%a %b %d %H:%M:%S %Z %Y' timestring2 = time.strftime( format2 , timetuple0 ) print timestring2 timetuple2 = time.strptime( timestring2 , format2 ) print timetuple2 ------ when i run the above, i get the following output: ------ (1999, 12, 21, 5, 25, 35, 1, 355, 0) Tue Dec 21 05:25:35 1999 (1999, 12, 21, 5, 25, 35, 1, 355, 0) Tue Dec 21 05:25:35 PST 1999 Traceback (innermost last): File "./test.py", line 17, in ? timetuple2 = time.strptime( timestring2 , format2 ) ValueError: format mismatch ------ ==================================================================== Audit trail: Tue Dec 21 11:47:04 1999 guido changed notes Tue Dec 21 11:47:05 1999 guido moved from incoming to platformbug Bug Importer REJECTED MEDIUM platform-specific Tim Peters Bug Importer Bug Importer 2000-07-31T21:29:00Z Jitterbug-Id: 164 Submitted-By: python-bugreport@derf.net Date: Tue, 21 Dec 1999 08:27:27 -0500 (EST) Version: 1.5.2 OS: RedHat 5.2; Linux 2.2.12 time.strptime() seems to fail when the time zone ('%Z') appears in the format string. when it is omitted from the format string (and from the string being parsed), strptime() works fine. here is a sample script which demonstrates the bug: ------ #!/usr/bin/python import time timetuple0 = time.localtime(time.time()) print timetuple0 format1 = '%a %b %d %H:%M:%S %Y' timestring1 = time.strftime( format1 , timetuple0 ) print timestring1 timetuple1 = time.strptime( timestring1 , format1 ) print timetuple1 format2 = '%a %b %d %H:%M:%S %Z %Y' timestring2 = time.strftime( format2 , timetuple0 ) print timestring2 timetuple2 = time.strptime( timestring2 , format2 ) print timetuple2 ------ when i run the above, i get the following output: ------ (1999, 12, 21, 5, 25, 35, 1, 355, 0) Tue Dec 21 05:25:35 1999 (1999, 12, 21, 5, 25, 35, 1, 355, 0) Tue Dec 21 05:25:35 PST 1999 Traceback (innermost last): File "./test.py", line 17, in ? timetuple2 = time.strptime( timestring2 , format2 ) ValueError: format mismatch ------ ==================================================================== Audit trail: Tue Dec 21 11:47:04 1999 guido changed notes Tue Dec 21 11:47:05 1999 guido moved from incoming to platformbug Bug Importer 2000-08-01T21:03:00Z The C library strptime() needs fixin'. Bug Importer 2000-08-01T21:03:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] strptime gives format mismatch when time zone present (PR#164) Date: Tue, 21 Dec 1999 09:12:15 -0500 > time.strptime() seems to fail when the time zone ('%Z') appears in > the format string. when it is omitted from the format string (and > from the string being parsed), strptime() works fine. Reporting this as a Python bug is not going to fix it. The time.strptime() function in Python is a very thin wrapper around the strptime() function in the C library. We get a lot of complaints about this, but there's no way that we're able to fix this -- it's the C strptime() function that needs to be fixed. Write to your friendly Linux support people! --Guido van Rossum (home page: http://www.python.org/~guido/) Jeremy Hylton 2000-09-07T22:06:00Z Please do triage on this bug. M.-A. Lemburg 2000-09-08T12:27:00Z FYI, you could check out mxDateTime which provides a parser for various date/time formats instead of waiting for your strptime() C API to get fixed. mxDateTime is available at http://starship.python.net/~lemburg/. Tim Peters 2000-09-08T16:13:00Z Closed it, as it's not a Python bug but a bug in the platform libc (if a non-std fnc can be called "buggy" at all ...). Trewitt 2003-11-15T00:17:00Z I get the same error *for some builds*. I'm using Redhat 9, and the bug shows up in (I think) the stock Python 2.2. If I compile 2.3.2 from source, it works fine. (2003, 11, 14, 16, 3, 22, 4, 318, 0) Fri Nov 14 16:03:22 2003 (2003, 11, 14, 16, 3, 22, 4, 318, 0) Fri Nov 14 16:03:22 PST 2003 Traceback (most recent call last): File "timep.py", line 17, in ? timetuple2 = time.strptime( timestring2 , format2 ) ValueError: format mismatch Brett Cannon 2003-11-15T04:04:00Z 2.3 switched over to a pure Python implementation of strptime that makes the behavior predictable and testable. Thanks for the info anyway, trewitt. 2000-07-31T21:29:00Z sf210699 Jitterbug-Id: 165 Submitted-By: xxx-bad@juno.com Date: Tue, 21 Dec 1999 11:43:08 -0500 (EST) Version: 1.5.2 OS: Win NT 4.0, SP4 Hello, I have troubles running Python scripts from command line. The script print "Hello" works fine if ran as test.py However, if I run it as test.py >test.txt The test.txt is empty (0 bytes), and no console output. I did not see similar behavior in 95. In addition, sys.stdout.fileno() is -1 for redirected file which does not look right. Thank you, Vadim ==================================================================== Audit trail: Tue Dec 21 11:46:47 1999 guido changed notes Tue Dec 21 11:46:47 1999 guido moved from incoming to platformbug Bug Importer REJECTED MEDIUM not-a-bug windows Bug Importer Bug Importer 2000-07-31T21:29:00Z Jitterbug-Id: 165 Submitted-By: xxx-bad@juno.com Date: Tue, 21 Dec 1999 11:43:08 -0500 (EST) Version: 1.5.2 OS: Win NT 4.0, SP4 Hello, I have troubles running Python scripts from command line. The script print "Hello" works fine if ran as test.py However, if I run it as test.py >test.txt The test.txt is empty (0 bytes), and no console output. I did not see similar behavior in 95. In addition, sys.stdout.fileno() is -1 for redirected file which does not look right. Thank you, Vadim ==================================================================== Audit trail: Tue Dec 21 11:46:47 1999 guido changed notes Tue Dec 21 11:46:47 1999 guido moved from incoming to platformbug Bug Importer 2000-08-01T21:03:00Z See FAQ 8.14. Bug Importer 2000-08-01T21:03:00Z From: "Mark Hammond" <mhammond@skippinet.com.au> Subject: RE: [Python-bugs-list] redirected stdout under Windows NT (PR#165) Date: Wed, 22 Dec 1999 09:54:22 +1100 This is a bug in Windows NT, not in Python. The exact same thing happens with Perl and all other command line programs. The solution is to always prefix the name of the .py file with the name of the Python executable. Eg: foo.py > foo # Will not work python.exe foo.py > foo # will work. This is a bug in Windows NT, but has apparently been fixed in Windows 2000. Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of xxx-bad@juno.com > Sent: Wednesday, 22 December 1999 3:43 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] redirected stdout under Windows NT (PR#165) > > > Full_Name: Vadim Suvorov > Version: 1.5.2 > OS: Win NT 4.0, SP4 > Submission from: internet1.compressorcontrols.com (165.90.228.92) > > > Hello, > > I have troubles running Python scripts from command line. The script > > print "Hello" > > works fine if ran as > > test.py > > However, if I run it as > > test.py >test.txt > > The test.txt is empty (0 bytes), and no console output. > > I did not see similar behavior in 95. > > In addition, sys.stdout.fileno() is -1 for redirected file which > does not look > right. > > Thank you, > > Vadim > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > Bug Importer 2000-08-01T21:03:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] redirected stdout under Windows NT (PR#165) Date: Tue, 21 Dec 1999 11:47:12 -0500 > I have troubles running Python scripts from command line. The script > > print "Hello" > > works fine if ran as > > test.py > > However, if I run it as > > test.py >test.txt > > The test.txt is empty (0 bytes), and no console output. > > I did not see similar behavior in 95. > > In addition, sys.stdout.fileno() is -1 for redirected file which does not look > right. This is a problem in Windows -- I/O redirection doesn't always work as expected, depending on how your script is invoked. See Python FAQ 8.14 for various work-arounds: http://www.python.org/cgi-bin/faqw.py?req=show&file=faq08.014.htp --Guido van Rossum (home page: http://www.python.org/~guido/) Mark Hammond 2000-08-14T06:51:00Z As the comments indicate, this is a well known bug in Windows, not in Python. Setting to "Not a Bug", and closing. 2000-07-31T21:29:00Z sf210700 Jitterbug-Id: 183 Submitted-By: calvin@cs.uni-sb.de Date: Thu, 13 Jan 2000 11:00:38 -0500 (EST) Version: 1.5.2 OS: Linux (Debian slink) test.py: import time # crash it by swapping year and month argument print time.strftime("%d.%m.%Y %H:%M:%S", (1,2000, 1, 0, 0, 0, 0, 1, 0)) python test.py Segmentation fault Well there were similar crashes with time.strptime calls. I think this is a platform bug with the C function strftime, but I did not test this in a C program. ==================================================================== Audit trail: Thu Jan 13 11:04:15 2000 guido changed notes Thu Jan 13 11:04:16 2000 guido moved from incoming to platformbug Bug Importer REJECTED MEDIUM platform-specific Bug Importer Bug Importer 2000-07-31T21:29:00Z Jitterbug-Id: 183 Submitted-By: calvin@cs.uni-sb.de Date: Thu, 13 Jan 2000 11:00:38 -0500 (EST) Version: 1.5.2 OS: Linux (Debian slink) test.py: import time # crash it by swapping year and month argument print time.strftime("%d.%m.%Y %H:%M:%S", (1,2000, 1, 0, 0, 0, 0, 1, 0)) python test.py Segmentation fault Well there were similar crashes with time.strptime calls. I think this is a platform bug with the C function strftime, but I did not test this in a C program. ==================================================================== Audit trail: Thu Jan 13 11:04:15 2000 guido changed notes Thu Jan 13 11:04:16 2000 guido moved from incoming to platformbug Bug Importer 2000-08-01T21:03:00Z From: Bastian Kleineidam <calvin@cs.uni-sb.de> Subject: Re: [Python-bugs-list] strftime crashes with invalid args (PR#183) Date: Thu, 13 Jan 2000 19:39:52 +0100 (CET) :) Yes, this is a platform bug. Please report it to the C library folks :) (sorry, I can't do that for you). I got answer from Andreas Jaeger that this bug is fixed with the current glibc version 2.1.2. Bastian Kleineidam Bug Importer 2000-08-01T21:03:00Z The Linux C library code has a long way to go... Bug Importer 2000-08-01T21:03:00Z From: Bastian Kleineidam <calvin@void.cs.uni-sb.de> Subject: Re: [Python-bugs-list] strftime crashes with invalid args (PR#183) Date: Thu, 13 Jan 2000 18:37:14 +0100 (CET) [snip bug report] :) Yes, this is a platform bug. Please report it to the C library folks :) (sorry, I can't do that for you). Ok, did it. So the safe side is to check the arguments before calling time.strftime() Bastian Kleineidam Bug Importer 2000-08-01T21:03:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] strftime crashes with invalid args (PR#183) Date: Thu, 13 Jan 2000 11:03:50 -0500 > Full_Name: Bastian Kleineidam > Version: 1.5.2 > OS: Linux (Debian slink) > Submission from: www-proxy.rz.uni-sb.de (134.96.7.81) > > > test.py: > import time > # crash it by swapping year and month argument > print time.strftime("%d.%m.%Y %H:%M:%S", (1,2000, 1, 0, 0, 0, 0, 1, 0)) > > python test.py > Segmentation fault > > Well there were similar crashes with time.strptime calls. I think this > is a platform bug with the C function strftime, but I did not test this > in a C program. Yes, this is a platform bug. Please report it to the C library folks (sorry, I can't do that for you). --Guido van Rossum (home page: http://www.python.org/~guido/) Thomas Wouters 2000-08-06T16:42:00Z Caused by a (by now fixed) bug in GNU libc, not one in Python, therefor closed the bug report. 2000-07-31T21:29:00Z sf210701 Jitterbug-Id: 191 Submitted-By: gurney_j@efn.org Date: Tue, 25 Jan 2000 12:33:51 -0500 (EST) Version: 1.5.2 OS: FreeBSD 3.4R When I try to run the following program I get an undefined symbol on PyDict_SetString. #include <Python.h> void main() { Py_Initialize(); PyRun_SimpleString("import base64\n"); Py_Finalize(); } I believe this is because the interpeter library doesn't reference all of the symbols that it may need when loading modules. So the linker will throw out any unecessary symbols which happen to include PyDict_SetString. I tried to include PyDict_SetString into my program, but was unable to make it work. ==================================================================== Audit trail: Mon Feb 07 12:36:08 2000 guido changed notes Mon Feb 07 12:36:08 2000 guido moved from incoming to platformbug Bug Importer FIXRELEASED MEDIUM not-a-bug Bug Importer Bug Importer 2000-07-31T21:29:00Z Jitterbug-Id: 191 Submitted-By: gurney_j@efn.org Date: Tue, 25 Jan 2000 12:33:51 -0500 (EST) Version: 1.5.2 OS: FreeBSD 3.4R When I try to run the following program I get an undefined symbol on PyDict_SetString. #include <Python.h> void main() { Py_Initialize(); PyRun_SimpleString("import base64\n"); Py_Finalize(); } I believe this is because the interpeter library doesn't reference all of the symbols that it may need when loading modules. So the linker will throw out any unecessary symbols which happen to include PyDict_SetString. I tried to include PyDict_SetString into my program, but was unable to make it work. ==================================================================== Audit trail: Mon Feb 07 12:36:08 2000 guido changed notes Mon Feb 07 12:36:08 2000 guido moved from incoming to platformbug Martin von Löwis 2000-09-05T22:00:00Z This is not a bug in Python. When linking a custom interpreter, you need to make sure all symbols are exported to modules. On FreeBSD, you do this by adding -Wl,--export-dynamic to the linker line. Jeremy Hylton 2000-09-05T22:14:00Z On python-dev, Martin von Löwis wrote: This is not a bug in Python. When linking a custom interpreter, you need to make sure all symbols are exported to modules. On FreeBSD, you do this by adding -Wl,--export-dynamic to the linker line. 2000-07-31T21:29:00Z sf210702 Jitterbug-Id: 33 Submitted-By: laik@cs.stanford.edu Date: Tue, 20 Jul 1999 14:00:11 -0400 (EDT) Version: 1.5.2 OS: Linux 2.2.10 I can't close a pipe's file descriptor without an error: >>> import os >>> p1 = os.popen("cat dummy1", "r") >>> p2 = os.popen("cat dummy2", "r") >>> p1.close() Traceback (innermost last): File "<stdin>", line 1, in ? IOError: (0, 'Error') It only happens if I do two or more popens. If I try to close any file descriptor but the last one I opened, I get this mysterious IOError. It happens regardless of the order I try to close the descriptors. ==================================================================== Audit trail: Sat Jul 24 17:02:54 1999 guido sent reply 1 Sat Jul 24 17:03:22 1999 guido changed notes Sat Jul 24 17:03:22 1999 guido moved from incoming to open Sat Jul 24 17:05:25 1999 guido moved from open to platformbug Bug Importer REJECTED MEDIUM platform-specific Fred Drake extension-modules Bug Importer Bug Importer 2000-07-31T21:29:00Z Jitterbug-Id: 33 Submitted-By: laik@cs.stanford.edu Date: Tue, 20 Jul 1999 14:00:11 -0400 (EDT) Version: 1.5.2 OS: Linux 2.2.10 I can't close a pipe's file descriptor without an error: >>> import os >>> p1 = os.popen("cat dummy1", "r") >>> p2 = os.popen("cat dummy2", "r") >>> p1.close() Traceback (innermost last): File "<stdin>", line 1, in ? IOError: (0, 'Error') It only happens if I do two or more popens. If I try to close any file descriptor but the last one I opened, I get this mysterious IOError. It happens regardless of the order I try to close the descriptors. ==================================================================== Audit trail: Sat Jul 24 17:02:54 1999 guido sent reply 1 Sat Jul 24 17:03:22 1999 guido changed notes Sat Jul 24 17:03:22 1999 guido moved from incoming to open Sat Jul 24 17:05:25 1999 guido moved from open to platformbug Bug Importer 2000-08-01T21:03:00Z From: laik@tnt.Stanford.EDU Subject: Re: closing a popen file descriptor (PR#33) Date: Tue, 27 Jul 1999 01:41:15 -0700 Guido, Thanks for your quick reply. As far as I can tell, the man page for pclose() doesn't mention any API changes. I have included the popen() and wait4() man pages for the system I am using (PII 300, Linux 2.2.10, glibc 2.1.1). I have written a short C program which tries to exercise the bug. On my system, it gives these results: [laik@nebraska]~>gcc popen.c [laik@nebraska]~>a.out pclose(p1): 0, WIFEXITED: 1, WEXITSTATUS:0, WIFSIGNALED:0 pclose(p2): 0, WIFEXITED: 1, WEXITSTATUS:0, WIFSIGNALED:0 pclose(p3): 0, WIFEXITED: 1, WEXITSTATUS:0, WIFSIGNALED:0 On a Linux 2.0.33, glibc 2.0.7 system, it gives the same results. However, my system exhibits the problem under Python, while the other does not. I conclude that my C program doesn't mimic the Python program well enough to trigger the bug, but I don't know how to fix that. #include <stdio.h> #define _USE_BSD #include <sys/types.h> #include <sys/resource.h> #include <sys/wait.h> main() { FILE *p1, *p2, *p3; int pc1, pc2, pc3; p1 = popen("ls", "r"); p2 = popen("ls", "r"); p3 = popen("ls", "r"); sleep(1); pc1 = pclose(p1); printf("pclose(p1): %d, WIFEXITED: %d, WEXITSTATUS:%d, WIFSIGNALED:%d\n", pc1, WIFEXITED(pc1), WEXITSTATUS(pc1), WIFSIGNALED(pc1)); pc2 = pclose(p2); printf("pclose(p2): %d, WIFEXITED: %d, WEXITSTATUS:%d, WIFSIGNALED:%d\n", pc1, WIFEXITED(pc2), WEXITSTATUS(pc2), WIFSIGNALED(pc2)); pc3 = pclose(p3); printf("pclose(p3): %d, WIFEXITED: %d, WEXITSTATUS:%d, WIFSIGNALED:%d\n", pc3, WIFEXITED(pc3), WEXITSTATUS(pc3), WIFSIGNALED(pc3)); } POPEN(3) Linux Programmer's Manual POPEN(3) NAME popen, pclose - process I/O SYNOPSIS #include <stdio.h> FILE *popen(const char *command, const char *type); int pclose(FILE *stream); DESCRIPTION The popen() function opens a process by creating a pipe, forking, and invoking the shell. Since a pipe is by defi- nition unidirectional, the type argument may specify only reading or writing, not both; the resulting stream is cor- respondingly read-only or write-only. The command argument is a pointer to a null-terminated string containing a shell command line. This command is passed to /bin/sh using the -c flag; interpretation, if any, is performed by the shell. The mode argument is a pointer to a null-terminated string which must be either `r' for reading or `w' for writing. The return value from popen() is a normal standard I/O stream in all respects save that it must be closed with pclose() rather than fclose(). Writing to such a stream writes to the standard input of the command; the command's standard output is the same as that of the process that called popen(), unless this is altered by the command itself. Conversely, reading from a ``popened'' stream reads the command's standard output, and the command's standard input is the same as that of the process that called popen. Note that output popen streams are fully buffered by default. The pclose function waits for the associated process to terminate and returns the exit status of the command as returned by wait4. RETURN VALUE The popen function returns NULL if the fork(2) or pipe(2) calls fail, or if it cannot allocate memory. The pclose function returns -1 if wait4 returns an error, or some other error is detected. ERRORS The popen function does not set errno if memory allocation fails. If the underlying fork() or pipe() fails, errno is set appropriately. If the mode argument is invalid, and this condition is detected, errno is set to EINVAL. If pclose() cannot obtain the child status, errno is set to ECHILD. CONFORMING TO POSIX.2 BUGS Since the standard input of a command opened for reading shares its seek offset with the process that called popen(), if the original process has done a buffered read, the command's input position may not be as expected. Sim- ilarly, the output from a command opened for writing may become intermingled with that of the original process. The latter can be avoided by calling fflush(3) before popen. Failure to execute the shell is indistinguishable from the shell's failure to execute command, or an immediate exit of the command. The only hint is an exit status of 127. HISTORY A popen() and a pclose() function appeared in Version 7 AT&T UNIX. SEE ALSO fork(2), sh(1), pipe(2), wait4(2), fflush(3), fclose(3), fopen(3), stdio(3), system(3). BSD MANPAGE 7 May 1998 1 WAIT4(2) Linux Programmer's Manual WAIT4(2) NAME wait3, wait4 - wait for process termination, BSD style SYNOPSIS #define _USE_BSD #include <sys/types.h> #include <sys/resource.h> #include <sys/wait.h> pid_t wait3(int *status, int options, struct rusage *rusage) pid_t wait4(pid_t pid, int *status, int options, struct rusage *rusage) DESCRIPTION The wait3 function suspends execution of the current pro- cess until a child has exited, or until a signal is deliv- ered whose action is to terminate the current process or to call a signal handling function. If a child has already exited by the time of the call (a so-called "zom- bie" process), the function returns immediately. Any sys- tem resources used by the child are freed. The wait4 function suspends execution of the current pro- cess until a child as specified by the pid argument has exited, or until a signal is delivered whose action is to terminate the current process or to call a signal handling function. If a child as requested by pid has already exited by the time of the call (a so-called "zombie" pro- cess), the function returns immediately. Any system resources used by the child are freed. The value of pid can be one of: < -1 which means to wait for any child process whose process group ID is equal to the absolute value of pid. -1 which means to wait for any child process; this is equivalent to calling wait3. 0 which means to wait for any child process whose process group ID is equal to that of the calling process. > 0 which means to wait for the child whose process ID is equal to the value of pid. The value of options is a bitwise OR of zero or more of the following constants: WNOHANG which means to return immediately if no child is there to be waited for. WUNTRACED which means to also return for children which are stopped, and whose status has not been reported. If status is not NULL, wait3 or wait4 store status infor- mation in the location pointed to by status. This status can be evaluated with the following macros (these macros take the stat buffer (an int) as an argument -- not a pointer to the buffer!): WIFEXITED(status) is non-zero if the child exited normally. WEXITSTATUS(status) evaluates to the least significant eight bits of the return code of the child which terminated, which may have been set as the argument to a call to exit() or as the argument for a return state- ment in the main program. This macro can only be evaluated if WIFEXITED returned non-zero. WIFSIGNALED(status) returns true if the child process exited because of a signal which was not caught. WTERMSIG(status) returns the number of the signal that caused the child process to terminate. This macro can only be evaluated if WIFSIGNALED returned non-zero. WIFSTOPPED(status) returns true if the child process which caused the return is currently stopped; this is only possible if the call was done using WUNTRACED. WSTOPSIG(status) returns the number of the signal which caused the child to stop. This macro can only be evaluated if WIFSTOPPED returned non-zero. If rusage is not NULL, the struct rusage as defined in <sys/resource.h> it points to will be filled with accounting information. See getrusage(2) for details. RETURN VALUE The process ID of the child which exited, -1 on error (in particular, when no unwaited-for child processes of the specified kind exist) or zero if WNOHANG was used and no child was available yet. In the latter two cases errno will be set appropriately. ERRORS ECHILD No unwaited-for child process as specified does exist. ERESTARTSYS if WNOHANG was not set and an unblocked signal or a SIGCHLD was caught. This error is returned by the system call. The library interface is not allowed to return ERESTARTSYS, but will return EINTR. CONFORMING TO SVr4, POSIX.1 SEE ALSO signal(2), getrusage(2), wait(2), signal(7) Linux 23 June 1997 1 Bug Importer 2000-08-01T21:03:00Z Perhaps a bug or interface change in Linux popen()? Bug Importer 2000-08-01T21:03:00Z From: Guido van Rossum <bugs-py@python.org> Subject: Re: closing a popen file descriptor (PR#33) Date: Sat Jul 24 17:02:54 1999 > Full_Name: Kevin Lai > Version: 1.5.2 > OS: Linux 2.2.10 > Submission from: (NULL) (192.25.214.6) > > > I can't close a pipe's file descriptor without an error: > >>>> import os >>>> p1 = os.popen("cat dummy1", "r") >>>> p2 = os.popen("cat dummy2", "r") >>>> p1.close() > Traceback (innermost last): > File "<stdin>", line 1, in ? > IOError: (0, 'Error') > > It only happens if I do two or more popens. If I try to close any file > descriptor > but the last one I opened, I get this mysterious IOError. It happens regardless > of the order I try to close the descriptors. Kevin, this works on other platforms I can try (Solaris 2.6, linux 2.0.34). One possibility is that the C library in the Linux version you are using has changed; the IOError means that its pclose() returns an error indicator. The (0, 'Error') message means that pclose() didn't set the errno variable. It could be a bug in the Linux C library, or a change in interface that requires Python to interpret the error return differently. Can you help us discover which is the case? Does the man page for pclose() say anything about this? Does this fail in an equivalent C program? --Guido van Rossum Jeremy Hylton 2000-09-07T22:05:00Z Please do triage on this bug. Fred Drake 2000-09-08T02:51:00Z I can't reproduce this on a Linux 2.2.15 kernel (Mandrake 7.1) using Python 2.0beta1. Will ask the submitter to test with a more recent Python and request a re-open of the report if the problem persists. Fred Drake 2000-09-08T19:22:00Z Just received this comment from the original submitter: I'm using Python for a project on deadline right now so I don't want to install a new version of Python. However, I tested again on Redhat 6.2 Linux 2.2.12 Python 1.5.2 and the bug is gone. Thanks, Kevin 2000-07-31T21:29:00Z sf210703 Jitterbug-Id: 35 Submitted-By: ddula@alfomc.net Date: Thu, 22 Jul 1999 17:01:04 -0400 (EDT) Version: 1.5.2 OS: Digital Unix (OSF/1) 4.0E with latest patches Select cores while waiting on a socket spoo.alfomc.net> dbx /usr/local/ddula/tar/Python-1.5.2/python core dbx version 3.11.10 Type 'help' for help. Core file created by program "python" thread 0xb signal Segmentation fault at >*[nxm_thread_kill, 0x3ff805ab3b8] retr31, (r26), 1 (dbx) t > 0 nxm_thread_kill(0x14003bb40, 0x3ff807e31c8, 0x3ffc0085c98, 0x3ff805ab0a8, 0x14003bb40) [0x3ff805ab3b8] 1 pthread_kill(0x1, 0x0, 0x0, 0x1400df980, 0x3ff00000000) [0x3ff80598b94] 2 (unknown)() [0x3ff8058cb38] 3 (unknown)() [0x3ff807e35ec] 4 exc_unwind(0x1400dde78, 0x1400dc5a0, 0xabadabad00beed00, 0x0, 0x3ff807e3964) [0x3ff807e36d4] 5 exc_raise_signal_exception(0x86, 0x0, 0x1200735b8, 0x1, 0x2) [0x3ff807e3960] 6 (unknown)() [0x3ff8059a248] 7 select_select(args = (nil)) ["./selectmodule.c":221, 0x1200735b4] 8 eval_code2(co = [bad address (0x14010d838)], globals = 0xfc50, locals = (nil), args = [bad address (0x14010d840)], kws = [bad address (0x14010d848)], kwcount = [bad address (0x14010d9a8)], defs = [bad address (0x14010d9b0)], defcount = [bad address (0x14010d9b8)]) ["ceval.c":1654, 0x12003e57c] Appears eval_code2 is getting passed bad addresses? My code snipped <--SNIP--> class TelnetProxy(SocketServer.StreamRequestHandler,SocketServer.BaseRequestHand ler): def handle(self): o = socket(AF_INET,SOCK_STREAM) o.connect(OHOST,OPORT) while 1: print o.fileno() print self.rfile.fileno() r,w,e = select.select([o,self.rfile],[],[],1) <---CORE HERE if o in r: <--SNIP--> Same problem under 1.5.1 as well. The 1.5.2 is the latest source I downloaded Jul 20 This same code works fine on NT and LINUX I believe. Dave Dula ddula@alfomc.net ==================================================================== Audit trail: Sat Jul 24 16:52:19 1999 guido changed notes Sat Jul 24 16:52:19 1999 guido moved from incoming to open Sat Jul 24 17:05:25 1999 guido moved from open to platformbug Bug Importer REJECTED MEDIUM platform-specific Guido van Rossum Bug Importer Bug Importer 2000-07-31T21:29:00Z Jitterbug-Id: 35 Submitted-By: ddula@alfomc.net Date: Thu, 22 Jul 1999 17:01:04 -0400 (EDT) Version: 1.5.2 OS: Digital Unix (OSF/1) 4.0E with latest patches Select cores while waiting on a socket spoo.alfomc.net> dbx /usr/local/ddula/tar/Python-1.5.2/python core dbx version 3.11.10 Type 'help' for help. Core file created by program "python" thread 0xb signal Segmentation fault at >*[nxm_thread_kill, 0x3ff805ab3b8] retr31, (r26), 1 (dbx) t > 0 nxm_thread_kill(0x14003bb40, 0x3ff807e31c8, 0x3ffc0085c98, 0x3ff805ab0a8, 0x14003bb40) [0x3ff805ab3b8] 1 pthread_kill(0x1, 0x0, 0x0, 0x1400df980, 0x3ff00000000) [0x3ff80598b94] 2 (unknown)() [0x3ff8058cb38] 3 (unknown)() [0x3ff807e35ec] 4 exc_unwind(0x1400dde78, 0x1400dc5a0, 0xabadabad00beed00, 0x0, 0x3ff807e3964) [0x3ff807e36d4] 5 exc_raise_signal_exception(0x86, 0x0, 0x1200735b8, 0x1, 0x2) [0x3ff807e3960] 6 (unknown)() [0x3ff8059a248] 7 select_select(args = (nil)) ["./selectmodule.c":221, 0x1200735b4] 8 eval_code2(co = [bad address (0x14010d838)], globals = 0xfc50, locals = (nil), args = [bad address (0x14010d840)], kws = [bad address (0x14010d848)], kwcount = [bad address (0x14010d9a8)], defs = [bad address (0x14010d9b0)], defcount = [bad address (0x14010d9b8)]) ["ceval.c":1654, 0x12003e57c] Appears eval_code2 is getting passed bad addresses? My code snipped <--SNIP--> class TelnetProxy(SocketServer.StreamRequestHandler,SocketServer.BaseRequestHand ler): def handle(self): o = socket(AF_INET,SOCK_STREAM) o.connect(OHOST,OPORT) while 1: print o.fileno() print self.rfile.fileno() r,w,e = select.select([o,self.rfile],[],[],1) <---CORE HERE if o in r: <--SNIP--> Same problem under 1.5.1 as well. The 1.5.2 is the latest source I downloaded Jul 20 This same code works fine on NT and LINUX I believe. Dave Dula ddula@alfomc.net ==================================================================== Audit trail: Sat Jul 24 16:52:19 1999 guido changed notes Sat Jul 24 16:52:19 1999 guido moved from incoming to open Sat Jul 24 17:05:25 1999 guido moved from open to platformbug Bug Importer 2000-08-01T21:03:00Z Digital Unix problem when combining threads with select? Bug Importer 2000-08-01T21:03:00Z From: David Dula <ddula@alfomc.net> Subject: Re: [Python-bugs-list] select with dec-threads core dumps (PR#35) Date: Thu, 22 Jul 1999 18:43:48 -0400 Guido van Rossum wrote: > I seriously suspect that this is a bug in your C library, not in > Python. Select is rock-solid on other platforms. Do you feel > confident enough to try debugging this some more? Otherwise, you have > no choice but to post a question to the newsgrup, maybe someone has > seen this before or is willing to help debugging it. > > --Guido van Rossum (home page: http://www.python.org/~guido/) Well a little more debugging shows that this is certainly a threading + select problem because a forking method works. The forks will serve my purposes so I have a work around. Thanks Dave Dula Bug Importer 2000-08-01T21:03:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] select with dec-threads core dumps (PR#35) Date: Thu, 22 Jul 1999 17:46:26 -0400 I seriously suspect that this is a bug in your C library, not in Python. Select is rock-solid on other platforms. Do you feel confident enough to try debugging this some more? Otherwise, you have no choice but to post a question to the newsgrup, maybe someone has seen this before or is willing to help debugging it. --Guido van Rossum (home page: http://www.python.org/~guido/) Jeremy Hylton 2000-09-07T22:04:00Z Please do triage on this bug. Guido van Rossum 2000-09-13T10:45:00Z It's unlikely that we'll ever fix this, because of the uncommon platform, and the suspicion that the bug is in the platform. If you have more information pointing to a bug in Python, and if this is still not broken in Python 2.0, please send mail and we'll reopen the bug. 2000-07-31T21:29:00Z sf210704 Jitterbug-Id: 400 Submitted-By: crislipm@earthlink.net Date: Sun, 16 Jul 2000 20:40:24 -0400 (EDT) Version: 1.5.2 OS: Linuxppc, Suse dist more for curiosity/FYI Using 1.5.2 (the version that came with the suse linuxppc) and IDLE 0.5 on an ibook (version 2). IDLE causes the keyboard to stop working (I am not certain which, if any action, causes this, but it is reproducable) and the problem continues when I warm boot back to the MAC OS. Have to do a cold boot to get keyboard to respond again. ==================================================================== Audit trail: Mon Jul 24 18:30:07 2000 jeremy changed notes Mon Jul 24 18:30:07 2000 jeremy moved from incoming to platformbug Bug Importer REJECTED LOW platform-specific Guido van Rossum idle Bug Importer Bug Importer 2000-07-31T21:29:00Z Jitterbug-Id: 400 Submitted-By: crislipm@earthlink.net Date: Sun, 16 Jul 2000 20:40:24 -0400 (EDT) Version: 1.5.2 OS: Linuxppc, Suse dist more for curiosity/FYI Using 1.5.2 (the version that came with the suse linuxppc) and IDLE 0.5 on an ibook (version 2). IDLE causes the keyboard to stop working (I am not certain which, if any action, causes this, but it is reproducable) and the problem continues when I warm boot back to the MAC OS. Have to do a cold boot to get keyboard to respond again. ==================================================================== Audit trail: Mon Jul 24 18:30:07 2000 jeremy changed notes Mon Jul 24 18:30:07 2000 jeremy moved from incoming to platformbug Jeremy Hylton 2000-09-07T22:03:00Z Please do triage on this bug. barry 2000-09-16T22:04:00Z Reassigned to Guido for disposal. Maybe Jack should take a look? Guido van Rossum 2000-09-18T22:37:00Z Alas, Tkinter on a Mac is terribly unstable. There's not much I can do about that. Too bad! I wish it weren't so. 2000-07-31T21:29:00Z sf210705 Jitterbug-Id: 401 Submitted-By: andyg@one.net.au Date: Mon, 17 Jul 2000 04:26:12 -0400 (EDT) Version: Python 1.5.2 (#3, Jun 29 2000, 15:52:04) [GCC 2.8.1] on sunos5 OS: SunOS psol002 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-Enterprise A combination of socket.gethostbyname and os.system appears to hang python intermittently. We run Dec and Sun systems - it only appears to be a problem with sun systems. The following is the simplest way I can reproduce the problem: test.py: -------------------------------- #!/usr/local/bin/python import os import socket print socket.gethostbyname( "a hostname (but not localhost)" ) os.system("echo fred") hang.sh: -------------------------------- #!/bin/ksh while true ; do ./test.py done output: --------------------------------- 10.666.666.666 fred 10.666.666.666 fred ... eventually ... 10.666.666.666 <hung> If "a hostname" is "localhost" it doesn't hang. For anything else which it can successfully resolve, it seems to hang. Thanks ! Andy. ==================================================================== Audit trail: Mon Jul 24 18:39:07 2000 jeremy changed notes Mon Jul 24 18:39:07 2000 jeremy moved from incoming to platformbug Bug Importer FIXRELEASED LOW platform-specific Jeremy Hylton extension-modules Bug Importer Bug Importer 2000-07-31T21:29:00Z Jitterbug-Id: 401 Submitted-By: andyg@one.net.au Date: Mon, 17 Jul 2000 04:26:12 -0400 (EDT) Version: Python 1.5.2 (#3, Jun 29 2000, 15:52:04) [GCC 2.8.1] on sunos5 OS: SunOS psol002 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-Enterprise A combination of socket.gethostbyname and os.system appears to hang python intermittently. We run Dec and Sun systems - it only appears to be a problem with sun systems. The following is the simplest way I can reproduce the problem: test.py: -------------------------------- #!/usr/local/bin/python import os import socket print socket.gethostbyname( "a hostname (but not localhost)" ) os.system("echo fred") hang.sh: -------------------------------- #!/bin/ksh while true ; do ./test.py done output: --------------------------------- 10.666.666.666 fred 10.666.666.666 fred ... eventually ... 10.666.666.666 <hung> If "a hostname" is "localhost" it doesn't hang. For anything else which it can successfully resolve, it seems to hang. Thanks ! Andy. ==================================================================== Audit trail: Mon Jul 24 18:39:07 2000 jeremy changed notes Mon Jul 24 18:39:07 2000 jeremy moved from incoming to platformbug Jeremy Hylton 2000-09-07T22:01:00Z Please do triage on this bug. Jeremy Hylton 2000-09-12T15:58:00Z attempt to contact the original submittor Guido van Rossum 2000-09-22T03:57:00Z Ask if the Sun system is a multi CPU system. It could be the dual CPU bug in disguise. Otherwise I have no clue how this could be a bug in Python (more likely a platform C library interaction), so am lowering the priority. Guido van Rossum 2000-12-12T20:52:00Z No new information. Giving up on this one. 2000-07-31T21:29:00Z sf210706 Jitterbug-Id: 44 Submitted-By: rene@kronos.szabinet.hu Date: Sun, 1 Aug 1999 16:39:42 -0400 (EDT) Version: 1.5.2 OS: Linux Compile error with Python-1.5.2 on Linux Slackware 4.0, kernel 2.2.10-ac8, gcc 2.7.2.3, make 3.76.1 ./configure --prefix=/usr/local --with-threads && make ... ./socketmodule.c: In function `setipaddr': ./socketmodule.c:392: warning: passing arg 5 of `gethostbyname_r' from incompatible pointer type ./socketmodule.c:392: too many arguments to function `gethostbyname_r' ./socketmodule.c:392: warning: assignment makes integer from pointer without a cast ./socketmodule.c: In function `PySocket_gethostbyname_ex': ./socketmodule.c:1471: warning: passing arg 5 of `gethostbyname_r' from incompatible pointer type ./socketmodule.c:1471: too many arguments to function `gethostbyname_r' ./socketmodule.c:1471: warning: assignment makes integer from pointer without a cast ./socketmodule.c: In function `PySocket_gethostbyaddr': ./socketmodule.c:1534: warning: passing arg 7 of `gethostbyaddr_r' from incompatible pointer type ./socketmodule.c:1534: too many arguments to function `gethostbyaddr_r' ./socketmodule.c:1534: warning: assignment makes integer from pointer without a cast make[1]: *** [socketmodule.o] Error 1 make: *** [Modules] Error 2 ==================================================================== Audit trail: Wed Aug 04 12:12:39 1999 guido moved from incoming to platformbug Mon Aug 30 12:37:34 1999 guido changed notes Mon Oct 25 15:15:46 1999 guido changed notes Bug Importer REJECTED MEDIUM platform-specific Fred Drake build Bug Importer Bug Importer 2000-07-31T21:29:00Z Jitterbug-Id: 44 Submitted-By: rene@kronos.szabinet.hu Date: Sun, 1 Aug 1999 16:39:42 -0400 (EDT) Version: 1.5.2 OS: Linux Compile error with Python-1.5.2 on Linux Slackware 4.0, kernel 2.2.10-ac8, gcc 2.7.2.3, make 3.76.1 ./configure --prefix=/usr/local --with-threads && make ... ./socketmodule.c: In function `setipaddr': ./socketmodule.c:392: warning: passing arg 5 of `gethostbyname_r' from incompatible pointer type ./socketmodule.c:392: too many arguments to function `gethostbyname_r' ./socketmodule.c:392: warning: assignment makes integer from pointer without a cast ./socketmodule.c: In function `PySocket_gethostbyname_ex': ./socketmodule.c:1471: warning: passing arg 5 of `gethostbyname_r' from incompatible pointer type ./socketmodule.c:1471: too many arguments to function `gethostbyname_r' ./socketmodule.c:1471: warning: assignment makes integer from pointer without a cast ./socketmodule.c: In function `PySocket_gethostbyaddr': ./socketmodule.c:1534: warning: passing arg 7 of `gethostbyaddr_r' from incompatible pointer type ./socketmodule.c:1534: too many arguments to function `gethostbyaddr_r' ./socketmodule.c:1534: warning: assignment makes integer from pointer without a cast make[1]: *** [socketmodule.o] Error 1 make: *** [Modules] Error 2 ==================================================================== Audit trail: Wed Aug 04 12:12:39 1999 guido moved from incoming to platformbug Mon Aug 30 12:37:34 1999 guido changed notes Mon Oct 25 15:15:46 1999 guido changed notes Jeremy Hylton 2000-09-07T22:06:00Z Please do triage on this bug. Tim Peters 2000-09-15T05:50:00Z Assigned to Fred for the heck of it. Changed the "Summary" msg as the original "Compiler error" gave me an entirely wrong impression. Fred Drake 2000-09-15T17:11:00Z Sent a message to the submitter asking if this is still a problem with more recent Python releases; this sounds very much like a bug that's been squashed, but I don't have a Slackware Linux installation available for testing. Fred Drake 2000-09-15T18:05:00Z I cannot reproduce this with Slackware 7.0 (kernel 2.2.14 SMP; the version installed on the SourceForge compile farm). Fred Drake 2000-09-17T18:36:00Z Lowering priority since I can't reproduce this on the current version of Slackware (as installed on the SF compile farm). Fred Drake 2000-09-19T17:29:00Z Was not able to reach the submitter; mail eventually bounced back. Closing this as "Works for Me" since I can't get any further information required to verify that this bug still exists. 2000-07-31T21:29:00Z sf210707 Jitterbug-Id: 57 Submitted-By: jital@knoggin.com Date: Fri, 20 Aug 1999 04:18:04 -0400 (EDT) Version: py152 OS: BSDI IServer seems to think it is a NeXT arch or something $ ./configure --prefix=/usr/home/knoggin/usr/local/ --exec-prefix=/usr/home/knoggin/usr/local/ creating cache ./config.cache checking MACHDEP... bsdos3 checking CCC... checking for --without-gcc... no checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking LINKCC... $(PURIFY) $(CC) checking LDLIBRARY... checking for ranlib... ranlib checking for ar... ar checking how to run the C preprocessor... gcc -D_HAVE_BSDI -E checking for AIX... no checking for minix/config.h... no checking whether gcc -D_HAVE_BSDI accepts -OPT:Olimit=0... no checking whether gcc -D_HAVE_BSDI accepts -Olimit 1500... no checking for C preprocessor type... ansi checking for ANSI C header files... yes checking for dlfcn.h... yes checking for fcntl.h... yes checking for limits.h... yes checking for locale.h... yes checking for ncurses.h... yes checking for pthread.h... yes checking for signal.h... yes checking for stdarg.h... yes checking for stddef.h... yes checking for stdlib.h... yes checking for thread.h... no checking for unistd.h... yes checking for utime.h... yes checking for sys/audioio.h... no checking for sys/file.h... yes checking for sys/lock.h... yes checking for sys/param.h... yes checking for sys/select.h... yes checking for sys/time.h... yes checking for sys/times.h... yes checking for sys/un.h... yes checking for sys/utsname.h... yes checking for sys/wait.h... yes checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for clock_t in time.h... yes checking for mode_t... yes checking for off_t... yes checking for pid_t... yes checking return type of signal handlers... void checking for size_t... yes checking for uid_t in sys/types.h... yes checking size of int... 4 checking size of long... 4 checking size of void *... 4 checking for long long support... yes checking size of long long... 8 checking size of off_t... 8 checking whether to enable large file support... yes checking for --with-next-framework... no checking for --with-dyld... required for framework build checking SO... .so checking LDSHARED... ld checking CCSHARED... checking LINKFORSHARED... checking for dlopen in -ldl... yes checking for shl_load in -ldld... no checking for t_open in -lnsl... no checking for socket in -lsocket... no checking for socket in -lnet... no checking for --with-libs... no checking for --with(out)-readline... not specified. checking for --with-dec-threads... no checking for --with-threads... no checking for --with-thread... no checking for --with-sgi-dl... no checking for --with-dl-dld... no checking for alarm... yes checking for chown... yes checking for clock... yes checking for dlopen... yes checking for execv... yes checking for flock... yes checking for fork... yes checking for fsync... yes checking for fdatasync... no checking for ftime... no checking for ftruncate... yes checking for getpeername... yes checking for getpgrp... yes checking for getpid... yes checking for getpwent... yes checking for gettimeofday... yes checking for getwd... yes checking for kill... yes checking for link... yes checking for lstat... yes checking for mkfifo... yes checking for mktime... yes checking for nice... yes checking for pause... yes checking for plock... no checking for pthread_init... yes checking for putenv... yes checking for readlink... yes checking for select... yes checking for setgid... yes checking for setlocale... yes checking for setuid... yes checking for setsid... yes checking for setpgid... yes checking for setpgrp... yes checking for setvbuf... yes checking for sigaction... yes checking for siginterrupt... yes checking for sigrelse... no checking for strftime... yes checking for strptime... no checking for symlink... yes checking for tcgetpgrp... yes checking for tcsetpgrp... yes checking for timegm... no checking for times... yes checking for truncate... yes checking for uname... yes checking for waitpid... yes checking for fseek64... no checking for fseeko... no checking for fstatvfs... no checking for ftell64... no checking for ftello... no checking for statvfs... no checking for dup2... yes checking for getcwd... yes checking for strdup... yes checking for strerror... yes checking for memmove... yes checking for getpgrp... (cached) yes checking for setpgrp... (cached) yes checking for gettimeofday... (cached) yes checking whether time.h and sys/time.h may both be included... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for tm_zone in struct tm... yes checking for time.h that defines altzone... no checking whether sys/select.h and sys/time.h may both be included... yes checking whether char is unsigned... no checking for working const... yes checking for working volatile... yes checking for working signed char... yes checking for prototypes... yes checking for variable length prototypes and stdarg.h... yes checking for bad exec* prototypes... no checking for bad static forward... no checking whether va_list is an array... no checking for gethostbyname_r... no checking for gethostbyname... yes checking for __fpu_control in -lieee... no checking for --with-fpectl... checking for --with-libm=STRING... default LIBM="- lm" checking for --with-libc=STRING... default LIBC="" checking for hypot... yes checking for hypot... (cached) yes checking for genuine getopt... yes checking what malloc(0) returns... nonnull updating cache ./config.cache creating ./config.status creating Makefile creating Objects/Makefile creating Parser/Makefile creating Python/Makefile creating Modules/Makefile.pre creating Modules/Setup.thread creating config.h pcvendor:~/usr/local/src/Python-1.5.2 $ make (cd Modules; make -f Makefile.pre Makefile) cp ./Setup.in Setup echo "# Edit this file for local setup changes" >Setup.local rm -f ../libpython1.5.a /bin/sh ./makesetup Setup.thread Setup.local Setup making Makefile in subdirectory . `Makefile' is up to date. making Makefile in subdirectory Parser `Makefile' is up to date. making Makefile in subdirectory Objects `Makefile' is up to date. making Makefile in subdirectory Python `Makefile' is up to date. making Makefile in subdirectory Modules `Makefile' is up to date. (rm -f Modules/hassignal; cd Modules; make hassignal) rm -f hassignal for i in regexmodule.o regexpr.o pcremodule.o pypcre.o posixmodule.o signalmo dule.o arraymodule.o cmathmodule.o mathmodule.o stropmodule.o structmodule. o timemodule.o operator.o fcntlmodule.o pwdmodule.o grpmodule.o selectmodu le.o socketmodule.o errnomodule.o md5module.o md5c.o shamodule.o rotormodul e.o newmodule.o binascii.o parsermodule.o cStringIO.o cPickle.o config.o ge tpath.o main.o getbuildinfo.o; do if test "$i" = "signalmodule.o"; then echo y es >hassignal; break; fi; done cd Parser ; make OPT="-g -O2" VERSION="1.5" prefix="/usr/home/knoggin/usr/local /" exec_prefix="/usr/home/knoggin/usr/local/" all gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c pgenmain.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c acceler.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar1.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c listnode.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c node.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c parser.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c parsetok.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c tokenizer.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c bitset.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c metagrammar.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c firstsets.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c pgen.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c printgrammar.c gcc -D_HAVE_BSDI -g -O2 pgenmain.o acceler.o grammar1.o listnode.o node.o parse r.o parsetok.o tokenizer.o bitset.o metagrammar.o firstsets.o grammar.o pgen.o printgrammar.o -ldl -o pgen gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c myreadline.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c intrcheck.c cd Objects ; make OPT="-g -O2" VERSION="1.5" prefix="/usr/home/knoggin/usr/local/" exec_prefix="/usr/home/knoggin/usr/local/" all gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c abstract.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c bufferobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c classobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c cobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c complexobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c fileobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c floatobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c frameobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c funcobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c intobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c listobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c longobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c dictobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c moduleobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c object.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c rangeobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c sliceobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c stringobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c tupleobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c typeobject.c cd Python ; make OPT="-g -O2" VERSION="1.5" prefix="/usr/home/knoggin/usr/local/" exec_prefix="/usr/home/knoggin/usr/local/" all gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c bltinmodule.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ceval.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c compile.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c errors.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c frozen.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c frozenmain.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getargs.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getcompiler.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getcopyright.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getmtime.c gcc -D_HAVE_BSDI -c -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -DPLATFORM='"bsdos3"' ./getplatform.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getversion.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c graminit.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c import.c gcc -D_HAVE_BSDI -c -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -I/ ./importdl.c ./importdl.c:269: mach-o/dyld.h: No such file or directory *** Error code 1 Stop. *** Error code 1 Stop. ==================================================================== Audit trail: Mon Aug 30 12:40:26 1999 guido changed notes Mon Aug 30 12:40:26 1999 guido moved from incoming to irreproducible Tue Oct 19 23:20:49 1999 guido sent reply 1 Tue Oct 19 23:21:36 1999 guido changed notes Tue Oct 19 23:21:36 1999 guido moved from irreproducible to open Tue Oct 19 23:30:25 1999 guido changed notes Tue Oct 19 23:30:25 1999 guido moved from open to platformbug Bug Importer REJECTED MEDIUM platform-specific Fred Drake build Bug Importer Bug Importer 2000-07-31T21:29:00Z Jitterbug-Id: 57 Submitted-By: jital@knoggin.com Date: Fri, 20 Aug 1999 04:18:04 -0400 (EDT) Version: py152 OS: BSDI IServer seems to think it is a NeXT arch or something $ ./configure --prefix=/usr/home/knoggin/usr/local/ --exec-prefix=/usr/home/knoggin/usr/local/ creating cache ./config.cache checking MACHDEP... bsdos3 checking CCC... checking for --without-gcc... no checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking LINKCC... $(PURIFY) $(CC) checking LDLIBRARY... checking for ranlib... ranlib checking for ar... ar checking how to run the C preprocessor... gcc -D_HAVE_BSDI -E checking for AIX... no checking for minix/config.h... no checking whether gcc -D_HAVE_BSDI accepts -OPT:Olimit=0... no checking whether gcc -D_HAVE_BSDI accepts -Olimit 1500... no checking for C preprocessor type... ansi checking for ANSI C header files... yes checking for dlfcn.h... yes checking for fcntl.h... yes checking for limits.h... yes checking for locale.h... yes checking for ncurses.h... yes checking for pthread.h... yes checking for signal.h... yes checking for stdarg.h... yes checking for stddef.h... yes checking for stdlib.h... yes checking for thread.h... no checking for unistd.h... yes checking for utime.h... yes checking for sys/audioio.h... no checking for sys/file.h... yes checking for sys/lock.h... yes checking for sys/param.h... yes checking for sys/select.h... yes checking for sys/time.h... yes checking for sys/times.h... yes checking for sys/un.h... yes checking for sys/utsname.h... yes checking for sys/wait.h... yes checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for clock_t in time.h... yes checking for mode_t... yes checking for off_t... yes checking for pid_t... yes checking return type of signal handlers... void checking for size_t... yes checking for uid_t in sys/types.h... yes checking size of int... 4 checking size of long... 4 checking size of void *... 4 checking for long long support... yes checking size of long long... 8 checking size of off_t... 8 checking whether to enable large file support... yes checking for --with-next-framework... no checking for --with-dyld... required for framework build checking SO... .so checking LDSHARED... ld checking CCSHARED... checking LINKFORSHARED... checking for dlopen in -ldl... yes checking for shl_load in -ldld... no checking for t_open in -lnsl... no checking for socket in -lsocket... no checking for socket in -lnet... no checking for --with-libs... no checking for --with(out)-readline... not specified. checking for --with-dec-threads... no checking for --with-threads... no checking for --with-thread... no checking for --with-sgi-dl... no checking for --with-dl-dld... no checking for alarm... yes checking for chown... yes checking for clock... yes checking for dlopen... yes checking for execv... yes checking for flock... yes checking for fork... yes checking for fsync... yes checking for fdatasync... no checking for ftime... no checking for ftruncate... yes checking for getpeername... yes checking for getpgrp... yes checking for getpid... yes checking for getpwent... yes checking for gettimeofday... yes checking for getwd... yes checking for kill... yes checking for link... yes checking for lstat... yes checking for mkfifo... yes checking for mktime... yes checking for nice... yes checking for pause... yes checking for plock... no checking for pthread_init... yes checking for putenv... yes checking for readlink... yes checking for select... yes checking for setgid... yes checking for setlocale... yes checking for setuid... yes checking for setsid... yes checking for setpgid... yes checking for setpgrp... yes checking for setvbuf... yes checking for sigaction... yes checking for siginterrupt... yes checking for sigrelse... no checking for strftime... yes checking for strptime... no checking for symlink... yes checking for tcgetpgrp... yes checking for tcsetpgrp... yes checking for timegm... no checking for times... yes checking for truncate... yes checking for uname... yes checking for waitpid... yes checking for fseek64... no checking for fseeko... no checking for fstatvfs... no checking for ftell64... no checking for ftello... no checking for statvfs... no checking for dup2... yes checking for getcwd... yes checking for strdup... yes checking for strerror... yes checking for memmove... yes checking for getpgrp... (cached) yes checking for setpgrp... (cached) yes checking for gettimeofday... (cached) yes checking whether time.h and sys/time.h may both be included... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for tm_zone in struct tm... yes checking for time.h that defines altzone... no checking whether sys/select.h and sys/time.h may both be included... yes checking whether char is unsigned... no checking for working const... yes checking for working volatile... yes checking for working signed char... yes checking for prototypes... yes checking for variable length prototypes and stdarg.h... yes checking for bad exec* prototypes... no checking for bad static forward... no checking whether va_list is an array... no checking for gethostbyname_r... no checking for gethostbyname... yes checking for __fpu_control in -lieee... no checking for --with-fpectl... checking for --with-libm=STRING... default LIBM="- lm" checking for --with-libc=STRING... default LIBC="" checking for hypot... yes checking for hypot... (cached) yes checking for genuine getopt... yes checking what malloc(0) returns... nonnull updating cache ./config.cache creating ./config.status creating Makefile creating Objects/Makefile creating Parser/Makefile creating Python/Makefile creating Modules/Makefile.pre creating Modules/Setup.thread creating config.h pcvendor:~/usr/local/src/Python-1.5.2 $ make (cd Modules; make -f Makefile.pre Makefile) cp ./Setup.in Setup echo "# Edit this file for local setup changes" >Setup.local rm -f ../libpython1.5.a /bin/sh ./makesetup Setup.thread Setup.local Setup making Makefile in subdirectory . `Makefile' is up to date. making Makefile in subdirectory Parser `Makefile' is up to date. making Makefile in subdirectory Objects `Makefile' is up to date. making Makefile in subdirectory Python `Makefile' is up to date. making Makefile in subdirectory Modules `Makefile' is up to date. (rm -f Modules/hassignal; cd Modules; make hassignal) rm -f hassignal for i in regexmodule.o regexpr.o pcremodule.o pypcre.o posixmodule.o signalmo dule.o arraymodule.o cmathmodule.o mathmodule.o stropmodule.o structmodule. o timemodule.o operator.o fcntlmodule.o pwdmodule.o grpmodule.o selectmodu le.o socketmodule.o errnomodule.o md5module.o md5c.o shamodule.o rotormodul e.o newmodule.o binascii.o parsermodule.o cStringIO.o cPickle.o config.o ge tpath.o main.o getbuildinfo.o; do if test "$i" = "signalmodule.o"; then echo y es >hassignal; break; fi; done cd Parser ; make OPT="-g -O2" VERSION="1.5" prefix="/usr/home/knoggin/usr/local /" exec_prefix="/usr/home/knoggin/usr/local/" all gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c pgenmain.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c acceler.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar1.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c listnode.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c node.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c parser.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c parsetok.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c tokenizer.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c bitset.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c metagrammar.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c firstsets.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c pgen.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c printgrammar.c gcc -D_HAVE_BSDI -g -O2 pgenmain.o acceler.o grammar1.o listnode.o node.o parse r.o parsetok.o tokenizer.o bitset.o metagrammar.o firstsets.o grammar.o pgen.o printgrammar.o -ldl -o pgen gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c myreadline.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c intrcheck.c cd Objects ; make OPT="-g -O2" VERSION="1.5" prefix="/usr/home/knoggin/usr/local/" exec_prefix="/usr/home/knoggin/usr/local/" all gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c abstract.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c bufferobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c classobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c cobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c complexobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c fileobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c floatobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c frameobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c funcobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c intobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c listobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c longobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c dictobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c moduleobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c object.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c rangeobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c sliceobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c stringobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c tupleobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c typeobject.c cd Python ; make OPT="-g -O2" VERSION="1.5" prefix="/usr/home/knoggin/usr/local/" exec_prefix="/usr/home/knoggin/usr/local/" all gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c bltinmodule.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ceval.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c compile.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c errors.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c frozen.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c frozenmain.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getargs.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getcompiler.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getcopyright.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getmtime.c gcc -D_HAVE_BSDI -c -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -DPLATFORM='"bsdos3"' ./getplatform.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getversion.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c graminit.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c import.c gcc -D_HAVE_BSDI -c -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -I/ ./importdl.c ./importdl.c:269: mach-o/dyld.h: No such file or directory *** Error code 1 Stop. *** Error code 1 Stop. ==================================================================== Audit trail: Mon Aug 30 12:40:26 1999 guido changed notes Mon Aug 30 12:40:26 1999 guido moved from incoming to irreproducible Tue Oct 19 23:20:49 1999 guido sent reply 1 Tue Oct 19 23:21:36 1999 guido changed notes Tue Oct 19 23:21:36 1999 guido moved from irreproducible to open Tue Oct 19 23:30:25 1999 guido changed notes Tue Oct 19 23:30:25 1999 guido moved from open to platformbug Bug Importer 2000-08-01T21:03:00Z Work-around: if you delete #define WITH_DYLD from config.h, the build succeeds. Bug Importer 2000-08-01T21:03:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] does not compile under BSDI (PR#57) Date: Fri, 20 Aug 1999 07:57:10 -0400 > Full_Name: John Ital > Version: py152 > OS: BSDI IServer > > seems to think it is a NeXT arch or something > [...] > gcc -D_HAVE_BSDI -c -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -I/ ./importdl.c > ./importdl.c:269: mach-o/dyld.h: No such file or directory > *** Error code 1 Very strange. I've never seen this before. It appears that somehow USE_DYLD is defined at that point, which can only happen if WITH_DYLD is defined, which can only happen if you specify --with-next-framework or --with-dyld on the configure command line, which you didn't. Perhaps you have a buggy preprocessor that is confused by the tangle of #ifdefs in importdl.c? I don't know how to help you; I know Python has been built successfully on bsdos3 before, so I'm guessing it's something in your setup, not a Python bug. If you need more help, please ask a newsgroup -- either comp.lang.python or a BSD specific one. --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-08-01T21:03:00Z From: Guido van Rossum <bugs-py@python.org> Subject: Re: does not compile under BSDI (PR#57) Date: Tue Oct 19 23:20:49 1999 This same bug was reported by someone else for the same platform. We arrived at the work-around of deleting the line #define WITH_DYLD from the config.h generated by the configure script. If you are still experiencing problems building Python, please try this. --Guido van Rossum Thomas Wouters 2000-08-03T16:00:00Z For the record, I cannot reproduce this on the BSDI 3.1 systems we still have lying around. It *might* have been specific to BSDI 3.0, which we no longer have (for various reasons, like y2k bugs ;) and I've heard similar (but not the same) reports about BSD/OS running under a 'virtual' machine. However, I've never seen or heard about those 'virtual' BSD/OSes, other than in that c.l.py posting. Jeremy Hylton 2000-09-07T22:05:00Z Please do triage on this bug. Fred Drake 2000-09-08T22:12:00Z I've sent a message to the submitter asking if this can be reproduced with more recent Python versions. Closed as "Works for Me" based on Thomas' comment. This can be reopened based on further input from the original submitter. 2000-07-31T21:29:00Z sf210708 Jitterbug-Id: 64 Submitted-By: ddula@atl.mediaone.net Date: Wed, 25 Aug 1999 14:02:51 -0400 (EDT) Version: 152c1 OS: Debian Alpha Linux (potato) 2.2.1 This is a interesting bug that seems to have started after I upgraded to debian potato from slink. It must be a library related bug but this report might help somebody troubleshoot. At first I thought it was a bug in threading because it prevented the solaris hack sleep from returning thus my thread.start() never returned. But further digging show that import time time.sleep(0.1) # will always hang on on this platform Work around is to always sleep at least one second - I will do some more looking at the time class when I get a chance. Dave Dula ==================================================================== Audit trail: Mon Aug 30 12:35:54 1999 guido moved from incoming to platformbug Mon Aug 30 12:36:15 1999 guido changed notes Bug Importer REJECTED LOW platform-specific python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:29:00Z Jitterbug-Id: 64 Submitted-By: ddula@atl.mediaone.net Date: Wed, 25 Aug 1999 14:02:51 -0400 (EDT) Version: 152c1 OS: Debian Alpha Linux (potato) 2.2.1 This is a interesting bug that seems to have started after I upgraded to debian potato from slink. It must be a library related bug but this report might help somebody troubleshoot. At first I thought it was a bug in threading because it prevented the solaris hack sleep from returning thus my thread.start() never returned. But further digging show that import time time.sleep(0.1) # will always hang on on this platform Work around is to always sleep at least one second - I will do some more looking at the time class when I get a chance. Dave Dula ==================================================================== Audit trail: Mon Aug 30 12:35:54 1999 guido moved from incoming to platformbug Mon Aug 30 12:36:15 1999 guido changed notes Jeremy Hylton 2000-08-25T14:03:00Z I poked the original contributor. If he responds, I'll raise the priority. Jeremy Hylton 2000-08-25T17:43:00Z Dave Dula writes: My further digging show that it wasn't a bug with python really but the bug was that floor returned a very large number that caused sleep to 'hang' So I believed it either to be a kernel bug or a bug in libm but regardless I have just confirmed that on potato running 2.2.16 the problem no longer seems to exist so I think the bug can be closed out as a library bug that is now fixed 2000-07-31T21:30:00Z sf210709 Jitterbug-Id: 65 Submitted-By: Dave Dula <ddula@darkroom.cx> Date: Wed, 25 Aug 1999 20:18:25 -0400 (EDT) Version: None OS: None >>Full_Name: David Dula >>Version: 152c1 >>OS: Debian Alpha Linux (potato) 2.2.1 >>Submission from: client42207.atl.mediaone.net (24.88.42.207) >>his is a interesting bug that seems to have started after I upgraded to debian >>potato from slink. >>It must be a library related bug but this report might help somebody >>troubleshoot. >>At first I thought it was a bug in threading because it prevented the solaris >>hack sleep from returning >>thus my thread.start() never returned. >>But further digging show that >>import time >>time.sleep(0.1) # will always hang on on this platform >>Work around is to always sleep at least one second - I will do some more looking >>at the time class when I get a chance. This code shows it is the library that is broken. int main() { printf("%f\n",floor(0.100000)); } returns 36028797018963968.000000 So floor is broken. not a python bug sorry. I guess something is up with libm Dave Dula *-------------------------------------------------------------------------- Dave Dula ddula@atl.mediaone.net http://www.darkroom.cx Despite the cost of living, have you noticed how popular it remains? ==================================================================== Audit trail: Mon Aug 30 12:35:54 1999 guido moved from incoming to platformbug Mon Aug 30 12:36:23 1999 guido changed notes Bug Importer FIXRELEASED MEDIUM platform-specific Bug Importer Bug Importer 2000-07-31T21:30:00Z Jitterbug-Id: 65 Submitted-By: Dave Dula <ddula@darkroom.cx> Date: Wed, 25 Aug 1999 20:18:25 -0400 (EDT) Version: None OS: None >>Full_Name: David Dula >>Version: 152c1 >>OS: Debian Alpha Linux (potato) 2.2.1 >>Submission from: client42207.atl.mediaone.net (24.88.42.207) >>his is a interesting bug that seems to have started after I upgraded to debian >>potato from slink. >>It must be a library related bug but this report might help somebody >>troubleshoot. >>At first I thought it was a bug in threading because it prevented the solaris >>hack sleep from returning >>thus my thread.start() never returned. >>But further digging show that >>import time >>time.sleep(0.1) # will always hang on on this platform >>Work around is to always sleep at least one second - I will do some more looking >>at the time class when I get a chance. This code shows it is the library that is broken. int main() { printf("%f\n",floor(0.100000)); } returns 36028797018963968.000000 So floor is broken. not a python bug sorry. I guess something is up with libm Dave Dula *-------------------------------------------------------------------------- Dave Dula ddula@atl.mediaone.net http://www.darkroom.cx Despite the cost of living, have you noticed how popular it remains? ==================================================================== Audit trail: Mon Aug 30 12:35:54 1999 guido moved from incoming to platformbug Mon Aug 30 12:36:23 1999 guido changed notes Jeremy Hylton 2000-08-25T17:46:00Z Dave Dula writes: My further digging show that it wasn't a bug with python really but the bug was that floor returned a very large number that caused sleep to 'hang' So I believed it either to be a kernel bug or a bug in libm but regardless I have just confirmed that on potato running 2.2.16 the problem no longer seems to exist so I think the bug can be closed out as a library bug that is now fixed 2000-07-31T21:30:00Z sf210710 Jitterbug-Id: 71 Submitted-By: mz@pdm.pvt.net Date: Mon, 6 Sep 1999 06:45:45 -0400 (EDT) Version: 1.5.2 OS: Debian GNU/Linux 2.1 When I start python and try to evaluate `range(1000000000)', I receive segmentation fault: $ python Python 1.5.2 (#0, May 4 1999, 14:45:33) [GCC 2.7.2.3] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> range(1000000000) Segmentation fault This can also be reproduced with Python 1.5.1 from the Debian 2.1 i386 distribution. ==================================================================== Audit trail: Tue Sep 07 11:13:29 1999 guido changed notes Tue Sep 07 11:13:29 1999 guido moved from incoming to platformbug Bug Importer FIXRELEASED MEDIUM Guido van Rossum python-interpreter-core Bug Importer Bug Importer 2000-07-31T21:30:00Z Jitterbug-Id: 71 Submitted-By: mz@pdm.pvt.net Date: Mon, 6 Sep 1999 06:45:45 -0400 (EDT) Version: 1.5.2 OS: Debian GNU/Linux 2.1 When I start python and try to evaluate `range(1000000000)', I receive segmentation fault: $ python Python 1.5.2 (#0, May 4 1999, 14:45:33) [GCC 2.7.2.3] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> range(1000000000) Segmentation fault This can also be reproduced with Python 1.5.1 from the Debian 2.1 i386 distribution. ==================================================================== Audit trail: Tue Sep 07 11:13:29 1999 guido changed notes Tue Sep 07 11:13:29 1999 guido moved from incoming to platformbug Jeremy Hylton 2000-08-04T14:00:00Z I can't reproduce this bug on 1.5.2 or current CVS. In both cases, I get a MemoryError. Jeremy Hylton 2000-09-07T22:04:00Z Please do triage on this bug. Guido van Rossum 2000-09-13T10:46:00Z Fixed in 2.0. This now gives a MemoryError exception. 2000-07-31T21:30:00Z sf210711 Jitterbug-Id: 85 Submitted-By: sdunn@digitalanvil.com Date: Thu, 23 Sep 1999 23:03:49 -0400 (EDT) Version: 1.5.2 OS: Irix 6.5 Description: The builtin function apply() seems to barf on empty dictionaries when passed as the keyword list. See the following output: ### Python 1.5.2 (#33, Sep 23 1999, 21:46:26) [C] on irix6 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> def func(a): ... return a ... >>> print func <function func at 1018aa68> >>> func(1) 1 >>> apply(func, (1,)) 1 >>> apply(func, (1,), {}) Traceback (innermost last): File "<stdin>", line 1, in ? MemoryError >>> ### I first found this problem when trying to simply import the 'threading' module: ### Python 1.5.2 (#33, Sep 23 1999, 21:46:26) [C] on irix6 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import threading Traceback (innermost last): File "<stdin>", line 1, in ? File "./Lib/threading.py", line 545, in ? _MainThread() File "./Lib/threading.py", line 460, in __init__ Thread.__init__(self, name="MainThread") File "./Lib/threading.py", line 332, in __init__ self.__block = Condition(Lock()) File "./Lib/threading.py", line 136, in Condition return apply(_Condition, args, kwargs) MemoryError >>> ### The variable 'kwargs' in this case is {}. The actual exception is thrown at line 2467 of Python/ceval.c: if (kw != NULL) { int pos, i; nk = PyDict_Size(kw); /* 2467 */ k = PyMem_NEW(PyObject *, 2*nk); /* nk, the PyDict_Size (the size of ma_used) is 0 */ if (k == NULL) { PyErr_NoMemory(); Py_DECREF(arg); return NULL; } pos = i = 0; while (PyDict_Next(kw, &pos, &k[i], &k[i+1])) i += 2; nk = i/2; /* XXX This is broken if the caller deletes dict items! */ } Currently, I am making the following change to threading to catch {} kwargs: ### def Condition(*args, **kwargs): if kwargs=={}: return apply(_Condition, args) else: return apply(_Condition, args, kwargs) ### ==================================================================== Audit trail: Fri Sep 24 16:14:47 1999 guido changed notes Fri Sep 24 16:14:48 1999 guido moved from incoming to platformbug Bug Importer FIXRELEASED MEDIUM platform-specific Bug Importer Bug Importer 2000-07-31T21:30:00Z Jitterbug-Id: 85 Submitted-By: sdunn@digitalanvil.com Date: Thu, 23 Sep 1999 23:03:49 -0400 (EDT) Version: 1.5.2 OS: Irix 6.5 Description: The builtin function apply() seems to barf on empty dictionaries when passed as the keyword list. See the following output: ### Python 1.5.2 (#33, Sep 23 1999, 21:46:26) [C] on irix6 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> def func(a): ... return a ... >>> print func <function func at 1018aa68> >>> func(1) 1 >>> apply(func, (1,)) 1 >>> apply(func, (1,), {}) Traceback (innermost last): File "<stdin>", line 1, in ? MemoryError >>> ### I first found this problem when trying to simply import the 'threading' module: ### Python 1.5.2 (#33, Sep 23 1999, 21:46:26) [C] on irix6 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import threading Traceback (innermost last): File "<stdin>", line 1, in ? File "./Lib/threading.py", line 545, in ? _MainThread() File "./Lib/threading.py", line 460, in __init__ Thread.__init__(self, name="MainThread") File "./Lib/threading.py", line 332, in __init__ self.__block = Condition(Lock()) File "./Lib/threading.py", line 136, in Condition return apply(_Condition, args, kwargs) MemoryError >>> ### The variable 'kwargs' in this case is {}. The actual exception is thrown at line 2467 of Python/ceval.c: if (kw != NULL) { int pos, i; nk = PyDict_Size(kw); /* 2467 */ k = PyMem_NEW(PyObject *, 2*nk); /* nk, the PyDict_Size (the size of ma_used) is 0 */ if (k == NULL) { PyErr_NoMemory(); Py_DECREF(arg); return NULL; } pos = i = 0; while (PyDict_Next(kw, &pos, &k[i], &k[i+1])) i += 2; nk = i/2; /* XXX This is broken if the caller deletes dict items! */ } Currently, I am making the following change to threading to catch {} kwargs: ### def Condition(*args, **kwargs): if kwargs=={}: return apply(_Condition, args) else: return apply(_Condition, args, kwargs) ### ==================================================================== Audit trail: Fri Sep 24 16:14:47 1999 guido changed notes Fri Sep 24 16:14:48 1999 guido moved from incoming to platformbug Bug Importer 2000-08-01T21:03:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] apply(): throws MemoryError when sending an {} as the keyword list (PR#85) Date: Fri, 24 Sep 1999 10:46:01 -0400 > The builtin function apply() seems to barf on empty dictionaries > when passed as the keyword list. See the following output: > >>> apply(func, (1,), {}) > Traceback (innermost last): > File "<stdin>", line 1, in ? > MemoryError > >>> > The variable 'kwargs' in this case is {}. The actual exception is thrown > at line 2467 of Python/ceval.c: > > if (kw != NULL) { > int pos, i; > nk = PyDict_Size(kw); > > /* 2467 */ k = PyMem_NEW(PyObject *, 2*nk); > /* nk, the PyDict_Size (the size of ma_used) is 0 */ > > if (k == NULL) { > PyErr_NoMemory(); > Py_DECREF(arg); > return NULL; > } > pos = i = 0; > while (PyDict_Next(kw, &pos, &k[i], &k[i+1])) > i += 2; > nk = i/2; > /* XXX This is broken if the caller deletes dict items! */ > } Thanks very much for your detailed analysis! The cause is probably that somehow the configure script doesn't compute the correct value for MALLOC_ZERO_RETURNS_NULL. I don't know why; the test seems simple enough. (Maybe you inherited a config.cache file from a previous Irix version?) To work around this in the build, if "make clobber" and rerunning configure don't do the trick, add #define MALLOC_ZERO_RETURNS_NULL 1 to the top of Include/mymalloc.h. Please let me know if rerunning configure makes the bug go away; this will decides the classification of your bug report. --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-08-01T21:04:00Z It appears that on Irix, malloc(0) returns NULL when -lmalloc is used but a valid pointer without -lmalloc. Not clear how the configure script could have made the wrong choice, but user error is not ruled out (could have reconfigured without clearing config.clache). Bug Importer 2000-08-01T21:04:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] apply(): throws MemoryError when sending an {} as the keyword list (PR#85) Date: Fri, 24 Sep 1999 16:11:11 -0400 > The use of > > #define MALLOC_ZERO_RETURNS_NULL 1 > > at the top of mymalloc.h worked fine... > By curiousity.. I just tried compiling the following: > > /*testmalloc.c*/ > #include <stdio.h> > main() > { > int *fp; > int *sp; > > fp = (int*)malloc(0); > sp = (int*)malloc(sizeof(int)); > printf("fp: %x\nsp: %x\n", fp, sp); > } > /**/ > > First, I just compiled normally: > > > cc -o testmalloc testmalloc.c > > ./testmalloc > fp: 10015010 > sp: 10015020 > > Then I compiled with the -lmalloc flag (libmalloc is the SGI high performance > memory library - which seems to be the default used after running the > configure script) > > > cc -o testmalloc testmalloc.c > > ./testmalloc > fp: 0 > sp: 10015048 > > So... It looks like without libmalloc, we're actually getting memory when we > "shouldn't" - but from reading your source code it seems like that's the way > it is usually made to work (weird). When compiling with libmalloc, the > returned 0 is triggering the MemError flag. There are two schools of thought here -- one says that malloc(0) should return a non-NULL pointer because it doesn't "fail": it correctly allocates an array of 0 bytes; the other of course says that malloc(0) is nonsensical and should return an error. ANSI C allows both (as long as consistent) so Python supports either. Could it be that the configure script was run without -lmalloc but later for some reason you rebuilt with -lmalloc? (I think that enabling threading might cause this.) > At ceval.c:2467, should it even get to this point if the passed in kwargs == > {}? It does a PyDict_Size of it, which returns 0 (which seems correct) but kw > isn't NULL. It seems like at this point that it should be.. {} is an object so it is not NULL. Given a correct malloc, the code will work with {} or NULL. --Guido van Rossum (home page: http://www.python.org/~guido/) 2000-07-31T21:30:00Z sf210712 Jitterbug-Id: 86 Submitted-By: Sean Dunn <sdunn@digitalanvil.com> Date: Fri, 24 Sep 1999 14:44:22 -0500 Version: None OS: None The use of #define MALLOC_ZERO_RETURNS_NULL 1 at the top of mymalloc.h worked fine... By curiousity.. I just tried compiling the following: /*testmalloc.c*/ #include <stdio.h> main() { int *fp; int *sp; fp = (int*)malloc(0); sp = (int*)malloc(sizeof(int)); printf("fp: %x\nsp: %x\n", fp, sp); } /**/ First, I just compiled normally: > cc -o testmalloc testmalloc.c > ./testmalloc fp: 10015010 sp: 10015020 Then I compiled with the -lmalloc flag (libmalloc is the SGI high performance memory library - which seems to be the default used after running the configure script) > cc -o testmalloc testmalloc.c > ./testmalloc fp: 0 sp: 10015048 So... It looks like without libmalloc, we're actually getting memory when we "shouldn't" - but from reading your source code it seems like that's the way it is usually made to work (weird). When compiling with libmalloc, the returned 0 is triggering the MemError flag. At ceval.c:2467, should it even get to this point if the passed in kwargs == {}? It does a PyDict_Size of it, which returns 0 (which seems correct) but kw isn't NULL. It seems like at this point that it should be.. Sean Guido van Rossum wrote: > > The builtin function apply() seems to barf on empty dictionaries > > when passed as the keyword list. See the following output: > > > >>> apply(func, (1,), {}) > > Traceback (innermost last): > > File "<stdin>", line 1, in ? > > MemoryError > > >>> > > > The variable 'kwargs' in this case is {}. The actual exception is thrown > > at line 2467 of Python/ceval.c: > > > > if (kw != NULL) { > > int pos, i; > > nk = PyDict_Size(kw); > > > > /* 2467 */ k = PyMem_NEW(PyObject *, 2*nk); > > /* nk, the PyDict_Size (the size of ma_used) is 0 */ > > > > if (k == NULL) { > > PyErr_NoMemory(); > > Py_DECREF(arg); > > return NULL; > > } > > pos = i = 0; > > while (PyDict_Next(kw, &pos, &k[i], &k[i+1])) > > i += 2; > > nk = i/2; > > /* XXX This is broken if the caller deletes dict items! */ > > } > > Thanks very much for your detailed analysis! The cause is probably > that somehow the configure script doesn't compute the correct value > for MALLOC_ZERO_RETURNS_NULL. I don't know why; the test seems simple > enough. (Maybe you inherited a config.cache file from a previous Irix > version?) To work around this in the build, if "make clobber" and > rerunning configure don't do the trick, add > > #define MALLOC_ZERO_RETURNS_NULL 1 > > to the top of Include/mymalloc.h. > > Please let me know if rerunning configure makes the bug go away; this > will decides the classification of your bug report. > > --Guido van Rossum (home page: http://www.python.org/~guido/) ==================================================================== Audit trail: Fri Sep 24 16:15:04 1999 guido changed notes Fri Sep 24 16:15:04 1999 guido moved from incoming to platformbug Bug Importer REJECTED MEDIUM platform-specific Guido van Rossum Bug Importer Bug Importer 2000-07-31T21:30:00Z Jitterbug-Id: 86 Submitted-By: Sean Dunn <sdunn@digitalanvil.com> Date: Fri, 24 Sep 1999 14:44:22 -0500 Version: None OS: None The use of #define MALLOC_ZERO_RETURNS_NULL 1 at the top of mymalloc.h worked fine... By curiousity.. I just tried compiling the following: /*testmalloc.c*/ #include <stdio.h> main() { int *fp; int *sp; fp = (int*)malloc(0); sp = (int*)malloc(sizeof(int)); printf("fp: %x\nsp: %x\n", fp, sp); } /**/ First, I just compiled normally: > cc -o testmalloc testmalloc.c > ./testmalloc fp: 10015010 sp: 10015020 Then I compiled with the -lmalloc flag (libmalloc is the SGI high performance memory library - which seems to be the default used after running the configure script) > cc -o testmalloc testmalloc.c > ./testmalloc fp: 0 sp: 10015048 So... It looks like without libmalloc, we're actually getting memory when we "shouldn't" - but from reading your source code it seems like that's the way it is usually made to work (weird). When compiling with libmalloc, the returned 0 is triggering the MemError flag. At ceval.c:2467, should it even get to this point if the passed in kwargs == {}? It does a PyDict_Size of it, which returns 0 (which seems correct) but kw isn't NULL. It seems like at this point that it should be.. Sean Guido van Rossum wrote: > > The builtin function apply() seems to barf on empty dictionaries > > when passed as the keyword list. See the following output: > > > >>> apply(func, (1,), {}) > > Traceback (innermost last): > > File "<stdin>", line 1, in ? > > MemoryError > > >>> > > > The variable 'kwargs' in this case is {}. The actual exception is thrown > > at line 2467 of Python/ceval.c: > > > > if (kw != NULL) { > > int pos, i; > > nk = PyDict_Size(kw); > > > > /* 2467 */ k = PyMem_NEW(PyObject *, 2*nk); > > /* nk, the PyDict_Size (the size of ma_used) is 0 */ > > > > if (k == NULL) { > > PyErr_NoMemory(); > > Py_DECREF(arg); > > return NULL; > > } > > pos = i = 0; > > while (PyDict_Next(kw, &pos, &k[i], &k[i+1])) > > i += 2; > > nk = i/2; > > /* XXX This is broken if the caller deletes dict items! */ > > } > > Thanks very much for your detailed analysis! The cause is probably > that somehow the configure script doesn't compute the correct value > for MALLOC_ZERO_RETURNS_NULL. I don't know why; the test seems simple > enough. (Maybe you inherited a config.cache file from a previous Irix > version?) To work around this in the build, if "make clobber" and > rerunning configure don't do the trick, add > > #define MALLOC_ZERO_RETURNS_NULL 1 > > to the top of Include/mymalloc.h. > > Please let me know if rerunning configure makes the bug go away; this > will decides the classification of your bug report. > > --Guido van Rossum (home page: http://www.python.org/~guido/) ==================================================================== Audit trail: Fri Sep 24 16:15:04 1999 guido changed notes Fri Sep 24 16:15:04 1999 guido moved from incoming to platformbug Jeremy Hylton 2000-09-07T21:28:00Z Please do triage Guido van Rossum 2000-09-13T10:51:00Z I don't understand why the configure script would use a different malloc library for its test of malloc(0) than what is used later to compile Python. Could it be that simply "make clobber" and running configure again would solve the problem? I'm closing the bug report for now. If this is still a problem with Python 2.0, please send email and I'll reopen it. 2000-07-31T21:30:00Z sf210713 Jitterbug-Id: 95 Submitted-By: bridge@gsnet.com Date: Tue, 5 Oct 1999 12:45:12 -0400 (EDT) Version: 1.5.2 OS: RedHat 5.2 Hi- I got a core dump with the following line, and I don't see it in the bug database. I inadvertantly put a %X instead of a %Y in the format string for strptime: Python 1.5.2 (#1, Apr 18 1999, 16:03:16) [GCC pgcc-2.91.60 19981201 (egcs-1.1.1 on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import time >>> time.strptime("Oct 28 1999", "%b %d %X") Segmentation fault (core dumped) ==================================================================== Audit trail: Wed Oct 06 11:12:55 1999 guido changed notes Wed Oct 06 11:12:55 1999 guido moved from incoming to platformbug Bug Importer REJECTED HIGH x-3rd-party Jeremy Hylton python-library Bug Importer Bug Importer 2000-07-31T21:30:00Z Jitterbug-Id: 95 Submitted-By: bridge@gsnet.com Date: Tue, 5 Oct 1999 12:45:12 -0400 (EDT) Version: 1.5.2 OS: RedHat 5.2 Hi- I got a core dump with the following line, and I don't see it in the bug database. I inadvertantly put a %X instead of a %Y in the format string for strptime: Python 1.5.2 (#1, Apr 18 1999, 16:03:16) [GCC pgcc-2.91.60 19981201 (egcs-1.1.1 on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import time >>> time.strptime("Oct 28 1999", "%b %d %X") Segmentation fault (core dumped) ==================================================================== Audit trail: Wed Oct 06 11:12:55 1999 guido changed notes Wed Oct 06 11:12:55 1999 guido moved from incoming to platformbug Peter Schneider-Kamp 2000-08-05T10:57:00Z I cannot test this as I do not have RedHat 5.2. It works for me on SuSE Linux 6.4 both with 1.5.2 and the current CVS version. Somebody with a RedHat 5.2 system should check this out. Jeremy Hylton 2000-08-25T17:00:00Z This is not a Python bug. I can reproduce the core dump using straight C code. I'm running a RedHat 6.x system with glibc-2.1.2-11. I will investigate whether this is a known bug. There doesn't seem to be any way for Python to cope with this. /* Check for a bug in the local strptime, which manifests itself in Python as time.strptime("Oct 28 1999", "%b %d %X") */ #define _GNU_SOURCE #include <time.h> main() { struct tm tm; char *result; memset((void *)&tm, '\0', sizeof(tm)); result = strptime("Oct 28 1999", "%b %d %X", &tm); } Jeremy Hylton 2000-08-25T17:12:00Z Verified that this bug is fixed with glibc 2.1.3. 2000-07-31T21:36:00Z sf210715 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM x-3rd-party Bug Importer Bug Importer 2000-07-31T21:36:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:27:00Z test bug from Jitterbug -> SF conversion Skip Montanaro 2002-03-24T16:42:00Z outdated - references 1.5.2 and old versions of gcc and glibc Tim Peters 2002-03-24T17:55:00Z Closed as 3rd-Party and Fixed: no info was added to this bug in more than 2 years, the original report said it depended on which kernel was in use, and AFAICT the problem was never reported again. 2000-07-31T21:36:00Z sf210716 Jitterbug-Id: 109 Submitted-By: Curt Finch <curt@journyx.com> Date: Thu, 14 Oct 1999 14:58:08 -0500 (CDT) Version: None OS: None anyone heard of any python time bugs? __________________________________________________________________ Web-Based Project Management, Journyx TimeSheet and Tracking Software FREE (800)755-9878 FREE at http://journyx.com/wts.html curt@www.JOURNYX.com ------------------------------------------------------------------ ---------- Forwarded message ---------- Date: Thu, 14 Oct 1999 14:09:35 -0500 (CDT) From: John Maddalozzo <john@journyx.com> To: "Stappert, Andreas" <andreas.stappert@key-work.de> Cc: support@journyx.com Subject: Re: Date problem unresolved [DIN 2646] Andreas, I'm stumped. It seems there is a problem in the python time library. I may have to post a message to a python news group if code inspection doesn't turn anything up. 2646 is the problem report number. We'll dig around and see what we can find out. Meanwhile, you might want to send me the output of the uname -a command and any other information you have that might help. (Linux level, etc) Regards, John __________________________________________________________________ Web-Based Project Management and TimeSheet Software JournyxTime FREE at http://journyx.com/wts.html John Maddalozzo - john@JOURNYX.com (512)834-8888 / (800)755-9878 ------------------------------------------------------------------ On Thu, 14 Oct 1999, Stappert, Andreas wrote: > Hi John, > > Well, for some reason I always have the strangest thing happen to me :-) > even though I try to conform to every standards I know of... > > Here is what I get. Looks like it matches your machine (our server date is > set a day off). Do you think it would help if we change the timezone to EST > or something? > > > date +%s > 939838233 > timesheet:~> > > The hardware is an (old) 486 (yes I know old ... that is just our > testserver, once we are putting Journyx to real use, we are going to put a > nicer machine underneath it). I don't know the mainboard type by heart. > > Oh, I should probably also tell you this: At the beginning, the time was > right but once we got some modifications done and rebootet the machine, it > started acting this strange. > > Regards, > Andreas > > -----Ursprungliche Nachricht----- > Von: John Maddalozzo [mailto:john@journyx.com] > Gesendet: Donnerstag, 14. Oktober 1999 20:05 > An: Stappert, Andreas > Betreff: Re: AW: AW: Date problem unresolved > > > > Very strange, Andreas. > the time.time() result shows the number of seconds since the "epoch" > (see http://python.org/doc/current/lib/module-time.html) > Your number of seconds should be somewhere between > 939916983.851 (the time on my computer when I wrote example note below) > and > 939923915.897 (the time on my computer I just now checked) > > What does the command > date +%s > say? > What hardware are you using? > > __________________________________________________________________ > Web-Based Project Management and TimeSheet Software JournyxTime > FREE at http://journyx.com/wts.html > John Maddalozzo - john@JOURNYX.com (512)834-8888 / (800)755-9878 > ------------------------------------------------------------------ > > On Thu, 14 Oct 1999, Stappert, Andreas wrote: > > > Here you go (my mistake): > > > > timesheet:~/jtime/jtime/pi/bin> python > > Python 1.5.2 (#1, Sep 27 1999, 17:01:09) [GCC egcs-2.91.66 19990314/Linux > > (egcs > > - on linux2 > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > >>> import time > > >>> import wtdate > > >>> wtdate.today() > > Thu 13 Jul 1995 > > >>> time.localtime(time.time()) > > (1995, 7, 13, 8, 38, 9, 3, 194, 1) > > >>> time.time() > > 805617494.587 > > >>> time.gmtime(time.time()) > > (1995, 7, 13, 6, 38, 54, 3, 194, 0) > > >>> time.gzname > > Traceback (innermost last): > > File "<stdin>", line 1, in ? > > AttributeError: gzname > > >>> time.timezone > > -3600 > > >>> time.tzname > > ('CET', 'CEST') > > >>> > > > > -----Ursprungliche Nachricht----- > > Von: John Maddalozzo [mailto:john@journyx.com] > > Gesendet: Donnerstag, 14. Oktober 1999 19:09 > > An: Stappert, Andreas > > Betreff: Re: AW: Date problem unresolved > > > > > > > > Hi Andreas, > > Did you remember to source setup? > > In pi/bin at the shell prompt do: > > . ./setup > > You need to do that first. To check that it has been sourced, do > > echo $PYTHONPATH > > that should return something like this: > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 753>. ./setup > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 754>echo $PYTHONPATH > > > //home/john_scratch/jtime/jtime/pi/apache/wtlib://home/john_scratch/jtime/jt > > > ime/pd/Linux/python/lib/python1.5/://home/john_scratch/jtime/jtime/pi/apache > > /serverroot/cgi-bin > > > > Then it should be able to find wtdate.pyc in pi/apache/wtlib > > > > Regards, John > > > > On Thu, 14 Oct 1999, Stappert, Andreas wrote: > > > > > Hi John, > > > > > > I already get stuck when I try to import wtdate: > > > > > > python > > > Python 1.5.1 (#1, Mar 21 1999, 22:49:36) [GCC egcs-2.91.66 19990314/Li > on > > > linux > > > -i386 > > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > > >>> import time > > > >>> import wtdate > > > Traceback (innermost last): > > > File "<stdin>", line 1, in ? > > > ImportError: No module named wtdate > > > > > > -----Ursprungliche Nachricht----- > > > Von: John Maddalozzo [mailto:john@journyx.com] > > > Gesendet: Donnerstag, 14. Oktober 1999 18:05 > > > An: Stappert, Andreas > > > Cc: support@journyx.com > > > Betreff: Re: Date problem unresolved > > > > > > > > > > > > Andreas, > > > This must be some problem with resolving the time zone. > > > Please do the following and send me the output. > > > > > > What this is doing is invoking python and using its libraries to get > > dates. > > > I'm hoping that this will give us some idea of what is wrong. > > > Regards, John > > > > > > cd <jtime install dir>/jtime/pi/bin > > > . ./setup > > > python > > > import time > > > import wtdate > > > wtdate.today() > > > time.localtime(time.time()) > > > time.time() > > > time.gmtime(time.time()) > > > time.gzname > > > time.timezone > > > > > > For example when I do it here I get... > > > > > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 743>python > > > Python 1.5.2 (#1, Oct 2 1999, 23:28:23) [GCC egcs-2.91.66 > 19990314/Linux > > > (egcs- on linux2 > > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > > >>> import time > > > >>> import wtdate > > > >>> wtdate.today() > > > Thu 14 Oct 1999 > > > >>> time.localtime(time.time()) > > > (1999, 10, 14, 11, 2, 51, 3, 287, 1) > > > >>> time.time() > > > 939916983.851 > > > >>> time.gmtime(time.time()) > > > (1999, 10, 14, 16, 7, 10, 3, 287, 0) > > > >>> time.tzname > > > ('CST', 'CDT') > > > >>> time.timezone > > > 21600 > > > > > > > > > > > > __________________________________________________________________ > > > Web-Based Project Management and TimeSheet Software JournyxTime > > > FREE at http://journyx.com/wts.html > > > John Maddalozzo - john@JOURNYX.com (512)834-8888 / (800)755-9878 > > > ------------------------------------------------------------------ > > > > > > On Thu, 14 Oct 1999, Stappert, Andreas wrote: > > > > > > > Hello there, > > > > We are still having a major problem with the Journyx installation on > our > > > > Linux server: > > > > The current date on the Linux machine is > > > > Mit Okt 13 10:35:14 CEST 1999 > > > > but Journyx uses the below July 12, 1995 as current date. Is there any > > way > > > > to correct this problem? > > > > We would like to go and find some more customers for Journyx but if we > > can > > > > not figure out how to correct this problem, we will not be able to > > > > demonstrate it. > > > > Thanks for your immediate attention > > > > Andreas > > > > > > > > License Key Data > > > > * Dates > > > > * Install Date: Mon Okt 4 17:36:04 CEST 1999 > > > > * Product Expiration Date: Never > > > > * Current Date: Wed 12 Jul 1995 > > > > * Users > > > > * Licensed Number of Users: 10 > > > > * Current Number of User Data Unavailable > > > > * Hosts > > > > * Licensed Host: 192 > > > > * Current Host: 192 > > > > Operating System Information > > > > * Current: Linux 192.168.0.100 2.2.5-15de #1 Tue May 25 00:43:15 EDT > > > > 1999 i486 > > > > * Original: Linux karsrv01.key-work.de 2.2.5-15de #1 Tue May 25 > > > > 00:43:15 EDT 1999 i486 unknown > > > > Credits > > > > * Docs: Sarah Griswold > > > > * Testing: Matt Neiman > > > > * Coding: > > > > * Chris Anderson > > > > * Curt Finch > > > > * John Maddalozzo > > > > * Andrew Reutter > > > > * Design and enhancement ideas: literally thousands of registered > > > > users just like you. <http://journyx.com/featureq.html> > > > > > > > > > > > > > > > > ----------------------------------------------- > > > > Andreas Stappert > > > > Key-Work Consulting GmbH > > > > > > > > Haid-und-Neu-Strasse 7 - 76131 Karlsruhe - Germany > > > > +49 721 664936-0 - mailto:andreas.stappert@key-work.de > > > > > > > > > > > > > > > ==================================================================== Audit trail: Mon Oct 18 17:53:07 1999 guido changed notes Mon Oct 18 17:53:07 1999 guido changed notification Mon Oct 18 17:53:08 1999 guido moved from incoming to open Tue Oct 19 00:42:35 1999 guido changed notes Tue Oct 19 00:42:37 1999 guido moved from open to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-07-31T21:36:00Z Jitterbug-Id: 109 Submitted-By: Curt Finch <curt@journyx.com> Date: Thu, 14 Oct 1999 14:58:08 -0500 (CDT) Version: None OS: None anyone heard of any python time bugs? __________________________________________________________________ Web-Based Project Management, Journyx TimeSheet and Tracking Software FREE (800)755-9878 FREE at http://journyx.com/wts.html curt@www.JOURNYX.com ------------------------------------------------------------------ ---------- Forwarded message ---------- Date: Thu, 14 Oct 1999 14:09:35 -0500 (CDT) From: John Maddalozzo <john@journyx.com> To: "Stappert, Andreas" <andreas.stappert@key-work.de> Cc: support@journyx.com Subject: Re: Date problem unresolved [DIN 2646] Andreas, I'm stumped. It seems there is a problem in the python time library. I may have to post a message to a python news group if code inspection doesn't turn anything up. 2646 is the problem report number. We'll dig around and see what we can find out. Meanwhile, you might want to send me the output of the uname -a command and any other information you have that might help. (Linux level, etc) Regards, John __________________________________________________________________ Web-Based Project Management and TimeSheet Software JournyxTime FREE at http://journyx.com/wts.html John Maddalozzo - john@JOURNYX.com (512)834-8888 / (800)755-9878 ------------------------------------------------------------------ On Thu, 14 Oct 1999, Stappert, Andreas wrote: > Hi John, > > Well, for some reason I always have the strangest thing happen to me :-) > even though I try to conform to every standards I know of... > > Here is what I get. Looks like it matches your machine (our server date is > set a day off). Do you think it would help if we change the timezone to EST > or something? > > > date +%s > 939838233 > timesheet:~> > > The hardware is an (old) 486 (yes I know old ... that is just our > testserver, once we are putting Journyx to real use, we are going to put a > nicer machine underneath it). I don't know the mainboard type by heart. > > Oh, I should probably also tell you this: At the beginning, the time was > right but once we got some modifications done and rebootet the machine, it > started acting this strange. > > Regards, > Andreas > > -----Ursprungliche Nachricht----- > Von: John Maddalozzo [mailto:john@journyx.com] > Gesendet: Donnerstag, 14. Oktober 1999 20:05 > An: Stappert, Andreas > Betreff: Re: AW: AW: Date problem unresolved > > > > Very strange, Andreas. > the time.time() result shows the number of seconds since the "epoch" > (see http://python.org/doc/current/lib/module-time.html) > Your number of seconds should be somewhere between > 939916983.851 (the time on my computer when I wrote example note below) > and > 939923915.897 (the time on my computer I just now checked) > > What does the command > date +%s > say? > What hardware are you using? > > __________________________________________________________________ > Web-Based Project Management and TimeSheet Software JournyxTime > FREE at http://journyx.com/wts.html > John Maddalozzo - john@JOURNYX.com (512)834-8888 / (800)755-9878 > ------------------------------------------------------------------ > > On Thu, 14 Oct 1999, Stappert, Andreas wrote: > > > Here you go (my mistake): > > > > timesheet:~/jtime/jtime/pi/bin> python > > Python 1.5.2 (#1, Sep 27 1999, 17:01:09) [GCC egcs-2.91.66 19990314/Linux > > (egcs > > - on linux2 > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > >>> import time > > >>> import wtdate > > >>> wtdate.today() > > Thu 13 Jul 1995 > > >>> time.localtime(time.time()) > > (1995, 7, 13, 8, 38, 9, 3, 194, 1) > > >>> time.time() > > 805617494.587 > > >>> time.gmtime(time.time()) > > (1995, 7, 13, 6, 38, 54, 3, 194, 0) > > >>> time.gzname > > Traceback (innermost last): > > File "<stdin>", line 1, in ? > > AttributeError: gzname > > >>> time.timezone > > -3600 > > >>> time.tzname > > ('CET', 'CEST') > > >>> > > > > -----Ursprungliche Nachricht----- > > Von: John Maddalozzo [mailto:john@journyx.com] > > Gesendet: Donnerstag, 14. Oktober 1999 19:09 > > An: Stappert, Andreas > > Betreff: Re: AW: Date problem unresolved > > > > > > > > Hi Andreas, > > Did you remember to source setup? > > In pi/bin at the shell prompt do: > > . ./setup > > You need to do that first. To check that it has been sourced, do > > echo $PYTHONPATH > > that should return something like this: > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 753>. ./setup > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 754>echo $PYTHONPATH > > > //home/john_scratch/jtime/jtime/pi/apache/wtlib://home/john_scratch/jtime/jt > > > ime/pd/Linux/python/lib/python1.5/://home/john_scratch/jtime/jtime/pi/apache > > /serverroot/cgi-bin > > > > Then it should be able to find wtdate.pyc in pi/apache/wtlib > > > > Regards, John > > > > On Thu, 14 Oct 1999, Stappert, Andreas wrote: > > > > > Hi John, > > > > > > I already get stuck when I try to import wtdate: > > > > > > python > > > Python 1.5.1 (#1, Mar 21 1999, 22:49:36) [GCC egcs-2.91.66 19990314/Li > on > > > linux > > > -i386 > > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > > >>> import time > > > >>> import wtdate > > > Traceback (innermost last): > > > File "<stdin>", line 1, in ? > > > ImportError: No module named wtdate > > > > > > -----Ursprungliche Nachricht----- > > > Von: John Maddalozzo [mailto:john@journyx.com] > > > Gesendet: Donnerstag, 14. Oktober 1999 18:05 > > > An: Stappert, Andreas > > > Cc: support@journyx.com > > > Betreff: Re: Date problem unresolved > > > > > > > > > > > > Andreas, > > > This must be some problem with resolving the time zone. > > > Please do the following and send me the output. > > > > > > What this is doing is invoking python and using its libraries to get > > dates. > > > I'm hoping that this will give us some idea of what is wrong. > > > Regards, John > > > > > > cd <jtime install dir>/jtime/pi/bin > > > . ./setup > > > python > > > import time > > > import wtdate > > > wtdate.today() > > > time.localtime(time.time()) > > > time.time() > > > time.gmtime(time.time()) > > > time.gzname > > > time.timezone > > > > > > For example when I do it here I get... > > > > > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 743>python > > > Python 1.5.2 (#1, Oct 2 1999, 23:28:23) [GCC egcs-2.91.66 > 19990314/Linux > > > (egcs- on linux2 > > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > > >>> import time > > > >>> import wtdate > > > >>> wtdate.today() > > > Thu 14 Oct 1999 > > > >>> time.localtime(time.time()) > > > (1999, 10, 14, 11, 2, 51, 3, 287, 1) > > > >>> time.time() > > > 939916983.851 > > > >>> time.gmtime(time.time()) > > > (1999, 10, 14, 16, 7, 10, 3, 287, 0) > > > >>> time.tzname > > > ('CST', 'CDT') > > > >>> time.timezone > > > 21600 > > > > > > > > > > > > __________________________________________________________________ > > > Web-Based Project Management and TimeSheet Software JournyxTime > > > FREE at http://journyx.com/wts.html > > > John Maddalozzo - john@JOURNYX.com (512)834-8888 / (800)755-9878 > > > ------------------------------------------------------------------ > > > > > > On Thu, 14 Oct 1999, Stappert, Andreas wrote: > > > > > > > Hello there, > > > > We are still having a major problem with the Journyx installation on > our > > > > Linux server: > > > > The current date on the Linux machine is > > > > Mit Okt 13 10:35:14 CEST 1999 > > > > but Journyx uses the below July 12, 1995 as current date. Is there any > > way > > > > to correct this problem? > > > > We would like to go and find some more customers for Journyx but if we > > can > > > > not figure out how to correct this problem, we will not be able to > > > > demonstrate it. > > > > Thanks for your immediate attention > > > > Andreas > > > > > > > > License Key Data > > > > * Dates > > > > * Install Date: Mon Okt 4 17:36:04 CEST 1999 > > > > * Product Expiration Date: Never > > > > * Current Date: Wed 12 Jul 1995 > > > > * Users > > > > * Licensed Number of Users: 10 > > > > * Current Number of User Data Unavailable > > > > * Hosts > > > > * Licensed Host: 192 > > > > * Current Host: 192 > > > > Operating System Information > > > > * Current: Linux 192.168.0.100 2.2.5-15de #1 Tue May 25 00:43:15 EDT > > > > 1999 i486 > > > > * Original: Linux karsrv01.key-work.de 2.2.5-15de #1 Tue May 25 > > > > 00:43:15 EDT 1999 i486 unknown > > > > Credits > > > > * Docs: Sarah Griswold > > > > * Testing: Matt Neiman > > > > * Coding: > > > > * Chris Anderson > > > > * Curt Finch > > > > * John Maddalozzo > > > > * Andrew Reutter > > > > * Design and enhancement ideas: literally thousands of registered > > > > users just like you. <http://journyx.com/featureq.html> > > > > > > > > > > > > > > > > ----------------------------------------------- > > > > Andreas Stappert > > > > Key-Work Consulting GmbH > > > > > > > > Haid-und-Neu-Strasse 7 - 76131 Karlsruhe - Germany > > > > +49 721 664936-0 - mailto:andreas.stappert@key-work.de > > > > > > > > > > > > > > > ==================================================================== Audit trail: Mon Oct 18 17:53:07 1999 guido changed notes Mon Oct 18 17:53:07 1999 guido changed notification Mon Oct 18 17:53:08 1999 guido moved from incoming to open Tue Oct 19 00:42:35 1999 guido changed notes Tue Oct 19 00:42:37 1999 guido moved from open to irreproducible Jeremy Hylton 2000-08-01T21:34:00Z test bug from Jitterbug -> SF conversion 2000-07-31T21:36:00Z sf210717 Jitterbug-Id: 143 Submitted-By: ellement@sdd.hp.com Date: Thu, 2 Dec 1999 14:04:38 -0500 (EST) Version: 1.5.2 OS: HP-UX 10.20 After building python, 'make test' fails when test_array is run: > python Lib/test/test_array.py Traceback (innermost last): File "Lib/test/test_array.py", line 85, in ? main() File "Lib/test/test_array.py", line 10, in main testtype('c', 'c') File "Lib/test/test_array.py", line 21, in testtype a.append(example) AttributeError: '' object has no attribute 'append' Memory fault(coredump) How do I go about debugging this? ==================================================================== Audit trail: Fri Dec 03 10:38:53 1999 guido changed notes Fri Dec 03 10:38:53 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-07-31T21:36:00Z Jitterbug-Id: 143 Submitted-By: ellement@sdd.hp.com Date: Thu, 2 Dec 1999 14:04:38 -0500 (EST) Version: 1.5.2 OS: HP-UX 10.20 After building python, 'make test' fails when test_array is run: > python Lib/test/test_array.py Traceback (innermost last): File "Lib/test/test_array.py", line 85, in ? main() File "Lib/test/test_array.py", line 10, in main testtype('c', 'c') File "Lib/test/test_array.py", line 21, in testtype a.append(example) AttributeError: '' object has no attribute 'append' Memory fault(coredump) How do I go about debugging this? ==================================================================== Audit trail: Fri Dec 03 10:38:53 1999 guido changed notes Fri Dec 03 10:38:53 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:34:00Z test bug from Jitterbug -> SF conversion 2000-08-01T04:23:00Z sf210738 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer REJECTED MEDIUM trash Bug Importer Bug Importer 2000-08-01T04:23:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T04:25:00Z test bug from Jitterbug -> SF conversion 2000-08-01T04:23:00Z sf210739 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer REJECTED MEDIUM trash Bug Importer Bug Importer 2000-08-01T04:23:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T04:26:00Z test bug from jitterbug -> SF conversion 2000-08-01T04:23:00Z sf210740 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T04:23:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:28:00Z test bug from Jitterbug -> SF conversion 2000-08-01T04:26:00Z sf210741 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T04:26:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:28:00Z test bug from Jitterbug -> SF conversion 2000-08-01T04:26:00Z sf210742 Jitterbug-Id: 109 Submitted-By: Curt Finch <curt@journyx.com> Date: Thu, 14 Oct 1999 14:58:08 -0500 (CDT) Version: None OS: None anyone heard of any python time bugs? __________________________________________________________________ Web-Based Project Management, Journyx TimeSheet and Tracking Software FREE (800)755-9878 FREE at http://journyx.com/wts.html curt@www.JOURNYX.com ------------------------------------------------------------------ ---------- Forwarded message ---------- Date: Thu, 14 Oct 1999 14:09:35 -0500 (CDT) From: John Maddalozzo <john@journyx.com> To: "Stappert, Andreas" <andreas.stappert@key-work.de> Cc: support@journyx.com Subject: Re: Date problem unresolved [DIN 2646] Andreas, I'm stumped. It seems there is a problem in the python time library. I may have to post a message to a python news group if code inspection doesn't turn anything up. 2646 is the problem report number. We'll dig around and see what we can find out. Meanwhile, you might want to send me the output of the uname -a command and any other information you have that might help. (Linux level, etc) Regards, John __________________________________________________________________ Web-Based Project Management and TimeSheet Software JournyxTime FREE at http://journyx.com/wts.html John Maddalozzo - john@JOURNYX.com (512)834-8888 / (800)755-9878 ------------------------------------------------------------------ On Thu, 14 Oct 1999, Stappert, Andreas wrote: > Hi John, > > Well, for some reason I always have the strangest thing happen to me :-) > even though I try to conform to every standards I know of... > > Here is what I get. Looks like it matches your machine (our server date is > set a day off). Do you think it would help if we change the timezone to EST > or something? > > > date +%s > 939838233 > timesheet:~> > > The hardware is an (old) 486 (yes I know old ... that is just our > testserver, once we are putting Journyx to real use, we are going to put a > nicer machine underneath it). I don't know the mainboard type by heart. > > Oh, I should probably also tell you this: At the beginning, the time was > right but once we got some modifications done and rebootet the machine, it > started acting this strange. > > Regards, > Andreas > > -----Ursprungliche Nachricht----- > Von: John Maddalozzo [mailto:john@journyx.com] > Gesendet: Donnerstag, 14. Oktober 1999 20:05 > An: Stappert, Andreas > Betreff: Re: AW: AW: Date problem unresolved > > > > Very strange, Andreas. > the time.time() result shows the number of seconds since the "epoch" > (see http://python.org/doc/current/lib/module-time.html) > Your number of seconds should be somewhere between > 939916983.851 (the time on my computer when I wrote example note below) > and > 939923915.897 (the time on my computer I just now checked) > > What does the command > date +%s > say? > What hardware are you using? > > __________________________________________________________________ > Web-Based Project Management and TimeSheet Software JournyxTime > FREE at http://journyx.com/wts.html > John Maddalozzo - john@JOURNYX.com (512)834-8888 / (800)755-9878 > ------------------------------------------------------------------ > > On Thu, 14 Oct 1999, Stappert, Andreas wrote: > > > Here you go (my mistake): > > > > timesheet:~/jtime/jtime/pi/bin> python > > Python 1.5.2 (#1, Sep 27 1999, 17:01:09) [GCC egcs-2.91.66 19990314/Linux > > (egcs > > - on linux2 > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > >>> import time > > >>> import wtdate > > >>> wtdate.today() > > Thu 13 Jul 1995 > > >>> time.localtime(time.time()) > > (1995, 7, 13, 8, 38, 9, 3, 194, 1) > > >>> time.time() > > 805617494.587 > > >>> time.gmtime(time.time()) > > (1995, 7, 13, 6, 38, 54, 3, 194, 0) > > >>> time.gzname > > Traceback (innermost last): > > File "<stdin>", line 1, in ? > > AttributeError: gzname > > >>> time.timezone > > -3600 > > >>> time.tzname > > ('CET', 'CEST') > > >>> > > > > -----Ursprungliche Nachricht----- > > Von: John Maddalozzo [mailto:john@journyx.com] > > Gesendet: Donnerstag, 14. Oktober 1999 19:09 > > An: Stappert, Andreas > > Betreff: Re: AW: Date problem unresolved > > > > > > > > Hi Andreas, > > Did you remember to source setup? > > In pi/bin at the shell prompt do: > > . ./setup > > You need to do that first. To check that it has been sourced, do > > echo $PYTHONPATH > > that should return something like this: > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 753>. ./setup > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 754>echo $PYTHONPATH > > > //home/john_scratch/jtime/jtime/pi/apache/wtlib://home/john_scratch/jtime/jt > > > ime/pd/Linux/python/lib/python1.5/://home/john_scratch/jtime/jtime/pi/apache > > /serverroot/cgi-bin > > > > Then it should be able to find wtdate.pyc in pi/apache/wtlib > > > > Regards, John > > > > On Thu, 14 Oct 1999, Stappert, Andreas wrote: > > > > > Hi John, > > > > > > I already get stuck when I try to import wtdate: > > > > > > python > > > Python 1.5.1 (#1, Mar 21 1999, 22:49:36) [GCC egcs-2.91.66 19990314/Li > on > > > linux > > > -i386 > > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > > >>> import time > > > >>> import wtdate > > > Traceback (innermost last): > > > File "<stdin>", line 1, in ? > > > ImportError: No module named wtdate > > > > > > -----Ursprungliche Nachricht----- > > > Von: John Maddalozzo [mailto:john@journyx.com] > > > Gesendet: Donnerstag, 14. Oktober 1999 18:05 > > > An: Stappert, Andreas > > > Cc: support@journyx.com > > > Betreff: Re: Date problem unresolved > > > > > > > > > > > > Andreas, > > > This must be some problem with resolving the time zone. > > > Please do the following and send me the output. > > > > > > What this is doing is invoking python and using its libraries to get > > dates. > > > I'm hoping that this will give us some idea of what is wrong. > > > Regards, John > > > > > > cd <jtime install dir>/jtime/pi/bin > > > . ./setup > > > python > > > import time > > > import wtdate > > > wtdate.today() > > > time.localtime(time.time()) > > > time.time() > > > time.gmtime(time.time()) > > > time.gzname > > > time.timezone > > > > > > For example when I do it here I get... > > > > > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 743>python > > > Python 1.5.2 (#1, Oct 2 1999, 23:28:23) [GCC egcs-2.91.66 > 19990314/Linux > > > (egcs- on linux2 > > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > > >>> import time > > > >>> import wtdate > > > >>> wtdate.today() > > > Thu 14 Oct 1999 > > > >>> time.localtime(time.time()) > > > (1999, 10, 14, 11, 2, 51, 3, 287, 1) > > > >>> time.time() > > > 939916983.851 > > > >>> time.gmtime(time.time()) > > > (1999, 10, 14, 16, 7, 10, 3, 287, 0) > > > >>> time.tzname > > > ('CST', 'CDT') > > > >>> time.timezone > > > 21600 > > > > > > > > > > > > __________________________________________________________________ > > > Web-Based Project Management and TimeSheet Software JournyxTime > > > FREE at http://journyx.com/wts.html > > > John Maddalozzo - john@JOURNYX.com (512)834-8888 / (800)755-9878 > > > ------------------------------------------------------------------ > > > > > > On Thu, 14 Oct 1999, Stappert, Andreas wrote: > > > > > > > Hello there, > > > > We are still having a major problem with the Journyx installation on > our > > > > Linux server: > > > > The current date on the Linux machine is > > > > Mit Okt 13 10:35:14 CEST 1999 > > > > but Journyx uses the below July 12, 1995 as current date. Is there any > > way > > > > to correct this problem? > > > > We would like to go and find some more customers for Journyx but if we > > can > > > > not figure out how to correct this problem, we will not be able to > > > > demonstrate it. > > > > Thanks for your immediate attention > > > > Andreas > > > > > > > > License Key Data > > > > * Dates > > > > * Install Date: Mon Okt 4 17:36:04 CEST 1999 > > > > * Product Expiration Date: Never > > > > * Current Date: Wed 12 Jul 1995 > > > > * Users > > > > * Licensed Number of Users: 10 > > > > * Current Number of User Data Unavailable > > > > * Hosts > > > > * Licensed Host: 192 > > > > * Current Host: 192 > > > > Operating System Information > > > > * Current: Linux 192.168.0.100 2.2.5-15de #1 Tue May 25 00:43:15 EDT > > > > 1999 i486 > > > > * Original: Linux karsrv01.key-work.de 2.2.5-15de #1 Tue May 25 > > > > 00:43:15 EDT 1999 i486 unknown > > > > Credits > > > > * Docs: Sarah Griswold > > > > * Testing: Matt Neiman > > > > * Coding: > > > > * Chris Anderson > > > > * Curt Finch > > > > * John Maddalozzo > > > > * Andrew Reutter > > > > * Design and enhancement ideas: literally thousands of registered > > > > users just like you. <http://journyx.com/featureq.html> > > > > > > > > > > > > > > > > ----------------------------------------------- > > > > Andreas Stappert > > > > Key-Work Consulting GmbH > > > > > > > > Haid-und-Neu-Strasse 7 - 76131 Karlsruhe - Germany > > > > +49 721 664936-0 - mailto:andreas.stappert@key-work.de > > > > > > > > > > > > > > > ==================================================================== Audit trail: Mon Oct 18 17:53:07 1999 guido changed notes Mon Oct 18 17:53:07 1999 guido changed notification Mon Oct 18 17:53:08 1999 guido moved from incoming to open Tue Oct 19 00:42:35 1999 guido changed notes Tue Oct 19 00:42:37 1999 guido moved from open to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T04:26:00Z Jitterbug-Id: 109 Submitted-By: Curt Finch <curt@journyx.com> Date: Thu, 14 Oct 1999 14:58:08 -0500 (CDT) Version: None OS: None anyone heard of any python time bugs? __________________________________________________________________ Web-Based Project Management, Journyx TimeSheet and Tracking Software FREE (800)755-9878 FREE at http://journyx.com/wts.html curt@www.JOURNYX.com ------------------------------------------------------------------ ---------- Forwarded message ---------- Date: Thu, 14 Oct 1999 14:09:35 -0500 (CDT) From: John Maddalozzo <john@journyx.com> To: "Stappert, Andreas" <andreas.stappert@key-work.de> Cc: support@journyx.com Subject: Re: Date problem unresolved [DIN 2646] Andreas, I'm stumped. It seems there is a problem in the python time library. I may have to post a message to a python news group if code inspection doesn't turn anything up. 2646 is the problem report number. We'll dig around and see what we can find out. Meanwhile, you might want to send me the output of the uname -a command and any other information you have that might help. (Linux level, etc) Regards, John __________________________________________________________________ Web-Based Project Management and TimeSheet Software JournyxTime FREE at http://journyx.com/wts.html John Maddalozzo - john@JOURNYX.com (512)834-8888 / (800)755-9878 ------------------------------------------------------------------ On Thu, 14 Oct 1999, Stappert, Andreas wrote: > Hi John, > > Well, for some reason I always have the strangest thing happen to me :-) > even though I try to conform to every standards I know of... > > Here is what I get. Looks like it matches your machine (our server date is > set a day off). Do you think it would help if we change the timezone to EST > or something? > > > date +%s > 939838233 > timesheet:~> > > The hardware is an (old) 486 (yes I know old ... that is just our > testserver, once we are putting Journyx to real use, we are going to put a > nicer machine underneath it). I don't know the mainboard type by heart. > > Oh, I should probably also tell you this: At the beginning, the time was > right but once we got some modifications done and rebootet the machine, it > started acting this strange. > > Regards, > Andreas > > -----Ursprungliche Nachricht----- > Von: John Maddalozzo [mailto:john@journyx.com] > Gesendet: Donnerstag, 14. Oktober 1999 20:05 > An: Stappert, Andreas > Betreff: Re: AW: AW: Date problem unresolved > > > > Very strange, Andreas. > the time.time() result shows the number of seconds since the "epoch" > (see http://python.org/doc/current/lib/module-time.html) > Your number of seconds should be somewhere between > 939916983.851 (the time on my computer when I wrote example note below) > and > 939923915.897 (the time on my computer I just now checked) > > What does the command > date +%s > say? > What hardware are you using? > > __________________________________________________________________ > Web-Based Project Management and TimeSheet Software JournyxTime > FREE at http://journyx.com/wts.html > John Maddalozzo - john@JOURNYX.com (512)834-8888 / (800)755-9878 > ------------------------------------------------------------------ > > On Thu, 14 Oct 1999, Stappert, Andreas wrote: > > > Here you go (my mistake): > > > > timesheet:~/jtime/jtime/pi/bin> python > > Python 1.5.2 (#1, Sep 27 1999, 17:01:09) [GCC egcs-2.91.66 19990314/Linux > > (egcs > > - on linux2 > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > >>> import time > > >>> import wtdate > > >>> wtdate.today() > > Thu 13 Jul 1995 > > >>> time.localtime(time.time()) > > (1995, 7, 13, 8, 38, 9, 3, 194, 1) > > >>> time.time() > > 805617494.587 > > >>> time.gmtime(time.time()) > > (1995, 7, 13, 6, 38, 54, 3, 194, 0) > > >>> time.gzname > > Traceback (innermost last): > > File "<stdin>", line 1, in ? > > AttributeError: gzname > > >>> time.timezone > > -3600 > > >>> time.tzname > > ('CET', 'CEST') > > >>> > > > > -----Ursprungliche Nachricht----- > > Von: John Maddalozzo [mailto:john@journyx.com] > > Gesendet: Donnerstag, 14. Oktober 1999 19:09 > > An: Stappert, Andreas > > Betreff: Re: AW: Date problem unresolved > > > > > > > > Hi Andreas, > > Did you remember to source setup? > > In pi/bin at the shell prompt do: > > . ./setup > > You need to do that first. To check that it has been sourced, do > > echo $PYTHONPATH > > that should return something like this: > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 753>. ./setup > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 754>echo $PYTHONPATH > > > //home/john_scratch/jtime/jtime/pi/apache/wtlib://home/john_scratch/jtime/jt > > > ime/pd/Linux/python/lib/python1.5/://home/john_scratch/jtime/jtime/pi/apache > > /serverroot/cgi-bin > > > > Then it should be able to find wtdate.pyc in pi/apache/wtlib > > > > Regards, John > > > > On Thu, 14 Oct 1999, Stappert, Andreas wrote: > > > > > Hi John, > > > > > > I already get stuck when I try to import wtdate: > > > > > > python > > > Python 1.5.1 (#1, Mar 21 1999, 22:49:36) [GCC egcs-2.91.66 19990314/Li > on > > > linux > > > -i386 > > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > > >>> import time > > > >>> import wtdate > > > Traceback (innermost last): > > > File "<stdin>", line 1, in ? > > > ImportError: No module named wtdate > > > > > > -----Ursprungliche Nachricht----- > > > Von: John Maddalozzo [mailto:john@journyx.com] > > > Gesendet: Donnerstag, 14. Oktober 1999 18:05 > > > An: Stappert, Andreas > > > Cc: support@journyx.com > > > Betreff: Re: Date problem unresolved > > > > > > > > > > > > Andreas, > > > This must be some problem with resolving the time zone. > > > Please do the following and send me the output. > > > > > > What this is doing is invoking python and using its libraries to get > > dates. > > > I'm hoping that this will give us some idea of what is wrong. > > > Regards, John > > > > > > cd <jtime install dir>/jtime/pi/bin > > > . ./setup > > > python > > > import time > > > import wtdate > > > wtdate.today() > > > time.localtime(time.time()) > > > time.time() > > > time.gmtime(time.time()) > > > time.gzname > > > time.timezone > > > > > > For example when I do it here I get... > > > > > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 743>python > > > Python 1.5.2 (#1, Oct 2 1999, 23:28:23) [GCC egcs-2.91.66 > 19990314/Linux > > > (egcs- on linux2 > > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > > >>> import time > > > >>> import wtdate > > > >>> wtdate.today() > > > Thu 14 Oct 1999 > > > >>> time.localtime(time.time()) > > > (1999, 10, 14, 11, 2, 51, 3, 287, 1) > > > >>> time.time() > > > 939916983.851 > > > >>> time.gmtime(time.time()) > > > (1999, 10, 14, 16, 7, 10, 3, 287, 0) > > > >>> time.tzname > > > ('CST', 'CDT') > > > >>> time.timezone > > > 21600 > > > > > > > > > > > > __________________________________________________________________ > > > Web-Based Project Management and TimeSheet Software JournyxTime > > > FREE at http://journyx.com/wts.html > > > John Maddalozzo - john@JOURNYX.com (512)834-8888 / (800)755-9878 > > > ------------------------------------------------------------------ > > > > > > On Thu, 14 Oct 1999, Stappert, Andreas wrote: > > > > > > > Hello there, > > > > We are still having a major problem with the Journyx installation on > our > > > > Linux server: > > > > The current date on the Linux machine is > > > > Mit Okt 13 10:35:14 CEST 1999 > > > > but Journyx uses the below July 12, 1995 as current date. Is there any > > way > > > > to correct this problem? > > > > We would like to go and find some more customers for Journyx but if we > > can > > > > not figure out how to correct this problem, we will not be able to > > > > demonstrate it. > > > > Thanks for your immediate attention > > > > Andreas > > > > > > > > License Key Data > > > > * Dates > > > > * Install Date: Mon Okt 4 17:36:04 CEST 1999 > > > > * Product Expiration Date: Never > > > > * Current Date: Wed 12 Jul 1995 > > > > * Users > > > > * Licensed Number of Users: 10 > > > > * Current Number of User Data Unavailable > > > > * Hosts > > > > * Licensed Host: 192 > > > > * Current Host: 192 > > > > Operating System Information > > > > * Current: Linux 192.168.0.100 2.2.5-15de #1 Tue May 25 00:43:15 EDT > > > > 1999 i486 > > > > * Original: Linux karsrv01.key-work.de 2.2.5-15de #1 Tue May 25 > > > > 00:43:15 EDT 1999 i486 unknown > > > > Credits > > > > * Docs: Sarah Griswold > > > > * Testing: Matt Neiman > > > > * Coding: > > > > * Chris Anderson > > > > * Curt Finch > > > > * John Maddalozzo > > > > * Andrew Reutter > > > > * Design and enhancement ideas: literally thousands of registered > > > > users just like you. <http://journyx.com/featureq.html> > > > > > > > > > > > > > > > > ----------------------------------------------- > > > > Andreas Stappert > > > > Key-Work Consulting GmbH > > > > > > > > Haid-und-Neu-Strasse 7 - 76131 Karlsruhe - Germany > > > > +49 721 664936-0 - mailto:andreas.stappert@key-work.de > > > > > > > > > > > > > > > ==================================================================== Audit trail: Mon Oct 18 17:53:07 1999 guido changed notes Mon Oct 18 17:53:07 1999 guido changed notification Mon Oct 18 17:53:08 1999 guido moved from incoming to open Tue Oct 19 00:42:35 1999 guido changed notes Tue Oct 19 00:42:37 1999 guido moved from open to irreproducible Jeremy Hylton 2000-08-01T21:34:00Z test bug from Jitterbug -> SF conversion 2000-08-01T04:27:00Z sf210743 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T04:27:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:28:00Z test bug from Jitterbug -> SF conversion 2000-08-01T04:27:00Z sf210744 Jitterbug-Id: 109 Submitted-By: Curt Finch <curt@journyx.com> Date: Thu, 14 Oct 1999 14:58:08 -0500 (CDT) Version: None OS: None anyone heard of any python time bugs? __________________________________________________________________ Web-Based Project Management, Journyx TimeSheet and Tracking Software FREE (800)755-9878 FREE at http://journyx.com/wts.html curt@www.JOURNYX.com ------------------------------------------------------------------ ---------- Forwarded message ---------- Date: Thu, 14 Oct 1999 14:09:35 -0500 (CDT) From: John Maddalozzo <john@journyx.com> To: "Stappert, Andreas" <andreas.stappert@key-work.de> Cc: support@journyx.com Subject: Re: Date problem unresolved [DIN 2646] Andreas, I'm stumped. It seems there is a problem in the python time library. I may have to post a message to a python news group if code inspection doesn't turn anything up. 2646 is the problem report number. We'll dig around and see what we can find out. Meanwhile, you might want to send me the output of the uname -a command and any other information you have that might help. (Linux level, etc) Regards, John __________________________________________________________________ Web-Based Project Management and TimeSheet Software JournyxTime FREE at http://journyx.com/wts.html John Maddalozzo - john@JOURNYX.com (512)834-8888 / (800)755-9878 ------------------------------------------------------------------ On Thu, 14 Oct 1999, Stappert, Andreas wrote: > Hi John, > > Well, for some reason I always have the strangest thing happen to me :-) > even though I try to conform to every standards I know of... > > Here is what I get. Looks like it matches your machine (our server date is > set a day off). Do you think it would help if we change the timezone to EST > or something? > > > date +%s > 939838233 > timesheet:~> > > The hardware is an (old) 486 (yes I know old ... that is just our > testserver, once we are putting Journyx to real use, we are going to put a > nicer machine underneath it). I don't know the mainboard type by heart. > > Oh, I should probably also tell you this: At the beginning, the time was > right but once we got some modifications done and rebootet the machine, it > started acting this strange. > > Regards, > Andreas > > -----Ursprungliche Nachricht----- > Von: John Maddalozzo [mailto:john@journyx.com] > Gesendet: Donnerstag, 14. Oktober 1999 20:05 > An: Stappert, Andreas > Betreff: Re: AW: AW: Date problem unresolved > > > > Very strange, Andreas. > the time.time() result shows the number of seconds since the "epoch" > (see http://python.org/doc/current/lib/module-time.html) > Your number of seconds should be somewhere between > 939916983.851 (the time on my computer when I wrote example note below) > and > 939923915.897 (the time on my computer I just now checked) > > What does the command > date +%s > say? > What hardware are you using? > > __________________________________________________________________ > Web-Based Project Management and TimeSheet Software JournyxTime > FREE at http://journyx.com/wts.html > John Maddalozzo - john@JOURNYX.com (512)834-8888 / (800)755-9878 > ------------------------------------------------------------------ > > On Thu, 14 Oct 1999, Stappert, Andreas wrote: > > > Here you go (my mistake): > > > > timesheet:~/jtime/jtime/pi/bin> python > > Python 1.5.2 (#1, Sep 27 1999, 17:01:09) [GCC egcs-2.91.66 19990314/Linux > > (egcs > > - on linux2 > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > >>> import time > > >>> import wtdate > > >>> wtdate.today() > > Thu 13 Jul 1995 > > >>> time.localtime(time.time()) > > (1995, 7, 13, 8, 38, 9, 3, 194, 1) > > >>> time.time() > > 805617494.587 > > >>> time.gmtime(time.time()) > > (1995, 7, 13, 6, 38, 54, 3, 194, 0) > > >>> time.gzname > > Traceback (innermost last): > > File "<stdin>", line 1, in ? > > AttributeError: gzname > > >>> time.timezone > > -3600 > > >>> time.tzname > > ('CET', 'CEST') > > >>> > > > > -----Ursprungliche Nachricht----- > > Von: John Maddalozzo [mailto:john@journyx.com] > > Gesendet: Donnerstag, 14. Oktober 1999 19:09 > > An: Stappert, Andreas > > Betreff: Re: AW: Date problem unresolved > > > > > > > > Hi Andreas, > > Did you remember to source setup? > > In pi/bin at the shell prompt do: > > . ./setup > > You need to do that first. To check that it has been sourced, do > > echo $PYTHONPATH > > that should return something like this: > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 753>. ./setup > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 754>echo $PYTHONPATH > > > //home/john_scratch/jtime/jtime/pi/apache/wtlib://home/john_scratch/jtime/jt > > > ime/pd/Linux/python/lib/python1.5/://home/john_scratch/jtime/jtime/pi/apache > > /serverroot/cgi-bin > > > > Then it should be able to find wtdate.pyc in pi/apache/wtlib > > > > Regards, John > > > > On Thu, 14 Oct 1999, Stappert, Andreas wrote: > > > > > Hi John, > > > > > > I already get stuck when I try to import wtdate: > > > > > > python > > > Python 1.5.1 (#1, Mar 21 1999, 22:49:36) [GCC egcs-2.91.66 19990314/Li > on > > > linux > > > -i386 > > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > > >>> import time > > > >>> import wtdate > > > Traceback (innermost last): > > > File "<stdin>", line 1, in ? > > > ImportError: No module named wtdate > > > > > > -----Ursprungliche Nachricht----- > > > Von: John Maddalozzo [mailto:john@journyx.com] > > > Gesendet: Donnerstag, 14. Oktober 1999 18:05 > > > An: Stappert, Andreas > > > Cc: support@journyx.com > > > Betreff: Re: Date problem unresolved > > > > > > > > > > > > Andreas, > > > This must be some problem with resolving the time zone. > > > Please do the following and send me the output. > > > > > > What this is doing is invoking python and using its libraries to get > > dates. > > > I'm hoping that this will give us some idea of what is wrong. > > > Regards, John > > > > > > cd <jtime install dir>/jtime/pi/bin > > > . ./setup > > > python > > > import time > > > import wtdate > > > wtdate.today() > > > time.localtime(time.time()) > > > time.time() > > > time.gmtime(time.time()) > > > time.gzname > > > time.timezone > > > > > > For example when I do it here I get... > > > > > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 743>python > > > Python 1.5.2 (#1, Oct 2 1999, 23:28:23) [GCC egcs-2.91.66 > 19990314/Linux > > > (egcs- on linux2 > > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > > >>> import time > > > >>> import wtdate > > > >>> wtdate.today() > > > Thu 14 Oct 1999 > > > >>> time.localtime(time.time()) > > > (1999, 10, 14, 11, 2, 51, 3, 287, 1) > > > >>> time.time() > > > 939916983.851 > > > >>> time.gmtime(time.time()) > > > (1999, 10, 14, 16, 7, 10, 3, 287, 0) > > > >>> time.tzname > > > ('CST', 'CDT') > > > >>> time.timezone > > > 21600 > > > > > > > > > > > > __________________________________________________________________ > > > Web-Based Project Management and TimeSheet Software JournyxTime > > > FREE at http://journyx.com/wts.html > > > John Maddalozzo - john@JOURNYX.com (512)834-8888 / (800)755-9878 > > > ------------------------------------------------------------------ > > > > > > On Thu, 14 Oct 1999, Stappert, Andreas wrote: > > > > > > > Hello there, > > > > We are still having a major problem with the Journyx installation on > our > > > > Linux server: > > > > The current date on the Linux machine is > > > > Mit Okt 13 10:35:14 CEST 1999 > > > > but Journyx uses the below July 12, 1995 as current date. Is there any > > way > > > > to correct this problem? > > > > We would like to go and find some more customers for Journyx but if we > > can > > > > not figure out how to correct this problem, we will not be able to > > > > demonstrate it. > > > > Thanks for your immediate attention > > > > Andreas > > > > > > > > License Key Data > > > > * Dates > > > > * Install Date: Mon Okt 4 17:36:04 CEST 1999 > > > > * Product Expiration Date: Never > > > > * Current Date: Wed 12 Jul 1995 > > > > * Users > > > > * Licensed Number of Users: 10 > > > > * Current Number of User Data Unavailable > > > > * Hosts > > > > * Licensed Host: 192 > > > > * Current Host: 192 > > > > Operating System Information > > > > * Current: Linux 192.168.0.100 2.2.5-15de #1 Tue May 25 00:43:15 EDT > > > > 1999 i486 > > > > * Original: Linux karsrv01.key-work.de 2.2.5-15de #1 Tue May 25 > > > > 00:43:15 EDT 1999 i486 unknown > > > > Credits > > > > * Docs: Sarah Griswold > > > > * Testing: Matt Neiman > > > > * Coding: > > > > * Chris Anderson > > > > * Curt Finch > > > > * John Maddalozzo > > > > * Andrew Reutter > > > > * Design and enhancement ideas: literally thousands of registered > > > > users just like you. <http://journyx.com/featureq.html> > > > > > > > > > > > > > > > > ----------------------------------------------- > > > > Andreas Stappert > > > > Key-Work Consulting GmbH > > > > > > > > Haid-und-Neu-Strasse 7 - 76131 Karlsruhe - Germany > > > > +49 721 664936-0 - mailto:andreas.stappert@key-work.de > > > > > > > > > > > > > > > ==================================================================== Audit trail: Mon Oct 18 17:53:07 1999 guido changed notes Mon Oct 18 17:53:07 1999 guido changed notification Mon Oct 18 17:53:08 1999 guido moved from incoming to open Tue Oct 19 00:42:35 1999 guido changed notes Tue Oct 19 00:42:37 1999 guido moved from open to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T04:27:00Z Jitterbug-Id: 109 Submitted-By: Curt Finch <curt@journyx.com> Date: Thu, 14 Oct 1999 14:58:08 -0500 (CDT) Version: None OS: None anyone heard of any python time bugs? __________________________________________________________________ Web-Based Project Management, Journyx TimeSheet and Tracking Software FREE (800)755-9878 FREE at http://journyx.com/wts.html curt@www.JOURNYX.com ------------------------------------------------------------------ ---------- Forwarded message ---------- Date: Thu, 14 Oct 1999 14:09:35 -0500 (CDT) From: John Maddalozzo <john@journyx.com> To: "Stappert, Andreas" <andreas.stappert@key-work.de> Cc: support@journyx.com Subject: Re: Date problem unresolved [DIN 2646] Andreas, I'm stumped. It seems there is a problem in the python time library. I may have to post a message to a python news group if code inspection doesn't turn anything up. 2646 is the problem report number. We'll dig around and see what we can find out. Meanwhile, you might want to send me the output of the uname -a command and any other information you have that might help. (Linux level, etc) Regards, John __________________________________________________________________ Web-Based Project Management and TimeSheet Software JournyxTime FREE at http://journyx.com/wts.html John Maddalozzo - john@JOURNYX.com (512)834-8888 / (800)755-9878 ------------------------------------------------------------------ On Thu, 14 Oct 1999, Stappert, Andreas wrote: > Hi John, > > Well, for some reason I always have the strangest thing happen to me :-) > even though I try to conform to every standards I know of... > > Here is what I get. Looks like it matches your machine (our server date is > set a day off). Do you think it would help if we change the timezone to EST > or something? > > > date +%s > 939838233 > timesheet:~> > > The hardware is an (old) 486 (yes I know old ... that is just our > testserver, once we are putting Journyx to real use, we are going to put a > nicer machine underneath it). I don't know the mainboard type by heart. > > Oh, I should probably also tell you this: At the beginning, the time was > right but once we got some modifications done and rebootet the machine, it > started acting this strange. > > Regards, > Andreas > > -----Ursprungliche Nachricht----- > Von: John Maddalozzo [mailto:john@journyx.com] > Gesendet: Donnerstag, 14. Oktober 1999 20:05 > An: Stappert, Andreas > Betreff: Re: AW: AW: Date problem unresolved > > > > Very strange, Andreas. > the time.time() result shows the number of seconds since the "epoch" > (see http://python.org/doc/current/lib/module-time.html) > Your number of seconds should be somewhere between > 939916983.851 (the time on my computer when I wrote example note below) > and > 939923915.897 (the time on my computer I just now checked) > > What does the command > date +%s > say? > What hardware are you using? > > __________________________________________________________________ > Web-Based Project Management and TimeSheet Software JournyxTime > FREE at http://journyx.com/wts.html > John Maddalozzo - john@JOURNYX.com (512)834-8888 / (800)755-9878 > ------------------------------------------------------------------ > > On Thu, 14 Oct 1999, Stappert, Andreas wrote: > > > Here you go (my mistake): > > > > timesheet:~/jtime/jtime/pi/bin> python > > Python 1.5.2 (#1, Sep 27 1999, 17:01:09) [GCC egcs-2.91.66 19990314/Linux > > (egcs > > - on linux2 > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > >>> import time > > >>> import wtdate > > >>> wtdate.today() > > Thu 13 Jul 1995 > > >>> time.localtime(time.time()) > > (1995, 7, 13, 8, 38, 9, 3, 194, 1) > > >>> time.time() > > 805617494.587 > > >>> time.gmtime(time.time()) > > (1995, 7, 13, 6, 38, 54, 3, 194, 0) > > >>> time.gzname > > Traceback (innermost last): > > File "<stdin>", line 1, in ? > > AttributeError: gzname > > >>> time.timezone > > -3600 > > >>> time.tzname > > ('CET', 'CEST') > > >>> > > > > -----Ursprungliche Nachricht----- > > Von: John Maddalozzo [mailto:john@journyx.com] > > Gesendet: Donnerstag, 14. Oktober 1999 19:09 > > An: Stappert, Andreas > > Betreff: Re: AW: Date problem unresolved > > > > > > > > Hi Andreas, > > Did you remember to source setup? > > In pi/bin at the shell prompt do: > > . ./setup > > You need to do that first. To check that it has been sourced, do > > echo $PYTHONPATH > > that should return something like this: > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 753>. ./setup > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 754>echo $PYTHONPATH > > > //home/john_scratch/jtime/jtime/pi/apache/wtlib://home/john_scratch/jtime/jt > > > ime/pd/Linux/python/lib/python1.5/://home/john_scratch/jtime/jtime/pi/apache > > /serverroot/cgi-bin > > > > Then it should be able to find wtdate.pyc in pi/apache/wtlib > > > > Regards, John > > > > On Thu, 14 Oct 1999, Stappert, Andreas wrote: > > > > > Hi John, > > > > > > I already get stuck when I try to import wtdate: > > > > > > python > > > Python 1.5.1 (#1, Mar 21 1999, 22:49:36) [GCC egcs-2.91.66 19990314/Li > on > > > linux > > > -i386 > > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > > >>> import time > > > >>> import wtdate > > > Traceback (innermost last): > > > File "<stdin>", line 1, in ? > > > ImportError: No module named wtdate > > > > > > -----Ursprungliche Nachricht----- > > > Von: John Maddalozzo [mailto:john@journyx.com] > > > Gesendet: Donnerstag, 14. Oktober 1999 18:05 > > > An: Stappert, Andreas > > > Cc: support@journyx.com > > > Betreff: Re: Date problem unresolved > > > > > > > > > > > > Andreas, > > > This must be some problem with resolving the time zone. > > > Please do the following and send me the output. > > > > > > What this is doing is invoking python and using its libraries to get > > dates. > > > I'm hoping that this will give us some idea of what is wrong. > > > Regards, John > > > > > > cd <jtime install dir>/jtime/pi/bin > > > . ./setup > > > python > > > import time > > > import wtdate > > > wtdate.today() > > > time.localtime(time.time()) > > > time.time() > > > time.gmtime(time.time()) > > > time.gzname > > > time.timezone > > > > > > For example when I do it here I get... > > > > > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 743>python > > > Python 1.5.2 (#1, Oct 2 1999, 23:28:23) [GCC egcs-2.91.66 > 19990314/Linux > > > (egcs- on linux2 > > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > > >>> import time > > > >>> import wtdate > > > >>> wtdate.today() > > > Thu 14 Oct 1999 > > > >>> time.localtime(time.time()) > > > (1999, 10, 14, 11, 2, 51, 3, 287, 1) > > > >>> time.time() > > > 939916983.851 > > > >>> time.gmtime(time.time()) > > > (1999, 10, 14, 16, 7, 10, 3, 287, 0) > > > >>> time.tzname > > > ('CST', 'CDT') > > > >>> time.timezone > > > 21600 > > > > > > > > > > > > __________________________________________________________________ > > > Web-Based Project Management and TimeSheet Software JournyxTime > > > FREE at http://journyx.com/wts.html > > > John Maddalozzo - john@JOURNYX.com (512)834-8888 / (800)755-9878 > > > ------------------------------------------------------------------ > > > > > > On Thu, 14 Oct 1999, Stappert, Andreas wrote: > > > > > > > Hello there, > > > > We are still having a major problem with the Journyx installation on > our > > > > Linux server: > > > > The current date on the Linux machine is > > > > Mit Okt 13 10:35:14 CEST 1999 > > > > but Journyx uses the below July 12, 1995 as current date. Is there any > > way > > > > to correct this problem? > > > > We would like to go and find some more customers for Journyx but if we > > can > > > > not figure out how to correct this problem, we will not be able to > > > > demonstrate it. > > > > Thanks for your immediate attention > > > > Andreas > > > > > > > > License Key Data > > > > * Dates > > > > * Install Date: Mon Okt 4 17:36:04 CEST 1999 > > > > * Product Expiration Date: Never > > > > * Current Date: Wed 12 Jul 1995 > > > > * Users > > > > * Licensed Number of Users: 10 > > > > * Current Number of User Data Unavailable > > > > * Hosts > > > > * Licensed Host: 192 > > > > * Current Host: 192 > > > > Operating System Information > > > > * Current: Linux 192.168.0.100 2.2.5-15de #1 Tue May 25 00:43:15 EDT > > > > 1999 i486 > > > > * Original: Linux karsrv01.key-work.de 2.2.5-15de #1 Tue May 25 > > > > 00:43:15 EDT 1999 i486 unknown > > > > Credits > > > > * Docs: Sarah Griswold > > > > * Testing: Matt Neiman > > > > * Coding: > > > > * Chris Anderson > > > > * Curt Finch > > > > * John Maddalozzo > > > > * Andrew Reutter > > > > * Design and enhancement ideas: literally thousands of registered > > > > users just like you. <http://journyx.com/featureq.html> > > > > > > > > > > > > > > > > ----------------------------------------------- > > > > Andreas Stappert > > > > Key-Work Consulting GmbH > > > > > > > > Haid-und-Neu-Strasse 7 - 76131 Karlsruhe - Germany > > > > +49 721 664936-0 - mailto:andreas.stappert@key-work.de > > > > > > > > > > > > > > > ==================================================================== Audit trail: Mon Oct 18 17:53:07 1999 guido changed notes Mon Oct 18 17:53:07 1999 guido changed notification Mon Oct 18 17:53:08 1999 guido moved from incoming to open Tue Oct 19 00:42:35 1999 guido changed notes Tue Oct 19 00:42:37 1999 guido moved from open to irreproducible Bug Importer 2000-08-01T21:04:00Z Can't reproduce this here. Your best bet is to look into the conversion of the time() value to floating point -- maybe you are using a bogus floating point emulation? BTW, forwarding such a long thread of email without a clear summary of the problem at the top makes it hard for me to read the bug report. Jeremy Hylton 2000-08-01T21:34:00Z test bug from Jitterbug -> SF conversion 2000-08-01T04:29:00Z sf210745 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T04:29:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:28:00Z test bug from Jitterbug -> SF conversion 2000-08-01T04:30:00Z sf210746 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T04:30:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:29:00Z test bug from Jitterbug -> SF conversion 2000-08-01T04:46:00Z sf210747 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T04:46:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:29:00Z test bug from Jitterbug -> SF conversion 2000-08-01T04:47:00Z sf210748 this is a test Jeremy Hylton FIXRELEASED MEDIUM not-a-bug Jeremy Hylton Jeremy Hylton 2000-08-01T04:47:00Z this is a test Jeremy Hylton 2000-08-01T21:35:00Z test bug from Jitterbug -> SF conversion 2000-08-01T04:48:00Z sf210749 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T04:48:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:29:00Z test bug from Jitterbug -> SF conversion 2000-08-01T04:50:00Z sf210750 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T04:50:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:29:00Z test bug from Jitterbug -> SF conversion 2000-08-01T16:01:00Z sf210778 pyport.h contains the following line, previously from myselect.h #define NFDBITS (sizeof(fd_mask) * NBBY) /* bits per mask */ On windows, NBBY is not defined (Im not sure who is supposed to define it). myselect.h was never included on windows, so this had never previously been a problem Htrd FIXRELEASED HIGH Tim Peters build Htrd Htrd 2000-08-01T16:01:00Z pyport.h contains the following line, previously from myselect.h #define NFDBITS (sizeof(fd_mask) * NBBY) /* bits per mask */ On windows, NBBY is not defined (Im not sure who is supposed to define it). myselect.h was never included on windows, so this had never previously been a problem Htrd 2000-08-02T09:32:00Z This is fixed in CVS revision 2.10 Tim Peters 2000-08-30T03:31:00Z Like the man said, this was fixed a long time ago. Closed it. 2000-08-01T19:16:00Z sf210791 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T19:16:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:29:00Z test bug from Jitterbug -> SF conversion 2000-08-01T19:17:00Z sf210792 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T19:17:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:30:00Z test bug from Jitterbug -> SF conversion 2000-08-01T19:17:00Z sf210793 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T19:17:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:30:00Z test bug from Jitterbug -> SF conversion 2000-08-01T19:18:00Z sf210794 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T19:18:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:31:00Z test bug from Jitterbug -> SF conversion 2000-08-01T19:18:00Z sf210795 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T19:18:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:31:00Z test bug from Jitterbug -> SF conversion 2000-08-01T19:18:00Z sf210796 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T19:18:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:32:00Z test bug from Jitterbug -> SF conversion 2000-08-01T19:19:00Z sf210797 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T19:19:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:32:00Z test bug from Jitterbug -> SF conversion 2000-08-01T19:19:00Z sf210798 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T19:19:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:32:00Z test bug from Jitterbug -> SF conversion 2000-08-01T19:19:00Z sf210799 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T19:19:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:32:00Z test bug from Jitterbug -> SF conversion 2000-08-01T19:22:00Z sf210801 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T19:22:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:32:00Z test bug from Jitterbug -> SF conversion 2000-08-01T19:22:00Z sf210802 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T19:22:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:32:00Z test bug from Jitterbug -> SF conversion 2000-08-01T19:56:00Z sf210804 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T19:56:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:33:00Z test bug from Jitterbug -> SF conversion 2000-08-01T19:58:00Z sf210805 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T19:58:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:33:00Z test bug from Jitterbug -> SF conversion 2000-08-01T19:58:00Z sf210806 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T19:58:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:33:00Z test bug from Jitterbug -> SF conversion 2000-08-01T20:28:00Z sf210809 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T20:28:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:33:00Z test bug from Jitterbug -> SF conversion 2000-08-01T20:29:00Z sf210810 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T20:29:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:34:00Z test bug from Jitterbug -> SF conversion 2000-08-01T20:29:00Z sf210811 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T20:29:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Jeremy Hylton 2000-08-01T21:35:00Z test bug from Jitterbug -> SF conversion 2000-08-01T20:31:00Z sf210812 Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer FIXRELEASED MEDIUM irreproducible Bug Importer Bug Importer 2000-08-01T20:31:00Z Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. The functions work ok with kernel 1.2.13 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Bug Importer 2000-08-01T20:31:00Z Probably caused by a huge jump in Linux kernel version without recompiling Python. Bug Importer 2000-08-01T20:31:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] Segmentation fault with kernel 2.2.12 (PR#103) Date: Mon, 11 Oct 1999 23:09:13 -0400 > Full_Name: Alfred Steffens Jr. > Version: 1.5.2 > OS: Linux > Submission from: p138.netwood.net (209.247.185.38) > > I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to > execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. > The functions work ok with kernel 1.2.13 . The Linux and glibc kernel versions don't mean much to me. Can you fire up a debugger and see where in the C code it crashes? Also, is this for a specific URL or is it for any URL? If a specific URL, I'd like to know which one. Finally, did you get or build the Python executable matching your kernel? A Linux upgrade from 1.x to 2.x seems a big deal, it's possible that you'll need a new Python installation or build. --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-08-01T21:04:00Z Probably caused by a huge jump in Linux kernel version without recompiling Python. Bug Importer 2000-08-01T21:04:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] Segmentation fault with kernel 2.2.12 (PR#103) Date: Mon, 11 Oct 1999 23:09:13 -0400 > Full_Name: Alfred Steffens Jr. > Version: 1.5.2 > OS: Linux > Submission from: p138.netwood.net (209.247.185.38) > > I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 . When I try to > execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault. > The functions work ok with kernel 1.2.13 . The Linux and glibc kernel versions don't mean much to me. Can you fire up a debugger and see where in the C code it crashes? Also, is this for a specific URL or is it for any URL? If a specific URL, I'd like to know which one. Finally, did you get or build the Python executable matching your kernel? A Linux upgrade from 1.x to 2.x seems a big deal, it's possible that you'll need a new Python installation or build. --Guido van Rossum (home page: http://www.python.org/~guido/) Jeremy Hylton 2000-08-01T21:35:00Z test bug from Jitterbug -> SF conversion 2000-08-01T21:08:00Z sf210818 Jitterbug-Id: 1 Submitted-By: guido@python.org Date: Mon, 3 May 1999 17:31:27 -0400 (EDT) Version: any OS: any Subject says it all. Not everything is tested. ==================================================================== Audit trail: Mon May 03 18:01:53 1999 guido sent reply 1 Mon Jul 12 15:33:07 1999 guido moved from incoming to request Mon Jul 12 19:09:04 1999 guido changed notes Bug Importer FIXRELEASED MEDIUM feature-request Bug Importer Bug Importer 2000-08-01T21:08:00Z Jitterbug-Id: 1 Submitted-By: guido@python.org Date: Mon, 3 May 1999 17:31:27 -0400 (EDT) Version: any OS: any Subject says it all. Not everything is tested. ==================================================================== Audit trail: Mon May 03 18:01:53 1999 guido sent reply 1 Mon Jul 12 15:33:07 1999 guido moved from incoming to request Mon Jul 12 19:09:04 1999 guido changed notes Jeremy Hylton 2000-08-01T21:36:00Z test bug from Jitterbug -> SF conversion 2000-08-01T21:09:00Z sf210819 Jitterbug-Id: 1 Submitted-By: guido@python.org Date: Mon, 3 May 1999 17:31:27 -0400 (EDT) Version: any OS: any Subject says it all. Not everything is tested. ==================================================================== Audit trail: Mon May 03 18:01:53 1999 guido sent reply 1 Mon Jul 12 15:33:07 1999 guido moved from incoming to request Mon Jul 12 19:09:04 1999 guido changed notes Bug Importer REJECTED LOW feature-request Skip Montanaro Bug Importer Bug Importer 2000-08-01T21:09:00Z Jitterbug-Id: 1 Submitted-By: guido@python.org Date: Mon, 3 May 1999 17:31:27 -0400 (EDT) Version: any OS: any Subject says it all. Not everything is tested. ==================================================================== Audit trail: Mon May 03 18:01:53 1999 guido sent reply 1 Mon Jul 12 15:33:07 1999 guido moved from incoming to request Mon Jul 12 19:09:04 1999 guido changed notes Bug Importer 2000-08-01T21:10:00Z Of course, it's not likely that this will ever by completely resolved... :-) Bug Importer 2000-08-01T21:10:00Z From: Guido van Rossum <bugs-py@python.org> Subject: Re: test suite incomplete (PR#1) Date: Mon May 3 18:01:53 1999 I know, I know... Jeremy Hylton 2000-08-02T00:45:00Z Thought you'd like to have this one assigned to you, Skip <wink>. Skip Montanaro 2000-08-05T13:03:00Z as if i didn't have enough to do... ;-) maybe this is a good excuse to look at pyUnit. More tests might get written with a more easily used testing framework. Skip Montanaro 2000-09-15T21:14:00Z added this to pep-0042 2000-08-01T21:10:00Z sf210820 Jitterbug-Id: 116 Submitted-By: Guido van Rossum <guido@CNRI.Reston.VA.US> Date: Mon, 25 Oct 1999 10:38:58 -0400 Version: None OS: None A worthy to-do item. ------- Forwarded Message Date: Sat, 23 Oct 1999 08:24:32 -0000 From: Jonathan Craft <jcchina@bigfoot.com> To: guido@python.org Subject: Possible to-do addition Hi Guido, Is there a visual interface builder (as in VBasic, Hypercard, Icon) for Tkinter? I haven't been able to find any information on it (I'm new to Python). If not, that would be a good to-do. Jonathan Craft mailto:jcchina@bigfoot.com ------- End of Forwarded Message ==================================================================== Audit trail: Mon Oct 25 15:13:11 1999 guido moved from incoming to request Bug Importer FIXRELEASED MEDIUM feature-request barry tkinter Bug Importer Bug Importer 2000-08-01T21:10:00Z Jitterbug-Id: 116 Submitted-By: Guido van Rossum <guido@CNRI.Reston.VA.US> Date: Mon, 25 Oct 1999 10:38:58 -0400 Version: None OS: None A worthy to-do item. ------- Forwarded Message Date: Sat, 23 Oct 1999 08:24:32 -0000 From: Jonathan Craft <jcchina@bigfoot.com> To: guido@python.org Subject: Possible to-do addition Hi Guido, Is there a visual interface builder (as in VBasic, Hypercard, Icon) for Tkinter? I haven't been able to find any information on it (I'm new to Python). If not, that would be a good to-do. Jonathan Craft mailto:jcchina@bigfoot.com ------- End of Forwarded Message ==================================================================== Audit trail: Mon Oct 25 15:13:11 1999 guido moved from incoming to request Thomas Wouters 2000-08-06T17:03:00Z I believe several people are working on something like this (or at least said they were... they might have quit in despair :-) I'm not sure if this belongs on the Python buglist, though. Jeremy Hylton 2000-09-07T22:03:00Z Please do triage on this bug. barry 2000-09-16T22:06:00Z Added to PEP 42 2000-08-01T21:10:00Z sf210821 Jitterbug-Id: 121 Submitted-By: "Brad Clements" <bkc@murkworks.com> Date: Wed, 3 Nov 1999 15:53:01 -0500 Version: None OS: None The system encountered a fatal error After command: Received: The last error code was: Connection refused Web interface using {HYPERLINK "http://samba.anu.edu.au/jitterbug/"}Jitterbug {HYPERLINK "../python-bugs/"}Public interface {HYPERLINK "../python-bugs.private"}Private interface (requires password) {HYPERLINK "http://www.python.org/"}Python home page ----- Here's what I said for Python 1.5.2 on Win32 #0 PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not usable on WIN32 from non-VC applications because python15.dll is statically linked to the MS runtime DLL. Embedding applications that try to use these functions are passing in FILE * structures that do not match MS's runtime format. For example, I'm using Python in a Borland C++ Builder application. Although I can open a FILE *, when passed to python15.dll the FILE * is not usable. The addition of two helper functions would solve this problem: FILE * PyRun_OpenFile(char *file, char *mode) { return fopen(file,mode) } int PyRun_CloseFile(FILE *ptr) { return fclose(ptr) } This way embedding apps could get python15.dll to open the file and it would work. A temporary workaround is to always load the .pyc file in PyRun_SimpleFile.. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937 ==================================================================== Audit trail: Fri Nov 05 10:31:10 1999 guido moved from incoming to request Bug Importer REJECTED MEDIUM feature-request Jeremy Hylton python-interpreter-core Bug Importer Bug Importer 2000-08-01T21:10:00Z Jitterbug-Id: 121 Submitted-By: "Brad Clements" <bkc@murkworks.com> Date: Wed, 3 Nov 1999 15:53:01 -0500 Version: None OS: None The system encountered a fatal error After command: Received: The last error code was: Connection refused Web interface using {HYPERLINK "http://samba.anu.edu.au/jitterbug/"}Jitterbug {HYPERLINK "../python-bugs/"}Public interface {HYPERLINK "../python-bugs.private"}Private interface (requires password) {HYPERLINK "http://www.python.org/"}Python home page ----- Here's what I said for Python 1.5.2 on Win32 #0 PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not usable on WIN32 from non-VC applications because python15.dll is statically linked to the MS runtime DLL. Embedding applications that try to use these functions are passing in FILE * structures that do not match MS's runtime format. For example, I'm using Python in a Borland C++ Builder application. Although I can open a FILE *, when passed to python15.dll the FILE * is not usable. The addition of two helper functions would solve this problem: FILE * PyRun_OpenFile(char *file, char *mode) { return fopen(file,mode) } int PyRun_CloseFile(FILE *ptr) { return fclose(ptr) } This way embedding apps could get python15.dll to open the file and it would work. A temporary workaround is to always load the .pyc file in PyRun_SimpleFile.. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937 ==================================================================== Audit trail: Fri Nov 05 10:31:10 1999 guido moved from incoming to request Bug Importer 2000-08-01T21:10:00Z From: "Brad Clements" <bkc@murkworks.com> Subject: Re: [Python-bugs-list] Python 1.5.2 bug, tried to post but got error (PR#121) Date: Wed, 3 Nov 1999 20:22:21 -0500 Here it is again. Also, I believe this will resolve FAQ entry 8.10 > 8.10. Can't get Py_RunSimpleFile() to work. > This is very sensitive to the compiler vendor, version and (perhaps) even > options. If the FILE* structure in your embedding program isn't the same as > is assumed by the Python interpreter it won't work. The Python 1.5.* DLLs > (python15.dll) are all compiled with MS VC++ 5.0 and with > multithreading-DLL options (/MD, I think). > > If you can't change compilers or flags, try using Py_RunSimpleString(). A > trick to get it to run an arbitrary file is to construct a call to > execfile() with the name of your file as argument. > > > > --------------------------------------------------------------------------- > ----- > Here's what I said for Python 1.5.2 on Win32 #0 > > PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not > usable on WIN32 from non-VC applications because python15.dll is statically > linked to the MS runtime DLL. Embedding applications that try to use these > functions are passing in FILE * structures that do not match MS's runtime > format. > > For example, I'm using Python in a Borland C++ Builder application. Although I > can open a FILE *, when passed to python15.dll the FILE * is not usable. > > The addition of two helper functions would solve this problem: > > FILE * PyRun_OpenFile(char *file, char *mode) > { > return fopen(file,mode) > } > > int PyRun_CloseFile(FILE *ptr) > { > return fclose(ptr) > } > > This way embedding apps could get python15.dll to open the file and it would > work. > > A temporary workaround is to always load the .pyc file in PyRun_SimpleFile.. I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937 Bug Importer 2000-08-01T21:10:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] Python 1.5.2 bug, tried to post but got error (PR#121) Date: Wed, 03 Nov 1999 20:08:11 -0500 > I tried to post a bug, but got this error: > > The system encountered a fatal error We were being slammed by a defective spider (or, if you're more paranoid, by a hacker) so we temporarily turned off the webserver. It should be back on now. > Here's what I said for Python 1.5.2 on Win32 #0 > > PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not > usable on WIN32 from non-VC applications because python15.dll is statically > linked to the MS runtime DLL. Embedding applications that try to use these > functions are passing in FILE * structures that do not match MS's runtime > format. > > For example, I'm using Python in a Borland C++ Builder application. Although I > can open a FILE *, when passed to python15.dll the FILE * is not usable. > > The addition of two helper functions would solve this problem: > > FILE * PyRun_OpenFile(char *file, char *mode) > { > return fopen(file,mode) > } > > int PyRun_CloseFile(FILE *ptr) > { > return fclose(ptr) > } > > This way embedding apps could get python15.dll to open the file and it would > work. > > A temporary workaround is to always load the .pyc file in PyRun_SimpleFile.. This is an elegant solution. I think I'll add it. Could you mail me your suggestion again with the legal boilerplate included? See http://www.python.org/1.5/bugrelease.html for the text and explanation. Our lawyers require that I request this silliness... --Guido van Rossum (home page: http://www.python.org/~guido/) Jeremy Hylton 2000-09-07T22:01:00Z Please do triage on this bug. Jeremy Hylton 2000-09-12T16:01:00Z Guido -- In 1999, you said you would add this feature. Did you? Guido van Rossum 2000-09-13T10:53:00Z This is a feature request. Jeremy, how's that feature request PEP coming? Jeremy Hylton 2000-09-15T19:21:00Z added to pep 42 Strife35 2001-08-23T14:33:00Z I have a related question, I have a project that I am working on, and I ran into an enormous amount of problems with file i/o as a result of pythons standard file stuf not using win32api, what I'm doing to prevent the problem is re- building python, and my project (embedded into python) but in rebuilding i have edited fileobject.c to force all file operation calls to use their win32api counterparts by defining macros to replace the stdio functions. I.E. fopen () -> createfile(), ...The macro replacement accepts the original arguements, converts them as neccessary to the ones needed by the win32API func, calls the win32api function and then returns a value which models the behavior of the original function. As you may have guessed already this presented some interesting problems as most of these functions are all passing around (FILE *) structures. To work around this I am returning the HANDLE's that these functions return letting the program pretend that they are FILE *s. I would have macrod FILE * to be a HANDLE except that one of the first functions PyFile_AsFile(f) is of type FILE *, and didnt like that very much.... Finally I had replaced almost everything.. Currently I am down to 2 last problems, dealing with fputs(), and that in now in my tracebacks sys.stdout instead of being an open path to stdout so as to enable sys.stdout.write('whatever') to write to stdout and thus to screen, it becomes an error as 'my' file opener i believe attempts to open a file named stdout.. I havent had much luck trying to figure what happens in sysmodule, and was wondering if any one had any ideas comments suggestions or help to offer. Guido van Rossum 2001-08-23T14:38:00Z To strife35 (Adam Edelstein?): It might be better to have a separate object type that resembles a file object in its Python interface but uses the win32api calls rather than stdio. Can you explain why you need to use win32api I/O calls directly rather than via the MS-provided standard C library (which makes Win32 API calls underneath)? Strife35 2001-08-23T15:00:00Z The problem arrises in that this project is running over a network, and later I get problems with lockfiles and deleting files because although files may appear to be "closed" at the python level from the old stdio functions like fclose, they are indeed still open at the NT level and as a result cant be deleted. This becomes a real problem with OCI files, and other things on NT. It is not a problem on other os's like Solaris, Unix, linux, hpux, etc.., it is a WINnt problem Adam Guido van Rossum 2001-08-23T16:36:00Z Hm. Are you *sure* that you are calling the close() method? I find it hard to believe that the stdio fclose() wouldn't make the corresponding Win32 call to really close the object. A fairly common failure mode in Python is to have a local variable referencing an open file and assuming that when the local variable goes out of scope, the file is closed. This will *usually* happen, but sometimes the stack frame is kept alive (e.g. by exception handling machinery) and that prevents the file from being closed. I am very familiar with the Windows problem that you can't remove/rename a file that's still open -- but I've never heard of a case where making the explicit close() call doesn't fix it. Just trying to be helpful -- what you're embarking on seems a big project... 2000-08-01T21:10:00Z sf210822 Jitterbug-Id: 130 Submitted-By: grant.griffin@alliedsignal.com Date: Mon, 15 Nov 1999 15:26:44 -0500 (EST) Version: 1.5.2 OS: Windows NT 4.0 I would like to suggest that the "TCL_LIBRARY" variable be automatically set by the Win32 installer program. Currently, this is a manual process. It can be frustrating for the user because when he tries to run a Tkinter program, it says "cannot find tcl80.dll...". (I was able to figure out the solution here only by digging through comp.lang.python in Deja.) Therefore, I recommend the installer be changed as follows: 1) Do TCL installation before Python, not after. 2) Somehow figure out what the value of TCL_LIBRARY should be as a function of the directory that the user had installed TCL in. 3) Automatically write the proper value of TCL_LIBRARY into the Windows registry. Alternatively, you could just add a prompt like "In order to use TCL with Python, you must set the 'TCL_LIBRARY' environment variable to point to the directory where tcl80.dll is installed." Anyway, thanks, guys--keep up the GREAT work! -Grant ==================================================================== Audit trail: Tue Nov 16 13:58:27 1999 guido changed notes Tue Nov 16 13:58:27 1999 guido moved from incoming to request Bug Importer FIXRELEASED MEDIUM feature-request tkinter Bug Importer Bug Importer 2000-08-01T21:10:00Z Jitterbug-Id: 130 Submitted-By: grant.griffin@alliedsignal.com Date: Mon, 15 Nov 1999 15:26:44 -0500 (EST) Version: 1.5.2 OS: Windows NT 4.0 I would like to suggest that the "TCL_LIBRARY" variable be automatically set by the Win32 installer program. Currently, this is a manual process. It can be frustrating for the user because when he tries to run a Tkinter program, it says "cannot find tcl80.dll...". (I was able to figure out the solution here only by digging through comp.lang.python in Deja.) Therefore, I recommend the installer be changed as follows: 1) Do TCL installation before Python, not after. 2) Somehow figure out what the value of TCL_LIBRARY should be as a function of the directory that the user had installed TCL in. 3) Automatically write the proper value of TCL_LIBRARY into the Windows registry. Alternatively, you could just add a prompt like "In order to use TCL with Python, you must set the 'TCL_LIBRARY' environment variable to point to the directory where tcl80.dll is installed." Anyway, thanks, guys--keep up the GREAT work! -Grant ==================================================================== Audit trail: Tue Nov 16 13:58:27 1999 guido changed notes Tue Nov 16 13:58:27 1999 guido moved from incoming to request Bug Importer 2000-08-01T21:10:00Z We will try to fgix this for Python 1.6. Bug Importer 2000-08-01T21:10:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] TCL_LIBRARY variable for win32 (PR#130) Date: Mon, 15 Nov 1999 15:35:20 -0500 > I would like to suggest that the "TCL_LIBRARY" variable be automatically set by > the Win32 installer program. Currently, this is a manual process. It can be > frustrating for the user because when he tries to run a Tkinter program, it says > "cannot find tcl80.dll...". (I was able to figure out the solution here only by > digging through comp.lang.python in Deja.) > > Therefore, I recommend the installer be changed as follows: > > 1) Do TCL installation before Python, not after. > 2) Somehow figure out what the value of TCL_LIBRARY should be as a function of > the directory that the user had installed TCL in. > 3) Automatically write the proper value of TCL_LIBRARY into the Windows > registry. > > Alternatively, you could just add a prompt like "In order to use TCL with > Python, you must set the 'TCL_LIBRARY' environment variable to point to the > directory where tcl80.dll is installed." > > Anyway, thanks, guys--keep up the GREAT work! Thanks for the suggestion. The problem is that on Windows 95/98, the environment is not kept in the registry! Editing autoexec.bat has been suggested but is too error-prone. But we will definitely revisit this problem again with the next release (not due until late 2000); the best solution we can think of is to integrate the Tcl files in the Python installation instead of running the Tcl installer; this way we can be sure that Tcl is always in the same directory as Python. --Guido van Rossum (home page: http://www.python.org/~guido/) Thomas Wouters 2000-08-06T17:11:00Z Partly (or completely ?) resolved by including Tcl/Tk in the Python Installer for Windows. Guido van Rossum 2000-08-06T17:34:00Z Yes, this is fixed in the 1.6 windows installation (through a helper module FixTk.py which is imported by importing Tkinter). 2000-08-01T21:10:00Z sf210823 Jitterbug-Id: 132 Submitted-By: aa8vb@yahoo.com Date: Thu, 18 Nov 1999 08:16:55 -0500 (EST) Version: 1.5.2 OS: IRIX 6.5 I have: picture.bind( "<ButtonPress-1>" , click_cb ) picture.bind( "<ButtonRelease-1>", click_cb ) In click_cb(), event.state is 0 for ButtonPress and 256 for ButtonRelease. Where are the Tkinter constants for these? Or how should one distinguish between a press and release in a callback? (I want to avoid having a separate callback for each type of event.) ==================================================================== Audit trail: Thu Nov 18 10:42:46 1999 guido changed notes Thu Nov 18 10:42:46 1999 guido moved from incoming to notabug Thu Nov 18 14:07:59 1999 guido changed notes Thu Nov 18 14:07:59 1999 guido moved from notabug to request Bug Importer REJECTED MEDIUM feature-request Guido van Rossum tkinter Bug Importer Bug Importer 2000-08-01T21:10:00Z Jitterbug-Id: 132 Submitted-By: aa8vb@yahoo.com Date: Thu, 18 Nov 1999 08:16:55 -0500 (EST) Version: 1.5.2 OS: IRIX 6.5 I have: picture.bind( "<ButtonPress-1>" , click_cb ) picture.bind( "<ButtonRelease-1>", click_cb ) In click_cb(), event.state is 0 for ButtonPress and 256 for ButtonRelease. Where are the Tkinter constants for these? Or how should one distinguish between a press and release in a callback? (I want to avoid having a separate callback for each type of event.) ==================================================================== Audit trail: Thu Nov 18 10:42:46 1999 guido changed notes Thu Nov 18 10:42:46 1999 guido moved from incoming to notabug Thu Nov 18 14:07:59 1999 guido changed notes Thu Nov 18 14:07:59 1999 guido moved from notabug to request Bug Importer 2000-08-01T21:10:00Z Should add a symbol as he suggests. Bug Importer 2000-08-01T21:10:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] Tkinter missing button state symbols (PR#132) Date: Thu, 18 Nov 1999 14:05:57 -0500 Yes, requests are okay. Sorry for the confusion. --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-08-01T21:10:00Z From: Randall Hopper <Hopper.Randall@epa.gov> Subject: Re: [Python-bugs-list] Tkinter missing button state symbols (PR#132) Date: Thu, 18 Nov 1999 14:04:13 -0500 Guido van Rossum: |> Full_Name: Randall Hopper |> Version: 1.5.2 |> OS: IRIX 6.5 |> Submission from: ethyl-f.rtpfddi.epa.gov (134.67.65.11) |> |> |> I have: |> |> picture.bind( "<ButtonPress-1>" , click_cb ) |> picture.bind( "<ButtonRelease-1>", click_cb ) |> |> In click_cb(), event.state is 0 for ButtonPress and 256 for ButtonRelease. |> |> Where are the Tkinter constants for these? Or how should one distinguish |> between a press and release in a callback? |> |> (I want to avoid having a separate callback for each type of event.) | |This is not a question for the bugs list. | |Write to help@python.org or use the newsgroup for help. I don't know |offhand what the answer is to your question; I suspect that the answer |is in the Tcl/Tk man page for the bind command though. My fault. I should have rephrased the question into a statement. Tkinter does not provide symbol defines for event.state values (%s keyword in Tcl). Tcl doesn't either, but it would be useful if Tkinter did. This is a small enhancement request rather than a hard bug, but I thought the submission form was for probably applicable for both. Thanks, Randall Bug Importer 2000-08-01T21:10:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] Tkinter missing button state symbols (PR#132) Date: Thu, 18 Nov 1999 10:41:31 -0500 > Full_Name: Randall Hopper > Version: 1.5.2 > OS: IRIX 6.5 > Submission from: ethyl-f.rtpfddi.epa.gov (134.67.65.11) > > > I have: > > picture.bind( "<ButtonPress-1>" , click_cb ) > picture.bind( "<ButtonRelease-1>", click_cb ) > > In click_cb(), event.state is 0 for ButtonPress and 256 for ButtonRelease. > > Where are the Tkinter constants for these? Or how should one distinguish > between a press and release in a callback? > > (I want to avoid having a separate callback for each type of event.) This is not a question for the bugs list. Write to help@python.org or use the newsgroup for help. I don't know offhand what the answer is to your question; I suspect that the answer is in the Tcl/Tk man page for the bind command though. --Guido van Rossum (home page: http://www.python.org/~guido/) Fredrik Lundh 2000-08-09T09:21:00Z IIRC, these constants are platform (X library) dependent (they have to be exported from _tkinter.c, not Tkconstants.py). I'll investigate. Feel free to assign the bug to me if you like. </F> Guido van Rossum 2000-08-10T18:43:00Z /F, go for it! Bug Importer 2000-09-24T14:01:00Z LOL.I DON'T UNDERSTAND THIS SHIT BUT SOUNDS REALLY INTERESTING.WHERE CAN I LEARN HOW TO DO THIS??? SOME-ONE HELP ME!! Guido van Rossum 2000-10-01T04:30:00Z Fredrik, you promised to do this... Do you have time? Guido van Rossum 2000-10-03T15:22:00Z I'll do this so Fredrik can do SRE. Guido van Rossum 2000-10-03T16:41:00Z Sorry, I won't fix this. Tcl/Tk doesn't document the values you get here, and I don't want to make assumptions about their undocumented features. The proper solution is to be a man and use separate callbacks. :-) 2000-08-01T21:10:00Z sf210824 Jitterbug-Id: 133 Submitted-By: aa8vb@yahoo.com Date: Thu, 18 Nov 1999 13:34:44 -0500 (EST) Version: 1.5.2 OS: IRIX 6.5 From: "Fredrik Lundh" <fredrik@pythonware.com> Date: Tue, 2 Nov 1999 09:53:17 +0100 Subject: Re: Tkinter canvas blow-up: bbox(ALL) == None Randall Hopper <aa8vb@yahoo.com> wrote: > Apparently if the bounds of the items in a Tk canvas widget exceed > MAXINT, bbox(ALL) returns None. The attached Python script demonstrates > this. > > Intuitively it seems like this is a bug since the contents of the > canvas are maintained in floating point; integer bounds shouldn't be > involved, should they? > > Is this a Tk bug or a Tkinter bug? both. Tkinter uses _getints instead of _getdoubles to convert the bounding box to a tuple... ...but the reason you get None instead of an over- flow error is that Tk returns an empty string in this case (at least in 8.0.5). ------------------------------------------------------------------------------- #!/usr/bin/env python # # canvas_test.py - Demonstrates a bug in Tkinter's Canvas widget # where bbox = None when the bbox exceeds signed MAXINT # (2^31 on most machines). from Tkinter import * # # Create widgets # root = Tk() canvas = Canvas( root, width = 300, height = 300 ) canvas.pack() canvas.create_rectangle( (-100,-100,100,100), outline = "#008000", fill="#800000", width = 3 ) canvas.create_line( (-100,-100,100,100), fill="blue", width=3 ) canvas.create_line( (-100,100,100,-100), fill="blue", width=3 ) canvas.config( scrollregion = canvas.bbox( ALL ) ) # # Zoom the canvas until it's bounds get toasted because they exceed MAXINT # def TimerCB( canvas=canvas ): old = canvas.bbox( ALL ) canvas.scale( ALL, 0.0, 0.0, 2.0, 2.0 ) new = canvas.bbox( ALL ) print "Old = %s, New = %s" % ( old, new ) if new == None: raise SystemError, "canvas's bbox is toast (exceeds signed MAXINT)" canvas.after( 300, TimerCB ) print "CANVAS ZOOM BLOW-UP TEST:\n" canvas.after( 1500, TimerCB ) root.mainloop() ==================================================================== Audit trail: Thu Nov 18 14:06:40 1999 guido changed notes Thu Nov 18 14:06:41 1999 guido moved from incoming to request Bug Importer REJECTED MEDIUM x-3rd-party Fredrik Lundh tkinter Bug Importer Bug Importer 2000-08-01T21:10:00Z Jitterbug-Id: 133 Submitted-By: aa8vb@yahoo.com Date: Thu, 18 Nov 1999 13:34:44 -0500 (EST) Version: 1.5.2 OS: IRIX 6.5 From: "Fredrik Lundh" <fredrik@pythonware.com> Date: Tue, 2 Nov 1999 09:53:17 +0100 Subject: Re: Tkinter canvas blow-up: bbox(ALL) == None Randall Hopper <aa8vb@yahoo.com> wrote: > Apparently if the bounds of the items in a Tk canvas widget exceed > MAXINT, bbox(ALL) returns None. The attached Python script demonstrates > this. > > Intuitively it seems like this is a bug since the contents of the > canvas are maintained in floating point; integer bounds shouldn't be > involved, should they? > > Is this a Tk bug or a Tkinter bug? both. Tkinter uses _getints instead of _getdoubles to convert the bounding box to a tuple... ...but the reason you get None instead of an over- flow error is that Tk returns an empty string in this case (at least in 8.0.5). ------------------------------------------------------------------------------- #!/usr/bin/env python # # canvas_test.py - Demonstrates a bug in Tkinter's Canvas widget # where bbox = None when the bbox exceeds signed MAXINT # (2^31 on most machines). from Tkinter import * # # Create widgets # root = Tk() canvas = Canvas( root, width = 300, height = 300 ) canvas.pack() canvas.create_rectangle( (-100,-100,100,100), outline = "#008000", fill="#800000", width = 3 ) canvas.create_line( (-100,-100,100,100), fill="blue", width=3 ) canvas.create_line( (-100,100,100,-100), fill="blue", width=3 ) canvas.config( scrollregion = canvas.bbox( ALL ) ) # # Zoom the canvas until it's bounds get toasted because they exceed MAXINT # def TimerCB( canvas=canvas ): old = canvas.bbox( ALL ) canvas.scale( ALL, 0.0, 0.0, 2.0, 2.0 ) new = canvas.bbox( ALL ) print "Old = %s, New = %s" % ( old, new ) if new == None: raise SystemError, "canvas's bbox is toast (exceeds signed MAXINT)" canvas.after( 300, TimerCB ) print "CANVAS ZOOM BLOW-UP TEST:\n" canvas.after( 1500, TimerCB ) root.mainloop() ==================================================================== Audit trail: Thu Nov 18 14:06:40 1999 guido changed notes Thu Nov 18 14:06:41 1999 guido moved from incoming to request Bug Importer 2000-08-01T21:11:00Z bbox should use floats instead of ints, since Tcl/Tk can return them. Fredrik Lundh 2000-08-09T18:10:00Z this is a Tk feature. the "canvas bbox" command uses integers internally, so there's not much we can do about it :-( 2000-08-01T21:11:00Z sf210826 Jitterbug-Id: 136 Submitted-By: Randall Hopper <aa8vb@yahoo.com> Date: Wed, 24 Nov 1999 09:51:10 -0500 Version: None OS: None Just tried to submit this via the web interface which has worked in the past. This time, I got: The system encountered a fatal error After command: Received: The last error code was: Connection refused This was a non-private bug report, as usual. Anyway, here's the bug report: ============================================================================== aa8vb@yahoo.com Python mymalloc.h; not C++ compatible Randall Hopper 1.5.2 IRIX 6.5 Private: NO I hit a problem trying to compile wxPython on IRIX 6.5. The issue is NULL should be "0" when compiling for C++. The IRIX headers define it this way. The Python mymalloc.h header doesn't. A work-around is to require clients to include stdio.h before including any Python header files, but this is a hack. Here's a snip from a recent Python post I made with a proposed fix: ------------------------------------------------------------------------------ ...After a bit of grepping, the culprit seems to be Python (1.5.2): /usr/local/include/python1.5/mymalloc.h: #ifndef NULL #define NULL ((ANY *)0) #endif ... It appears to me that the right fix is for Python's mymalloc.h, if it must define NULL (does it?), be updated to be more C++ friendly. E.g.: #ifndef NULL # ifdef __cplusplus # define NULL 0 # else # define NULL ((ANY *)0) # endif #endif I'm assuming there's some reason we can't just #include <stdio.h> from mymalloc.h (?) ------------------------------------------------------------------------------ Thanks, Randall ==================================================================== Audit trail: Fri Dec 03 10:32:05 1999 guido sent reply 1 Fri Dec 03 10:32:19 1999 guido changed notes Fri Dec 03 10:32:20 1999 guido moved from incoming to request Bug Importer FIXRELEASED MEDIUM feature-request Tim Peters python-interpreter-core Bug Importer Bug Importer 2000-08-01T21:11:00Z Jitterbug-Id: 136 Submitted-By: Randall Hopper <aa8vb@yahoo.com> Date: Wed, 24 Nov 1999 09:51:10 -0500 Version: None OS: None Just tried to submit this via the web interface which has worked in the past. This time, I got: The system encountered a fatal error After command: Received: The last error code was: Connection refused This was a non-private bug report, as usual. Anyway, here's the bug report: ============================================================================== aa8vb@yahoo.com Python mymalloc.h; not C++ compatible Randall Hopper 1.5.2 IRIX 6.5 Private: NO I hit a problem trying to compile wxPython on IRIX 6.5. The issue is NULL should be "0" when compiling for C++. The IRIX headers define it this way. The Python mymalloc.h header doesn't. A work-around is to require clients to include stdio.h before including any Python header files, but this is a hack. Here's a snip from a recent Python post I made with a proposed fix: ------------------------------------------------------------------------------ ...After a bit of grepping, the culprit seems to be Python (1.5.2): /usr/local/include/python1.5/mymalloc.h: #ifndef NULL #define NULL ((ANY *)0) #endif ... It appears to me that the right fix is for Python's mymalloc.h, if it must define NULL (does it?), be updated to be more C++ friendly. E.g.: #ifndef NULL # ifdef __cplusplus # define NULL 0 # else # define NULL ((ANY *)0) # endif #endif I'm assuming there's some reason we can't just #include <stdio.h> from mymalloc.h (?) ------------------------------------------------------------------------------ Thanks, Randall ==================================================================== Audit trail: Fri Dec 03 10:32:05 1999 guido sent reply 1 Fri Dec 03 10:32:19 1999 guido changed notes Fri Dec 03 10:32:20 1999 guido moved from incoming to request Bug Importer 2000-08-01T21:11:00Z Maybe, maybe not. Bug Importer 2000-08-01T21:11:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] Re: Re: WebBugRptBroken & "Python mymalloc.h; not C++ compatible" (PR#136) Date: Wed, 08 Dec 1999 17:04:30 -0500 > > ----- Forwarded message from Guido van Rossum <bugs-py@python.org> ----- > > > > Date: Fri, 3 Dec 1999 10:32:03 -0500 (EST) > > From: Guido van Rossum <bugs-py@python.org> > > Subject: Re: WebBugRptBroken & "Python mymalloc.h; not C++ compatible" > (PR#136) > > > > > I hit a problem trying to compile wxPython on IRIX 6.5. The issue is > NULL > > > should be "0" when compiling for C++. The IRIX headers define it this > way. > > > The Python mymalloc.h header doesn't. A work-around is to require > clients > > > to include stdio.h before including any Python header files, but this is > a > > > hack. > > > > Why is wxPython using mymalloc.h directly? It should use Python.h, > > which *does* include stdio.h first. > > > > > > ----- End forwarded message ----- > > > > wxPython does use Python.h and if I remember correctly, moving it to be the > first #include (to ensure that none of the wx or my headers were screwing > things up) didn't help Randall at all. He had to put an #include <stdio.h> > before it. Strange. I don't have your source so there's no point arguing about it here. Python.h definitely includes <stdio.h> before including "mymalloc.h". At least in 1.5(.x), I haven't checked older versions. --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-08-01T21:11:00Z From: "Robin Dunn" <robin@alldunn.com> Subject: Re: Re: WebBugRptBroken & "Python mymalloc.h; not C++ compatible" (PR#136) Date: Wed, 8 Dec 1999 12:03:08 -0800 > ----- Forwarded message from Guido van Rossum <bugs-py@python.org> ----- > > Date: Fri, 3 Dec 1999 10:32:03 -0500 (EST) > From: Guido van Rossum <bugs-py@python.org> > Subject: Re: WebBugRptBroken & "Python mymalloc.h; not C++ compatible" (PR#136) > > > I hit a problem trying to compile wxPython on IRIX 6.5. The issue is NULL > > should be "0" when compiling for C++. The IRIX headers define it this way. > > The Python mymalloc.h header doesn't. A work-around is to require clients > > to include stdio.h before including any Python header files, but this is a > > hack. > > Why is wxPython using mymalloc.h directly? It should use Python.h, > which *does* include stdio.h first. > > > ----- End forwarded message ----- > wxPython does use Python.h and if I remember correctly, moving it to be the first #include (to ensure that none of the wx or my headers were screwing things up) didn't help Randall at all. He had to put an #include <stdio.h> before it. -- Robin Dunn Software Craftsman robin@AllDunn.com http://AllDunn.com/robin/ http://AllDunn.com/wxPython/ Check it out! Bug Importer 2000-08-01T21:11:00Z From: Guido van Rossum <bugs-py@python.org> Subject: Re: WebBugRptBroken & "Python mymalloc.h; not C++ compatible" (PR#136) Date: Fri Dec 3 10:32:05 1999 > I hit a problem trying to compile wxPython on IRIX 6.5. The issue is NULL > should be "0" when compiling for C++. The IRIX headers define it this way. > The Python mymalloc.h header doesn't. A work-around is to require clients > to include stdio.h before including any Python header files, but this is a > hack. Why is wxPython using mymalloc.h directly? It should use Python.h, which *does* include stdio.h first. Thomas Wouters 2000-08-06T17:33:00Z Looks like a "won't fix" to me, unless there is a good reason not to include Python.h. If you start including other python header files, you better know damn well what you're doing, and include the necessary files beforehand, yourself. But that's just me. Jeremy Hylton 2000-09-07T22:06:00Z Please do triage on this bug. Tim Peters 2000-09-10T01:04:00Z The checkin comment, applied to 2.0b1: Close SF bug 110826: a complaint about the way Python #define'd NULL. It's hard to sort out what the bug was, exactly. So, Big Hammer: 1. Python shouldn't be in the business of #define'ing NULL, period. 2. Users of the Python C API shouldn't be in the business of not including Python.h, period. Hence: 1. Removed all #define's of NULL in Python source code (pyport.h and object.h). 2. Since we're *relying* on stdio.h defining NULL, put an #error in Python.h after its #include of stdio.h if NULL isn't defined then. 2000-08-01T21:11:00Z sf210827 Jitterbug-Id: 148 Submitted-By: Gregor Hoffleit <flight@mathi.uni-heidelberg.de> Date: Sat, 4 Dec 1999 00:01:46 +0100 Version: None OS: None --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I'd like to "mirror" python-bugs for offline reading. While the pages are really quite static and it should be easy to mirror them, Jitterbug tends to make the URLs more complex than necessary, so that a single page is accessed via many different URLs: E.g. the first page with "notabug" reports currently has those URLs, which always led to the same page: http://www.python.org/python-bugs/notabug?user=3Dguest http://www.python.org/python-bugs/notabug?page=3D0;user=3Dguest =20 http://www.python.org/python-bugs/notabug?page=3D0;page=3D1;user=3Dguest http://www.python.org/python-bugs/notabug?page=3D0;page=3D2;user=3Dguest http://www.python.org/python-bugs/notabug Even worse, the navigation is sometimes quite strange: If you're on the second "notabug" page and click e.g. on "request" in the headline, you get to the second "request" page. I'd expect to get on the first page of the new section. I don't know if this is a problem of this installation of Jitterbug, or if it is a problem of Jitterbug itself. In the later case, I think we should notify the Jitterbug maintainers of this shortcoming. Gregor =20 --SUOF0GtieIMvvwua Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4SEva3eVfDf25G40RAWCwAJ4qpdV8RHaBLrzT1pgpaVM5g+rJ8QCgrd8S W+VCGLgPB8BH/Aru4po46EQ= =7iBw -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- ==================================================================== Audit trail: Tue Dec 14 17:20:48 1999 guido changed notes Tue Dec 14 17:20:48 1999 guido moved from incoming to request Bug Importer REJECTED MEDIUM feature-request Bug Importer Bug Importer 2000-08-01T21:11:00Z Jitterbug-Id: 148 Submitted-By: Gregor Hoffleit <flight@mathi.uni-heidelberg.de> Date: Sat, 4 Dec 1999 00:01:46 +0100 Version: None OS: None --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I'd like to "mirror" python-bugs for offline reading. While the pages are really quite static and it should be easy to mirror them, Jitterbug tends to make the URLs more complex than necessary, so that a single page is accessed via many different URLs: E.g. the first page with "notabug" reports currently has those URLs, which always led to the same page: http://www.python.org/python-bugs/notabug?user=3Dguest http://www.python.org/python-bugs/notabug?page=3D0;user=3Dguest =20 http://www.python.org/python-bugs/notabug?page=3D0;page=3D1;user=3Dguest http://www.python.org/python-bugs/notabug?page=3D0;page=3D2;user=3Dguest http://www.python.org/python-bugs/notabug Even worse, the navigation is sometimes quite strange: If you're on the second "notabug" page and click e.g. on "request" in the headline, you get to the second "request" page. I'd expect to get on the first page of the new section. I don't know if this is a problem of this installation of Jitterbug, or if it is a problem of Jitterbug itself. In the later case, I think we should notify the Jitterbug maintainers of this shortcoming. Gregor =20 --SUOF0GtieIMvvwua Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4SEva3eVfDf25G40RAWCwAJ4qpdV8RHaBLrzT1pgpaVM5g+rJ8QCgrd8S W+VCGLgPB8BH/Aru4po46EQ= =7iBw -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- ==================================================================== Audit trail: Tue Dec 14 17:20:48 1999 guido changed notes Tue Dec 14 17:20:48 1999 guido moved from incoming to request Bug Importer 2000-08-01T21:12:00Z The problems are all with Jitterbug. Bug Importer 2000-08-01T21:12:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] Jitterbug cumbersome to use with offline cache (PR#148) Date: Mon, 06 Dec 1999 09:46:53 -0500 > I'd like to "mirror" python-bugs for offline reading. While the pages are > really quite static and it should be easy to mirror them, Jitterbug tends to > make the URLs more complex than necessary, so that a single page is accessed > via many different URLs: > > E.g. the first page with "notabug" reports currently has those URLs, which > always led to the same page: > > http://www.python.org/python-bugs/notabug?user=3Dguest > http://www.python.org/python-bugs/notabug?page=3D0;user=3Dguest =20 > http://www.python.org/python-bugs/notabug?page=3D0;page=3D1;user=3Dguest > http://www.python.org/python-bugs/notabug?page=3D0;page=3D2;user=3Dguest > http://www.python.org/python-bugs/notabug > > Even worse, the navigation is sometimes quite strange: If you're on the > second "notabug" page and click e.g. on "request" in the headline, you get > to the second "request" page. I'd expect to get on the first page of the new > section. > > > I don't know if this is a problem of this installation of Jitterbug, or if > it is a problem of Jitterbug itself. In the later case, I think we should > notify the Jitterbug maintainers of this shortcoming. I can't check this right now (python.org is having hardware problems) but I think these are all problems with Jitterbug. Our use of it is really very simpleminded. Basically, it stinks, but the other bug reporting systems I've looked at stink worse. Eventually it should be redone in Zope -- feel like a weekend hacking? --Guido van Rossum (home page: http://www.python.org/~guido/) Jeremy Hylton 2000-08-02T00:35:00Z We don't use Jitterbug anymore. 2000-08-01T21:12:00Z sf210829 Jitterbug-Id: 166 Submitted-By: aa8vb@ipass.net Date: Wed, 22 Dec 1999 07:57:58 -0500 (EST) Version: 1.5.2 OS: Irix In implementing a Python reader for VPF GIS data, I noticed that the struct module makes it very easy to read in data that may be in a different byte order than the local machine: val = struct.unpack( "<l", buf ) This parses from a little-endian file/buffer, and swaps bytes "if needed" to the endianness of the local machine. However, using the array module is not so convenient. The developer has to write code to sense the byte order of the local machine, and tell the array module whether or not to swap bytes. I.e. there is no "swap to native byte order" functionality: def _IsByteSwapNeeded( file_byte_order ): """ The array module doesn't do byte swapping to the native byte order. So we have to get under the hood and check it ourselves. """ def host_endian(): if ord( array.array( "i", [1] ).tostring()[ 0 ] ): return 'L' else: return 'M' assert file_byte_order in 'LM' return ( host_endian() != file_byte_order ) a = array.array( "l", buf ) if _IsByteSwapNeeded( 'L' ): a.byteswap() val = a.tolist() The reason for using the array module (versus the struct module with repeat counts) is for more efficient memory storage and access of large numbers of lists containing large numbers of coordinates. struct insists on converting everything at once, and the length must be exactly right. array provides direct access to the any element of slice of a list so it is my preferred choice. It would be useful if the "<" and ">" byte order prefixes used in the struct module were added to the array module. Thanks, Randall ==================================================================== Audit trail: Wed Jan 12 18:16:54 2000 guido changed notes Wed Jan 12 18:16:54 2000 guido moved from incoming to request Bug Importer FIXRELEASED MEDIUM feature-request Fred Drake extension-modules Bug Importer Bug Importer 2000-08-01T21:12:00Z Jitterbug-Id: 166 Submitted-By: aa8vb@ipass.net Date: Wed, 22 Dec 1999 07:57:58 -0500 (EST) Version: 1.5.2 OS: Irix In implementing a Python reader for VPF GIS data, I noticed that the struct module makes it very easy to read in data that may be in a different byte order than the local machine: val = struct.unpack( "<l", buf ) This parses from a little-endian file/buffer, and swaps bytes "if needed" to the endianness of the local machine. However, using the array module is not so convenient. The developer has to write code to sense the byte order of the local machine, and tell the array module whether or not to swap bytes. I.e. there is no "swap to native byte order" functionality: def _IsByteSwapNeeded( file_byte_order ): """ The array module doesn't do byte swapping to the native byte order. So we have to get under the hood and check it ourselves. """ def host_endian(): if ord( array.array( "i", [1] ).tostring()[ 0 ] ): return 'L' else: return 'M' assert file_byte_order in 'LM' return ( host_endian() != file_byte_order ) a = array.array( "l", buf ) if _IsByteSwapNeeded( 'L' ): a.byteswap() val = a.tolist() The reason for using the array module (versus the struct module with repeat counts) is for more efficient memory storage and access of large numbers of lists containing large numbers of coordinates. struct insists on converting everything at once, and the length must be exactly right. array provides direct access to the any element of slice of a list so it is my preferred choice. It would be useful if the "<" and ">" byte order prefixes used in the struct module were added to the array module. Thanks, Randall ==================================================================== Audit trail: Wed Jan 12 18:16:54 2000 guido changed notes Wed Jan 12 18:16:54 2000 guido moved from incoming to request Bug Importer 2000-08-01T21:12:00Z Actually, all we need is a simpler way to discover the native byte order. A flag in the struct module would do just fine. Bug Importer 2000-08-01T21:12:00Z From: Randall Hopper <aa8vb@ipass.net> Subject: Re: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Date: Thu, 30 Dec 1999 19:19:09 -0500 Guido van Rossum: |Randall Hopper: |> However, using the array module is not so convenient. The developer has to |> write code to sense the byte order of the local machine, and tell the |> array module whether or not to swap bytes. I.e. there is no |> "swap to native byte order" functionality: |> |> def _IsByteSwapNeeded( file_byte_order ): |> """ The array module doesn't do byte swapping to the native byte order. |> So we have to get under the hood and check it ourselves. |> """ |> def host_endian(): |> if ord( array.array( "i", [1] ).tostring()[ 0 ] ): return 'L' |> else: return 'M' | |(I presume 'L' is little-endian, but what does 'M' stand for?) L/M - LSB/MSB - [L]east/[M]ost Significant Byte First though: L/B - [L]ittle/[B]ig Endian might have been more intuitive. |However I don't think that adding '<' to the format string is the |right solution -- the format string declares the format of the data in |the array, not how it should be converted from elsewhere. (The array |module has other uses besides I/O of binary data.) ... |I can see several solutions: |- Add a byte order indicator to some standard module (e.g. the array | module, or the sys module) so you can write a = array.array("l", buf) if | sys.byte_order == 'big': a.byteswap() |- Add a byte order flag to all the array methods that add raw data to | the array object (constructor, fromfile(), fromstring(); and for | symmetry also to the methods that write raw data out (tofile(), | tostring()). A problem with tofile() is that in order to do the | byteswap we'd either have to allocate temporary memory or byteswap in | place, and then byteswap back after writing. Having considered this again from what you've said, I agree that a byte order indicator would probably be better for the array case. I see your point: temporary buffers for reads or writes would be needed since array is a type used for storage whereas struct is not. A byte order indicator leads to more user code in doing the byte swapping and is inconsistent with struct's, but it does avoid all (potentially large) temporary buffer generation whether byte swapping is needed or not, which is important. Thanks, Randall Bug Importer 2000-08-01T21:12:00Z From: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us> Subject: Re: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Date: Wed, 22 Dec 1999 11:59:07 -0500 (EST) >>>>> "Fred" == <fdrake@acm.org> writes: Fred> I agree, but I'd also like to see an indicator for the Fred> native byte order somewhere (like sys) as well. (How Fred> possible would this be for JPython, Barry?) Java's native format is bigendian, regardless of the system's underlying endian-ness. I'm not aware of any way of figuring out what the system's endian-ness is. -Barry Bug Importer 2000-08-01T21:12:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Date: Wed, 22 Dec 1999 11:45:34 -0500 > guido@cnri.reston.va.us writes: > > I vote for the byte order indicator, giving total control to the user. > > I agree, but I'd also like to see an indicator for the native byte > order somewhere (like sys) as well. (How possible would this be for > JPython, Barry?) Ack! I was ambiguous! I meant to see a native byte order somewhere! --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-08-01T21:12:00Z From: "Fred L. Drake, Jr." <fdrake@acm.org> Subject: Re: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Date: Wed, 22 Dec 1999 10:43:32 -0500 (EST) guido@cnri.reston.va.us writes: > I vote for the byte order indicator, giving total control to the user. I agree, but I'd also like to see an indicator for the native byte order somewhere (like sys) as well. (How possible would this be for JPython, Barry?) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives Bug Importer 2000-08-01T21:12:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Date: Wed, 22 Dec 1999 09:30:21 -0500 > In implementing a Python reader for VPF GIS data, I noticed that the struct > module makes it very easy to read in data that may be in a different byte > order than the local machine: > > val = struct.unpack( "<l", buf ) > > This parses from a little-endian file/buffer, and swaps bytes "if needed" to > the endianness of the local machine. > > However, using the array module is not so convenient. The developer has to > write code to sense the byte order of the local machine, and tell the > array module whether or not to swap bytes. I.e. there is no > "swap to native byte order" functionality: > > def _IsByteSwapNeeded( file_byte_order ): > """ The array module doesn't do byte swapping to the native byte order. > So we have to get under the hood and check it ourselves. > """ > def host_endian(): > if ord( array.array( "i", [1] ).tostring()[ 0 ] ): return 'L' > else: return 'M' (I presume 'L' is little-endian, but what does 'M' stand for?) > assert file_byte_order in 'LM' > return ( host_endian() != file_byte_order ) > > a = array.array( "l", buf ) > if _IsByteSwapNeeded( 'L' ): > a.byteswap() > val = a.tolist() > > > The reason for using the array module (versus the struct module with > repeat counts) is for more efficient memory storage and access of large > numbers of lists containing large numbers of coordinates. struct insists > on converting everything at once, and the length must be exactly right. > array provides direct access to the any element of slice of a list so it > is my preferred choice. > > It would be useful if the "<" and ">" byte order prefixes used > in the struct module were added to the array module. You're right that this is more work than it should be. However I don't think that adding '<' to the format string is the right solution -- the format string declares the format of the data in the array, not how it should be converted from elsewhere. (The array module has other uses besides I/O of binary data.) I can see several solutions: - Add a byte order indicator to some standard module (e.g. the array module, or the sys module) so you can write a = array.array("l", buf) if sys.byte_order == 'big': a.byteswap() - Add a byte order flag to all the array methods that add raw data to the array object (constructor, fromfile(), fromstring(); and for symmetry also to the methods that write raw data out (tofile(), tostring()). A problem with tofile() is that in order to do the byteswap we'd either have to allocate temporary memory or byteswap in place, and then byteswap back after writing. I vote for the byte order indicator, giving total control to the user. --Guido van Rossum (home page: http://www.python.org/~guido/) Fred Drake 2000-08-14T15:51:00Z The sys.byte_order indicator is now in CVS, and will be available in Python 2.0. I think there's nothing left to fix. 2000-08-01T21:12:00Z sf210830 Jitterbug-Id: 177 Submitted-By: simonb@logical.co.za Date: Tue, 11 Jan 2000 05:17:37 -0500 (EST) Version: 1-5-2 OS: NT 4.0 Hi there I don't know if this is a bug, or is intentional behaviour for a specific reason. The following code produces a syntax error about the continue not being within a looping structure rather than a prefectly silly infinite loop... while 1: try: continue except: pass where the following works as one would expect... while 1: try: raise 1 except: continue I figure that there is more likely a sane reason for this behaviour than being a bug, but I am curious. Thanks Simon ==================================================================== Audit trail: Wed Jan 12 18:11:45 2000 guido changed notes Wed Jan 12 18:11:45 2000 guido moved from incoming to request Bug Importer REJECTED LOW feature-request Fred Drake parser-compiler Bug Importer Bug Importer 2000-08-01T21:12:00Z Jitterbug-Id: 177 Submitted-By: simonb@logical.co.za Date: Tue, 11 Jan 2000 05:17:37 -0500 (EST) Version: 1-5-2 OS: NT 4.0 Hi there I don't know if this is a bug, or is intentional behaviour for a specific reason. The following code produces a syntax error about the continue not being within a looping structure rather than a prefectly silly infinite loop... while 1: try: continue except: pass where the following works as one would expect... while 1: try: raise 1 except: continue I figure that there is more likely a sane reason for this behaviour than being a bug, but I am curious. Thanks Simon ==================================================================== Audit trail: Wed Jan 12 18:11:45 2000 guido changed notes Wed Jan 12 18:11:45 2000 guido moved from incoming to request Bug Importer 2000-08-01T21:12:00Z It's a zero-priority bug (i.e. not likely to be fixed). Bug Importer 2000-08-01T21:12:00Z From: "Tim Peters" <tim_one@email.msn.com> Subject: RE: [Python-bugs-list] Syntax (PR#177) Date: Tue, 11 Jan 2000 12:10:17 -0500 [Simon Barratt, putting "continue" in a "try" block] > I don't know if this is a bug, or is intentional behaviour > for a specific reason. Actually, it's a bit of both <wink>. See the Language Reference Manual's section on the "continue" statement, particularly the footnote: The restriction on occurring in the try clause is implementer's laziness and will eventually be lifted. It's been this way (and documented) forever; it's simply hard to implement given the current structure of the interpreter loop. Rest assured there's nothing *conceptually* wrong with putting continue in a try! It's simply an implementation restriction; the error msg should probably make that clearer. IIRC, JPython doesn't have this restriction. "Someday" it will get repaired in CPython too. Thomas Wouters 2000-08-03T20:00:00Z Like the bot said, low priority 'to be fixed' bug. Jeremy Hylton 2000-09-07T22:05:00Z Please do triage on this bug. Fred Drake 2000-09-08T16:37:00Z Improved exception messages when 'continue' is in a 'try' block, checked in as Python/compile.c revision 2.141. This still doesn't do the "right thing" by implementing 'continue' in this context, but makes it easier for users to understand the exception. Fred Drake 2000-10-03T15:45:00Z Added this to PEP 42; closing the bug report. 2000-08-01T21:12:00Z sf210831 Jitterbug-Id: 192 Submitted-By: davidv@elisra.com Date: Thu, 27 Jan 2000 13:31:16 -0500 (EST) Version: 1.52 OS: Qnx This is not a bug. I have compiled Python 1.52 with Watcom on QNX. The Linux readline doesn't work good with QNX. This simple patch for /Parser/myreadline.c replaces readline with QNX input_line function. ------------------------------------------------------------ 60,68d59 < < #ifdef __QNX__ < p = input_line( fp, buf, len ); < if( p ) { < int n = strlen(p); < p[n] = '\n'; < p[n+1] = 0; < } < #else 70d60 < #endif ------------------------------------------------------------- ==================================================================== Audit trail: Mon Feb 07 12:34:32 2000 guido sent reply 1 Mon Feb 07 12:34:49 2000 guido changed notes Mon Feb 07 12:34:49 2000 guido moved from incoming to request Bug Importer FIXRELEASED MEDIUM feature-request Guido van Rossum Bug Importer Bug Importer 2000-08-01T21:12:00Z Jitterbug-Id: 192 Submitted-By: davidv@elisra.com Date: Thu, 27 Jan 2000 13:31:16 -0500 (EST) Version: 1.52 OS: Qnx This is not a bug. I have compiled Python 1.52 with Watcom on QNX. The Linux readline doesn't work good with QNX. This simple patch for /Parser/myreadline.c replaces readline with QNX input_line function. ------------------------------------------------------------ 60,68d59 < < #ifdef __QNX__ < p = input_line( fp, buf, len ); < if( p ) { < int n = strlen(p); < p[n] = '\n'; < p[n+1] = 0; < } < #else 70d60 < #endif ------------------------------------------------------------- ==================================================================== Audit trail: Mon Feb 07 12:34:32 2000 guido sent reply 1 Mon Feb 07 12:34:49 2000 guido changed notes Mon Feb 07 12:34:49 2000 guido moved from incoming to request Bug Importer 2000-08-01T21:13:00Z Should go to patches@python.org. Bug Importer 2000-08-01T21:13:00Z From: Guido van Rossum <bugs-py@python.org> Subject: Re: readline on QNX (PR#192) Date: Mon Feb 7 12:34:32 2000 > This is not a bug. > I have compiled Python 1.52 with Watcom on QNX. The Linux readline doesn't > work good with QNX. This simple patch for /Parser/myreadline.c > replaces readline with QNX input_line function. > > ------------------------------------------------------------ > 60,68d59 > < > < #ifdef __QNX__ > < p = input_line( fp, buf, len ); > < if( p ) { > < int n = strlen(p); > < p[n] = '\n'; > < p[n+1] = 0; > < } > < #else > 70d60 > < #endif > ------------------------------------------------------------- David, please see www.python.org/patches for instructions on how to send patches. The Bugs List is not the right place, sorry! --Guido van Rossum Jeremy Hylton 2000-09-07T22:04:00Z Please do triage on this bug. Guido van Rossum 2000-09-13T10:57:00Z There is not enough context in the patch to do anything with it. (PLEASE ALWAYS USE CONTEXT DIFFS OR UNIFIED DIFFS!) If the submittor is still interested in supplying a working patch, and if this is still a problem with Python 2.0b1, please use the SF patch manager to submit a proper patch. 2000-08-01T21:13:00Z sf210832 Jitterbug-Id: 194 Submitted-By: DrMalte@ddd.de Date: Sun, 30 Jan 2000 19:40:45 -0500 (EST) Version: 1.5.2 and 1.4 OS: Linux While playing with linbot I noticed some failed requests to 'http://xxx.xxx.xx/../img/xxx.gif' for a document in the root directory containing <IMG SRC="../img/xxx.gif">. The Reason is in urlparse.urljoin() urljoin() fails to remove an odd number of '../' from the path. Demonstration: from urlparse import urljoin print urljoin( 'http://127.0.0.1/', '../imgs/logo.gif' ) # gives 'http://127.0.0.1/../imgs/logo.gif' # should give 'http://127.0.0.1/imgs/logo.gif' print urljoin( 'http://127.0.0.1/', '../../imgs/logo.gif' ) # gives 'http://127.0.0.1/imgs/logo.gif' # works # '../../imgs/logo.gif' gives 'http://127.0.0.1/../imgs/logo.gif' and so on The patch for 1.5.2 ( I'm not sure if it works generally, but tests with linbot looked good) *** /usr/local/lib/python1.5/urlparse.py Sat Jun 26 19:11:59 1999 --- urlparse.py Mon Jan 31 01:31:45 2000 *************** *** 170,175 **** --- 170,180 ---- segments[-1] = '' elif len(segments) >= 2 and segments[-1] == '..': segments[-2:] = [''] + + if segments[0] == '': + while segments[1] == '..': # remove all leading '..' + del segments[1] + return urlunparse((scheme, netloc, joinfields(segments, '/'), params, query, fragment)) ==================================================================== Audit trail: Mon Feb 07 12:35:35 2000 guido changed notes Mon Feb 07 12:35:35 2000 guido moved from incoming to request Bug Importer FIXRELEASED MEDIUM Fred Drake python-library Bug Importer Bug Importer 2000-08-01T21:13:00Z Jitterbug-Id: 194 Submitted-By: DrMalte@ddd.de Date: Sun, 30 Jan 2000 19:40:45 -0500 (EST) Version: 1.5.2 and 1.4 OS: Linux While playing with linbot I noticed some failed requests to 'http://xxx.xxx.xx/../img/xxx.gif' for a document in the root directory containing <IMG SRC="../img/xxx.gif">. The Reason is in urlparse.urljoin() urljoin() fails to remove an odd number of '../' from the path. Demonstration: from urlparse import urljoin print urljoin( 'http://127.0.0.1/', '../imgs/logo.gif' ) # gives 'http://127.0.0.1/../imgs/logo.gif' # should give 'http://127.0.0.1/imgs/logo.gif' print urljoin( 'http://127.0.0.1/', '../../imgs/logo.gif' ) # gives 'http://127.0.0.1/imgs/logo.gif' # works # '../../imgs/logo.gif' gives 'http://127.0.0.1/../imgs/logo.gif' and so on The patch for 1.5.2 ( I'm not sure if it works generally, but tests with linbot looked good) *** /usr/local/lib/python1.5/urlparse.py Sat Jun 26 19:11:59 1999 --- urlparse.py Mon Jan 31 01:31:45 2000 *************** *** 170,175 **** --- 170,180 ---- segments[-1] = '' elif len(segments) >= 2 and segments[-1] == '..': segments[-2:] = [''] + + if segments[0] == '': + while segments[1] == '..': # remove all leading '..' + del segments[1] + return urlunparse((scheme, netloc, joinfields(segments, '/'), params, query, fragment)) ==================================================================== Audit trail: Mon Feb 07 12:35:35 2000 guido changed notes Mon Feb 07 12:35:35 2000 guido moved from incoming to request Bug Importer 2000-08-01T21:13:00Z Patch being considered. Bug Importer 2000-08-01T21:13:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] urljoin() bug with odd no of '..' (PR#194) Date: Mon, 31 Jan 2000 12:28:55 -0500 Thanks for your bug report and fix. I agree with your diagnosis. Would you please be so kind as to resend your patch with the legal disclaimer from http://www.python.org/1.5/bugrelease.html --Guido van Rossum (home page: http://www.python.org/~guido/) Moshez-users 2000-08-13T08:36:00Z OK, Jeremy -- this one is yours. Either notabug it, or check in the relevant patch (101064 -- assigned to you) Fred Drake 2000-08-24T04:22:00Z RFC 1808 gives examples of this form in section 5.2, "Abnormal Examples," and gives the current behavior as the desired treatment, stating that all parsers (urljoin() counts given the RFC's terminology) should treat the abnormal examples consistently. Walter Dörwald 2000-12-19T16:30:00Z Section 5.2 of RFC 1808 states that in the context of the base URL <> = <URL:http://a/b/c/d;p?q#f> URLs that have more .. than the base has directory names, should be resolved in the following way: ../../../g = <URL:http://a/../g> ../../../../g = <URL:http://a/../../g> i.e. they should be preserved, which urljoin does in the first example gives in the bug report: print urljoin( 'http://127.0.0.1/', '../imgs/logo.gif' ) http://127.0.0.1/../imgs/logo.gif but not in the second example: print urljoin( 'http://127.0.0.1/', '../../imgs/logo.gif' ) http://127.0.0.1/imgs/logo.gif where the result should have been http://127.0.0.1/../../imgs/logo.gif Guido van Rossum 2000-12-19T16:38:00Z OK, reopened. Fred Drake 2000-12-19T16:41:00Z Ok, confirmed. Reopening the bug until I get a chance to look at the proposed patch and can update the test suite. Fred Drake 2001-01-05T05:59:00Z Lib/urlparse.py revision 1.27 conforms to all recommended practices from RFC 1808 which don't conflict with RFC 1630. Test cases have been added to ensure we don't lose this attribute. Jnelson-users 2004-06-02T15:35:00Z I'm not 100% sure, but as of Python 2.2.2 (#1, Feb 24 2003, 19:13:11) for RedHat, this is still a problem: >>> import urlparse >>> print urlparse.urljoin( 'http://127.0.0.1/', '../imgs/logo.gif' ) http://127.0.0.1/../imgs/logo.gif >>> The patch above obviously no longer applies. Walter Dörwald 2004-06-02T15:49:00Z This is the same behaviour as in Python 2.3.4 and exactly what RFC 1808 specifies (see http://www.ietf.org/rfc/rfc1808.txt and scroll down to section 5.2. "Abnormal Examples"). Why do you think this is a problem? Jnelson-users 2004-06-02T17:48:00Z I stand corrected. Just because browsers deal with it, doesn't mean that it's right. FYI - RFC1808 has been superceded by 2396. 2000-08-01T21:13:00Z sf210833 Jitterbug-Id: 195 Submitted-By: John-Mark Gurney <gurney_j@efn.org> Date: Sun, 30 Jan 2000 18:09:56 -0800 Version: None OS: None I have found out that I need to add -Xlinker -export-dynamic to the gcc command to compile a program linked w/ the libpython.a library... if you do not specify this option, all unreferenced symbols will be discarded... please document this requirement in the documentation, and after that has happened, close this bug report... Thanks. -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson ==================================================================== Audit trail: Mon Feb 07 12:37:05 2000 guido changed notes Mon Feb 07 12:37:05 2000 guido moved from incoming to request Bug Importer FIXRELEASED MEDIUM feature-request Fred Drake documentation Bug Importer Bug Importer 2000-08-01T21:13:00Z Jitterbug-Id: 195 Submitted-By: John-Mark Gurney <gurney_j@efn.org> Date: Sun, 30 Jan 2000 18:09:56 -0800 Version: None OS: None I have found out that I need to add -Xlinker -export-dynamic to the gcc command to compile a program linked w/ the libpython.a library... if you do not specify this option, all unreferenced symbols will be discarded... please document this requirement in the documentation, and after that has happened, close this bug report... Thanks. -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson ==================================================================== Audit trail: Mon Feb 07 12:37:05 2000 guido changed notes Mon Feb 07 12:37:05 2000 guido moved from incoming to request Bug Importer 2000-08-01T21:13:00Z Still waiting for a patch... Bug Importer 2000-08-01T21:13:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] please resolve 191.. (PR#195) Date: Mon, 31 Jan 2000 15:35:35 -0500 > Guido van Rossum scribbled this message on Jan 31: > > > I have found out that I need to add -Xlinker -export-dynamic to the gcc > > > command to compile a program linked w/ the libpython.a library... if you > > > do not specify this option, all unreferenced symbols will be discarded... > > > > > > please document this requirement in the documentation, and after that has > > > happened, close this bug report... > > > > I read your bug report 191 and I think it may be platform specific, or > > a bug in how you link with Python, since I cannot reproduce this here > > on Solaris. > > I would try it under Solaris, but I don't have the time right now to > compile up the latest GNU ld on solaris, to make sure that it is compiler > specific... > > > Until we are clear on this we can't fix the documentation, sorry. > > I would think that you would want to document such a behavior considering > just how many people happen to use gcc... I am using gcc 2.7.2.3 and GNU > ld 2.9.1, and considering the number of people that are using GNU ld 2.9.1, > I would assume you'd want to document it so that people like myself, don't > run into this problem... > > the -Xlinker -export-dynamic happens to be a GNU ld specific solution, > but the bug that python doesn't force include all the symbols should be > documented so that people don't encounter the problem... This (that it's GNU ld specific) is information that you didn't explain first. I am probably not using GNU ld, which may explain why I couldn't reproduce your problem. If you want to save me the most time, please suggest the exact patch for the documentation, using the latest version of the docs from the CVS tree. (python.org/download/cvs.html) To save me at least some time, write a paragraph of text and give me at least a hint on which section of which document it should be inserted into, and we'll figure it out from there. --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-08-01T21:13:00Z From: Guido van Rossum <guido@python.org> Subject: Re: [Python-bugs-list] please resolve 191.. (PR#195) Date: Mon, 07 Feb 2000 12:55:20 -0500 > the -Xlinker -export-dynamic happens to be a GNU ld specific solution, > but the bug that python doesn't force include all the symbols should be > documented so that people don't encounter the problem... There's a Solaris-specific patch (just checked in a few days ago) to configure.in that takes care of this; maybe it can be made general? No time to explain, see latest configure.in cvs log. python.org/download/cvs.html --Guido van Rossum (home page: http://www.python.org/~guido/) Bug Importer 2000-08-01T21:13:00Z From: John-Mark Gurney <gurney_j@efn.org> Subject: Re: [Python-bugs-list] please resolve 191.. (PR#195) Date: Mon, 31 Jan 2000 11:40:12 -0800 Guido van Rossum scribbled this message on Jan 31: > > I have found out that I need to add -Xlinker -export-dynamic to the gcc > > command to compile a program linked w/ the libpython.a library... if you > > do not specify this option, all unreferenced symbols will be discarded... > > > > please document this requirement in the documentation, and after that has > > happened, close this bug report... > > I read your bug report 191 and I think it may be platform specific, or > a bug in how you link with Python, since I cannot reproduce this here > on Solaris. I would try it under Solaris, but I don't have the time right now to compile up the latest GNU ld on solaris, to make sure that it is compiler specific... > Until we are clear on this we can't fix the documentation, sorry. I would think that you would want to document such a behavior considering just how many people happen to use gcc... I am using gcc 2.7.2.3 and GNU ld 2.9.1, and considering the number of people that are using GNU ld 2.9.1, I would assume you'd want to document it so that people like myself, don't run into this problem... the -Xlinker -export-dynamic happens to be a GNU ld specific solution, but the bug that python doesn't force include all the symbols should be documented so that people don't encounter the problem... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson Bug Importer 2000-08-01T21:13:00Z From: Guido van Rossum <guido@CNRI.Reston.VA.US> Subject: Re: [Python-bugs-list] please resolve 191.. (PR#195) Date: Mon, 31 Jan 2000 12:25:49 -0500 > I have found out that I need to add -Xlinker -export-dynamic to the gcc > command to compile a program linked w/ the libpython.a library... if you > do not specify this option, all unreferenced symbols will be discarded... > > please document this requirement in the documentation, and after that has > happened, close this bug report... I read your bug report 191 and I think it may be platform specific, or a bug in how you link with Python, since I cannot reproduce this here on Solaris. Until we are clear on this we can't fix the documentation, sorry. --Guido van Rossum (home page: http://www.python.org/~guido/) Fred Drake 2000-09-08T22:57:00Z Add section to the Extending & Embedding manual discussing linking issues for embedded Python. Checked in as Doc/ext/ext.tex revision 1.83. 2000-08-01T21:13:00Z sf210834 Jitterbug-Id: 205 Submitted-By: mnot@akamai.com Date: Tue, 15 Feb 2000 17:09:44 -0500 (EST) Version: 1.5.2 OS: All Python parses urls into the following data structure: (scheme, netloc, path, params, query, fragment) and references RFC1808. 1808 has been updated by RFC2396, which allows on each path segment, not just the last. This would imply a data structure either like this: (scheme, netloc, path, query, fragment) or this: (scheme, netloc, [(segment, parameters)...], query, fragment) Rather than updating urlparse.py (and introducing incompatibility), it may be nice to introduce a new class (say, uriparse.py) that implements 2396. If there's enough interest, I may give it a go... ==================================================================== Audit trail: Wed Feb 23 21:39:30 2000 guido sent reply 1 Wed Feb 23 21:39:42 2000 guido changed notes Wed Feb 23 21:39:42 2000 guido moved from incoming to request Bug Importer REJECTED LOW feature-request Jeremy Hylton python-library Bug Importer Bug Importer 2000-08-01T21:13:00Z Jitterbug-Id: 205 Submitted-By: mnot@akamai.com Date: Tue, 15 Feb 2000 17:09:44 -0500 (EST) Version: 1.5.2 OS: All Python parses urls into the following data structure: (scheme, netloc, path, params, query, fragment) and references RFC1808. 1808 has been updated by RFC2396, which allows on each path segment, not just the last. This would imply a data structure either like this: (scheme, netloc, path, query, fragment) or this: (scheme, netloc, [(segment, parameters)...], query, fragment) Rather than updating urlparse.py (and introducing incompatibility), it may be nice to introduce a new class (say, uriparse.py) that implements 2396. If there's enough interest, I may give it a go... ==================================================================== Audit trail: Wed Feb 23 21:39:30 2000 guido sent reply 1 Wed Feb 23 21:39:42 2000 guido changed notes Wed Feb 23 21:39:42 2000 guido moved from incoming to request Bug Importer 2000-08-01T21:13:00Z Go for it! Bug Importer 2000-08-01T21:13:00Z From: Guido van Rossum <bugs-py@python.org> Subject: Re: urlparse and HTTP parameters (PR#205) Date: Wed Feb 23 21:39:30 2000 Go for it! --Guido van Rossum Fred Drake 2000-08-17T02:02:00Z An excellent idea; it can be incorporated in the existing urlparse module using new names. This won't be done for Python 2.0 at any rate, however. Jeremy Hylton 2000-09-07T22:03:00Z Please do triage on this bug. barry 2000-09-16T22:07:00Z Jeremy seems like the best person to decide about this. Jeremy Hylton 2000-10-03T14:14:00Z added to pep 42 Brett Cannon 2004-04-19T06:28:00Z is urlparse still not compatible? The regression tests test against RFC 2396 examples now. 2000-08-01T21:13:00Z sf210835 Jitterbug-Id: 214 Submitted-By: loewis@informatik.hu-berlin.de Date: Fri, 25 Feb 2000 14:28:33 -0500 (EST) Version: 1.5.2 OS: Solaris This is a feature request made on python-help. If you want to estimate how much memory your application uses, you currently have to count the bytes manually. If there was a builtin function (say, sys.sizeof), counting would be much easier. It would be documented as sizeof(object) -> integer Return the number of bytes that an object uses internally. This only counts the number of bytes used by the object itself, not those of any of its attributes. Ie. sys.sizeof(0) would give 12 on my system, the size of a dictionary would count the dictentries, but the size of an instanceobject would not count the the size of the __dict__ attribute. ==================================================================== Audit trail: Tue Mar 07 14:42:18 2000 guido changed notes Tue Mar 07 14:42:18 2000 guido moved from incoming to request Bug Importer REJECTED MEDIUM feature-request Jeremy Hylton python-interpreter-core Bug Importer Bug Importer 2000-08-01T21:13:00Z Jitterbug-Id: 214 Submitted-By: loewis@informatik.hu-berlin.de Date: Fri, 25 Feb 2000 14:28:33 -0500 (EST) Version: 1.5.2 OS: Solaris This is a feature request made on python-help. If you want to estimate how much memory your application uses, you currently have to count the bytes manually. If there was a builtin function (say, sys.sizeof), counting would be much easier. It would be documented as sizeof(object) -> integer Return the number of bytes that an object uses internally. This only counts the number of bytes used by the object itself, not those of any of its attributes. Ie. sys.sizeof(0) would give 12 on my system, the size of a dictionary would count the dictentries, but the size of an instanceobject would not count the the size of the __dict__ attribute. ==================================================================== Audit trail: Tue Mar 07 14:42:18 2000 guido changed notes Tue Mar 07 14:42:18 2000 guido moved from incoming to request Bug Importer 2000-08-01T21:14:00Z Interesting idea. Is this what we need? Jeremy Hylton 2000-09-07T22:01:00Z Please do triage on this bug. M.-A. Lemburg 2000-09-08T12:14:00Z See mxTools at http://starship.python.net/~lemburg/ for an example of how to implement a sizeof() function. The problem with this approach is that it only counts the size of the object struct itself and doesn't account for any external storage which may have been allocated by the object (e.g. Unicode objects and dictionaries use such external resources). Jeremy Hylton 2000-09-15T18:56:00Z entere in pep 42 2000-08-01T21:14:00Z sf210836 Jitterbug-Id: 228 Submitted-By: dean@dragonsys.com Date: Wed, 8 Mar 2000 15:36:00 -0500 (EST) Version: 1.5.2 OS: Linux I was trying to build python with a cross-compiler, so I put my cross-compiler bin directory in the front of my path and executed the configure script. The fact that a cross-compiler was being used was detected correctly, causing it to fail later on at line 1922: { echo "configure: error: can not run test program while cross compiling" 1>&2; exit 1; } This is a bug in configure, isn't it? ==================================================================== Audit trail: Mon Apr 03 18:37:06 2000 guido moved from incoming to request Bug Importer REJECTED LOW feature-request barry build Bug Importer Bug Importer 2000-08-01T21:14:00Z Jitterbug-Id: 228 Submitted-By: dean@dragonsys.com Date: Wed, 8 Mar 2000 15:36:00 -0500 (EST) Version: 1.5.2 OS: Linux I was trying to build python with a cross-compiler, so I put my cross-compiler bin directory in the front of my path and executed the configure script. The fact that a cross-compiler was being used was detected correctly, causing it to fail later on at line 1922: { echo "configure: error: can not run test program while cross compiling" 1>&2; exit 1; } This is a bug in configure, isn't it? ==================================================================== Audit trail: Mon Apr 03 18:37:06 2000 guido moved from incoming to request Bug Importer 2000-08-01T21:14:00Z From: Guido van Rossum <guido@python.org> Subject: Re: [Python-bugs-list] configure script fails with cross-compiler (PR#228) Date: Wed, 08 Mar 2000 22:19:12 -0500 > I was trying to build python with a cross-compiler, so I put my cross-compiler > bin directory in the front of my path and executed the configure script. The > fact that a cross-compiler was being used was detected correctly, causing it to > fail later on at line 1922: > { echo "configure: error: can not run test program while cross compiling" > 1>&2; exit 1; } > > This is a bug in configure, isn't it? Depends on your point of view. It's a restriction that the configure doesn't work with a cross compiler, because there are a bunch of tests for which it needs to run code to determine the outcome. If you want to contribute patches to configure.in to supply defaults (I think there are 6-8 cases) that would be approciated. See python.org/patches/. Cheers, --Guido van Rossum (home page: http://www.python.org/~guido/) barry 2000-10-05T15:38:00Z I'm not sure what changes to configure are necessary to support cross compiling, but if we decide to fix this, it shouldn't be until after 2.0 final. I've added this feature request to PEP 42, under the Building and Installing section. Closing this bug. 2000-08-01T21:14:00Z sf210837 Jitterbug-Id: 229 Submitted-By: aa8vb@yahoo.com Date: Thu, 9 Mar 2000 08:57:50 -0500 (EST) Version: 1.5.2 OS: IRIX 6.5 menu = apply( OptionMenu, ( parent, var ) + tuple( option_names ), { 'font':PANEL_FONT } ) generates: TypeError: unexpected keyword argument: font It would be helpful if the 'font' resource were accepted and used to create the menubutton and child command widgets. In its absense, folks need to poke at the internals of OptionMenu (obviously not a good idea) or establish a parent frame for each option menu with a unique name and use option_add to stuff *Class*Font: resources into the Tk resource database. If the 'font' option were supported, it would simplify this greatly. Thanks, Randall ==================================================================== Audit trail: Mon Apr 03 18:37:34 2000 guido changed notes Mon Apr 03 18:37:34 2000 guido moved from incoming to request Bug Importer REJECTED MEDIUM feature-request tkinter Bug Importer Bug Importer 2000-08-01T21:14:00Z Jitterbug-Id: 229 Submitted-By: aa8vb@yahoo.com Date: Thu, 9 Mar 2000 08:57:50 -0500 (EST) Version: 1.5.2 OS: IRIX 6.5 menu = apply( OptionMenu, ( parent, var ) + tuple( option_names ), { 'font':PANEL_FONT } ) generates: TypeError: unexpected keyword argument: font It would be helpful if the 'font' resource were accepted and used to create the menubutton and child command widgets. In its absense, folks need to poke at the internals of OptionMenu (obviously not a good idea) or establish a parent frame for each option menu with a unique name and use option_add to stuff *Class*Font: resources into the Tk resource database. If the 'font' option were supported, it would simplify this greatly. Thanks, Randall ==================================================================== Audit trail: Mon Apr 03 18:37:34 2000 guido changed notes Mon Apr 03 18:37:34 2000 guido moved from incoming to request Bug Importer 2000-08-01T21:14:00Z Probably won't be done. Bug Importer 2000-08-01T21:14:00Z From: Guido van Rossum <guido@python.org> Subject: Re: [Python-bugs-list] Tkinter Optionmenu doesn't accept 'font' resource (PR#229) Date: Thu, 09 Mar 2000 10:45:55 -0500 > It would be helpful if the 'font' resource were accepted and used to > create the menubutton and child command widgets. Unfortunately, the underlying Tk command, tk_optionmenu, doesn't support this. Nothing I can do about it. (See http://dev.scriptics.com/man/tcl8.3/TkCmd/optionMenu.htm.) --Guido van Rossum (home page: http://www.python.org/~guido/) Thomas Wouters 2000-08-06T21:10:00Z Not much Python can do, since it's a Tk limitation. 2000-08-01T21:15:00Z sf210838 Jitterbug-Id: 231 Submitted-By: nadavh@envision.co.il Date: Fri, 10 Mar 2000 18:35:07 -0500 (EST) Version: 1.52 OS: NT 4.0 SP4 1. The function cmath.acosh provides the negative branch with low precision. For example: >>> cmath.acosh(cmath.cosh(10.0)) (-10.0000000135+0j) Proposed solution --- use the following formula which is precise and avoids singularities with complex arguments: def acosh(x): return 2.0*log(sqrt(x+1.0) + sqrt(x-1.0)) - log(2.0) 2. The function cmath.sinh does not handle moderately large arguments. For example: >>> cmath.asinh(cmath.sinh(20.0)) (1.#INF+0j) Proposed solution: Use the textbook formula: def asinh(x): return log(x+sqrt(x*x+1.0)) This calculation is more limited then the acosh calculation, but still works fine. ==================================================================== Audit trail: Mon Apr 03 18:38:28 2000 guido changed notes Mon Apr 03 18:38:28 2000 guido moved from incoming to request Bug Importer FIXRELEASED LOW Tim Peters extension-modules Bug Importer Bug Importer 2000-08-01T21:15:00Z Jitterbug-Id: 231 Submitted-By: nadavh@envision.co.il Date: Fri, 10 Mar 2000 18:35:07 -0500 (EST) Version: 1.52 OS: NT 4.0 SP4 1. The function cmath.acosh provides the negative branch with low precision. For example: >>> cmath.acosh(cmath.cosh(10.0)) (-10.0000000135+0j) Proposed solution --- use the following formula which is precise and avoids singularities with complex arguments: def acosh(x): return 2.0*log(sqrt(x+1.0) + sqrt(x-1.0)) - log(2.0) 2. The function cmath.sinh does not handle moderately large arguments. For example: >>> cmath.asinh(cmath.sinh(20.0)) (1.#INF+0j) Proposed solution: Use the textbook formula: def asinh(x): return log(x+sqrt(x*x+1.0)) This calculation is more limited then the acosh calculation, but still works fine. ==================================================================== Audit trail: Mon Apr 03 18:38:28 2000 guido changed notes Mon Apr 03 18:38:28 2000 guido moved from incoming to request Bug Importer 2000-08-01T21:15:00Z Might be a good idea. Waiting for patches. Bug Importer 2000-08-01T21:15:00Z From: "Tim Peters" <tim_one@email.msn.com> Subject: RE: [Python-bugs-list] Inverse hyperbolic functions in cmath module (PR#231) Date: Sat, 11 Mar 2000 13:47:25 -0500 [Tim] > C doesn't define any functions on complex numbers -- cmathmodule.c > implements these all on its own. [David Ascher] > As an aside, if anyone ever wants to trim the number of builtin C > modules, I found that it was much easier to write cmath.py than to > write cmath.java (for JPython). The same cmath.py should work fine > in CPython. Yes, I don't see anything in cmathmodule.c that *needs* to be coded in C; & coding would be much clearer in Python, using infix notation for the basic complex binary ops. Two possible reasons for leaving it in C: 1. Lower internal call overheads (i.e., speed). 2. Improving quality -- complex libraries are very difficult to get right in all cases if they're made IEEE-754 aware, and doing so requires fiddling with the processor-level 754 control & status features. But there's no portable way to do that now, and won't be until the next iteration of C. > I can dig it up, but I can't swear that I used the most numerically stable > algorithms. I can: you didn't <wink>. Doesn't matter, though! cmathmodule.c is naive too, and achieving good accuracy across the whole domain is a major undertaking. That gives the best reason to write it in Python: 3. There's a long way to go to make this "industrial strength", so the current cmath is really just a prototype. Everyone knows prototyping is much easier in Python. QED <wink>. > It did give the same numbers as CPython's cmath on a test set. So ship it <wink>. Bug Importer 2000-08-01T21:15:00Z From: "David Ascher" <DavidA@ActiveState.com> Subject: RE: [Python-bugs-list] Inverse hyperbolic functions in cmath module (PR#231) Date: Fri, 10 Mar 2000 21:49:27 -0800 > [Nadav Horesh, suggests different algorithms in cmath, for some complex > inverse hyperbolics] > > [Guido, misfires] > > We're just using the VC++ C library. > > C doesn't define any functions on complex numbers -- cmathmodule.c > implements these all on its own. I can't make time to look at > this now, but > complaining to Microsoft about this will do Nadav even less good than when > it *is* their problem <wink>. As an aside, if anyone ever wants to trim the number of builtin C modules, I found that it was much easier to write cmath.py than to write cmath.java (for JPython). The same cmath.py should work fine in CPython. I can dig it up, but I can't swear that I used the most numerically stable algorithms. It did give the same numbers as CPython's cmath on a test set. -david Bug Importer 2000-08-01T21:15:00Z From: "Tim Peters" <tim_one@email.msn.com> Subject: RE: [Python-bugs-list] Inverse hyperbolic functions in cmath module (PR#231) Date: Fri, 10 Mar 2000 22:05:07 -0500 [Nadav Horesh, suggests different algorithms in cmath, for some complex inverse hyperbolics] [Guido, misfires] > We're just using the VC++ C library. C doesn't define any functions on complex numbers -- cmathmodule.c implements these all on its own. I can't make time to look at this now, but complaining to Microsoft about this will do Nadav even less good than when it *is* their problem <wink>. Bug Importer 2000-08-01T21:15:00Z From: "David Ascher" <DavidA@ActiveState.com> Subject: RE: [Python-bugs-list] Inverse hyperbolic functions in cmath module (PR#231) Date: Fri, 10 Mar 2000 16:47:23 -0800 > We're just using the VC++ C library. I suggest you send your bug > report to Microsoft. FWIW: the Perl folks are more and more (it seems to me) redoing things themselves if the C library tends to be broken or slow. I'm not suggesting that it's a good decision, just commenting. --david Bug Importer 2000-08-01T21:15:00Z From: Guido van Rossum <guido@python.org> Subject: Re: [Python-bugs-list] Inverse hyperbolic functions in cmath module (PR#231) Date: Fri, 10 Mar 2000 18:44:01 -0500 > Full_Name: Nadav Horesh > Version: 1.52 > OS: NT 4.0 SP4 > Submission from: (NULL) (212.25.119.223) > > > 1. The function cmath.acosh provides the negative branch with low > precision. For example: > > >>> cmath.acosh(cmath.cosh(10.0)) > (-10.0000000135+0j) > > Proposed solution --- use the following formula which is precise and > avoids singularities with complex arguments: > > def acosh(x): > return 2.0*log(sqrt(x+1.0) + sqrt(x-1.0)) - log(2.0) >