[ python-Bugs-1163244 ] Syntax error on large file with MBCS encoding
Bugs item #1163244, was opened at 2005-03-14 22:20 Message generated for change (Comment added) made by sdahlbac You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: Accepted Priority: 7 Submitted By: Tim N. van der Leeuw (tnleeuw) Assigned to: Nobody/Anonymous (nobody) Summary: Syntax error on large file with MBCS encoding Initial Comment: Large files generated by make-py.py from the win32all extensions cannot be compiled by Python2.4.1rc1 - they give a syntax error. This is a regression from 2.3.5 (With Python2.4, the interpreter crashes. That is fixed now.) Removing the mbcs encoding line from the top of the file, compilation succeeds. File should be attached, as zip-file. Probably requires win32all extensions to be installed to be compiled / imported (generated using build 203 of the win32all extensions). -- Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-07-21 13:38 Message: Logged In: YES user_id=750513 For what it's worth: I have two files (that I unfortunately cannot attach) which works fine on 2.3 that now on 2.4.1 produces spurious syntax errors when they have # -*- coding: ascii -*- if I change that to something that does not match the coding regex I do not get any syntax error (winxp) -- Comment By: Niki Spahiev (nikis) Date: 2005-06-02 19:11 Message: Logged In: YES user_id=27708 i have reproductable test case with encoding cp1251 file is 1594 bytes long, how to attach it? -- Comment By: Walter Dörwald (doerwalter) Date: 2005-04-15 02:40 Message: Logged In: YES user_id=89016 Importing foo2.py on Linux (with the current CVS HEAD version of Python) gives me a segmentation fault with the following stacktrace: 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 880 classname = inst->in_class->cl_name; (gdb) bt #0 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 #1 0x08082235 in PyObject_Repr (v=0xb7c158bc) at Objects/object.c:308 #2 0x080f3ccd in err_input (err=0xbfffe000) at Python/pythonrun.c:1478 #3 0x080f3956 in PyParser_SimpleParseFileFlags (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257, flags=0) at Python/pythonrun.c:1348 #4 0x080f3982 in PyParser_SimpleParseFile (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257) at Python/pythonrun.c:1355 #5 0x080e6fef in parse_source_module (pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:761 #6 0x080e72db in load_source_module (name=0xbfffe9d0 "foo2", pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:885 #7 0x080e86b4 in load_module (name=0xbfffe9d0 "foo2", fp=0x818d6e0, buf=0xbfffe530 "foo2.py", type=1, loader=0x0) at Python/import.c:1656 #8 0x080e9d52 in import_submodule (mod=0x8145768, subname=0xbfffe9d0 "foo2", fullname=0xbfffe9d0 "foo2") at Python/import.c:2250 #9 0x080e9511 in load_next (mod=0x8145768, altmod=0x8145768, p_name=0xbfffedf0, buf=0xbfffe9d0 "foo2", p_buflen=0xbfffe9cc) at Python/import.c:2070 #10 0x080e8e5e in import_module_ex (name=0x0, globals=0xb7d62e94, locals=0xb7d62e94, fromlist=0x8145768) at Python/import.c:1905 #11 0x080e914b in PyImport_ImportModuleEx (name=0xb7cd8824 "foo2", globals=0xb7d62e94, locals=0xb7d62e94, fromlist=0x8145768) at Python/import.c:1946 #12 0x080b5c87 in builtin___import__ (self=0x0, args=0xb7d1e634) at Python/bltinmodule.c:45 #13 0x0811d32e in PyCFunction_Call (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Objects/methodobject.c:73 #14 0x0805d188 in PyObject_Call (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Objects/abstract.c:1757 #15 0x080ca79d in PyEval_CallObjectWithKeywords (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Python/ceval.c:3425 #16 0x080c6719 in PyEval_EvalFrame (f=0x816dd7c) at Python/ceval.c:2026 #17 0x080c8fdd in PyEval_EvalCodeEx (co=0xb7cf1ef0, globals=0xb7d62e94, locals=0xb7d62e94, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2736 #18 0x080bffb0 in PyEval_EvalCode (co=0xb7cf1ef0, globals=0xb7d62e94, locals=0xb7d62e94) at Python/ceval.c:490 #19 0x080f361d in run_node (n=0xb7d122d0, filename=0x8123ba3 "", globals=0xb7d62e94, locals=0xb7d62e94, flags=0xb584) at Python/pythonrun.c:1265 #20 0x080f1f58 in PyRun_InteractiveOneFlags (fp=0xb7e94720, filename=0x8123ba3 "", flags=0xb584) at Python/pythonrun.c:762 #21 0x080f1c93 in PyRun_InteractiveLoopFlags (fp=0xb7e94720, filename=0x8123ba3 "", flags=0xb584) at Python/pythonrun.c:695 #22 0x080f1af6 in
[ python-Bugs-1241545 ] garbage collection asserts failing
Bugs item #1241545, was opened at 2005-07-20 08:27 Message generated for change (Comment added) made by munder12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: munder12 (munder12) Assigned to: Nobody/Anonymous (nobody) Summary: garbage collection asserts failing Initial Comment: Modules/gcmodule.c:294: visit_reachable: Assertion `gc_refs > 0 || gc_refs == (-3) || gc_refs == (-2)' failed. Running Python 2.3.4 on Fedora Core 3 (2.6.11-1.35_FC3smp). Also tried Python 2.3.5. When searching Google for this error, found following link where someone using yum updates was getting same error from python http://forums.fedoraforum.org/showthread.php?t=54704 -- >Comment By: munder12 (munder12) Date: 2005-07-21 13:05 Message: Logged In: YES user_id=1156202 Well, this gets even stranger. I am not running a debug version of python as far as I can tell. I built 2.4.1 in a fresh directory by: ./configure --prefix=/blah make make test make install The gcmodule was echo'd as being built this way: gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/gcmodule.o Modules/gcmodule.c I am leaning toward psyco as being the culprit based on your suggestions since it is the only one that has extra C libraries. I'm running the case with Tkinter, pyro, and psyco all not being imported. Thanks again, Mark -- Comment By: Tim Peters (tim_one) Date: 2005-07-20 19:35 Message: Logged In: YES user_id=31435 I'm intimately familiar with the gc code, and I'm sure this assert has never triggered in any core Python release, or in any Zope release, not even in between-releases buggy development states. It means some memory gc is staring at has an insane value, one that can't possibly arise in intended operation. If you get into gdb (whatever debugger you have), it might be useful to know what value gc_refs _does_ have at this point. One possibility is that you're mixing a debug-build Python (which you are using: asserts never trigger in a release-build Python, simply because the assert() macro expands to nothing then) with one or more release-build extension modules. Trying to mix like that can blow up in all sorts of "impossible" ways. -- Comment By: munder12 (munder12) Date: 2005-07-20 19:04 Message: Logged In: YES user_id=1156202 Sorry, I realize it is not much to go on but I cannot currently get it to fail other than when I run this one script. It is all written in python. It is a simulation running a genetic algorithm that is set up to run about 24 hours straight. This error occurs within about 5 hours into the simulation (repeatedly). Running similar simulations that complete in less than a couple hours run without a problem. Was hoping someone familiar with the gc routines might go "oh, yeah... -4 is valid now too.." or something similar. In the meantime, I will be trying to continue to reduce the number of imported modules where I can still get the problem to happen There are 2 modules psyco and pyro that are non- core and Tkinter. But since the Google search turned up yum giving same error (which I doubt uses psyco, pyro, or Tkinter), I thought I would mention it here as I continued searching. -- Comment By: Tim Peters (tim_one) Date: 2005-07-20 16:24 Message: Logged In: YES user_id=31435 Well, this isn't enough info to go on. For example, what program was Python running at the time? What were you doing? How could anyone else try to reproduce this? It's certainly not something Python normally does ;-) FWIW, the most likely cause is bad C coding in a Python extension (non-core) module. That the problem persists for you across Python versions points even more at non-core C code. -- Comment By: Neil Schemenauer (nascheme) Date: 2005-07-20 16:20 Message: Logged In: YES user_id=35752 Usually this kind of error is caused by a bug in a 3rd party extension module. Try to narrow down the test case as much as possible. Can you provide a Python script that triggers the assertion failure? -- Comment By: munder12 (munder12) Date: 2005-07-20 16:15 Message: Logged In: YES user_id=1156202 This also fails in Python 2.4.1 on same system. --
[ python-Bugs-1241545 ] garbage collection asserts failing
Bugs item #1241545, was opened at 2005-07-20 09:27 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: munder12 (munder12) Assigned to: Nobody/Anonymous (nobody) Summary: garbage collection asserts failing Initial Comment: Modules/gcmodule.c:294: visit_reachable: Assertion `gc_refs > 0 || gc_refs == (-3) || gc_refs == (-2)' failed. Running Python 2.3.4 on Fedora Core 3 (2.6.11-1.35_FC3smp). Also tried Python 2.3.5. When searching Google for this error, found following link where someone using yum updates was getting same error from python http://forums.fedoraforum.org/showthread.php?t=54704 -- >Comment By: Tim Peters (tim_one) Date: 2005-07-21 14:25 Message: Logged In: YES user_id=31435 This part of the command line you showed: -DNDEBUG causes C's assert() macro to "expand to nothing". That's part of the definition of the C language, not a Python convention. So if you compiled Python with -DNDEBUG, and are seeing an assert() trigger, then I can only conclude one of two things: 1. Your C compiler has a very bad bug. or 2. You're not actually using the Python you think you're using. That said, I've seen very strange bugs triggered by psyco too, but not even psyco can cause code to execute that doesn't exist. No code is generated for an assert() when compiling with -DNDEBUG: the C preprocessor throws assert()s away when NDEBUG is #define'd. -- Comment By: munder12 (munder12) Date: 2005-07-21 14:05 Message: Logged In: YES user_id=1156202 Well, this gets even stranger. I am not running a debug version of python as far as I can tell. I built 2.4.1 in a fresh directory by: ./configure --prefix=/blah make make test make install The gcmodule was echo'd as being built this way: gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/gcmodule.o Modules/gcmodule.c I am leaning toward psyco as being the culprit based on your suggestions since it is the only one that has extra C libraries. I'm running the case with Tkinter, pyro, and psyco all not being imported. Thanks again, Mark -- Comment By: Tim Peters (tim_one) Date: 2005-07-20 20:35 Message: Logged In: YES user_id=31435 I'm intimately familiar with the gc code, and I'm sure this assert has never triggered in any core Python release, or in any Zope release, not even in between-releases buggy development states. It means some memory gc is staring at has an insane value, one that can't possibly arise in intended operation. If you get into gdb (whatever debugger you have), it might be useful to know what value gc_refs _does_ have at this point. One possibility is that you're mixing a debug-build Python (which you are using: asserts never trigger in a release-build Python, simply because the assert() macro expands to nothing then) with one or more release-build extension modules. Trying to mix like that can blow up in all sorts of "impossible" ways. -- Comment By: munder12 (munder12) Date: 2005-07-20 20:04 Message: Logged In: YES user_id=1156202 Sorry, I realize it is not much to go on but I cannot currently get it to fail other than when I run this one script. It is all written in python. It is a simulation running a genetic algorithm that is set up to run about 24 hours straight. This error occurs within about 5 hours into the simulation (repeatedly). Running similar simulations that complete in less than a couple hours run without a problem. Was hoping someone familiar with the gc routines might go "oh, yeah... -4 is valid now too.." or something similar. In the meantime, I will be trying to continue to reduce the number of imported modules where I can still get the problem to happen There are 2 modules psyco and pyro that are non- core and Tkinter. But since the Google search turned up yum giving same error (which I doubt uses psyco, pyro, or Tkinter), I thought I would mention it here as I continued searching. -- Comment By: Tim Peters (tim_one) Date: 2005-07-20 17:24 Message: Logged In: YES user_id=31435 Well, this isn't enough info to go on. For example, what program was Python running at the time? What were you doing? How could anyone else try to reproduce this? It's certainly not somethi
[ python-Bugs-1242657 ] list(obj) can swallow KeyboardInterrupt
Bugs item #1242657, was opened at 2005-07-22 01:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1242657&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steve Alexander (stevea_zope) Assigned to: Nobody/Anonymous (nobody) Summary: list(obj) can swallow KeyboardInterrupt Initial Comment: The example below shows that list(f) swallows the KeyboardInterrupt. It swallows any other exception too, such as MemoryError or application-specific ConflictErrors. I think the "get the length of the object" optimisation should catch only AttributeError and TypeError. >>> class F(object): ... def __iter__(self): ... yield 23 ... def __len__(self): ... print "len called. raising Keyboard Interrupt." ... raise KeyboardInterrupt ... >>> f = F() >>> list(f) len called. raising Keyboard Interrupt. [23] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1242657&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1242657 ] list(obj) can swallow KeyboardInterrupt
Bugs item #1242657, was opened at 2005-07-21 17:22 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1242657&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steve Alexander (stevea_zope) >Assigned to: Raymond Hettinger (rhettinger) Summary: list(obj) can swallow KeyboardInterrupt Initial Comment: The example below shows that list(f) swallows the KeyboardInterrupt. It swallows any other exception too, such as MemoryError or application-specific ConflictErrors. I think the "get the length of the object" optimisation should catch only AttributeError and TypeError. >>> class F(object): ... def __iter__(self): ... yield 23 ... def __len__(self): ... print "len called. raising Keyboard Interrupt." ... raise KeyboardInterrupt ... >>> f = F() >>> list(f) len called. raising Keyboard Interrupt. [23] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1242657&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1183972 ] dest parameter in optparse
Bugs item #1183972, was opened at 2005-04-15 15:39 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183972&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: ahmado (ahmado) Assigned to: Greg Ward (gward) Summary: dest parameter in optparse Initial Comment: When using the "callback" action, optparse requires that you STILL specify a "dest" parameter, though it is not required or used by the option parser. In fact, if you do not include the "dest" parameter, your options will still work properly, but optparse will generate an exception when calling the "--help" option. Not specifying a "dest" parameter will result in the following Exception when using the default "--help" or "- h" option: File "c:\Python23\lib\optparse.py", line 229, in format_option_strings metavar = option.metavar or option.dest.upper() AttributeError: 'NoneType' object has no attribute 'upper' by simply adding a bogus bug, the --help / -h option works properly even though the dest isn't actually used. -- >Comment By: Greg Ward (gward) Date: 2005-07-21 22:03 Message: Logged In: YES user_id=14422 I'm pretty sure I fixed this in Optik 1.5 / Python 2.4. Can you 1) verify if the bug is still there in Python 2.4 and 2) if so, supply a small script demonstrating the problem? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183972&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1222235 ] Bad optparse help wrapping with multiple paragraphs
Feature Requests item #135, was opened at 2005-06-16 18:18 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Library >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Greg Ward (gward) Summary: Bad optparse help wrapping with multiple paragraphs Initial Comment: If the help text for an option consists of multiple paragraphs, optparse wraps all the paragraphs into one big mess when --help is used. optparse should really split the text by paragraphs and fill each individual paragraph. -- >Comment By: Greg Ward (gward) Date: 2005-07-21 22:08 Message: Logged In: YES user_id=14422 This sounds an awful lot like Optik RFE #1055954 -- see https://sourceforge.net/tracker/?func=detail&atid=421100&aid=1055954&group_id=38019 . -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=135&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
