[ python-Bugs-1747858 ] chown broken on 64bit
Bugs item #1747858, was opened at 2007-07-04 10:21
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=1747858&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
Private: No
Submitted By: Neal D. Becker (nbecker)
Assigned to: Nobody/Anonymous (nobody)
Summary: chown broken on 64bit
Initial Comment:
python-2.5 on fedora fc7 x86_64:
os.stat returns uid > 32bit:
os.stat ('shit')
(33204, 4420723, 64768L, 1, 4294967294, 500, 0, 1183558507, 1183558507,
1183558517)
os.chown doesn't like that:
os.chown ('shit', 4294967294, 4294967294)
Traceback (most recent call last):
File "", line 1, in
OverflowError: signed integer is greater than maximum
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1747858&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1747858 ] chown broken on 64bit
Bugs item #1747858, was opened at 2007-07-04 10:21
Message generated for change (Comment added) made by owsla
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1747858&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
Private: No
Submitted By: Neal D. Becker (nbecker)
Assigned to: Nobody/Anonymous (nobody)
Summary: chown broken on 64bit
Initial Comment:
python-2.5 on fedora fc7 x86_64:
os.stat returns uid > 32bit:
os.stat ('shit')
(33204, 4420723, 64768L, 1, 4294967294, 500, 0, 1183558507, 1183558507,
1183558517)
os.chown doesn't like that:
os.chown ('shit', 4294967294, 4294967294)
Traceback (most recent call last):
File "", line 1, in
OverflowError: signed integer is greater than maximum
--
Comment By: Andrew Ferguson (owsla)
Date: 2007-07-04 11:04
Message:
Logged In: YES
user_id=19094
Originator: NO
Indeed, in Modules/posixmodule.c::posix_chown(), the uid and gid variables
are defined as type 'int'. They should be of type 'uid_t' and 'gid_t' which
are mapped to 'unsigned int' on at least some Unix platforms (I haven't
checked extensively.)
The wrinkle here is that chown() needs to be able to handle the case of
uid/gid set to -1, which means to leave them as is. Therefore, os.chown(-1,
-1) is valid, but so is os.chown(4294967294, 4294967294).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1747858&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1748015 ] Module-level stack scopes have incorrect bindings.
Bugs item #1748015, was opened at 2007-07-04 19:53 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=1748015&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 Private: No Submitted By: Nefarious CodeMonkey, Jr. (nejucomo) Assigned to: Nobody/Anonymous (nobody) Summary: Module-level stack scopes have incorrect bindings. Initial Comment: For a variable defined in a module scope, and stack frame object's locals and globals scope dictionaries each contain that variables name mapped to None. This confuses python code which inspects the bindings, such as pdb. Such code incorrectly reports the value as None. It may be that the binding values are correct at the time of exception generation, but altered by the time the exception traceback is caught. This problem may also be related to module imports. Here's are two simple examples, the first does not trigger this problem, the second does. Both use this module called "buggy.py": # Begin buggy.py whatKnightsSay = 'Ni!' print 'We are the Knights who say: %r' % (whatKnightsSay,) 42 + whatKnightsSay # End buggy.py # Begin a non-failing example: $ pdb buggy.py > /home/n/sandbox/python-module-binding-bug-src/buggy.py(1)() -> whatKnightsSay = 'Ni!' (Pdb) print whatKnightsSay *** NameError: name 'whatKnightsSay' is not defined (Pdb) next > /home/n/sandbox/python-module-binding-bug-src/buggy.py(2)() -> print 'We are the Knights who say: %r' % (whatKnightsSay,) (Pdb) print whatKnightsSay Ni! (Pdb) next We are the Knights who say: 'Ni!' > /home/n/sandbox/python-module-binding-bug-src/buggy.py(3)() -> 42 + whatKnightsSay (Pdb) print whatKnightsSay Ni! (Pdb) next TypeError: "unsupported operand type(s) for +: 'int' and 'str'" > /home/n/sandbox/python-module-binding-bug-src/buggy.py(3)() -> 42 + whatKnightsSay (Pdb) print whatKnightsSay Ni! (Pdb) next --Return-- > /home/n/sandbox/python-module-binding-bug-src/buggy.py(3)()->None -> 42 + whatKnightsSay (Pdb) print whatKnightsSay Ni! (Pdb) next TypeError: "unsupported operand type(s) for +: 'int' and 'str'" > (1)()->None (Pdb) print whatKnightsSay Ni! # End succeeding example. And here's a simple failing example, which relies on a second module: # Begin triggerPdb.py import pdb pdb.set_trace() import buggy # End triggerPdb.py Now pdb get's confused about the module level binding: # Begin failure example: $ python triggerPdb.py > /home/n/sandbox/python-module-binding-bug-src/triggerPdb.py(3)() -> import buggy (Pdb) next We are the Knights who say: 'Ni!' TypeError: "unsupported operand type(s) for +: 'int' and 'str'" > /home/n/sandbox/python-module-binding-bug-src/triggerPdb.py(3)() -> import buggy (Pdb) down > /home/n/sandbox/python-module-binding-bug/buggy.py(3)() -> 42 + whatKnightsSay (Pdb) list 1 whatKnightsSay = 'Ni!' 2 print 'We are the Knights who say: %r' % (whatKnightsSay,) 3 -> 42 + whatKnightsSay [EOF] (Pdb) p whatKnightsSay None # End failing example. I've included these two simple sources, as well as another that does traceback inspection in an except clause (which fails like the second example here). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1748015&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1581906 ] test_sqlite fails on OSX G5 arch if test_ctypes is run
Bugs item #1581906, was opened at 2006-10-21 20:02
Message generated for change (Comment added) made by theller
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&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.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Skip Montanaro (montanaro)
Assigned to: Thomas Heller (theller)
Summary: test_sqlite fails on OSX G5 arch if test_ctypes is run
Initial Comment:
I noticed a test_sqlite test failure on my Mac G5 the other day while trying
to set up a buildbot for sqlalchemy. Everything runs fine on my G4
powerbook. Both machines run Mac OSX 10.4.8 with Apple's gcc 4.0.0,
build 5026.
I whittled the problem down to just having test_ctypes and test_sqlite
enabled, then further whittled it down to just having Lib/ctypes/test/
test_find.py available (all other ctypes tests eliminated). More detailed
problem descriptions are in these two postings to python-dev:
http://article.gmane.org/gmane.comp.python.devel/84478
http://article.gmane.org/gmane.comp.python.devel/84481
Skip
--
>Comment By: Thomas Heller (theller)
Date: 2007-07-04 22:01
Message:
Logged In: YES
user_id=11105
Originator: NO
Skip, thanks for the analysis and test patch.
IMO loading the GLUT library does not add significant value to the ctypes
tests, so wouldn't it be best to skip the GLUT lib on OSX? See the
attached patch "test_find without GLUT on OSX" (note that I didn't actually
test the patch, and I don't have access to OSX G5 anyway).
Maybe the problem and the analysis should be reported to the PyOpenGL
project...
File Added: test_find-no-osx-glut.diff
--
Comment By: Skip Montanaro (montanaro)
Date: 2007-06-30 15:17
Message:
Logged In: YES
user_id=44345
Originator: YES
Thomas,
Here's a possible modification to ctypes.test.test_find which appears
to be the only place that OpenGL (and thus CoreData on the Mac?) is
accessed. On Darwin I replace the GL find stuff with Tcl find stuff.
It's a bit ugly, but it might solve the problem.
Skip
File Added: test_find.diff
--
Comment By: Skip Montanaro (montanaro)
Date: 2007-06-30 13:15
Message:
Logged In: YES
user_id=44345
Originator: YES
I submitted a bug report to Apple about the problem, though I don't
really expect a response. (The other bug I filed in 2004 has never
received any response as far as I can tell.) Maybe a more recent
version of SQLite will be delivered with Leopard...
--
Comment By: Skip Montanaro (montanaro)
Date: 2007-06-30 12:42
Message:
Logged In: YES
user_id=44345
Originator: YES
I'll be damned... Based on your last response I ran Python
under ktrace then looked at the kdump output. As it's
marching along it sees a mention of /usr/lib/libsqlite3.so
in /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
then just a few lines later I see
20023 python NAMI "/usr/lib/libsqlite3.0.dylib"
20023 python RET open 3
20023 python CALL fstat(0x3,0xbfffc770)
20023 python RET fstat 0
20023 python CALL pread(0x3,0xbfffcbd0,0x1000,0)
then a bit later I see what I had wanted to see:
20023 python NAMI
"/Users/skip/local/lib/python2.6/lib-dynload/_sqlite3.so"
20023 python RET open 6
20023 python CALL fstat(0x6,0xbfff9c00)
20023 python RET fstat 0
20023 python CALL pread(0x6,0xbfffa060,0x1000,0)
...
20023 python NAMI "/Users/skip/local/lib/libsqlite3.0.dylib"
20023 python RET open 6
20023 python CALL fstat(0x6,0xbfff99b0)
20023 python RET fstat 0
20023 python CALL pread(0x6,0xbfff9e10,0x1000,0)
I can't execute the CDLL call if I've renamed
/usr/lib/libsqlite.3.0.dylib. (I suppose that stands to
reason.)
Now the question becomes whether or not the Apple-provided
library can be replaced with something more modern.
Presumably every application that uses CoreData (most
Apple things) gets it if during startup.
Thomas, for the purposes of the Python regression test
suite do you think you can find something other than
GLUT to dynamically load?
Mark, thanks for the sleuthing.
Skip
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-06-30 05:56
Message:
Logged In: YES
user_id=703403
Originator: NO
It looks as though GLUT is a red herring. I can reproduce the problem
with a variety of frameworks in place of GLUT, for example Quartz, Cocoa,
AppKit, CoreData, as in the following lines.
import ctypes
ctypes.CDLL('/System/Library/Frameworks/CoreData.fram
[ python-Bugs-1748064 ] inspect.getargspec fails on built-in or slot wrapper methods
Bugs item #1748064, was opened at 2007-07-04 14: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=1748064&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 Private: No Submitted By: Michael A. Hawker (hawkerm) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getargspec fails on built-in or slot wrapper methods Initial Comment: Hi, I'm new here, but I'm running into a little trouble with complex introspection techniques. I'm using Windows XP SP2 on an AMD64 chip. Tying to do some introspection on base types provides little information about the function as getargspec will not accept the slot wrapper or a built-in function as an argument (see attached interpreter trace). i.e. when trying to analyze functions such as list.remove, list.__getitem__, len, etc... This seems like abnormal behavior as it seems contrary as these are methods and functions, and the help function (while only providing the doc string) still provides information about the function, only in a different harder to parse format. Do I need to make a stronger argument? It would be very useful for the work I'm doing. Attached is a trace of various scenarios involving this issue and how it seems contrary to the expected behavior. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1748064&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1581906 ] test_sqlite fails on OSX G5 arch if test_ctypes is run
Bugs item #1581906, was opened at 2006-10-21 13:02 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: test_sqlite fails on OSX G5 arch if test_ctypes is run Initial Comment: I noticed a test_sqlite test failure on my Mac G5 the other day while trying to set up a buildbot for sqlalchemy. Everything runs fine on my G4 powerbook. Both machines run Mac OSX 10.4.8 with Apple's gcc 4.0.0, build 5026. I whittled the problem down to just having test_ctypes and test_sqlite enabled, then further whittled it down to just having Lib/ctypes/test/ test_find.py available (all other ctypes tests eliminated). More detailed problem descriptions are in these two postings to python-dev: http://article.gmane.org/gmane.comp.python.devel/84478 http://article.gmane.org/gmane.comp.python.devel/84481 Skip -- >Comment By: Skip Montanaro (montanaro) Date: 2007-07-04 20:31 Message: Logged In: YES user_id=44345 Originator: YES Certainly the patch is simpler. ;-) If loading GLUT doesn't add any value on OSX, would it add any value on other platforms? Do other tests have to find libraries successfully to pass? If so, maybe test_find should be dispensed with altogether, however if test_find has value we should figure out a library to load on OSX. -- Comment By: Thomas Heller (theller) Date: 2007-07-04 15:01 Message: Logged In: YES user_id=11105 Originator: NO Skip, thanks for the analysis and test patch. IMO loading the GLUT library does not add significant value to the ctypes tests, so wouldn't it be best to skip the GLUT lib on OSX? See the attached patch "test_find without GLUT on OSX" (note that I didn't actually test the patch, and I don't have access to OSX G5 anyway). Maybe the problem and the analysis should be reported to the PyOpenGL project... File Added: test_find-no-osx-glut.diff -- Comment By: Skip Montanaro (montanaro) Date: 2007-06-30 08:17 Message: Logged In: YES user_id=44345 Originator: YES Thomas, Here's a possible modification to ctypes.test.test_find which appears to be the only place that OpenGL (and thus CoreData on the Mac?) is accessed. On Darwin I replace the GL find stuff with Tcl find stuff. It's a bit ugly, but it might solve the problem. Skip File Added: test_find.diff -- Comment By: Skip Montanaro (montanaro) Date: 2007-06-30 06:15 Message: Logged In: YES user_id=44345 Originator: YES I submitted a bug report to Apple about the problem, though I don't really expect a response. (The other bug I filed in 2004 has never received any response as far as I can tell.) Maybe a more recent version of SQLite will be delivered with Leopard... -- Comment By: Skip Montanaro (montanaro) Date: 2007-06-30 05:42 Message: Logged In: YES user_id=44345 Originator: YES I'll be damned... Based on your last response I ran Python under ktrace then looked at the kdump output. As it's marching along it sees a mention of /usr/lib/libsqlite3.so in /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData then just a few lines later I see 20023 python NAMI "/usr/lib/libsqlite3.0.dylib" 20023 python RET open 3 20023 python CALL fstat(0x3,0xbfffc770) 20023 python RET fstat 0 20023 python CALL pread(0x3,0xbfffcbd0,0x1000,0) then a bit later I see what I had wanted to see: 20023 python NAMI "/Users/skip/local/lib/python2.6/lib-dynload/_sqlite3.so" 20023 python RET open 6 20023 python CALL fstat(0x6,0xbfff9c00) 20023 python RET fstat 0 20023 python CALL pread(0x6,0xbfffa060,0x1000,0) ... 20023 python NAMI "/Users/skip/local/lib/libsqlite3.0.dylib" 20023 python RET open 6 20023 python CALL fstat(0x6,0xbfff99b0) 20023 python RET fstat 0 20023 python CALL pread(0x6,0xbfff9e10,0x1000,0) I can't execute the CDLL call if I've renamed /usr/lib/libsqlite.3.0.dylib. (I suppose that stands to reason.) Now the question becomes whether or not the Apple-provided library can be replaced with something more modern. Presumably every application that uses CoreData (most Apple things) gets it if during startup. Thomas, for the purposes of the Python regression test suite do you think you can find something other than GL
