[ python-Bugs-1513646 ] os.access reports incorrect write permissions in Windows
Bugs item #1513646, was opened at 2006-06-27 15:01
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513646&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: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Yi S. Ding (yi_ding)
Assigned to: Martin v. Löwis (loewis)
Summary: os.access reports incorrect write permissions in Windows
Initial Comment:
Platform: Python 2.5b1 Windows XP
Bug:
os.access will report that a user doesn't have write
permissions to a file or directory when the user
actually does.
Reproducibility: always
This is being run on an administrator account.
>>> import os
>>> os.access("C:\\", os.W_OK)
False
>>> os.access("C:\\test.txt", os.W_OK)
False
I have also checked that Python can indeed write to the
file.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-30 00:12
Message:
Logged In: YES
user_id=33168
Your change looks correct, but I would really like a test
case to fix this problem. I don't have access to a Windows
box, so I can't verify the test fails before this patch and
succeeds with it. Can you create a test case too? The best
place to add the test would be Lib/test/test_posix.py. Thanks!
--
Comment By: Yi S. Ding (yi_ding)
Date: 2006-06-29 12:56
Message:
Logged In: YES
user_id=1081617
Yeah, it's only 2.5, and only 2.5b1. Basically, there's a
double ampersand used instead of a single ampersand in
posixmodule.c. I've attached the patch.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-27 22:28
Message:
Logged In: YES
user_id=33168
Does this problem only occur with 2.5 or is it also present
in 2.4?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513646&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202533 ] a bunch of infinite C recursions
Bugs item #1202533, was opened at 2005-05-15 23:43
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Armin Rigo (arigo)
Assigned to: Armin Rigo (arigo)
Summary: a bunch of infinite C recursions
Initial Comment:
There is a general way to cause unchecked infinite recursion at the C level,
and I have no clue at the moment how it could be reasonably fixed. The idea is
to define special __xxx__ methods in such a way that no Python code is actually
called before they invoke more special methods (e.g. themselves).
>>> class A: pass
>>> A.__mul__=new.instancemethod(operator.mul,None,A)
>>> A()*2
Segmentation fault
--
>Comment By: Armin Rigo (arigo)
Date: 2006-06-30 07:14
Message:
Logged In: YES
user_id=4771
Looks quite obscure, a hack to avoid the bad effects of the
previous hack of temporarily decreasing the recursion depth
(which no other piece of code does). I'd be much more
confident that I'm looking at correct code if we used a more
explicit approach. What about a prebuilt RuntimeError
instance with the message "maximum recursion depth
exceeded", similar to the prebuilt MemoryError instance?
Then at least PyObject_Call() could raise this instance
directly, with PyErr_SetObject(). We'd get an
already-normalized exception in this way, and remove any
need for tstate recursion_depth mangling.
--
Comment By: Brett Cannon (bcannon)
Date: 2006-06-26 19:31
Message:
Logged In: YES
user_id=357491
Yes, Armin, that is a rather evil piece of code. =) But I
have a possible simple solution. =)
If you add a check after the PyExceptionClass_Check() in the
'if' statement that tstate->recursion_depth is greater than
0, you short-circuit the infinite recursion and still get a
sensible output.
I have attached a patch with my proposed changes for
PyObject_Call() and PyErr_NormalizeException() and the
remove of the recursion check for slot_tp_call(). The only
issue I can see with this is if the recursion_depth check
turns out to be too small of a number. But I really doubt
that will be an issue since one shouldn't be having a depth
of tracebacks greater than the current recursion depth.
Let me know what you think of the patch.
--
Comment By: Armin Rigo (arigo)
Date: 2006-06-25 09:33
Message:
Logged In: YES
user_id=4771
Yes, it seems reasonable. You should probably manipulate
tstate->recursion_depth directly instead of via the
macros, as e.g. ceval.c does.
This would fix most crashes here. It would make the attached
test17.py segfault, though. This test17 already segfaults a
debug build of Python, but not a release build because the
recursive PyErr_NormalizeException() is turned into a tail
call by gcc. (What, a convoluted mind, mine?)
--
Comment By: Brett Cannon (bcannon)
Date: 2006-06-23 21:54
Message:
Logged In: YES
user_id=357491
I just had an idea, Armin. What if, at the recursive call
site in PyErr_NormalizeException(), we called
Py_LeaveRecursiveCall() before and Py_EnterRecursiveCall()
after? That would keep the recursion limit the same when
the normalization was done, but still allow the check in
PyObject_Call()::
Py_LeaveRecursiveCall();
PyErr_NormalizeException(exc, val, tb);
Py_EnterRecursiveCall("");
Since it is an internal call I think it would be safe to
"play" with the recursion depth value like this. What do
you think?
--
Comment By: Brett Cannon (bcannon)
Date: 2006-06-23 20:57
Message:
Logged In: YES
user_id=357491
The rev. that Armin checked in was actually r47061.
--
Comment By: Brett Cannon (bcannon)
Date: 2006-06-23 20:53
Message:
Logged In: YES
user_id=357491
I thought the check was in slot_tp_call and not
PyObject_Call. So yeah, I basically forgot. =)
The problem with allowing the segfault to stay is that it
destroys security in terms of protecting the interpreter,
which I am trying to deal with. So leaving random ways to
crash the interpreter is currently a no-no for me. I will
see if I can come up with another way to fix this issue.
--
Comment By: Armin Rigo (arigo)
Date: 2006-06-23 20:05
Message:
Logged In: YES
user_id=4771
I'd have answer "good idea, go ahead", if it were not for
what I fo
[ python-Bugs-1483133 ] gen_iternext: Assertion `f->f_back != ((void *)0)' failed
Bugs item #1483133, was opened at 2006-05-06 14:09 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483133&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: svensoho (svensoho) Assigned to: Phillip J. Eby (pje) Summary: gen_iternext: Assertion `f->f_back != ((void *)0)' failed Initial Comment: Seems to be similar bug as http://sourceforge.net/ tracker/index.php? func=detail&aid=1257960&group_id=5470&atid=105470 (fixed) Couldn't trigger with same script but with C application. Same source modification helps (at Objects/genobject.c:53) -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-30 00:14 Message: Logged In: YES user_id=33168 Does this affect 2.5 or only 2.4? There were a fair amount of generator changes in 2.5. -- Comment By: svensoho (svensoho) Date: 2006-05-26 07:42 Message: Logged In: YES user_id=1518209 This bug is blocking development of PostgreSQL Python based stored procedure language -- PL/Python. See http://archives.postgresql.org/pgsql-patches/2006-04/msg 00265.php -- Comment By: svensoho (svensoho) Date: 2006-05-15 01:26 Message: Logged In: YES user_id=1518209 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483133&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1483133 ] gen_iternext: Assertion `f->f_back != ((void *)0)' failed
Bugs item #1483133, was opened at 2006-05-07 00:09 Message generated for change (Comment added) made by svensoho You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483133&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: svensoho (svensoho) Assigned to: Phillip J. Eby (pje) Summary: gen_iternext: Assertion `f->f_back != ((void *)0)' failed Initial Comment: Seems to be similar bug as http://sourceforge.net/ tracker/index.php? func=detail&aid=1257960&group_id=5470&atid=105470 (fixed) Couldn't trigger with same script but with C application. Same source modification helps (at Objects/genobject.c:53) -- >Comment By: svensoho (svensoho) Date: 2006-06-30 10:35 Message: Logged In: YES user_id=1518209 2.5 is already fixed: http://sourceforge.net/tracker/ index.php?func=detail&aid=1257960&group_id=5470&atid=105470 2.4 has exactly same problematic assertion, even same modification helps. Fedora has fixed it in their distribution: https://bugzilla.redhat.com/bugzilla/ show_bug.cgi?id=192592 -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-30 10:14 Message: Logged In: YES user_id=33168 Does this affect 2.5 or only 2.4? There were a fair amount of generator changes in 2.5. -- Comment By: svensoho (svensoho) Date: 2006-05-26 17:42 Message: Logged In: YES user_id=1518209 This bug is blocking development of PostgreSQL Python based stored procedure language -- PL/Python. See http://archives.postgresql.org/pgsql-patches/2006-04/msg 00265.php -- Comment By: svensoho (svensoho) Date: 2006-05-15 11:26 Message: Logged In: YES user_id=1518209 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483133&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1515142 ] sgmllib should recover from unmatched quotes
Bugs item #1515142, was opened at 2006-06-30 09:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515142&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Sam Ruby (rubys) Assigned to: Nobody/Anonymous (nobody) Summary: sgmllib should recover from unmatched quotes Initial Comment: The good news is that previous fixes enable some of the previously disabled tests to be The one regression I have noticed is that sgmllib no longer recovers gracefully from broken start tags. This patch restores the prior behavior when faced with such constructs. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515142&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1515163 ] traceback now masks some string exceptions
Bugs item #1515163, was opened at 2006-06-30 10:34
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=1515163&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: traceback now masks some string exceptions
Initial Comment:
With 2.5, exceptions became new-style. Unfortunately,
the traceback module wasn't fully updated to still
properly handle all (admittedly deprecated) string
exceptions. I noticed this because of its affect on
unittest, where the original exception was masked.
Under 2.4.3:
>>> import traceback
>>> traceback.format_exception_only("strtype",
"strvalue")
['strtype: strvalue\n']
Under 2.5b1:
>>> import traceback
>>> traceback.format_exception_only("strtype",
"strvalue")
Traceback (most recent call last):
File "", line 1, in
traceback.format_exception_only("strtype",
"strvalue")
File "C:\Python25\lib\traceback.py", line 168, in
format_exception_only
if issubclass(etype, SyntaxError):
TypeError: issubclass() arg 1 must be a class
I will also be entering a patch, but know that we need
a bug number at this stage.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515163&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1515164 ] version says beta
Bugs item #1515164, was opened at 2006-06-30 10:36 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=1515164&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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: version says beta Initial Comment: The IDLE version in 2.5b1 has been updated to IDLE 1.2b1 It should be a non-beta number by the time of release, to avoid problems like we recently had with the logging module, where is seems less stable than it is. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515164&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1515169 ] ImportWarning should be removed
Bugs item #1515169, was opened at 2006-06-30 10:42 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=1515169&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: James Y Knight (foom) Assigned to: Nobody/Anonymous (nobody) Summary: ImportWarning should be removed Initial Comment: As discussed in email thread: http://www.gossamer-threads.com/lists/python/dev/497487 In particular, there are three specific reasons for not having it. I expect these reasons to translate to a larger number of specific reasons as more people use python 2.5. 1) Ralf's software gets a flood of ImportWarnings 2) Twisted's plugin system uses a directory named "twisted" without an __init__.py in it on the python path to store plugins in. Therefore, anybody running (importing) twisted will produce annoying warnings. 3) I have a directory in my homedir called "readline". Quoted from my email: I just found another reason to dislike the warnings: my homedir on one machine has a lot of random directories in it. One of them is named "readline". Every time I run python 2.5, it now helpfully notes: sys:1: ImportWarning: Not importing directory 'readline': missing __init__.py It used to be the case that it was very unlikely that running python in your homedir would cause issues. Even though the current directory is on the default pythonpath, you needed to have either a file ending in .py or a directory with an __init__.py with the same name as a python module to cause problems. And that is generally unlikely to happen. Now, however, you get warnings just by having _any_ directory in your CWD with the same name as a python module. That's much more likely to happen; I can't be the only one who will have this issue. Suggested solution: Remove ImportWarning, and make the ImportError message say: >> ImportError: No module named mypackage.foo >> Note that subdirectories are searched for imports only if they contain an >> __init__.py file: http://www.python.org/doc/essays/packages.html I really think this should be addressed before 2.5 is released. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515169&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1501934 ] incorrect LOAD/STORE_GLOBAL generation
Bugs item #1501934, was opened at 2006-06-06 23:57
Message generated for change (Comment added) made by nascheme
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501934&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.5
Status: Open
Resolution: None
Priority: 8
Submitted By: Thomas Wouters (twouters)
Assigned to: Jeremy Hylton (jhylton)
Summary: incorrect LOAD/STORE_GLOBAL generation
Initial Comment:
Python 2.5 compiles the following piece of code
differently than Python 2.4:
g = 1
def f():
g += 1
In Python 2.4, this raises an UnboundLocalError. In
current svn trunk, it will increment the global g by 1.
(dis.dis shows that it actually compiles into
LOAD/STORE_GLOBAL opcodes.) It seems the compiler
doesn't treat augmented assignment as assignment for
the purpose of determining locals, as this still fails
correctly:
g = 1
def f():
g += 1
g = 5
I can't find where this optimization happens nowadays,
but it feels like a short fix.
--
>Comment By: Neil Schemenauer (nascheme)
Date: 2006-06-30 16:22
Message:
Logged In: YES
user_id=35752
Here are some notes in case I wear out before finding a fix.
analyze_name() gets to the SET_SCOPE(dict, name,
GLOBAL_IMPLICIT) line because the name does not have the
DEF_LOCAL flag set as it should. It does not have DEF_LOCAL
because Name.ctx for 'g' is Load. I believe there should be
a set_context() call in ast_for_expr_stmt, as flagged as
TODO by Jeremy. Maybe set_context(..., Store, ...) would
work or maybe things need to be changed to allow ctx to have
AugAssign as a value.
--
Comment By: Thomas Wouters (twouters)
Date: 2006-06-19 17:44
Message:
Logged In: YES
user_id=34209
Possibly related is the discovery of free variables (used
when forming closures) and optimized-out codeblocks:
>>> def foo(x):
... def bar():
... if 0:
... print x
... return bar
In 2.4, there is no closure:
>>> foo.func_code.co_cellvars
()
>>> foo(5).func_closure
>>>
In 2.5, there is:
>>> foo.func_code.co_cellvars
('x',)
>>> foo(5).func_closure
(,)
(I don't think it's unreasonable to declare the old
behaviour bugged, though :-)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501934&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1515164 ] version says beta
Bugs item #1515164, was opened at 2006-06-30 16:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515164&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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: version says beta Initial Comment: The IDLE version in 2.5b1 has been updated to IDLE 1.2b1 It should be a non-beta number by the time of release, to avoid problems like we recently had with the logging module, where is seems less stable than it is. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-06-30 18:48 Message: Logged In: YES user_id=21627 What is the bug you are reporting? idlever.py is always changed in lockstep with the Python release version. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515164&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1510172 ] Absolute/relative import not working?
Bugs item #1510172, was opened at 2006-06-22 05:35 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Mitch Chapman (mitchchapman) Assigned to: Nick Coghlan (ncoghlan) Summary: Absolute/relative import not working? Initial Comment: Trying to import from a module using dotted import syntax produces this exception: ValueError: Relative importpath too deep This behavior has been confirmed on Mac OS X 10.4 using the Python 2.5b1 disk image; and on CentOS 4 using the Python 2.5b1 source tarball. The exception is raised regardless of whether the PYTHONPATH environment variable can see the toplevel directory of the package being tested; regardless of whether the import is performed from an interactive Python session or from a script invoked from the command line; and regardless of whether the main script starts with from __future__ import absolute_import To test, I tried to re-create the package structure used as an example in PEP 328. (See attachments.) Most of the files were empty, except moduleX.py and moduleY.py: #moduleX.py: from __future__ import absolute_import from .moduleY import spam #moduleY.py: spam = "spam" According to the PEP, if should be possible to import moduleX without error. But I get the above exception whenever I try to import moduleX or to run it from the command line. $ python2.5 moduleX.py Traceback (most recent call last): File "moduleX.py", line 3, in from .moduleY import spam ValueError: Relative importpath too deep Is this a usage/documentation error? -- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-01 02:51 Message: Logged In: YES user_id=1038590 Patch attached that allows relative imports from a main module to work so long as: a. the top level package is either in the current directory or somewhere else on sys.path; and b. the module is executed using -m so Python knows where it fits in the package hierarchy So to get the PEP 328 example to work, you'd have to run it as: $python2.5 -m package.subpackage1.moduleX The patch relies on a feature added to runpy in rev 47142 (post beta 1). I've added a question to PEP 356 as to how this should be handled, since we're technically in feature freeze. Patch attached directly to the bug report because it's stupidly early in the morning and I don't feel like dealing with SF and then copying the patch tracker number here :) -- Comment By: Nick Coghlan (ncoghlan) Date: 2006-06-27 21:46 Message: Logged In: YES user_id=1038590 All that said, PEP 328 currently says that "from ...sys import path" should be legal from moduleX in the example. I tried it, and it currently fails - the ValueError gets raised as soon as the number of dots in the relative path exceeds the number of dots in __name__, instead of treating a single excess dot as requesting an absolute import instead. (All of the other examples in the PEP work as specified when moduleX and subpackage1 are imported rather than executed directly) I believe fixing this would also fix Mitch's problem - an explicit relative import from __main__ would be treated as a top level import. I also have an idea regarding the -m switch that I will raise on python-dev. -- Comment By: Nick Coghlan (ncoghlan) Date: 2006-06-27 21:34 Message: Logged In: YES user_id=1038590 The issue isn't actually unique to the -m switch - the problem is that relative imports are based on __name__, and in the main module, __name__ always has the value '__main__'. Hence, relative imports currently can't work properly from the main module of an application, because the main module doesn't know where it really fits in the Python module namespace (this is at least fixable in theory for the main modules executed through the -m switch, but directly executed files and the interactive interpreter are completely out of luck). With the old implicit relative imports this behaviour is masked by the fact that executing a module puts that module's directory on sys.path. When you execute a module in a package directly, it actually imports its sibling modules as top-level modules. The fact that the -m switch doesn't allow this to occur is a deliberate design decision (putting package directories on the system level path is a bad idea because you can get multiple copies of the same module under different names). You should be able get something similar to the old implicit relative import b
[ python-Bugs-1202533 ] a bunch of infinite C recursions
Bugs item #1202533, was opened at 2005-05-15 16:43
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Armin Rigo (arigo)
>Assigned to: Brett Cannon (bcannon)
Summary: a bunch of infinite C recursions
Initial Comment:
There is a general way to cause unchecked infinite recursion at the C level,
and I have no clue at the moment how it could be reasonably fixed. The idea is
to define special __xxx__ methods in such a way that no Python code is actually
called before they invoke more special methods (e.g. themselves).
>>> class A: pass
>>> A.__mul__=new.instancemethod(operator.mul,None,A)
>>> A()*2
Segmentation fault
--
>Comment By: Brett Cannon (bcannon)
Date: 2006-06-30 10:06
Message:
Logged In: YES
user_id=357491
Seems reasonable to me. I will try to cook up a patch after
I am done trying to fix the xml_parsers.py crasher.
--
Comment By: Armin Rigo (arigo)
Date: 2006-06-30 00:14
Message:
Logged In: YES
user_id=4771
Looks quite obscure, a hack to avoid the bad effects of the
previous hack of temporarily decreasing the recursion depth
(which no other piece of code does). I'd be much more
confident that I'm looking at correct code if we used a more
explicit approach. What about a prebuilt RuntimeError
instance with the message "maximum recursion depth
exceeded", similar to the prebuilt MemoryError instance?
Then at least PyObject_Call() could raise this instance
directly, with PyErr_SetObject(). We'd get an
already-normalized exception in this way, and remove any
need for tstate recursion_depth mangling.
--
Comment By: Brett Cannon (bcannon)
Date: 2006-06-26 12:31
Message:
Logged In: YES
user_id=357491
Yes, Armin, that is a rather evil piece of code. =) But I
have a possible simple solution. =)
If you add a check after the PyExceptionClass_Check() in the
'if' statement that tstate->recursion_depth is greater than
0, you short-circuit the infinite recursion and still get a
sensible output.
I have attached a patch with my proposed changes for
PyObject_Call() and PyErr_NormalizeException() and the
remove of the recursion check for slot_tp_call(). The only
issue I can see with this is if the recursion_depth check
turns out to be too small of a number. But I really doubt
that will be an issue since one shouldn't be having a depth
of tracebacks greater than the current recursion depth.
Let me know what you think of the patch.
--
Comment By: Armin Rigo (arigo)
Date: 2006-06-25 02:33
Message:
Logged In: YES
user_id=4771
Yes, it seems reasonable. You should probably manipulate
tstate->recursion_depth directly instead of via the
macros, as e.g. ceval.c does.
This would fix most crashes here. It would make the attached
test17.py segfault, though. This test17 already segfaults a
debug build of Python, but not a release build because the
recursive PyErr_NormalizeException() is turned into a tail
call by gcc. (What, a convoluted mind, mine?)
--
Comment By: Brett Cannon (bcannon)
Date: 2006-06-23 14:54
Message:
Logged In: YES
user_id=357491
I just had an idea, Armin. What if, at the recursive call
site in PyErr_NormalizeException(), we called
Py_LeaveRecursiveCall() before and Py_EnterRecursiveCall()
after? That would keep the recursion limit the same when
the normalization was done, but still allow the check in
PyObject_Call()::
Py_LeaveRecursiveCall();
PyErr_NormalizeException(exc, val, tb);
Py_EnterRecursiveCall("");
Since it is an internal call I think it would be safe to
"play" with the recursion depth value like this. What do
you think?
--
Comment By: Brett Cannon (bcannon)
Date: 2006-06-23 13:57
Message:
Logged In: YES
user_id=357491
The rev. that Armin checked in was actually r47061.
--
Comment By: Brett Cannon (bcannon)
Date: 2006-06-23 13:53
Message:
Logged In: YES
user_id=357491
I thought the check was in slot_tp_call and not
PyObject_Call. So yeah, I basically forgot. =)
The problem with allowing the segfault to stay is that it
destroys security in terms of protecting the interpreter,
which I am trying to deal with. So leaving random ways to
crash the interpreter is currently a no-no for me. I wil
[ python-Bugs-1501934 ] incorrect LOAD/STORE_GLOBAL generation
Bugs item #1501934, was opened at 2006-06-06 23:57
Message generated for change (Comment added) made by nascheme
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501934&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.5
Status: Open
Resolution: None
Priority: 8
Submitted By: Thomas Wouters (twouters)
Assigned to: Jeremy Hylton (jhylton)
Summary: incorrect LOAD/STORE_GLOBAL generation
Initial Comment:
Python 2.5 compiles the following piece of code
differently than Python 2.4:
g = 1
def f():
g += 1
In Python 2.4, this raises an UnboundLocalError. In
current svn trunk, it will increment the global g by 1.
(dis.dis shows that it actually compiles into
LOAD/STORE_GLOBAL opcodes.) It seems the compiler
doesn't treat augmented assignment as assignment for
the purpose of determining locals, as this still fails
correctly:
g = 1
def f():
g += 1
g = 5
I can't find where this optimization happens nowadays,
but it feels like a short fix.
--
>Comment By: Neil Schemenauer (nascheme)
Date: 2006-06-30 17:51
Message:
Logged In: YES
user_id=35752
I've got a simple fix that seems to work. I feel this part
of the compiler could use some more serious cleanups but
probably not for 2.5. Note that test_ast fails after
applying my patch. I haven't had time to look into that yet
but I think it's shallow.
--
Comment By: Neil Schemenauer (nascheme)
Date: 2006-06-30 16:22
Message:
Logged In: YES
user_id=35752
Here are some notes in case I wear out before finding a fix.
analyze_name() gets to the SET_SCOPE(dict, name,
GLOBAL_IMPLICIT) line because the name does not have the
DEF_LOCAL flag set as it should. It does not have DEF_LOCAL
because Name.ctx for 'g' is Load. I believe there should be
a set_context() call in ast_for_expr_stmt, as flagged as
TODO by Jeremy. Maybe set_context(..., Store, ...) would
work or maybe things need to be changed to allow ctx to have
AugAssign as a value.
--
Comment By: Thomas Wouters (twouters)
Date: 2006-06-19 17:44
Message:
Logged In: YES
user_id=34209
Possibly related is the discovery of free variables (used
when forming closures) and optimized-out codeblocks:
>>> def foo(x):
... def bar():
... if 0:
... print x
... return bar
In 2.4, there is no closure:
>>> foo.func_code.co_cellvars
()
>>> foo(5).func_closure
>>>
In 2.5, there is:
>>> foo.func_code.co_cellvars
('x',)
>>> foo(5).func_closure
(,)
(I don't think it's unreasonable to declare the old
behaviour bugged, though :-)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501934&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1296433 ] expat crash python
Bugs item #1296433, was opened at 2005-09-20 07:10
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296433&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: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Mike Rozhnov (rozhnov)
>Assigned to: Brett Cannon (bcannon)
Summary: expat crash python
Initial Comment:
This simple script crash python.
Parsing of commented xml string work good.
(i.e. raised exception not crash python)
Buffer overflow during convertion to unicode?
Tested on Win XP and linux with kernel 2.4 with same
results.
--
>Comment By: Brett Cannon (bcannon)
Date: 2006-06-30 11:06
Message:
Logged In: YES
user_id=357491
The fault is with Expat and not us. I have submitted a bug
report with a possible patch at
http://sourceforge.net/tracker/index.php?func=detail&aid=1515266&group_id=10127&atid=110127
. I don't know what their turn-around time will be with
this so I will email python-dev to see how long people want
to wait on the Expat developers before we just push our own
patch for this.
--
Comment By: Brett Cannon (bcannon)
Date: 2006-06-29 18:33
Message:
Logged In: YES
user_id=357491
Still seems to be failing even with the Expat 2.0 upgrade in
HEAD.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-12 12:53
Message:
Logged In: YES
user_id=33168
I had recently upgraded to expat 1.95.8, so I was hopeful.
But it still crashed for me on linux.
I did get a better stack trace which allowed me to come up
with a patch that solves the problem and passes all the
tests. The patch seems a bit odd and I think there might be
another problem going on here. It would be great if someone
more familiar with xmlparse could take a look at the patch
and figure out if it's right or not.
--
Comment By: Fredrik Lundh (effbot)
Date: 2005-11-12 03:05
Message:
Logged In: YES
user_id=38376
Works for me under 2.3.2 (with expat 1.95.6) and 2.4.1 (with
expat 1.95.8).
Try upgrading your expat and see if the problem goes away.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-22 14:54
Message:
Logged In: YES
user_id=33168
I can reproduce on Linux with current CVS and expat
1.95.5-2. Note the size of the data only needs to be
greater than 1024.
xml = "%s" %
('a' * 1025)
I am not certain this problem is specific to Python. It
might be down in expat only. Need to investigate further.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296433&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1501934 ] incorrect LOAD/STORE_GLOBAL generation
Bugs item #1501934, was opened at 2006-06-06 23:57
Message generated for change (Comment added) made by nascheme
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501934&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.5
Status: Open
Resolution: None
Priority: 8
Submitted By: Thomas Wouters (twouters)
Assigned to: Jeremy Hylton (jhylton)
Summary: incorrect LOAD/STORE_GLOBAL generation
Initial Comment:
Python 2.5 compiles the following piece of code
differently than Python 2.4:
g = 1
def f():
g += 1
In Python 2.4, this raises an UnboundLocalError. In
current svn trunk, it will increment the global g by 1.
(dis.dis shows that it actually compiles into
LOAD/STORE_GLOBAL opcodes.) It seems the compiler
doesn't treat augmented assignment as assignment for
the purpose of determining locals, as this still fails
correctly:
g = 1
def f():
g += 1
g = 5
I can't find where this optimization happens nowadays,
but it feels like a short fix.
--
>Comment By: Neil Schemenauer (nascheme)
Date: 2006-06-30 22:03
Message:
Logged In: YES
user_id=35752
Adding a patch to "fix" test_ast.py. I have no idea what
the test is trying to verify. It looks like it was written
by martin.v.loewis so maybe he can comment.
--
Comment By: Neil Schemenauer (nascheme)
Date: 2006-06-30 17:51
Message:
Logged In: YES
user_id=35752
I've got a simple fix that seems to work. I feel this part
of the compiler could use some more serious cleanups but
probably not for 2.5. Note that test_ast fails after
applying my patch. I haven't had time to look into that yet
but I think it's shallow.
--
Comment By: Neil Schemenauer (nascheme)
Date: 2006-06-30 16:22
Message:
Logged In: YES
user_id=35752
Here are some notes in case I wear out before finding a fix.
analyze_name() gets to the SET_SCOPE(dict, name,
GLOBAL_IMPLICIT) line because the name does not have the
DEF_LOCAL flag set as it should. It does not have DEF_LOCAL
because Name.ctx for 'g' is Load. I believe there should be
a set_context() call in ast_for_expr_stmt, as flagged as
TODO by Jeremy. Maybe set_context(..., Store, ...) would
work or maybe things need to be changed to allow ctx to have
AugAssign as a value.
--
Comment By: Thomas Wouters (twouters)
Date: 2006-06-19 17:44
Message:
Logged In: YES
user_id=34209
Possibly related is the discovery of free variables (used
when forming closures) and optimized-out codeblocks:
>>> def foo(x):
... def bar():
... if 0:
... print x
... return bar
In 2.4, there is no closure:
>>> foo.func_code.co_cellvars
()
>>> foo(5).func_closure
>>>
In 2.5, there is:
>>> foo.func_code.co_cellvars
('x',)
>>> foo(5).func_closure
(,)
(I don't think it's unreasonable to declare the old
behaviour bugged, though :-)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501934&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1513646 ] os.access reports incorrect write permissions in Windows
Bugs item #1513646, was opened at 2006-06-27 15:01
Message generated for change (Comment added) made by yi_ding
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513646&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: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Yi S. Ding (yi_ding)
Assigned to: Martin v. Löwis (loewis)
Summary: os.access reports incorrect write permissions in Windows
Initial Comment:
Platform: Python 2.5b1 Windows XP
Bug:
os.access will report that a user doesn't have write
permissions to a file or directory when the user
actually does.
Reproducibility: always
This is being run on an administrator account.
>>> import os
>>> os.access("C:\\", os.W_OK)
False
>>> os.access("C:\\test.txt", os.W_OK)
False
I have also checked that Python can indeed write to the
file.
--
>Comment By: Yi S. Ding (yi_ding)
Date: 2006-06-30 16:12
Message:
Logged In: YES
user_id=1081617
Cool. I added the new patch with the test case.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-30 00:12
Message:
Logged In: YES
user_id=33168
Your change looks correct, but I would really like a test
case to fix this problem. I don't have access to a Windows
box, so I can't verify the test fails before this patch and
succeeds with it. Can you create a test case too? The best
place to add the test would be Lib/test/test_posix.py. Thanks!
--
Comment By: Yi S. Ding (yi_ding)
Date: 2006-06-29 12:56
Message:
Logged In: YES
user_id=1081617
Yeah, it's only 2.5, and only 2.5b1. Basically, there's a
double ampersand used instead of a single ampersand in
posixmodule.c. I've attached the patch.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-06-27 22:28
Message:
Logged In: YES
user_id=33168
Does this problem only occur with 2.5 or is it also present
in 2.4?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513646&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202533 ] a bunch of infinite C recursions
Bugs item #1202533, was opened at 2005-05-15 16:43
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: Armin Rigo (arigo)
>Assigned to: Armin Rigo (arigo)
Summary: a bunch of infinite C recursions
Initial Comment:
There is a general way to cause unchecked infinite recursion at the C level,
and I have no clue at the moment how it could be reasonably fixed. The idea is
to define special __xxx__ methods in such a way that no Python code is actually
called before they invoke more special methods (e.g. themselves).
>>> class A: pass
>>> A.__mul__=new.instancemethod(operator.mul,None,A)
>>> A()*2
Segmentation fault
--
>Comment By: Brett Cannon (bcannon)
Date: 2006-06-30 17:46
Message:
Logged In: YES
user_id=357491
OK, new patch, with the check in PyObject_Call() (and thus
slot_tp_call() recursion check removed), the addition of
PyExc_RecursionErrorInst which is an instance of
RuntimeError and a reasonable message set, and
PyErr_NormalizeException() checking the recursion depth
directly and using PyExc_RecursionErrorInst when the limit
is hit.
Hopefully this does it. =)
--
Comment By: Brett Cannon (bcannon)
Date: 2006-06-30 10:06
Message:
Logged In: YES
user_id=357491
Seems reasonable to me. I will try to cook up a patch after
I am done trying to fix the xml_parsers.py crasher.
--
Comment By: Armin Rigo (arigo)
Date: 2006-06-30 00:14
Message:
Logged In: YES
user_id=4771
Looks quite obscure, a hack to avoid the bad effects of the
previous hack of temporarily decreasing the recursion depth
(which no other piece of code does). I'd be much more
confident that I'm looking at correct code if we used a more
explicit approach. What about a prebuilt RuntimeError
instance with the message "maximum recursion depth
exceeded", similar to the prebuilt MemoryError instance?
Then at least PyObject_Call() could raise this instance
directly, with PyErr_SetObject(). We'd get an
already-normalized exception in this way, and remove any
need for tstate recursion_depth mangling.
--
Comment By: Brett Cannon (bcannon)
Date: 2006-06-26 12:31
Message:
Logged In: YES
user_id=357491
Yes, Armin, that is a rather evil piece of code. =) But I
have a possible simple solution. =)
If you add a check after the PyExceptionClass_Check() in the
'if' statement that tstate->recursion_depth is greater than
0, you short-circuit the infinite recursion and still get a
sensible output.
I have attached a patch with my proposed changes for
PyObject_Call() and PyErr_NormalizeException() and the
remove of the recursion check for slot_tp_call(). The only
issue I can see with this is if the recursion_depth check
turns out to be too small of a number. But I really doubt
that will be an issue since one shouldn't be having a depth
of tracebacks greater than the current recursion depth.
Let me know what you think of the patch.
--
Comment By: Armin Rigo (arigo)
Date: 2006-06-25 02:33
Message:
Logged In: YES
user_id=4771
Yes, it seems reasonable. You should probably manipulate
tstate->recursion_depth directly instead of via the
macros, as e.g. ceval.c does.
This would fix most crashes here. It would make the attached
test17.py segfault, though. This test17 already segfaults a
debug build of Python, but not a release build because the
recursive PyErr_NormalizeException() is turned into a tail
call by gcc. (What, a convoluted mind, mine?)
--
Comment By: Brett Cannon (bcannon)
Date: 2006-06-23 14:54
Message:
Logged In: YES
user_id=357491
I just had an idea, Armin. What if, at the recursive call
site in PyErr_NormalizeException(), we called
Py_LeaveRecursiveCall() before and Py_EnterRecursiveCall()
after? That would keep the recursion limit the same when
the normalization was done, but still allow the check in
PyObject_Call()::
Py_LeaveRecursiveCall();
PyErr_NormalizeException(exc, val, tb);
Py_EnterRecursiveCall("");
Since it is an internal call I think it would be safe to
"play" with the recursion depth value like this. What do
you think?
--
Comment By: Brett Cannon (bcannon)
Date: 2006-06-23 13:57
Message:
Logged In: YES
user_id=357491
The rev. that Armin ch
