[ python-Bugs-1166714 ] [ast branch] fatal error when compiling test_bool.py
Bugs item #1166714, was opened at 2005-03-20 00:14 Message generated for change (Comment added) made by jpe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470 Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Brett Cannon (bcannon) Summary: [ast branch] fatal error when compiling test_bool.py Initial Comment: When using the ast-branch compiler, python exits with a fatal error when compiling test_bool.py or the symplified test case that I'll attach. The immediate problem is that when the compiler is in make_closure after compiling the lambda, self is found to be a LOCAL reference type and make_closure assumes it's a FREE reference if it's not a CELL reference in the enclosing scope. I don't know if self is supposed to be a LOCAL reference or if make_closure should handle LOCAL references. -- >Comment By: John Ehresman (jpe) Date: 2005-04-25 01:18 Message: Logged In: YES user_id=22785 Yes, it should be PyDict_Update(free, newfree) like it is in the current CVS. The unicode failures should be fixed by compiling and using tokenizer.c rather than tokenizer_pgen.c, which is mentioned in the comment for patch 1170272 but didn't get changed when the patch was applied. I'm pretty sure tokenizer_pgen.c is not needed. -- Comment By: Brett Cannon (bcannon) Date: 2005-04-19 05:26 Message: Logged In: YES user_id=357491 John, on line 45 of the patch, which becomes line 580 in Python/symtable.c, you call PyDict_Update() with three arguments. Is 'local' supposed to be an argument, or is 'free' the erroneous one? If I change it so that 'local' is removed then the tests die on test_unicode (although a ton of other tests fail). -- Comment By: John Ehresman (jpe) Date: 2005-03-23 01:22 Message: Logged In: YES user_id=22785 Forgot to add the patch -- Comment By: John Ehresman (jpe) Date: 2005-03-23 01:21 Message: Logged In: YES user_id=22785 The attached patch seems to fix this by creating a dictionary for each scope's free vars and only propagating up the ones that aren't satisfied by a binding. With this and the other patches, the test suite runs w/o segfaulting up through test_unicode. -- Comment By: John Ehresman (jpe) Date: 2005-03-22 21:37 Message: Logged In: YES user_id=22785 The issue seems to be that in symtable_analyze, a free dictionary is created for the entire module and if a name is found to be free in any function, it is not converted from a LOCAL to a CELL is any context seen afterwards. I think the free variables need to be recorded on a function-by-function basis. -- Comment By: Brett Cannon (bcannon) Date: 2005-03-22 20:34 Message: Logged In: YES user_id=357491 An short example of the failure:: def outer(a): def first(): a def last(a): pass This leads to a fatal Python error. The issue is having a being a local or parameter (can make 'a' be 'a = 1' and not a parameter and still have it fail), the first closure reference it, and then the second one use it as a parameter. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1189216 ] zipfile module and 2G boundary
Bugs item #1189216, was opened at 2005-04-24 22:08 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=1189216&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile module and 2G boundary Initial Comment: The zipfile module currently can not handle archives that have file headers that begin past the 2**31 byte boundary. This is really bug #679953 all over again -- that fix didn't solve all of the problem. Patch to CVS HEAD attached, backport candidate to 2.4.2 and 2.3.6. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1189216&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1186345 ] [AST] assert failure on ``eval("u'\Ufffffffe'")``
Bugs item #1186345, was opened at 2005-04-19 16:24
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186345&group_id=5470
Category: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: [AST] assert failure on ``eval("u'\Ufffe'")``
Initial Comment:
Isolated the failure of test_unicode to be because of
the test of ``eval("u'\Ufffe'")``. What is odd is
that the Unicode string works fine as a literal at the
intepreter prompt. Somehow eval() is triggering this
problem.
--
>Comment By: Brett Cannon (bcannon)
Date: 2005-04-24 19:27
Message:
Logged In: YES
user_id=357491
jpe suggests looking at the comment of tracker #1170272; use
tokenizer.c instead of tokenizer_pgen.c (this is mentioned
in bug #1166714).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186345&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1166714 ] [ast branch] fatal error when compiling test_bool.py
Bugs item #1166714, was opened at 2005-03-19 16:14 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470 Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Brett Cannon (bcannon) Summary: [ast branch] fatal error when compiling test_bool.py Initial Comment: When using the ast-branch compiler, python exits with a fatal error when compiling test_bool.py or the symplified test case that I'll attach. The immediate problem is that when the compiler is in make_closure after compiling the lambda, self is found to be a LOCAL reference type and make_closure assumes it's a FREE reference if it's not a CELL reference in the enclosing scope. I don't know if self is supposed to be a LOCAL reference or if make_closure should handle LOCAL references. -- >Comment By: Brett Cannon (bcannon) Date: 2005-04-24 19:28 Message: Logged In: YES user_id=357491 OK, added a comment in bug #1186345 to this fact. -- Comment By: John Ehresman (jpe) Date: 2005-04-24 18:18 Message: Logged In: YES user_id=22785 Yes, it should be PyDict_Update(free, newfree) like it is in the current CVS. The unicode failures should be fixed by compiling and using tokenizer.c rather than tokenizer_pgen.c, which is mentioned in the comment for patch 1170272 but didn't get changed when the patch was applied. I'm pretty sure tokenizer_pgen.c is not needed. -- Comment By: Brett Cannon (bcannon) Date: 2005-04-18 22:26 Message: Logged In: YES user_id=357491 John, on line 45 of the patch, which becomes line 580 in Python/symtable.c, you call PyDict_Update() with three arguments. Is 'local' supposed to be an argument, or is 'free' the erroneous one? If I change it so that 'local' is removed then the tests die on test_unicode (although a ton of other tests fail). -- Comment By: John Ehresman (jpe) Date: 2005-03-22 17:22 Message: Logged In: YES user_id=22785 Forgot to add the patch -- Comment By: John Ehresman (jpe) Date: 2005-03-22 17:21 Message: Logged In: YES user_id=22785 The attached patch seems to fix this by creating a dictionary for each scope's free vars and only propagating up the ones that aren't satisfied by a binding. With this and the other patches, the test suite runs w/o segfaulting up through test_unicode. -- Comment By: John Ehresman (jpe) Date: 2005-03-22 13:37 Message: Logged In: YES user_id=22785 The issue seems to be that in symtable_analyze, a free dictionary is created for the entire module and if a name is found to be free in any function, it is not converted from a LOCAL to a CELL is any context seen afterwards. I think the free variables need to be recorded on a function-by-function basis. -- Comment By: Brett Cannon (bcannon) Date: 2005-03-22 12:34 Message: Logged In: YES user_id=357491 An short example of the failure:: def outer(a): def first(): a def last(a): pass This leads to a fatal Python error. The issue is having a being a local or parameter (can make 'a' be 'a = 1' and not a parameter and still have it fail), the first closure reference it, and then the second one use it as a parameter. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1186345 ] [AST] assert failure on ``eval("u'\Ufffffffe'")``
Bugs item #1186345, was opened at 2005-04-19 23:24
Message generated for change (Comment added) made by jpe
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186345&group_id=5470
Category: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: [AST] assert failure on ``eval("u'\Ufffe'")``
Initial Comment:
Isolated the failure of test_unicode to be because of
the test of ``eval("u'\Ufffe'")``. What is odd is
that the Unicode string works fine as a literal at the
intepreter prompt. Somehow eval() is triggering this
problem.
--
Comment By: John Ehresman (jpe)
Date: 2005-04-25 02:35
Message:
Logged In: YES
user_id=22785
Also look at patch 1189210, which probably should have just
been attached to this bug.
--
Comment By: Brett Cannon (bcannon)
Date: 2005-04-25 02:27
Message:
Logged In: YES
user_id=357491
jpe suggests looking at the comment of tracker #1170272; use
tokenizer.c instead of tokenizer_pgen.c (this is mentioned
in bug #1166714).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186345&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1189248 ] Seg Fault when compiling small program
Bugs item #1189248, was opened at 2005-04-24 22:00 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=1189248&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Reginald B. Charney (rcharney) Assigned to: Nobody/Anonymous (nobody) Summary: Seg Fault when compiling small program Initial Comment: I am using SuSE 9.2. When trying to compile/interpret the attached file, the python interpreter seg faults with no other information. Please note: the attached test file does not end in a new line. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1189248&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1189248 ] Seg Fault when compiling small program
Bugs item #1189248, was opened at 2005-04-24 22:00 Message generated for change (Comment added) made by rcharney You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1189248&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Reginald B. Charney (rcharney) Assigned to: Nobody/Anonymous (nobody) Summary: Seg Fault when compiling small program Initial Comment: I am using SuSE 9.2. When trying to compile/interpret the attached file, the python interpreter seg faults with no other information. Please note: the attached test file does not end in a new line. -- >Comment By: Reginald B. Charney (rcharney) Date: 2005-04-24 23:42 Message: Logged In: YES user_id=411372 It turns out that the seg fault was caused by the first line of the program: # coding: evil It seems that specifying an invalid character encoding causes a seg fault. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1189248&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
